API Request automatically changing Permalinks?

Are you saying your home page’s permalink is now appearing everywhere as startseite and not home? How did you get your home page’s URL be “home” in the first place? The WP default permalink for home pages is the domain alone with no slug: https://www.example.conm/

I’m not able to replicate the behavior you’ve observed. API requests never change any permalinks for me.

Generally speaking, it’s usually better to use a page’s ID in conditionals instead of relying on the current permalink structure. A page’s ID can be determined outside the loop with get_queried_object_id(). If the conditional is related to the current home page and not a specific page ID, using is_front_page() is typically the preferred template tag to use. YMMV

Thanks for your input. I made a short screen recording, which shows the impossible: https://streamable.com/8p7qy

I am also not able to reproduce the bevhavior on other pages (same WP, mostly the same plugins)
I deactivated all the plugins which I could (I need to have the plugin Polylang activated, otherwise my REST API endpoint will fail). But even then I have this automatic replacement.

The replacement only happens if this very page data is displayed in an REST API call. Meaning if I change it to ?home??and call /api/wp/v2 (which is equal to wp-json/wp/v2 in our case) there is no effect on the permalink. If I call /api/wp/v2/pages?per_page=4000 which actually displays the data, we have this strange automatic change to ?startseite?.

You are definitely right to use the page ID, but we have a bilingual page and we wanted to have the german home to have the permalink /home and the englisch en/home and then we just check for the home slug for some redirecting. Anyway, the page is built and it worked, we just now experience those problems with this strange behavior.

It can be reproduced by doing this on another computer, and we experienced it the first time when our Netlify build process accessed the api endpoint.

(Just that you are not confused, we are replacing /wp-json/wp/v2 in the url with /api/wp/v2)

I also say that it cannot be any caching issue, due to the fact, that we never had the permalink being ?startseite?. It must have changed at some point and it always takes the pages title as slug.

So is there maybe a setting that forces the permalinks to be just like the page-title?

I really have no explanation for this. At all.

That page was set as your site’s front page? It’s not normally possible to edit front page slugs through admin screens. It could be a Polylang thing allowing it. Have you confirmed the “home” slug works as a HTTP request before it gets corrupted by the API? Your recording makes it look like the slug was never actually saved even though the admin screen made appear so. I believe WP will auto-assign a slug from title if there is not any slug at all in submitted data. It’s possible the slug change value got lost along the submit path somewhere, such that WP auto-assigned the title. Because the admin screen slug name UI is managed with JavaScript, it’s possible for the screen to not reflect what’s happening in the DB. But if a request for the slug “home” works, then it was properly saved.

If you made a different page the site’s front page, does the behavior transfer to the new page or remain with startseite/home? I want to know if the cause is unique to this page or if it’s for any front page.

I’m not that familiar with Polylang, but I believe it does hook into the permalink process, so it is highly suspected to have a hand in this. I get that you need Polylang for custom endpoints to work, but you don’t seem to need to use a custom endpoint to cause the slug to be corrupted. Why couldn’t you do this test with Polylang deactivated?

If manually deactivating all of your plugins is kind of a pain, you can use the health-check plugin’s troubleshooting mode to easily do so without affecting other visitors. Set the “home” slug before doing the troubleshooting. You won’t be able to set front page slugs in the initial troubleshooting mode. I suppose you could if you made a different page the front page, then swapped back after assigning the slug.

The point is to get WP to a completely default mode, where you should find API requests don’t change anything. Your front page will also have no slug at all displayed. It still has one though. You can verify its value by checking the posts table through phpMyAdmin or by requesting the page by “name” query arg. It’ll be rewritten to no slug, but if the requested name is not assigned the request will come back as nothing found. Request by name as in: example.com/?name=home

Once you’ve confirmed nothing is amiss when WP is completely default, activate Polylang only through the troubleshooting admin bar item and retest. If all is still OK, activate your preferred theme (troubleshooting initially activates twentyseventeen), then other plugins one by one until the behavior returns. The last activated module would be the culprit.

Once the responsible module is identified, take up the issue with the devs of that module. They’ll have a better idea of what might be the problem more than anyone. I’m not trying to pass you off to someone else, I’ll continue to help in any way I can. It’s just that someone else could be in a better position to help.

Hi bcworkz

Thanks for your input. This is very helpful.
We did not set the page to ?frontpage? – it’s just a normal page.
And it has nothing to do with the frontpage anyway. I experience this behaviour on all the pages!

I will check the DB entry, but the strange thing is, that accessing the endpoint the first time after saving the slug, the REST API actually returns the correct (changed) slug. Only right after it will be switched back. It is really strange.

The good thing is that we have a completely decoupled backend to our frontend. We generate static htmls including the data, so we can tinker around in the backend as we like.

Anyway. I will try to find out what the polylangs role is in this mess.
Cheers

It was indeed the polylang plugin. It has the rights to change the permalinks, because it has to set the lang tag:

e.g.: the englisch home should have the permalink
/en/home

Obviously something in this process was fucked up. By updating the polylang plugin it fixed the problem.

Thanks for the support and cheers

Fixed by an update? Awesome! ??
This is a good lesson for me and other support people as well. When bizarre behavior is experienced, be sure all packages are up to date. Obvious in hindsight of course, not so obvious when in the thick of troubleshooting with lots of possibilities.