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 ?

1 Answer 1


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 ?

  • have you found a solution for this?
    – medBouzid
    Dec 21, 2020 at 6:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.