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 ?