New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
hedgefield opened this Issue Jul 6, 2017 · 14 comments

Comments

Projects
None yet
@hedgefield
Copy link

hedgefield commented Jul 6, 2017

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:
WP-API/WP-API#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

This comment has been minimized.

Copy link

kraftbj commented Jul 6, 2017

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

This comment has been minimized.

Copy link

hedgefield commented Jul 6, 2017

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

This comment has been minimized.

Copy link
Member

nylen commented Jul 6, 2017

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

@hedgefield

This comment has been minimized.

Copy link

hedgefield commented Jul 20, 2017

☝️ bump.

@hedgefield

This comment has been minimized.

Copy link

hedgefield commented Aug 7, 2017

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):

screenshot_2

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

@hedgefield

This comment has been minimized.

Copy link

hedgefield commented Dec 5, 2017

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:

screen shot 2017-12-05 at 11 47 13

@youknowriad

This comment has been minimized.

Copy link
Contributor

youknowriad commented Dec 22, 2017

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

@hedgefield

This comment has been minimized.

Copy link

hedgefield commented Dec 23, 2017

No, so that's fixed in 1.9.1. 👍 Now I'm back to the nonce errors during saving attempts. 🙃

@devjack

This comment has been minimized.

Copy link

devjack commented Feb 17, 2018

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

This comment has been minimized.

Copy link

doug-gv commented Feb 28, 2018

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.

image

@danielbachhuber

This comment has been minimized.

Copy link
Member

danielbachhuber commented May 10, 2018

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

This comment has been minimized.

Copy link

Savageman commented Aug 14, 2018

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 comment has been minimized.

Copy link

TWGerard commented Jan 17, 2019

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

@guidevine-devops

This comment has been minimized.

Copy link

guidevine-devops commented Jan 18, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment