wp-admin remove part of the url

admin管理员组

文章数量:1122846

This looks like wp-admin remove the subfolder URL but it's not the same problem, because the subfolder part is not a subfolder.

I'm working on a clean VM as a host for Docker containers. I have a dockerized Wordpress listening on 8080 on the VM.

I can hit Wordpress at http://<vm_ip>:8080 and install just fine. It takes me to the backend at http://<vm_ip>:8080/wp-admin/ and everything works as expected.

Now I'd like to access my blog at http://<vm_ip>/blog/ so I set up nginx on the VM to proxy requests per location :

upstream blog {
    server localhost:8080;
}
server {
    listen 80;

    server_name <vm_ip> localhost;

    location /blog/ {
        proxy_set_header  X-Real-IP        $remote_addr;
        proxy_set_header  X-Forwarded-For  $proxy_add_x_forwarded_for;
        proxy_set_header  X-Nginx-Proxy    true;
        proxy_pass        http://blog/;
    }
}

This is temporary as nginx will probably end up dockerized, but that requires custom images ; one thing at a time...
Also with an actual domain name, I would use subdomains so that would take care of my problem

I hit http://<vm_ip>/blog/ and I get to the install, but the static files' url are not correct : http://blog/wp-includes/css/... so the UI is a bit raw.

I move on with the install. It works and takes me to http://<vm_ip>/blog/wp-admin/install.php?step=2 but the Connect button points to http://blog/wp-login.php so I get a 404.

I need to make a change directly in the db : site_url and home (in wp_options) are set to http://blog so I update them both to http://<vm_ip>/blog.

Now the frontend works just fine, but the backend has problems. While most links are OK, some buttons' href miss the blog part : http://<vm_ip>/wp-admin so it takes me nowhere.

Those buttons usually have some kind of submit role :

• the close button (top left) in Appearance > Customize (points to http://wp-admin/)
• the Save button in Settings > General (submit for <form action="options.php">)

What's funny is it's not consistent : the Save button on Page > Add works just fine (though it throws a DOMException : Failed to execute 'replaceState' on 'History': A history state object with URL 'http://blog/wp-admin/post.php?post=15&action=edit' cannot be created in a document with origin 'http://<vm_ip>' and URL 'http://<vm_ip>/blog/wp-admin/post.php?post=15&action=edit&message=1')

Is it something with the site_urland homeoptions ?

Should I search the admin templates for the incomplete urls placeholders ?

Is there some hook or filter to force the right url ?

This looks like wp-admin remove the subfolder URL but it's not the same problem, because the subfolder part is not a subfolder.

I'm working on a clean VM as a host for Docker containers. I have a dockerized Wordpress listening on 8080 on the VM.

I can hit Wordpress at http://<vm_ip>:8080 and install just fine. It takes me to the backend at http://<vm_ip>:8080/wp-admin/ and everything works as expected.

Now I'd like to access my blog at http://<vm_ip>/blog/ so I set up nginx on the VM to proxy requests per location :

upstream blog {
    server localhost:8080;
}
server {
    listen 80;

    server_name <vm_ip> localhost;

    location /blog/ {
        proxy_set_header  X-Real-IP        $remote_addr;
        proxy_set_header  X-Forwarded-For  $proxy_add_x_forwarded_for;
        proxy_set_header  X-Nginx-Proxy    true;
        proxy_pass        http://blog/;
    }
}

This is temporary as nginx will probably end up dockerized, but that requires custom images ; one thing at a time...
Also with an actual domain name, I would use subdomains so that would take care of my problem

I hit http://<vm_ip>/blog/ and I get to the install, but the static files' url are not correct : http://blog/wp-includes/css/... so the UI is a bit raw.

I move on with the install. It works and takes me to http://<vm_ip>/blog/wp-admin/install.php?step=2 but the Connect button points to http://blog/wp-login.php so I get a 404.

I need to make a change directly in the db : site_url and home (in wp_options) are set to http://blog so I update them both to http://<vm_ip>/blog.

Now the frontend works just fine, but the backend has problems. While most links are OK, some buttons' href miss the blog part : http://<vm_ip>/wp-admin so it takes me nowhere.

Those buttons usually have some kind of submit role :

• the close button (top left) in Appearance > Customize (points to http://wp-admin/)
• the Save button in Settings > General (submit for <form action="options.php">)

What's funny is it's not consistent : the Save button on Page > Add works just fine (though it throws a DOMException : Failed to execute 'replaceState' on 'History': A history state object with URL 'http://blog/wp-admin/post.php?post=15&action=edit' cannot be created in a document with origin 'http://<vm_ip>' and URL 'http://<vm_ip>/blog/wp-admin/post.php?post=15&action=edit&message=1')

Is it something with the site_urland homeoptions ?

Should I search the admin templates for the incomplete urls placeholders ?

Is there some hook or filter to force the right url ?

• wp-admin
• urls
• nginx
• docker

Share Improve this question edited Jul 2, 2017 at 18:01 Manumie asked Jul 2, 2017 at 15:31 ManumieManumie 4377 bronze badges

Add a comment  | 

1 Answer 1

Sorted by: Reset to default 0

I've searched in the admin templates. It seems the placeholders rely on the functions wp_get_referer() and wp_get_raw_referer() which use $_SERVER["REQUEST_URI"], $_SERVER['HTTP_REFERER'] and a wp custom variable passed in the request : $_REQUEST['_wp_http_referer'].

So Wordpress builds some URLs (apparently not all) on REQUEST_URI, that is /wp-admin/whatever (in the backend). The logs show that wp-admin/admin-ajax.php comes through regularly, so it's hitting the right URL.

So I guess it has to do with the headers nginx passes through.

(That kind of answers my question as far as WP is concerned. If I need to ask on a nginx forum, I'll link it here.)

I tried various rewritings and if, to no avail.

But I'm closing in : the http://<vm_ip>/wp-admin/... requests are handled by nginx on the VM, in the / location block, so the /blog/ location block never gets them and they're never proxied to my WP container.

It seems that try_files does the trick, at least partly :

location / {
    try_files $uri /blog$uri;
}

That means that when the / location catches a request, it will first try to find a file matching the URI, then a file matching /blog + URI, which goes to the /blog/ location block and to my WP container.

So now, great, when I click on one of the faulty buttons, I'm redirected to my WP container.

Victory !? Not quite yet, because I need to log back in. And the URL is weird : http://<vm_ip>/blog/wp-login.php?redirect_to=http%3A%2F%2Fblog%2Fwp-admin%2Foptions-general.php&reauth=1 - if you look at the redirect_to part, it is now http://blog/wp-admin...
Hence, when I log back in, it takes me to the Dashboard.

However, the form's data has been saved in the meantime. Yes, making progress !

Deep down in the bottom, shouldn't Wordpress always use the same logic to build URLs used in the backend and the frontend ? Isn't that some kind of bug ?

本文标签： wpadmin remove part of the url