different WP_SITEURL and WP_HOME – internal requests
-
Problem occurred on clean installation of WordPress v5.3.2. No plugins.
I am developing site with headless WordPress and decoupled frontend. Both live on its own domain and frontend retrieves data from WordPress trough wp REST API. So I defined in wp-config.php different WP_SITEURL and WP_HOME.
define('WP_SITEURL', 'http://localhost:8069'); define('WP_HOME', 'http://localhost:8070');At the first glance everything looked fine. Posts permalinks lead to WP_HOME address as expected. REST API is under WP_SITEURL as it is supposed to be.
But one thing sucks. Why internal WordPress requests lead toward WP_HOME url? So it is not possible for example save post. What am I missing?
See also following screenshot with problem. https://ibb.co/QPw0Bxh
-
This topic was modified 5 years, 11 months ago by
vavra7.
-
This topic was modified 5 years, 11 months ago by
-
i think you change something in database
please see image https://prnt.sc/qk08dqHere I give result of database query:
SELECT * FROM wp_options WHERE option_name IN (‘siteurl’, ‘home’);2 home http://localhost:8069 yes 1 siteurl http://localhost:8069 yesI suppose it is correct, isn’t it?
using constants means avoiding the query to the database (otherwise said temporarily overwrites the value).
WP_HOME is the one shown to the browser.
technically you have a CORS (error for browser) it can be solved in api rest, however if you use WP_SITEURL I don’t understand why the url changes.So then it corresponds to what you write. In database is original value:
2 home http://localhost:8069 yes 1 siteurl http://localhost:8069 yesThese values are overwritten by my constants.
define('WP_SITEURL', 'http://localhost:8069'); define('WP_HOME', 'http://localhost:8070');Therefore in settings->general I can see these values that are currently valid.
WordPress Address (URL) http://localhost:8069 Site Address (URL) http://localhost:8070Which is exactly what I want. So back to my original question. Why WordPress internal requests are calling WP_HOME url??
edit: CORS (error for browser) would not be there if the request lead to WP_SITEURL.
-
This reply was modified 5 years, 11 months ago by
vavra7.
Your server have support for
$_SERVER['HTTP_ORIGIN']https://github.com/WordPress/WordPress/blob/5.3-branch/wp-includes/rest-api.php#L572 functionrest_send_cors_headers( $value );from your browser can you watch the sent headers? (header Origin: http://localhost:8069) in the case of a domain change including the port, $origins should be http://localhost:8069
also look at the save filters, maybe set WP_HOME.Ok, I have to admit I’m not sure exactly what you want me to do but…
I find out that it is problem specifically in Gutenberg. On edit page with classic editor works everything properly. So the problem is not CORS thing, but url. WordPress tries to access REST API on my WP_HOME and not on WP_SITEURL – which is totally wrong.
After hours of googling I found following thread: https://github.com/WordPress/gutenberg/issues/1761
Dont know why it is closed, because this is clearly WP core bug since 2017.
For those with similar issue there is workaround not a solution.
add_filter('rest_url', function ($url) { $url = str_replace(home_url(), site_url(), $url); return $url; });Thank you for help anyway.
if your server is configured to retrieve the Origin: http://localhost:8069 header that the browser sends, it does so with the variable
$_SERVER['HTTP_ORIGIN'], the api rest has support for CORS but your server must create this variable.
and anyway you have to use WP_HOME for the API rest and if the API takes the header it adds it with its header. usually the path is WP_HOME/wp-jsons/ if pretty permalik is enabled ,many plugins use this coding because from WordPress 3.5 it is possible to give your own directory by modifying WP_HOME.
Endpoints /wp/v2/posts https://developer.wordpress.org/rest-api/reference/
currently if you use http request language but you don’t have php or javascript (for nonce) support inside WordPress from an eye here https://wordpress.org/support/topic/cant-connect-to-wordpress-rest-api-without-a-plugin/@autotutorial I still don’t get what is your point.
Why should I care for CORS? It si supposed to send request from WP_SITEURL to WP_SITEURL (from http://localhost:8069 to http://localhost:8069). No CORS needed.
Instead Gutenberg sends request from WP_SITEURL to WP_HOME (from http://localhost:8069 to http://localhost:8070). Yes, consequently it crashes on CORS, but it is not the point at all. On WP_HOME is not the WP REST API endpoint anyway. So how it helps me allowing CORS? What is your point?
Here is my server configuration.
[SERVER_SOFTWARE] => Apache/2.4.38 (Debian) [REQUEST_URI] => / [HTTP_AUTHORIZATION] => [HTTP_HOST] => localhost:8069 [HTTP_CONNECTION] => keep-alive [HTTP_CACHE_CONTROL] => max-age=0 [HTTP_UPGRADE_INSECURE_REQUESTS] => 1 [HTTP_USER_AGENT] => Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.88 Safari/537.36 [HTTP_SEC_FETCH_USER] => ?1 [HTTP_ACCEPT] => text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9 [HTTP_SEC_FETCH_SITE] => none [HTTP_SEC_FETCH_MODE] => navigate [HTTP_ACCEPT_ENCODING] => gzip, deflate, br [HTTP_ACCEPT_LANGUAGE] => en-GB,en;q=0.9,cs;q=0.8,sk;q=0.7,en-US;q=0.6 [HTTP_COOKIE] => wordpress_test_cookie=WP+Cookie+check; _hjid=cd70cc16-f79f-4d36-b0ea-849271f457f5; _ga=GA1.1.1616490284.1572865052; _hjIncludedInSample=1; wordpress_logged_in_d1c9e11eb00bdf205a8c6f83abac0894=root%7C1573132470%7CLyuSnZKsfF2LzJB69kjYiE291ykGDAywQGi95juQVzm%7Cecbc51d64e8faa6ec6708991b7956e28df9e7bf553568c8246ddb4f0072ca3d9; portalAlert=true; io=RTKL0-iSHe7X_wrIAAAL; _gid=GA1.1.1638110781.1578300035; wordpress_logged_in_2e0ec32a4bf45e753218dfaa032bb751=root%7C1578482052%7Ctx5Oslx824QE4ifBIAhQIXePgvxBF4vnyiIJynfIwSz%7Cecdeaa34a049a0a3132222500bb0943e2411a19e6a1283b9f84303b46c4cf3a4; wp-settings-1=libraryContent%3Dbrowse%26mfold%3Do; wp-settings-time-1=1578309252; newOrders=true [PATH] => /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin [SERVER_SIGNATURE] => Apache/2.4.38 (Debian) Server at localhost Port 8069 [SERVER_NAME] => localhost [SERVER_ADDR] => 172.25.0.3 [SERVER_PORT] => 8069 [REMOTE_ADDR] => 172.25.0.1 [DOCUMENT_ROOT] => /var/www/html [REQUEST_SCHEME] => http [CONTEXT_PREFIX] => [CONTEXT_DOCUMENT_ROOT] => /var/www/html [SERVER_ADMIN] => webmaster@localhost [SCRIPT_FILENAME] => /var/www/html/index.php [REMOTE_PORT] => 54086 [GATEWAY_INTERFACE] => CGI/1.1 [SERVER_PROTOCOL] => HTTP/1.1 [REQUEST_METHOD] => GET [QUERY_STRING] => [SCRIPT_NAME] => /index.php [PHP_SELF] => /index.php [REQUEST_TIME_FLOAT] => 1578339291.897 [REQUEST_TIME] => 1578339291 [argv] => Array ( ) [argc] => 0 [WP_SITEURL] => http://localhost:8069 [WP_HOME] => http://localhost:8070 [JWT_SECRET_KEY] => jwt_temp_dev_secretWhy should I care for CORS?
if your client uses wordpress in a directory but wants a view without a directory how can you solve it?
Please or moderator delete value of cookie 😉
You not have support for$_SERVER['HTTP_ORIGIN']
you can change the function rest_send_cors_headers i have indicated, with the value for $origin http://localhost:8069
Gutenberg uses api rest with WP_HOME
take a good cup of coffee and think if it’s a bug Gtenberg open a pull request in the github gutenberg while if it’s a WordPress bug write on https://core.trac.wordpress.org/My client does not use wordpress in a directory and I dont want to view it at all. I use Gatsby js to generate frontend.
I am developing site with headless WordPress and decoupled frontend. Both live on its own domain and frontend retrieves data from WordPress trough wp REST API.
So still dont know why should I care for CORS?
feature requests or bugs you can write here.
If your request is not accepted you must change your coding. https://github.com/WordPress/gutenberg/issuesI’m experiencing a very similar problem. All the plugins & mu-plugins asset URLs are using the WP_SITE value when they should be using the same value WP Admin assets use: WP_SITEURL.
Super frustrating.
Actually, I just found it, you’ll want to set the
WP_CONTENT_URLvalue for routing plugins correctly. -
This reply was modified 5 years, 11 months ago by
The topic ‘different WP_SITEURL and WP_HOME – internal requests’ is closed to new replies.