sebibu

Hey @wbmnfktr, thx for taking the time! I think that's the default behaviour of browsers, too. Non ascii characters (like special characters) that are not substituted in ProcessWire are URL encoded by the browser and used for requests. So in Jumplinks broken links should be recognized and redirected as URL encoded Links (under the hood). But unfortunately this does not work: In 404-Monitor links are recognized with URL-Encoded special characters: news/2020-06-26-ich-war-schon-angekommen-bevor-ich-%c3%bcberhaupt-da-war (Better for reading would be the unencoded version, if possible.) When adopting the 404 by click on the corresponding „Request URI“, the URI is shown and saved unencoded in the next step under „Register New Jumplink“. news/2020-06-26-ich-war-schon-angekommen-bevor-ich-überhaupt-da-war These unencoded redirects (created via 404-Monitor) are not working. If manually changed to encoded version it works. On one website a lot. Lot's of news pages with pagetitles (= pagenames) having special characters. Coming from a CMS that allows nearly all special characters that are allowed in the web nowadays. Adding this manually would be really time consuming and error-prone. I assume fixing this should not take that long for a Pro. The most important thing is to preserve the right URL when adopting it from the 404-Monitor.

Hi @Mike Rockett! I Just noticed, that you are unfortunately no longer really active here. 3 weeks ago I created an issue after using your valuable module and having issues with encoded special characters: https://gitlab.com/rockettpw/seo/jumplinks-one/-/issues/5 Is there perhaps a chance that you could take a look at it? Thanks in advance! 🙏👋

Thanks a lot! Will jump in the hooks then..😁

Hey! Is anything still unclear to verify this? If so, what exactly, please?😇

(While the Pages::saveReady-hook is placed in ready.php ...) 1. I click on the save button on the page with pagetitle "Foo!" ich muss los 2. I fire the API $p->save() via TracyDebugger's console and save the page with pagetitle "Foo!" ich muss los. And get a wrong pagename with quot in it where " has been.

What could be the reason generated pagenames via my Pages::saveReady-hook that are initiated by hand over the Processwire backend with a " in the title differs from this fired in TracyDebugger's console via API $p->save(); like this: foreach($pages->find("template!=admin, has_parent!=2, include=all") as $p) { $p->save(); echo "Page {$page->title} (#$p) updated to {$p->name}<br>"; } E.g. Title: "Foo!" ich muss los Pagename via backend: 2025-01-10-foo-ich-muss-los ✓ Pagename via API: 2025-01-10-quot-foo-quot-ich-muss-los ✗ I would expect this to be the same result. Any ideas?

Thanks @bernhard! After shutting down the pc yesterday I got the cause. All pages without news template do not have a saveReady-hook. So for renewing pagenames on pages with other templates I simply have to temporarily create a new hook to set the pagename for other templates, too. Without the prepended news-published-day. Seems to work!☺️🙏🙋‍♂️

A very good hint to use TracyDebugger's console for that, @bernhard! Unfortunately in my tests the pagename is not renewed (or new set if empty) out of the pagetitle! foreach($pages->find("template!=admin, has_parent!=2, include=all") as $p) { $p->save(); echo "Page {$page->title} (#$p) updated to {$p->name}<br>"; } Any idea?👋

I discovered a bug in the pagename generation, see here: https://processwire.com/talk/topic/30444-prepend-date-in-page-name-by-hook-creates-improper-results-on-some-existing-pages/ If there is a final fix, I need to renew / regenerate pagenames out of all pagetitles for all pages of a website. How would you do this? Is there a GUI-way? Or via API with a foreach? With the help of RockMigrations? One pinch: All news pagenames should still be prepended with my hook listed in the forum topic above. Thanks in advance!

😅👍 I created a bug ticket for this: https://github.com/processwire/processwire-issues/issues/2015

Ah, did you tried the „ß“ examples?

Thanks for testing, @poljpocket! Interesting. Consistent inconsistent at least!😉 Yes, I discovered the punycode in the ascii-only name column. But you are right, this seems to be non-standard when I compare it with e.g. with the results from punycoder.com (Punycode converter IDN converter). I wonder whether the conversion to punycode is still appropriate at all!?

I tested a lot the last days also with fresh latest stable installs with blank site profile local in DDEV and on the server. Exported, changed the charset and reimported the database from utf8mb3 to utf8mb4. Now the german special character äöü work, but strangely enough not always!😳🤔 ✓ Die Kölner „Miteinander“ → die-kölner-miteinander ✗ Köln gegen Köln in Köln mit allen Köln Fans – die Kölner „Miteinander“ → köln-gegen-kln-in-kln-mit-allen-köln-fans-die-kölner-miteinander (two missing ö) Furthermore: ✗ Fuß → s (?? should be fuß) ✗ Füße → füsse (should be füße) I thought PageNameTranslate is not used when using $config->pageNameCharset = 'UTF8'; and ß is in the whitelist!? @poljpocket and other: Are you so kind and test if this pagetitles generate the same pagenames in your instances? Thanks a lot!🙏👋

Only one which is only for pages with one determined template. But the problem occurs for pages with all templates and even if the hook is disabled. The newest stable one 3.0.229 All modules up to date.😇 BTW.. PHP mbstring extension is enabled.

Thanks for testing, @poljpocket! Great to see that it is basically working. Testing with a fresh install would have been my next step to narrow it down.👍 Interesting. I see you are using in your .htaccess RewriteCond %{REQUEST_URI} "^/~?[-_/a-zA-Z0-9äöüß.+!*'(),] instead of RewriteCond %{REQUEST_URI} "^/~?[-_/a-zA-Z0-9äöüß.+!*'(),]*$" So *$" is missing, which is necessary only for resolving the page request. Not build the pagename. 👋