-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Comments
For the sake of testing, what plugin are you using for the domain mapping or are you simply setting different domains in Settings->General? |
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. |
cc @rmccue - anything we can do about this? Seems like we should fix this case in general |
☝️ bump. |
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. |
I believe the |
No, so that's fixed in 1.9.1. 👍 Now I'm back to the nonce errors during saving attempts. 🙃 |
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.
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 Given that the same install is running WP I wonder if gutenberg could somehow wrap Since this is outstanding for a few months, I'm reproducing in current Gutenberg 2.2.0. |
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 |
Here's what I did to make it work (I only have 1 site):
|
This issue is breaking a production site for me now too. Thanks WordPress. |
I can't imagine this is an uncommon use case.
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 |
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. |
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? |
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. |
I tried this with WP 5.2, and it did not work. However, after combining it with what I saw here, it did work!
|
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. |
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. |
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. |
But in your case the issue is related with a subfolder with the same domain. By the way, I've tested
And doesn't work either, home_url is domain1.com and $_SERVER['HTTP_REFERER'] is domain2.com but the
Is still there |
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 ***@***.***> 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
<#1761?email_source=notifications&email_token=AEZYYLJDIGYDPPBLXRRROXDQ5XBMZA5CNFSM4DR6FZ32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEI4XIAQ#issuecomment-574190594>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEZYYLKGDDUXPV5UJHFZWSTQ5XBMZANCNFSM4DR6FZ3Q>
.
|
Will it be ever fixed? |
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. |
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 ***@***.***> 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
<#1761 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABLSIMMUNKBRSPFYUXWG3VLRLW27XANCNFSM4DR6FZ3Q>
.
|
Ran into this issue too. Had blog at https://blog.amazingmarvin.com and wanted to migrate to https://amazingmarvin.com/blog/. I guess this is a somewhat common use case! So I made a new subdomain, blogger.amazingmarvin.com, which is a cloudfront origin for amazingmarvin.com/blog/. I setup an nginx rewrite for /blog/xyz -> xyz. Then I setup nginx to 301 all the old links to the new links. So now The workaround didn't work for me (5.7.2), so I worked around by reverting to the Classic Editor plugin. |
If you're using Root's Bedrock, you'll want to strip away the |
Yo, how the frick is something fundamental as this not being addressed by Wordpress core team?? This renders Wordpress basically useless for headless use... Also i had to append a "/" to the site URL for some reason.. add_filter('rest_url', function($url) {
$url = str_replace(home_url(), site_url(). '/', $url);
return $url;
}); |
Hi, encountering the same problem here, are there any updates ? |
@danielbachhuber Can you explain why this was an intentional decision? Why would purposely break WP? |
I spent a few hours on this too today. I can't believe this is considered a closed issue since this breaks the whole purpose of having a |
Why is this a closed ticket when this literally renders most headless setups useless |
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)
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?
The text was updated successfully, but these errors were encountered: