Migrating from Apache to NGINX

  • Our WordPress host (WPEngine) recently announced that when we upgrade from PHP 7.3 to 7.4 they will ignore .htaccess files so that they can move from Apache to NGINX. They suggest contacting their support team manually if we have certain settings that we want migrated to NGINX, but obviously this does not help with something like iThemes Security which needs to update rules in real time to stop threats.

    I’ve read in other posts that iThemes has NGINX support, however it seems stuck on using Apache. Even if I deactivate the plugin and rename the .htaccess file, it creates a new one when I activate it again. I’m guessing this is because I was using Apache when I installed initially and it assumes that will hold true in the future — but I now need to reconfigure it for NGINX. Any help appreciated. Thank you!

Viewing 5 replies - 1 through 5 (of 5 total)

  • Hi,

    The timing of your topic is spot on.

    My (shared) hosting provider recently offered PHP 7.4.11 support and after switching to it, I noticed the site was no longer using Apache. Instead it is now using NGINX 1.18.0!

    However the iTSec plugin (7.9.0) seems to be running fine on NGINX. It automagically switched over. No need to deactivate/activate the plugin. Though there are a number of minor UI related bugs where the plugin is still referring to the .htaccess file … and you should be aware of the fact that former plugin specific .htaccess rules are now written as NGINX rules to a (default) nginx.conf file AND this custom nginx.conf file should be included in the main NGINX server config for the rules to have any effect…

    On top of that, any changes made by the iTSec plugin to the custom nginx.conf file requires a restart of the NGINX server or a reload of the NGINX main configuration file!

    Actually when you change any iTSec plugin setting that writes to the nginx.conf file, saving the changes will now also display the message:

    You must restart your NGINX server for the changes to take effect.

    in addition to the usual message:

    The settings saved successfully.

    I guess I’m going to have to contact my hosting provider and ask how they are going to deal with this…

    Thread Starter bjuwebteam

    (@bjuwebteam)

    Thanks for the feedback. I’ll be in the same boat as you on a shared host which is responsible for multiple (>100?) WordPress sites. I’m sure they will not want to restart/reload NGINX for all of them whenever one of my sites has a config change.

    I did a trial upgrade to PHP 7.4, and as you said, iTSec seems to run fine for the most part, but I know that the realtime host ban/lockout/blacklist stuff isn’t actually working.

    Perhaps it’s time for me to re-evaluate hosting on Amazon Lightsail + Cloudflare. Frankly I’m not sure that setup wouldn’t perform better than my current host, be MUCH cheaper, have better security, protect me from noisy neighbors, and give me control over the server config so I don’t have to worry about these kinds of forced compatibility issues…

    Banning should still work as the banned IPs are also written to the database and the IPs are blocked in PHP. However it’s less efficient. As mentioned in the Banned Users module:

    Blocking IPs at the server level (in .htaccess or nginx.conf) is more efficient than blocking IPs at the (WordPress) application level using PHP.

    Lockouts are temporary (expire by default after 15 minutes) and IPs listed (or not) in .htaccess (Apache) or nginx.conf (NGINX) files have no bearing on this.

    Anyway, it’s always advisable to keep all options open ??

    Helpful:

    We use iThemes Security Pro 6.8.1 with PHP 7.4.11. No issues. Switching to a lower or higher PHP version creates no issues as well.

    Host: SiteGround (Shared Plan)
    Web Server: Apache
    Reverse Proxy: Nginx
    CDN: Cloudflare

    Cheers!

    Thread Starter bjuwebteam

    (@bjuwebteam)

    @nlpro thanks for the info. If iTSec is able to temporarily ban IPs through PHP and the WordPress database I think that will be good enough for us for now.

Viewing 5 replies - 1 through 5 (of 5 total)
  • The topic ‘Migrating from Apache to NGINX’ is closed to new replies.