Gutenberg: Gutenberg breaks completely if site URL is not the same as wordpress URL

[hedgefield]

Issue Overview

I have wordpress installed on domain1/subdirectory, but I set up an addon domain (domain2) to be the main way to visit the site. Wordpress supports this by allowing you to change the _site address_ to be different from the actual _wordpress address_ in settings. However, this breaks gutenberg entirely because of WP-NONCE.

Steps to Reproduce (for bugs)

1. Get a hosting account and a domain (domain1)
2. Install wordpress in a subdirectory
3. buy another domain (domain2)
4. set domain2 as addon domain, pointing to domain1/subdirectory (because I want people to end up on domain2/permalink-to-post, not domain1/subdirectory/permalink-to-post
5. install gutenberg
6. open gutenberg (new post or demo, doesn't matter) and see a white screen
   

Expected Behavior

For gutenberg to function as intended (or even load at all).

Current Behavior

Because the site URL and the wordpress URL differ, loading gutenberg throws the following errors:

XMLHttpRequest cannot load http://<domain1>/wp-json/wp/v2/. Request header field X-WP-Nonce is not allowed by Access-Control-Allow-Headers in preflight response.

GET http://<domain1>/wp-json/jetpack/v4/jitm?message_path=wp%3Agutenber…erg-demo%3Aadmin_notices&query=page%253Dgutenberg-demo&_wpnonce=49a5b82bc9 403 (Forbidden)

Related Issues and/or PRs

I've had contact with Automattic about this before, because gutenberg is not the only thing that breaks. Jetpack has been broken on my site for a long time. And the Customizer, too, does not work at all in a setup like this. Neither does Yoast's onboarding wizard and text link counter tool.

They told me this was related to a wontfix in core:
https://github.com/WP-API/WP-API/issues/1898
https://core.trac.wordpress.org/ticket/34921

The above could be lived with (I have for some years now), but if the core editor in wordpress breaks, that's another story.

First question: is there a better way to create this setup (without getting a second hosting account)? If so, that might render the problem moot (at least for me).
Second question: If not, what can be done about this?

[kraftbj]

For the sake of testing, what plugin are you using for the domain mapping or are you simply setting different domains in Settings->General?

[hedgefield]

Yes, I've changed it in settings. The domain itself is marked as an addon domain via Godaddy (so at the host level). I could grant someone access to my backend if it's hard to reproduce.

[nylen]

cc @rmccue - anything we can do about this? Seems like we should fix this case in general

[hedgefield]

☝️ bump.

[hedgefield]

Tested again today with v0.7.1, and the editor appears! Typing, inserting, adjusting settings, it seems to work. That's a big improvement, so great job, whoever has been working on this!

Only thing now is that I cannot save.

When it tries to autosave, it says "updating failed" and throws this error in the console (the ones with the numbers in front):

Same for manual saving. Demo post, new post, doesn't matter.

[hedgefield]

Tested again today with 1.8.1, and the editor appears for a brief moment, then the whole screen goes white, with these errors in the console:

[youknowriad]

I believe the hasClass error here is a metabox related issue that has been fixed. Could you reproduce this with the latest changes?

[hedgefield]

No, so that's fixed in 1.9.1. :+1: Now I'm back to the nonce errors during saving attempts. :upside_down_face:

[devjack]

I too have encountered this. The workaround seems to be getting the WP API to include "X-WP-Nonce" in the "Access-Control-Allow-Headers" header.

Something like this in a theme/plugin gets me a step further.

add_action( 'rest_api_init', function() {
    remove_filter( 'rest_pre_serve_request', 'rest_send_cors_headers' );
    add_filter( 'rest_pre_serve_request', function( $value ) {
        header( 'Access-Control-Allow-Headers: Authorization, X-WP-Nonce');
        header( 'Access-Control-Allow-Origin: *' );
        header( 'Access-Control-Allow-Methods: POST, GET, OPTIONS, PUT, DELETE' );
        header( 'Access-Control-Allow-Credentials: true' );
        return $value;  
    });
}, 15 );

Unfortunately, this leads me to get 403's on the API auth with an invalid nonce. My guess is that the different site_url invalidates the none. That would follow since the logged_in session cookie seems to be used in the validity check for the nonce. TLDR; I'm assuming API calls must be made to and from the same domain as the API for a valid nonce.

Given that the same install is running WP I wonder if gutenberg could somehow wrap get_rest_url() and encourage it strongly to return the current wp-admin hostname for API discovery (similar to renaming the base path via rest_url_prefix?

Since this is outstanding for a few months, I'm reproducing in current Gutenberg 2.2.0.

[doug-gv]

Experiencing this on my production blog right now. We serve on a subdomain and mount on our app using a reverse proxy. Some resources also seem to have problems.

Current workaround is to export from a staging blog, then import and publish using classic editor.

[danielbachhuber]

Hi folks,

Given the impact of this issue was a deliberate design decision for the REST API, it doesn't seem like something we're going to address in core at this point. Those affected by this issue can mitigate it by sending custom headers.

Let's move any future discussion back to the core Trac ticket: https://core.trac.wordpress.org/ticket/34921

[Savageman]

Here's what I did to make it work (I only have 1 site):

add_filter('rest_url', function($url) {
    $url = str_replace(home_url(), site_url(), $url);
    return $url;
});

[TWGerard]

This issue is breaking a production site for me now too. Thanks WordPress.

[guidevine-devops]

I can't imagine this is an uncommon use case.

1. I have a blog on wordpress
2. I want that blog to appear on my railswebsite.com/blog/slug

There's gotta be a way!

Right now we publish to Netlify, slurp down the static files with their end point distributed resources, and then save them to our public/blog directory

[charlestonsoftware]

An article on configuring nginx for sites that are installing WordPress in a subdirectory and have "pretty permalinks" (anything but 'Plain' permalinks set) in use. I found you must not only account for "pushing" requests to serve content to the /subdir/ via the web config but also rewrite the /wp-json/ URIs.

http://lance.bio/2019/02/12/nginx-installing-wordpress-in-a-subdirectory/

HTH.

[doug-gv]

Thanks for the tip. The problem is not that we can't mount the blog on our domain, it's that Gutenberg editor breaks when you do this — can't CRUD any blog posts. Do you know if this has an effect?

[rahulkhosla]

I found a CORS policy guide for a similar issue I was having — which seemed to work perfectly! 👍

It basically mentioned to the same URLs (www / non-www) in your code.

Hope this helps someone else too.

[Kelderic]

Here's what I did to make it work (I only have 1 site):

add_filter('rest_url', function($url) {
    $url = str_replace(home_url(), site_url(), $url);
    return $url;
});

I tried this with WP 5.2, and it did not work. However, after combining it with what I saw here, it did work!

add_filter('rest_url', function($url) {
    $url = str_replace(home_url(), site_url().'/index.php', $url);
    return $url;
});

[SirLouen]

I tried this with WP 5.2, and it did not work. However, after combining it with what I saw here, it did work!

add_filter('rest_url', function($url) {
    $url = str_replace(home_url(), site_url().'/index.php', $url);
    return $url;
});

Have you used multiple domains for this? Not working for me, same errors as the one stated in the issue.

[Kelderic]

I tried this with WP 5.2, and it did not work. However, after combining it with what I saw here, it did work!

add_filter('rest_url', function($url) {
    $url = str_replace(home_url(), site_url().'/index.php', $url);
    return $url;
});

Have you used multiple domains for this? Not working for me, same errors as the one stated in the issue.

I have only used it for one site, which was a local installation. Not sure if that would make a difference.

[SirLouen]

I have only used it for one site, which was a local installation. Not sure if that would make a difference.

Which was your issue exactly with more precision to have some context?

[Kelderic]

Which was your issue exactly with more precision to have some context?

I have a WP installation that is installed not in the direct web root folder, but in a sub folder called 'www'. GutenBerg wasn't updating. It was throwing an error, because the API wasn't responding properly.

[SirLouen]

I have a WP installation that is installed not in the direct web root folder, but in a sub folder called 'www'. GutenBerg wasn't updating. It was throwing an error, because the API wasn't responding properly.

But this doesn't seem to have anything to do with OP issue.

[Kelderic]

I have a WP installation that is installed not in the direct web root folder, but in a sub folder called 'www'. GutenBerg wasn't updating. It was throwing an error, because the API wasn't responding properly.

But this doesn't seem to have anything to do with OP issue.

The site URL not matching the home URL happens when the site is installed in a sub folder.

[SirLouen]

The site URL not matching the home URL happens when the site is installed in a sub folder.

But in your case the issue is related with a subfolder with the same domain.
The op scenario is based on two different domains, which seems to be a completely different case.
I happen to have the same config as the OP (two domains) and the rest_url filter doesn't solve the issue.

By the way, I've tested

add_filter('rest_url', function($url) {
    $url = str_replace(home_url(), $_SERVER['HTTP_REFERER'].'index.php', $url);
    return $url;
});

And doesn't work either, home_url is domain1.com and $_SERVER['HTTP_REFERER'] is domain2.com but the

Request header field x-wp-nonce is not allowed by Access-Control-Allow-Headers in preflight response.

Is still there

[doug-gv]

Moved to SquareSpace, and used a different domain. Problem solved. Can't
wait to never use WP again.
Wordpress is simply not worth the hassle and cost of ownership. May the
universe save your souls.

On Tue, Jan 14, 2020 at 6:08 AM SirLouen [e-mail] wrote:

The site URL not matching the home URL happens when the site is installed
in a sub folder.

But in your case the issue is related with a subfolder with the same
domain.
The op scenario is based on two different domains, which seems to be a
completely different case.
I happen to have the same config as the OP (two domains) and the rest_url
filter doesn't solve the issue.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/WordPress/gutenberg/issues/1761?email_source=notifications&email_token=AEZYYLJDIGYDPPBLXRRROXDQ5XBMZA5CNFSM4DR6FZ32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEI4XIAQ#issuecomment-574190594,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEZYYLKGDDUXPV5UJHFZWSTQ5XBMZANCNFSM4DR6FZ3Q
.

[isuke01]

Will it be ever fixed?
I have tested rest_url and it looks correct, but for some reason Gutenberg doing incorrect requests =,="

[callum-veloxcommerce]

It is absolutely bizarre that Gutenberg API calls are calling the site URL instead of the Wordpress installation URL!

Whats the point of having these 2 seperated fields if it doesnt even serve its basic purpose. It is leaving us unable to use the WP REST API as a standalone headless content service and still be able to preview and click links in the editor to view your posts, it is not user friendly at all. Seems such a simple issue to fix and this issue seems to have been open for a long time.

[TWGerard]

I haven't used WordPress in years, surprised to hear that this super basic
thing is still an issue. Happy to have moved on!

On Thu, Apr 9, 2020 at 8:07 AM Callum Carolan [e-mail]
wrote:

It is absolutely bizarre that Gutenberg API calls are calling the site URL
instead of the Wordpress installation URL!

Whats the point of having these 2 seperated fields if it doesnt even serve
its basic purpose. It is leaving us unable to use the WP REST API as a
standalone headless content service and still be able to preview and click
links in the editor to view your posts, it is not user friendly at all.
Seems such a simple issue to fix and this issue seems to have been open for
a long time.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/WordPress/gutenberg/issues/1761#issuecomment-611492501,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABLSIMMUNKBRSPFYUXWG3VLRLW27XANCNFSM4DR6FZ3Q
.