PHP server version changed after running the BPS Setup Wizard

Home Forums BulletProof Security Free PHP server version changed after running the BPS Setup Wizard

Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
  • #36626


    I am running the latest Free version of BPS in two  WordPress 4.9.8 sites, hosted in HostXnow’s servers (UK, Clouldlinux, Litespeed).

    I run one site in PHP 5.6 and the other in PHP 7.1. The reason being that the first WP site shares a domain with a Joomla 2.5 installation that needs 5.6 to run.

    My host offers two kinds of PHP version via cPanel’s MultiPHP Manager
    – alt-php files: these seem to be offered by ClouldLinux
    – ea-php files: these are offered by cPanel

    Here are the issues

    1) In the first site/domain, no matter how many times I run the Setup Wizard, install/uninstall, activate/deactivate BPS, after Setup Wizard finishes, on the the first new Admin page I open, I am still getting a notification that a plugin requires changes to BPS code.

    The matter is that the only different BPS plugin is Woocommerce; all other plugins are the same…but I didn’t have this problem until the last month or late September.

    Maybe this has to do with a new BPS version?

    2)  This is the critical issue. In the second domain – running as an addon-domain, in a subfolder of the first in public_html, when I run BPS’s Setup Wizard the following weird things happen:

    a. If I have ea-php 7.1.23 running, BPS Setup will force the website to revert back to PHP 5.6.38…and this BPS page gets really-really long time to load.

    b. If I am running both sites with the alt-Php files, 5.6 for the former and 7.1 for the latter, running the Setup Wizard will ACTUALLY force both domains to lose connection to the database…and I will get the message

    “Database connection error (1): The MySQL adapter ‘mysqli’ is not available.”

    I can;t wrap my head around this issue. My host cant figure out a solution either.

    AITpro Admin

    Try these steps to fix the Setup Wizard AutoFix problem with AutoFix still seeing a plugin fix that is needed.

    1. Go to BPS Custom Code.
    2. Use the Custom Code Export feature to backup and zip your current custom code.
    3. Click the Delete button to delete all of your current custom code.
    4. Run the Setup Wizard again.
    5. If the Setup Wizard AutoFix problem is fixed then unzip your exported custom code file and copy only valid/good custom code back into the appropriate Custom Code text boxes.  Do not copy the invalid/bad code that was causing Setup Wizard AutoFix to think some custom code is still needed.  If you are not sure what that custom code might be then send your exported custom code zip file to us so we can take a look at it and let you know where the problem is:  info at ait-pro dot com.

    If your PHP server version is being changed when running the Setup Wizard that means that your server uses PHP/php.ini handler htaccess code in your root htaccess file.  Do these steps below to fix that problem.

    1. Use FTP or your web host control panel file manager and download your original backed up root htaccess file in this folder:  /wp-content/bps-backup/master-backups/root.htaccess-{date and time stamp}.
    2. Copy your PHP/php.ini handler htaccess code and paste it into this BPS Root Custom Code text box:  1. CUSTOM CODE TOP PHP/PHP.INI HANDLER/CACHE CODE.  See example PHP/php.ini handler htaccess code below.  Your code will look similar, but not exactly the same.  This is just general example PHP/php.ini handler htaccess code below.

    AddHandler x-httpd-php5-cgi .php
    AddHandler x-httpd-php5-cgi .php5
    AddHandler application/x-httpd-php5s .php
    SetEnv PHPRC /path to file/
    SetEnv PHPRC /path to file/php.ini
    <IfModule mod_suphp.c>
    suPHP_ConfigPath /path to file/php.ini

    3. Scroll down and click the Save Root Custom Code button.
    4. Run the Setup Wizard again.

    The “Database connection error (1): The MySQL adapter ‘mysqli’ is not available.” could be caused because both sites require PHP/php.ini htaccess code in the root htaccess file.  One site needs PHP5.6 PHP/php.ini code in the root htaccess file and the other site needs PHP7.1 PHP/php.ini handler htaccess code in the root htaccess file or it could be caused by a directive in your php.ini file.  See the SO forum link below for a possible cause of the problem.


    You’re golden. Provided solution for every problem without taking a look at the website.

    1)Removing the custom code fixed the problem. Because I was dealing with more critical issues at the time I didn’t look into the problematic code…
    I didn’t write any code, it must have been some part of the proposed/extra security code proposed in BPS, which for some reason caused the issue there.
    …site runs fine and I haven’t had the time to take a better look.

    2-3) The critical problems were caused indeed by the weird interrelation between Cloudlinux’s “PHP Selector” and cPanel’s “MultiPHP Manager” and “MultiPHP Ini Editor” which would store php relevant code in the “.htaccess” files of the CMSs, but also of the root directory, and also created “php.ini” and “.user.ini”

    ..they would actually reference the session path of the php-version inside the files…

    I even found conflicting “EA-PHP” and “ALT-PHP” code in a .htaccess file, one beneath the other…

    …also by running the “Setup wizard” in BPS and effectively clearing that php handler code, even the selections for each domain were messed up, as WordPress installation -in a folder inside public_html (subdomain to the Joomla domain/site) – would probably then look for directions in the .htaccess file of Joomla, the Parent Directory, which was given different PHP version.

    My host initially circumvented the problem, rather than point to the solution, by putting my second domain in a separate cPanel account…but I still was left with messed up code in htaccss, php.ini files and choices in Cpanel…

    I then proceeded to clear all such code from the CMS’s .htaccess code, but I also deleted every “php.ini and “.user.ini” from the Home directory and subdirectories…

    I then followed the documentation in the following link so that I would control the PHP version via Cloudlinux’s “PHP Selector” and use “alt-PHP” files, which does not require any .htaccess code, but at the same time offers no option for per domain/folder configuration and sets Global policies

    …I set site to inherit the System PHP version in MultiPHP Manager (so that CL would actually control the php version) and proceeded to select my desired PHP version from “PHP Selector”

    Now my sites are trouble free and I don’t need to worry about php handler code in folders…

    If my two domains were kept in the same account, I would have done what you proposed…I would have set the desired PHP versions in Cpanel’s “MultiPHP Manager” and I would have placed the php handler code in the relevant CUSTOM CODE field for root .htaccess file in BPS, so that it would never be deleted and cause conflicts


    Now I have no .htaccess file in my HOME Directory of either Cpanel account…do I need to place one there, for security purposes?

    AITpro Admin

    Great job! You had some complex issues going on. So well done on figuring them all out.  The answer to your question about needing an htaccess file in your “home directory”, assuming your mean your hosting account root folder, is nope you do not need an htaccess file in your hosting account root folder and actually that is a better way to do things to avoid conflicts. htaccess files are recursive/hierarchical. So the security rules or any htaccess code in an htaccess file in the hosting account root folder will be applied to all child folders below the hosting account root folder, which can cause issues and problems.  It is always much better to have different .htaccess files in each website root folder (installation folder) so that each htaccess file will have rules that work specifically for that website (folder) and all child folders of that website (folder).  This forum topic explains htaccess hierchy in a “multi-website” environment in more depth >


    Thank you once again, I will take a look at your explanation in the link.

    I had just moved to the new host, hunting for higher IO mb/s in Shared Hosting and it was a blessing the problems arose straight away, in the initial setup process, cause it would have been a nightmare any other time.

    You immediately pointed to the root of the issue and fortunately the documentation is adequately clear to navigate to a solution…

    I read lots of people complaining about the way Cloudlinux’s alt-php versions and Cpanel’s ea-php versions and their respective php-version selection tools are correlated and many seem to have opted to disable one or the other (my two former hosts surely did)

    AITpro Admin

    Well I’m glad I could help you in getting you looking in the right direction, but you did all the heavy lifting yourself.  😉


    Hardly. In either case it was BPS Plugin that first alerted me to the issue, because of the way it works.

    As you also suggested from the start, it also provides a way to add that php code in the htaccess file without the danger of it being erased – and problems ensuing – when htaccess files are recreated.


    Is there any chance you could add “Litespeed Cache” to the list of the supported plugins, e.g. like W3 Total Cache, so that BPS recognizes what code the former attempts to add to the htaccess file and place it in the optimal position there?

    My host has advised me to use it instead, quoting significant performance enhances…

    …personally I did not witness such advantages, while briefly testing it, actually it even breaks my twitter posts module and my fancybox javascript (needs a refresh of the page to load them correctly), even without activating any minifying/combining etc…

    AITpro Admin

    I have created a work ticket to add the LiteSpeed Cache plugin to Setup Wizard AutoFix.  There are no guarantees that the Devs will ok that though.  Adding the LiteSpeed Cache plugin to Setup Wizard AutoFix or not will depend on how easy it is to hook into the LiteSpeed Cache plugin’s code.  If the work required is extensive or too time consuming then the LiteSpeed Cache plugin will not be added to Setup Wizard AutoFix.  If the work required is moderate then the LiteSpeed Cache plugin will be added to Setup Wizard AutoFix.  It could take a month or two for this work to be done if this is approved.  BPS and BPS Pro are considered completed projects/plugins at this time, but we will still add things here and there.

    Automated minification/compression should NEVER be used for any reason.  There is a very high chance that any plugin that does automated minification/compression will break a lot of other plugins including BPS Pro.  If you want to minify/compress things then do it the right way, which is to manually (not automated) minify/compress/combine scripts yourself by hand.  We experimented with using minification/compression many years ago and found it was a complete waste of time that does not really improve website performance significantly, unless of course you have a very poorly designed website.  The real solution is to redesign your website and optimize it for max performance.  That entails going through your Theme code and stripping it down to remove all the things that cause slowness and there are a lot of them in most WordPress Themes or even better is to create your own custom barebones Theme.

Viewing 8 posts - 1 through 8 (of 8 total)
  • You must be logged in to reply to this topic.