poljpocket

@netcarver wow, perfect! It is exactly that. I have switched to the UTF8 line and changed $config->pageNameCharset over to UTF8. Now it works perfectly. Even without any funky regex. So follow-up question: Now, for new pages, the translation rules in InputfieldPageName are disabled - makes sense because we get UTF8 pages names now. I guess we can have one of the two worlds, right? We absolutely don't want non-ascii page names on the new website. I guess I have to resort to some other form of redirecting outside of PW to accomplish both at once?

Dear community, I am having a strange problem for which I don't have the time to investigte in detail and I'm hoping someone might know why that is or if this is simply something PW cannot do at all. We have some redirect rules for a client's site which we have redone matching old URLs to new ones. In one of the rules - for blog posts, they are having German Umlauts (öäü) in their URLs (sometimes, but not always) which we need to redirect. There are a lot of posts and hard-coding every one of them is simply unfeasible. So I came up with this simple hook to solve all of the blog redirects at once. It works like a charm as long as there are no Umlauts in the URL. <?php namespace ProcessWire; /* this is in ready.php */ $wire->addHook('/post/(post_slug:[\wöäü]+)/?', function(HookEvent $hookEvent) { // find a matching to redirect to, or fall back with a 404 $post = $hookEvent->arguments('post_slug'); $postTranslated = $hookEvent->sanitizer->pageNameTranslate($post); $requestedPage = $hookEvent->pages->get('name=' . $hookEvent->sanitizer->selectorValue($postTranslated)); if ($requestedPage->id) { $hookEvent->session->redirect($requestedPage->url); $hookEvent->return = true; } else { $hookEvent->return = false; } }); The page name translation and funky regex are me trying to get the regex to match with Umlauts. But the problem is somewhere else because the hook doesn't get called at all if there are non-ascii characters in the URL. Does someone know more details about this? Thank you a lot!

Thanks for asking. I have to be honest, it wasn't clear why then and still isn't now. I have looked up the project in question and cannot replicate it anymore with the most recent code base. This project makes heavy use of vue.js for the frontend which lead to several problems with Tracy in the frontend. We ended up just disabling Tracy for the frontend and everything was fine and we stopped looking into it as it did no longer matter. If I'm enabling it now, everything is fine.

Page sure does have a changed() method. https://processwire.com/api/ref/wire/changed/

Still, this is what's happening on your live version, right? And it all works on your local environment? There must be a difference in the systems which leads to this difference in behavior. Let me also ask this. Is there a specific reason you don't use a simpler approach like this (careful - untested): <?php namespace ProcessWire /** * @var Wire $wire */ $wire->addHookBefore('Page(template=booking)::changed(tickets)', function($event) { $page = $event->object; $oldValue = $event->arguments(1); $newValue = $event->arguments(2); // [...] } Or like that (again careful - untested; if you don't care about the old value): <?php namespace ProcessWire /** * @var Wire $wire */ $wire->addHookBefore('Pages::saveReady(template=booking)', function($event) { $page = $event->arguments(0); if ($page->isChanged('tickets')) { $newValue = $page->tickets; // [...] } }

Line 126 is the $languages API variable seemingly being empty. Line 340 is about the language translation files, but must be of the same origin. This is all I can read from your context. We need more to help.. did you follow the steps to install the modules in order? Does this also happen on a fresh install of PW?

Ok, I tried to reproduce your situation locally on Docker. There are two languages "default" and "other". I have used site-blank as template and just added a TinyMCE ML field for body and added it to basic-page. Also, I changed the title field to be ML. PW version is 3.0.227 and PHP version is 8.2.18. Here's the result after I have changed nothing and just hit "Save" (same result when I change something): And here is the relevant code I used. I tried to stay as true to your code as possible. ready.php <?php namespace ProcessWire; if(!defined("PROCESSWIRE")) die(); /** @var ProcessWire $wire */ $wire->pages->addHookAfter('Pages::saved(template=basic-page)', 'hookPageSaved', ['priority' => 200]); function hookPageSaved(HookEvent $event) { $wire = $event->wire; $page = $event->arguments(0); // get the saved page // save current settings $saved_lang = $wire->user->language; $saved_user = $wire->user; $saved_output_formatting = $page->of(); // set current user to guest user $wire->users->setCurrentUser($wire->users->getGuestUser()); $page->of(true); $json_data = []; foreach ($wire->languages as $l) { $lang_name = $l->name; // set current language for rendering the page $wire->user->language = $l; // get rendered json data as string $markup = $page->render(); $json_data[$lang_name] = json_decode($markup); } // restore saved settings $page->of($saved_output_formatting); $wire->users->setCurrentUser($saved_user); $wire->user->language = $saved_lang; // write the JSON data to Tracy bd($json_data); } basic-page.php <?php namespace ProcessWire; /** @var Page $page */ $json_data = []; $json_data['headline'] = $page->title; $json_data['text'] = $page->body; header('Content-Type: application/json'); echo json_encode($json_data); Note two differences: I have restricted the hook to only fire for pages with template basic-page (as this would throw a bunch of errors in the Admin otherwise) I am not using a module to add the hook Maybe this sheds some light into the situation.

@flydev is implying that just a difference in $debug configuration or the module TracyDebugger being active or not can make some difference in how PW works in cases as peculiar as yours. That's why you need to make sure your environment is actually identical not just with PHP versions and database versions. We've experienced some problems/differences with Tracy messing up the frontend only when it's enabled (not even necessarily showing it's panels). Also that's why I suggested you make a carbon copy of your local install and try to run it somewhere else and look for anything that's changed to rule out it being your code or make sure it actually is your code and not something external and out of your control.

Looking through your other posts again, it seems like your hosting provider does have some problems and actually might be the culprit. We have had some peculiarities with some of them as well. I would suggest you try a completely different provider just to try out your install and make sure it's not the server it's on. So many differences in two systems is very unusual. You can use @flydev's Duplicator module to move it from local to this new environment. ? If you don't have access to something like that, pm me. I have a VPS with a known-good PW environment ?

Is your module configured as autoload? Also, as @flydev beat me to the punch, I assume this is some sort of an execution order problem you are having. My question is exactly about that... any non-autoload module actually gets loaded and initialized only on-demand, e.g. only at a certain point down the road when you are actually using it (in a hook for example) which might be after PW decides which PageClass to use. Also, gathering from your other posts, config.php might be too early in the OOE and ready.php might be too late. EDIT: I have had these problems in the past. I took on the whole PW core in an afternoon in order to understand how stuff works and especially, how PW works under the hood. This shed a ton of light into how to do things and where to hook into. Right now, if I am having a problem, I am just looking at the actual source code as my documentation.

Can you also provide the code for your template file (the one which gets used by the render()-function)? Also just a side note: Is there a reason you are generating JSON in the render file, decoding it just to pass it along and re-encode it again?

Then your function is the wrong way around. You are looking for outgoing links but the function gives you incoming links. Try (untested): <?php namespace ProcessWire; // Get all relevant pages directly in one query $relevantPages = $pages->find("template=post|service|home"); $blogPosts = $relevantPages->find("template=post"); $mainPages = $relevantPages->find("template=home|service"); /** @var PageArray $mainPagesLinks */ $mainPagesLinks = $wire->wire(new PageArray()); foreach ($mainPages as $mainPage) { // this will remove duplicates by default $mainPagesLinks->append($mainPage->links("template=post")); } // echo results foreach ($blogPosts as $post) { if (!$mainPagesLinks->has($post)) { echo "<tr>"; echo "<td><a href=\"{$post->url}\">{$post->title}</a></td>"; echo "<td><a href=\"{$post->editUrl}\">Edit</a></td>"; echo "</tr>"; } }

I have added to my post above. Maybe this is the reason?

You should make sure that the links you are looking for actually apply to the restrictions of the links() function in $page. The docs state that this, quote: Does this shed some light? Also, and most important: I think you are using it the wrong way around. The function docs headline is "Return pages linking to this one (in Textarea/HTML fields)". Now, you want pages with no outgoing links to some other pages whereas as I understand it, the links() function gives you incoming links from other pages. So to achieve your goal, you should make a set of pages by calling the links() function on your $relevantPages and check if your post page is in the set.

Since FormBuilder is a paid module, you should seek help in it's forum areas on this website. You need an active license to see the subforum I am talking about.

Following the code for InputfieldFile, if you have set it to maxFiles: 1 and replace: true, the old file should be deleted. See around here in the code.

Sorry if that wasn't clear: Simple approach with as little inter-dependencies as possible and editors will copy over content if needed.

Just adding my two cents about experiences with this sort of thing: No matter how many times you discuss things with clients to create beautiful solutions to exactly these problems, there will always be a point where you run into flexibility problems if you start combining things and creating complex dependencies too much. Yes, usually this means more work for content management but also, this usually costs less in the long run because of exactly that reason. It is always easier to use said page tree option and for us, after many many projects which needed adjustment down the road - or even a rework to finally use the page tree option, we just never think about this anymore at all.

Just off the top of my head, and completely without testing: From my knowledge of the PW internals, shouldn't you wire the newly created page? call the save() or pages->save() function?

Sure ? https://processwire.com/docs/fields/select-options-fieldtype/#multi-language-translating-options

Can you post your exact code lines where the sort "doesn't work"?

@Gideon So I beg to differ on that assumption. Pageimages is a WireArray and thus will have a sort() function. See here: Pageimages class - ProcessWire API. @biber You can find the API for sort() here: WireArray::sort() method - ProcessWire API. There is no rsort() function, but sort() can still reverse the order like so: $images = $page->images->sort("-iname_".$order, SORT_NATURAL |SORT_FLAG_CASE); note the "-" (minus) in front of the field name. Here is another approach: $images = $page->images->sort("iname_".$order, SORT_NATURAL |SORT_FLAG_CASE)->reverse(); This is using the reverse() function of WireArray, whose docs you can find here: WireArray::reverse() method - ProcessWire API

Have you tried uploading with these modules disabled, or in fact any custom modules altogether? This might help us narrow down the issue a bit...

The issue has been discussed and closed directly on GitHub.

I have opened an issue on GitHub since this would be the right place to discuss this: https://github.com/processwire/processwire-issues/issues/1885