Title: API Request automatically changing Permalinks?
Last modified: February 17, 2018

---

# API Request automatically changing Permalinks?

 *  Resolved [nr2012](https://wordpress.org/support/users/nr2012/)
 * (@nr2012)
 * [8 years, 3 months ago](https://wordpress.org/support/topic/magic-api-request-automatically-changing-permalinks/)
 * I hope someone can restore my view of the world again.
 * We had a running webpage with wordpress, where we accessed the data via WP REST
   API. We experience this very very strange behaviour:
 * For example on the startpage: we have set the permalink to mydomain.com/home/
   
   But the page itself is called “Startseite”. That is good and it worked well.
 * But since just a recent time when accessing the API (…/wp/v2/pages?per_page=1000)
   the permalink is overwritten with the page title:
    resulting in mydomain.com/
   startseite as permalink.
 * Due to the fact that we have quite some logic attached to the permalink ‘home’
   our page fails.
 * What we absolutely do not understand is how
    the process of Change permalink 
   > click OK > click Update
 * can be reversed by someone requesting the API (in the moment of request the permalink
   is still in order).
 * Is this a bug of the new WordPress? Or what could cause such a strange behaviour.
 * Thanks for any hints on that…
    Cheers

Viewing 6 replies - 1 through 6 (of 6 total)

 *  Moderator [bcworkz](https://wordpress.org/support/users/bcworkz/)
 * (@bcworkz)
 * [8 years, 3 months ago](https://wordpress.org/support/topic/magic-api-request-automatically-changing-permalinks/#post-9983495)
 * 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: _[http://www.example.conm/](http://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
 *  Thread Starter [nr2012](https://wordpress.org/support/users/nr2012/)
 * (@nr2012)
 * [8 years, 3 months ago](https://wordpress.org/support/topic/magic-api-request-automatically-changing-permalinks/#post-9984084)
 * Thanks for your input. I made a short screen recording, which shows the impossible:
   [https://streamable.com/8p7qy](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.
 *  Moderator [bcworkz](https://wordpress.org/support/users/bcworkz/)
 * (@bcworkz)
 * [8 years, 3 months ago](https://wordpress.org/support/topic/magic-api-request-automatically-changing-permalinks/#post-9985632)
 * 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](https://wordpress.org/plugins/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.
 *  Thread Starter [nr2012](https://wordpress.org/support/users/nr2012/)
 * (@nr2012)
 * [8 years, 3 months ago](https://wordpress.org/support/topic/magic-api-request-automatically-changing-permalinks/#post-9988612)
 * 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
 *  Thread Starter [nr2012](https://wordpress.org/support/users/nr2012/)
 * (@nr2012)
 * [8 years, 3 months ago](https://wordpress.org/support/topic/magic-api-request-automatically-changing-permalinks/#post-9989045)
 * 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
 *  Moderator [bcworkz](https://wordpress.org/support/users/bcworkz/)
 * (@bcworkz)
 * [8 years, 3 months ago](https://wordpress.org/support/topic/magic-api-request-automatically-changing-permalinks/#post-9990758)
 * 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.

Viewing 6 replies - 1 through 6 (of 6 total)

The topic ‘API Request automatically changing Permalinks?’ is closed to new replies.

 * In: [Developing with WordPress](https://wordpress.org/support/forum/wp-advanced/)
 * 6 replies
 * 2 participants
 * Last reply from: [bcworkz](https://wordpress.org/support/users/bcworkz/)
 * Last activity: [8 years, 3 months ago](https://wordpress.org/support/topic/magic-api-request-automatically-changing-permalinks/#post-9990758)
 * Status: resolved

## Topics

### Topics with no replies

### Non-support topics

### Resolved topics

### Unresolved topics

### All topics
