vavra7

Yes, args is an array. I have args of type array and args are correct. As I wrote in description. The code works for object types “post”|”page” etc. but not for “setting”.

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?

@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 https://localhost:8069 to https://localhost:8069). No CORS needed.

Instead Gutenberg sends request from WP_SITEURL to WP_HOME (from https://localhost:8069 to https://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] => https://localhost:8069
    [WP_HOME] => https://localhost:8070
    [JWT_SECRET_KEY] => jwt_temp_dev_secret

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.

So then it corresponds to what you write. In database is original value:

2	home	https://localhost:8069	yes
1	siteurl	https://localhost:8069	yes

These values are overwritten by my constants.

define('WP_SITEURL', 'https://localhost:8069');
define('WP_HOME',    'https://localhost:8070');

Therefore in settings->general I can see these values that are currently valid.

WordPress Address (URL)  https://localhost:8069
Site Address (URL)        https://localhost:8070

Which 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, 2 months ago by vavra7.

Here I give result of database query:
SELECT * FROM wp_options WHERE option_name IN (‘siteurl’, ‘home’);

2	home	https://localhost:8069	yes
1	siteurl	https://localhost:8069	yes

I suppose it is correct, isn’t it?