Updating NGINX *.conf 'root' Breaks 'WP Admin' Button

Q: Date/Time this occurred (Provide your time zone also)
A: December 19, 2022, at 9:00 pm CST

Q: DevKinsta Version
A: 2.9.0 (2.9.0.6039)

Q: OS Version
A: MacOS Ventura 13.1 (22C65)

Q: Docker Desktop Version
A: 4.15.0 (93002)

Q: Were any error codes or messages observed? If so, what were they?
A: None

Q: Detailed Description of the Problem
A: It appears, based on my testing, the ‘WP Admin’ button is hardcoded to use the NGINX original default ‘root’ folder (i.e., /www/kinsta/public/mickythompsoncom) set in the NGINX *.conf file (i.e., /Users/mickythompson/DevKinsta/nginx_sites/mickythompsoncom.conf). If this NGINX ‘root’ value is updated, the ‘WP Admin’ button becomes inactive.

Example: If you modify the NGINX root folder from the default (i.e., /www/kinsta/public/mickythompsoncom) to use the /public folder (i.e., /www/kinsta/public/mickythompsoncom/public) and move all the WordPress files to this /public folder, the ‘WP Admin’ button stops working (this is the bug).

Manual Resolution: To get the ‘WP Admin’ button to work again, you can manually copy the 1) wp-config.php and 2) wp-settings.php files and 3) wp-includes and 4) wp-admin folders to the original root location (i.e., /www/kinsta/public/mickythompsoncom). The ‘WP Admin’ button’s active/inactive state appears to be hardcoded to look for these files and folders in the original root location and not updated to pull the root location dynamically. Ironically, the ‘WP Admin’ button navigation link dynamically uses the root value set in the NGINX *.conf file as the correct wp-admin page is opened in the URL.

To resolve this bug, I recommend the ‘WP Admin’ button’s active/inactive state pull the updated root value dynamically from the NGINX *.conf file.

Hello @mickythompson :wave: Welcome to DevKinsta community!

Thank you for reporting this case. Looks like I was able to replicate the same on Linux (with the same steps of manual resolution you provided).

I will relay this information to our internal DevKinsta developers so they can check/replicate and review this case (to confirm if it’s indeed a bug), and see if it can be resolved in the next DevKinsta release (though there’s no ETA yet for this).

Cheers,
Agus

1 Like

I’ve just got a reply from our internal DevKinsta dev team, and they mentioned that manually restructuring the nginx configuration is currently not a supported feature and we (users) should only do this on our own risk (e.g. with the manual resolution/workaround you mentioned before for example).

For sure, we could improve this situation by dynamically reading it from NGINX conf for a site in the future, such as to release a built-in NGINX config editor in the app for example (but no ETA yet) that hopefully we can give some more freedom to the user, but fully supporting this scenario might affect other parts of the app as well, and we should be careful and do more testing before introducing this feature.

Cheers,
Agus

1 Like