poljpocket

Yep, see the first two screenshots in my post above 😁

And even more. This is how the page names and titles show up in the database. Looks like it is using some non-standard punycode to encode the names and this is also where everything seems to break:

Some more peculiarities which might help us:

There you go running on the same test install from above: You are on to something here.. that looks very inconsistent! Note how the page name in the log message is always correct but shows wrong in the "Settings" tab.

You are right, copy-pasta mistake. I just copied your stuff over. But I corrected it right now and it doesn't make a difference (and yes, it's only about the rewrite rules and doesn't affect the PW admin in any way). Maybe you will find something with the hooks I have talked about above.

You can maybe start by looking into where the problem occurs. You can for example use Tracy's bd() function to output the page name before and after every saveReady and saved hook. This will at least let you see in which part of the code you have to go dig for more. Do you have any hooks already in use for Page::saveReady and Page::saved? On which PW version are you?

You are obviously right! I am sorry... I tried your settings in a quick-and-dirty local Docker install using the blank site profile. I can use your whitelist no problem: This is what I added to the files:

This uses the PageNameTranslate rules which you can configure in Modules > Configure > InputfieldPageName. By default, it will replace ä with a, ö with o and ü with u. One of the first things I change on new sites. BTW: @bernhard's RockMigrations has an automation for this.

Did this site - by any chance - reside on a Mac at some point? Mac file systems sometimes pull strange stuff like that (e.g. a meta file with a dot in front, but the exact same filename otherwise). ProcessWire just looks at everything in the modules directory and gets confused by that.

Well, what I mean is that your deployments function won't work on any installation which needed the .htaccess edited (= comment out FollowSymlinks line) for ProcessWire to run properly. If you are checking for symlink function and work around it if it's not available, I retract everything I said :).

I am seeing the same as OP on many of our hosting partners: Some just won't allow you to use FollowSymlinks. Ever. This renders your plugin unusable on these installations. You should maybe mention this in your docs somewhere...

That's very sad to hear.. I used to use Linux during my university days (15 years ago) because for computer science, it just made the most sense. Later, I used Windows mainly because I was forced to do so at work (in the past). So finally, I decided to again move away from Windows right about when Microsoft really added an unbearable amount of bloat and tracking bulls*** with Windows 10 and later on 11. I first went with Manjaro because I thought it was an easy introduction to the "Arch way" but that was a mistake: Manjaro is still very opinionated and does a few things which didn't work for me. So this isn't any different to just using Ubuntu with pacman. So I took the courage and went full Arch. Installation isn't too bad if you know your way around the command line. Since I was using WSL on Windows and used to run Linux for years before, this isn't a problem for me. I must say, I have never looked back. Arch isn't very plug-and-play, that's true. But also, it doesn't stand in your way. Back then, I even moved my work PC to Arch after a few weeks because I got very confident with using it at home. There also, I never looked back: Everything is just faster and especially when your machine is idling, it is actually not doing anything. Ever. Gone are random "jetplane takeoffs" and slowdowns (search indexing, updates, antivirus). Also, on my Laptop, the battery lasts forever longer than with Windows. Right now, I am using a simple GNOME desktop environment on top of Arch. I am using PHPStorm and Docker CE for local development. All of these are just a few package installs away. No need to mention that web development is just so much easier on Linux. For my work scenarios: Printers are basically plug-and-play with Linux (much more than Windows!). Same for SMB shares on the network. Microsoft 365 has 99% of it's features in their web apps these days (Outlook, SharePoint, Excel, Word, ...), even Teams works perfectly as long as you are not using Firefox. What am I missing? Basically nothing important! There are a few very small things. One example: We have a Miracast thing in the conference room to share our screens to which just doesn't work for Linux. No biggie, because there is also a HDMI cable 🙂

Not that this will solve your problem or have anything to do with it, but I can see a <head> tag inside another <head> tag when looking at your source code. W3C validity check brings some more problems to the surface, especially with your meta tags: https://validator.w3.org/nu/?doc=https%3A%2F%2Fzar.co.com%2F You could try fixing at least everything in <head> and try again.

How would your structure look like in WordPress?

For such cases, even more readability: $wire->addHookAfter('Pages::saveReady(template=news)', function($event) { // [...] } This way, the hook doesn't even get called if template isn't news. Also, I think you can even get rid of the second guard clause like this: $wire->addHookAfter('Pages::saveReady(template=news,day!=)', function($event) { // [...] } If the page doesn't have a day field, the selector doesn't match and the hook isn't called. This is untested though 😊