Marcel Stäheli

  • Content count

  • Joined

  • Last visited

Community Reputation

6 Neutral

About Marcel Stäheli

  • Rank
    Jr. Member

Recent Profile Visitors

704 profile views
  1. Marcel Stäheli

    I overlooked that part of the documentation somehow, sorry. Thanks for the help.
  2. I have a search-page that searches through pages using a search term with the selector operator *= . My problem is that sometimes it finds no results eventhough the term I'm looking for is clearly on several pages. It depends on the search term and I can't find no pattern when it finds something and when not. If instead of *= I use the operator %= it always find the results as expected with the same search term. so: body*=zoe finds no results body%=zoe finds every page why is that? What exactly is the difference between the two? The documentation just mentions that %= is slower. I'm running the site on PW 3.0.95, but I also tested it on 3.0.88 with the same behaviour.
  3. Marcel Stäheli

    Thank you for your input. I know about the checkbox, but I don't know what it does. Because my language selector code still listed the deactivated language. Also I could still load every page in that language. That's why I deleted it, to me the checkbox has no effect. I deactivated xdebug per your suggestion and tried to install the module tracyDebugger. But i get this error in PW: Failed to init module: TracyDebugger - Tracy\Debugger::dispatch() called after some output has been sent. Try Tracy\OutputDebugger to find where output started. And now, instead of the nesting level error, when I load a page I get this error: Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 65488 bytes) in C:\xampp\htdocs\site15\wire\core\Functions.php on line 296
  4. I've been working on a multi-language website using xampp. I was preparing the site to be uploaded and wanted to delete my temporary second language, since the site initially will only be in one language. But since I deleted the language I get this error on many pages of the website: Error: Maximum function nesting level of '250' reached, aborting! (line 653 of C:\xampp\htdocs\site15\wire\core\Functions.php) I'm aware that I can set the xdebug maximum nesting level. That's why it says 250, and not the standard 100. I had to increase it before, for something completly unrelated to this (as fas as I can tell) . I increased the value up to 1000 and still get the same error. Whem I add a new second language again, everything works fine. The deletion of the language breaks something. Does anybody have any idea?
  5. Marcel Stäheli

    Thank you both for your reply. I tried it on a fresh installation of processwire and it worked fine as you stated. So it had to be something specific in my project. It couldn't be my templates, I never did anything with the modified and published values besides echoing them. So I had a look at my installed modules. And it turned out that some of them used those values. The module "batch child editor" had the most hits when I searched for the term "published" and after I uninstalled it and edited one of the articles, the two values were diffrent. So I assume something in that modules overwrites the published value every time I edit a page (I never edited those particular articles via that module). I either configurated it wrong (I haven't seen any option that could explain this behaviour though) or it is a bug in the module. I contacted the autor of the module, so he can check it out just in case. I will probably still add a custom date field to be more flexible, thanks for the input.
  6. I'm trying to create a news page. I ran into a problem with the sorting of the pages that are being displayed. I want to sort them by publishing date and it works, but whenever I edit one of the pages, the published and modified values get set to the new date and because of that the sorting order changes. Is this a bug? Do I have to activate something so the the publishing date stays unchanged?
  7. Marcel Stäheli

    The problem was with that particular repeater field. It caused an error in the backend no matter on what page I tried to use it. I recreated the repeater-field with a new name using the same fields as before and populated it with the same content as before. Now it works. No idea what caused that error, I didn't find anything suspicious in the settings of that repeater field.
  8. Marcel Stäheli

    Thanks for your correction, I did not notice. I updated the site to PW 2.8.62 but the error persists, it is on line 222 now though.
  9. Hello there I recently updated a website running PW 2.6.1 to PW 2.8.35. I followed the instructions and everything went fine. The website is being displayed as it should. However if I try to edit the home-page (ID=1) I get this error: Error: Call to a member function getInputfield() on null (line 204 of C:\inetpub\wwwroot\\wire\modules\Fieldtype\FieldtypeRepeater\InputfieldRepeater.module) the code in the file on that line is: /** * Determine if the request is one we should handle (internal) or one that another * script coming after this (external) will handle. * */ $internal = isset($_SERVER['HTTP_HOST']) && realpath(__FILE__) == realpath($_SERVER['SCRIPT_FILENAME']); if(!$internal) register_shutdown_function('ProcessWireExternalShutdown'); The site is running on IIS8. There is another page that uses a (diffrent) repeater field and it can be edited just fine. Is the error cause because the repeater is on the home-page? Any idea how to fix it?
  10. Marcel Stäheli

    @Zeka I forgot to answer, sorry. I solved the first problem: On pages with the same page name in both languages, I only entered a page name in the default language. Normally PW falls back to that name if no name is entered in another language. However if you use localName it doesn't. I just had to enter the same page name in both languages. Second problem: I couldn't get your code to work (I fixed the ')' instead of the '}' ). Something is wrong so I just tried to do it without checking if the tag exists. But I can't get that to work either: $articles = $pages->find("template=article,tag_select=$tagName"); This is supposed to find any article page where the multi-page reference field contains a page with the name $tagName in any language, right? It works only with the default language. As soon as I switch the language, no results. The only tags where I get results are the ones that have the same name in both languages. Since tag_select is a page-reference field, is it the same problem as before? If you search for pages with a certain name it only searches in the default language? If so, how could I search for say page titles within the page reference field?
  11. Marcel Stäheli

    @Zeka Thanks for testing it. I was not precise enough. It works with the default language German. But when I switch to English the query string of a page with the same name in both languages is &tag=. Did you check in both languages? Second question: It is meant as a security check. I noticed that should someone enter a query string manually like &tag=a I get all kinds of pages listed. So I make sure that the tag actually exists. There are probably better ways to do this. But I would still be interested to know what would be the easiest way to use find() to search for name-field values in the current language?
  12. Hello if have a few article pages that have a multi-page reference field with tags about the content of the article. All tags of a given page are displayed and link to a tag-overview page. Every link has a query string added with the tag name like &tag=cars so that I know which articles have to be displayed on the tag-overview page, The tag name is created using $tag->name. Since the website is multi language using German (default) and English, I use $page->localName($language) to get the localized page name . The code looks like this: foreach($tags as $tag) { $tagsMarkup .= "<a href='" . wire('pages')->get('/tags-overview/')->url . "?tag=" . $tag->localName(wire('user')->language) . "'>" . $tag->title . "</a>, "; } The code works mostly fine, but when a page has the same name in both languages, the query string will have no value just ?tag=. Why? A second problem that might be tied to the first: Once on that tags-overview page, I check if the tag actually exists using: $allTags = $pages->get("/tags/")->children); if($allTags->has("name=$tag") {...} But as I read on the forum ( that only checks for name in the default language. It was suggested to use $page->parent->path . "pageNameEnglish" but I'm not sure where and how to use it in my case. Any help?
  13. Marcel Stäheli

    That is so much easier, thank you!
  14. I added some fields to the user template. Among them is a single select field named "country" with a few country names in english and german. If logged in, the user has access to his profil page on the frontend where the fields that he is allowed to change are displayed in a form using the form API. I want to populate the select field with the same options as the field has in the backend. But I can't get it to work: //Getting all Options $fieldCountry = $fields->get('country'); $all_options = $fieldCountry->type->getOptions($fieldCountry)->getValues(); //Creating the field $field = $modules->get("InputfieldSelect"); $field->label = _("Country"); $field->addOptions($all_options); $field->set('initValue', $user->country->title); $form->append($field); Something about the selector for the options is wrong. I got the code from the Select Option Fieltype Page but it didn't work with $field->addOptions(). So I added ->getArray() myself. Now I have a dropdown list on the front end but it's just the numbers instead of the country names. Also I would like the currently chosen country to be the preselected option, So when the form gets saved without any new input, the country doesn't change. How would I do that? My code doesn't work.
  15. I'm nor sure anymore how that admintheme error happend, I think i read an outdated thread on how to customzite it. I copied the AdminTheme Folders from a diffrent project where everything was fine. Still had the problem, then I copied the \wire\templates-admin folder, and that did the trick.Everything is back to normal. Lesson: Never mess with the wire folder. Thanks, I don't think I would have tried that without your input.