BPS Issues on Staging Sites Only

Home Forums BulletProof Security Pro BPS Issues on Staging Sites Only

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
  • #38290
    Living Miracles


    We have 5  staging sites on a dedicated SiteGround server, and certain BPS processes are not working (whereas they do work on their associated production sites).

    Here’s what I found:

    1. AutoRestore turns itself off or goes pending during plugin/theme updates, but never turns back on.

    2. Quarantine does not work. File changes aren’t detected anywhere on the site (root, wp-admin, wp-content, wp-includes).

    3. BPS emails are not sent. Like when AutoRestore is turned off, the automatic email that is supposed to get sent every 15 minutes to inform us that it has been turned off does not get sent.

    • What does seem to work in terms of emails are those that I manually initiate. For example, BPS’s the test emails for “PHP mail() or WordPress wp_mail()” in the S-Monitor settings come through fine. Also, emails that are sent when setting up new user accounts are sent fine.

    So, I’m wondering if there’s an issue with the crons since the above processes all rely on crons. The issues occur regardless of whether we have crons set up manually in cPanel or use the standard WordPress crons. I’ve contacted SiteGround about this, but in the meantime I wanted to see if you had any thoughts about this as well.

    Thank you so much!

    AITpro Admin

    Wow sounds like your server has a lot of problems.  Not trying to pass on blame, but BPS Pro works out of the box on Shared, Dedicated, VPS hosting etc. worldwide.  ie 100’s of web hosts worldwide. 50K+ websites worldwide.  I have to be honest with you at this point – the amount of problems you are having with your server is not normal.  Something seems off about it. 😉

    Over the years I have seen many people buy a Dedicated or VPS server and they believe that it is setup and ready to go out of the box and is going to be better some how right out of the gate.

    A Dedicated or VPS server is a raw/bare bones server that requires extensive configuration by someone who has some experience with server config.
    A Dedicated or VPS server out of the box will typically perform slower than Shared Hosting until you trick it out.

    Living Miracles

    Thank you so much for your response! Very interesting, and I’ve passed some of what you shared on to SiteGround to see if they have anything to say about it. 😉

    I wanted to share with you what they told us about their staging site processes as well, in case you’re interested:

    When creating a WordPress staging copy we do not replace the Home and SiteUrl options for WordPress. They remain the same as the original website. Instead, we use three additional Apache modules that allow you to actually work on the correct application:

    – mod_host – contains 1 directive – RealHostname. If defined, all the requests to the application will be processed as they have been made to the real hostname (in our case all of the requests to the stagingXX.domain.com and not the URL in the WordPress configuration). This module is written by us.

    – mod_substitute – standard Apache module – used for replacing strings in the Apache’s response. We use this to replace domain.com with stagingN.domain.com

    – mod_headers – standard Apache module – used for changing request and response headers. Used for configuring the headers according to the staging subdomain.

    We have thoroughly tested the staging software with multiple different WordPress applications and our tests show it is working as expected. Still, unfortunately, we cannot give a guarantee it will not have discrepancies with other third-party plugins and/or custom code added to WordPress. It is possible that a custom plugin does not work as expected with staging.

    What we can suggest you, in this case, is to clone the staging1 site outside our staging software into a separate site, for example, https://dev.someka.net and reconfigure its Home and SiteUrl options to be the real ones: https://dev.someka.net. This way the Home and SiteUrl options will not be replaced by the web service with the real hostname. Note that in this case, you will not be able to push the site to live using our staging software.

    So, I will be creating an actual dev site for one of our production sites, to see if BPS Pro will work there the way it should. At least that would confirm that SiteGround’s staging site creation process somehow interferes with how BPS Pro is supposed to work.

    AITpro Admin

    The easy way to deal with this is just not to use the BPS Pro Plugin Firewall until your site(s) are ready to go Live.  It’s the same basic principle as if your site was in maintenance mode.  The way we work on sites is to develop them on a Local Dev server (offline ie XAMPP, MAMP, WAMP etc.) and then copy all the new stuff to the Live site after everything is completed.  So if you are going to work on dev sites on a live host then definitely turn off the BPS Pro Plugin Firewall. All other BPS Pro features should work “normally” and probably don’t need to be turned off on a dev site.  If any other BPS Pro features are not working correctly on your dev sites then just turn things off accordingly.  In your case it sounds like you will have to turn off several things until your dev site(s) is/are completed.  You should definitely be putting your sites in maintenance mode if you are working/building, etc. on a live host.  When a site is in maintenance mode various things overall are probably not going to run “normally”.

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