Viewing 5 replies - 1 through 5 (of 5 total)
  • Plugin Author Jan-Peter

    (@starguide)

    Hi Gerd,

    please try the option “Local API not reachable in root.” / “Lokale API nicht über das Stammverzeichnis erreichbar.” on the statistic tab.

    Cheers,
    JP

    Thread Starter gerd.neumann

    (@gerdneumann)

    Hi JP,

    thanks for the very(!) quick reply. Yes, this fixed it. Thank you!

    May I ask why this setting is necessary, that is, why isn’t siteurl detected automatically. I am asking because I actually noticed the problem on my test/stage system (where there is a prefix) but on the live system there is none. And I would not like to change settings between the both unless totally necessary but rather have these in sync.

    Plugin Author Jan-Peter

    (@starguide)

    Hi Gerd,

    the reason is, that by default the WP REST API is always reachable under the direct /wp-json/ path – regardless if it is installed in a subdirectory or not. Even more, it is only reachable there. That’s because it is not a real path, rather than it is using the pretty permalinks function. So on a default subdirectory install the site url would deliver the path my-domain.com/subdirectory-including-wordpress/wp-json/… and would produce a 404, because the WP REST API is only reachable under my-domain.com/wp-json/. So always using the site url would actually break the function on all standard subdirectory installations.

    I added the option mentioned above to take care of cases, in which, for whatever reason, the installation differs from the default subdirectory install. That can be the case on local development environments or if the rewrite rules for the installation are set in a non standard way or if there is a problem with the pretty permalinks function.

    Cheers,
    JP

    Thread Starter gerd.neumann

    (@gerdneumann)

    the reason is, that by default the WP REST API is always reachable under the direct /wp-json/ path – regardless if it is installed in a subdirectory or not.

    Thanks for answering. This sounds like a really strange design decision by WordPress. Do you have a link on this and why it’s been done like that? Couldn’t find anything on the web about it?

    Say WordPress only lives under /blog/ and anything else is nothing it should concern/care about. Still the REST API endpoint is moved to outside of its “territory” to the root. What’s wrong about /blog/wp-json/? (Not meaning/offending you, but since I couldn’t find anything on the web, maybe you have a link/pointer? Short answer would be sufficient, don’t waste too much time on this.).

    Plugin Author Jan-Peter

    (@starguide)

    Hello Gerd,

    I added the WordPress home_url() as another fallback in 4.2. I know this is a bit confusing, but the home_url is what is labeled “Site Address (URL)” in the WordPress admin area. The home_url is actually the one that should work 90 percent of the time, while the site_url is the one that is labeled “WordPress Address (URL)” in the admin area. This one is used, when you check that above mentioned option.

    If you find the time, please test the new version 4.2. It should now work out of the box for both of your types of installation. Of course you need to remove the above mentioned option first. I kept the option in case someone needs to force WordPress to use the site_url version.

    Cheers,
    JP

Viewing 5 replies - 1 through 5 (of 5 total)
  • The topic ‘share counts XHR does not respect 'siteurl' resulting in "404 Not Found"’ is closed to new replies.