Looking for some Sysadmin / Wordpress nginx expert

I have followed so many guides and tutorials that its just I don’t know what I’m doing. I’ve got some standard wordpress redirect after login functions that refuse to work on my easy engine Wordpress Nginx install. Other things that never worked were the phpMyAdmin installs (but I could care less about that). I would be happy to pay someone with some good knowledge on this to walk me through what I need to do. Its a digitalocean droplet (4gb / 2 cpu / 60gb ssd).

I’ve tested everything I want to do on a regular old apache wordpress config and it all works as expected. The problem is that passing any redirect_to vars to wp-login.php break the process. It just redirects you to the wp-login.php over and over again.

I was able to get some of the login functions working by using iThemes Security and changing the login location to something like /connect/. But it fails to listen to ‘login_redirect’ filters. So I can only assume I’ve got some nginx restrictions.

I’ll be honest, I don’t know my ass from a hole in the ground when it comes to nginx. But the server seems to struggle with a very simple / basic design and functions with the setup from easy engine. I tried to install varnish and set that up, but I couldn’t find the server { listen } area in any of the .conf files that easy engine sets up for the wp site.

I haven’t changed anything from the initial setup using ee site create example.com --wpfc

I just need an expert to help me get things setup and running and the site won’t change much so I’m hoping it won’t be a pita to maintain.

I have resolved the login redirect issue I was having by making a change to wpfc.conf

This is the default easy engine section

location ~ \.php$ {
try_files $uri =404;

I replaced that with this code from the Wordpress Codex.

location ~ [^/]\.php(/|$) {
fastcgi_split_path_info ^(.+?\.php)(/.*)$;
if (!-f $document_root$fastcgi_script_name) {
	return 404;

Although I don’t know if it had anything to do with the issue I have also uncommented the line cgi.fix_pathinfo=1 and changed it to cgi.fix_pathinfo=0 not sure what that means but based on my research its a security risk to leave it at 1.

Anyway. Maybe this is a huge issue, but it can’t be completely bad since it is from WP Codex and perhaps this is how EE will be setup to build this in the future if they’ve noticed WP has adjusted its documentation.