SiteGround: ARQ turns off during updates

Home Forums BulletProof Security Pro SiteGround: ARQ turns off during updates

This topic contains 17 replies, has 3 voices, and was last updated by  Living Miracles 6 days, 5 hours ago.

Viewing 15 posts - 1 through 15 (of 18 total)
  • Author
    Posts
  • #35521

    Living Miracles
    Participant

    Hi,

    I’ve been monitoring a behavior on 3 WordPress sites I host on SiteGround over the last couple of months. Every time I make plugin or theme updates through ManageWP (my standard way of updating sites), ARQ gets turned off during the process. So, I need to log into each site and turn ARQ back on manually. Granted, this isn’t a lot of work, but it’s just curious that this happens at all.

    I have about 15 other WordPress sites (mostly hosted on GoDaddy Managed WordPress) and this same behavior doesn’t occur on those sites (surprise!).

    Any idea how I can troubleshoot this or what could be causing this?

    Also, this morning during updates, when ARQ turned off on one of those SiteGround sites in particular, I received 37 “BPS Pro Alert: AutoRestore is turned Off” emails within a matter of 7 minutes for that one website. Not sure what happened there either…

    Update: On that same site, I actually just noticed that ARQ remained “Pending” instead of “Off” and I had to run the Setup Wizards in order for it to turn back on. Usually, for these SiteGround sites, after updates I get the “BPS Pro Alert: AutoRestore is turned Off” email for each site, then I log into each site, find ARQ “Off”, and simply turn it back on.

    Thank you so much!
    Jutta

    #35523

    AITpro Admin
    Keymaster

    Normal AutoRestore functionality is that ARQ is automatically turned Off during plugin and theme upgrades for up to 3 minutes (average ARQ Off time is between 30 – 60 seconds), a Pending Status for ARQ is shown in the BPS Pro Dashboard Status Display and then a Cron Job is run after ARQ file backup has occurred and ARQ is automatically turned back On.  If you have disabled/altered or changed WordPress Standard Crons then the BPS Pro ARQ Cron Job that automatically turns ARQ back On will probably not work or work correctly.

    So logically the problem has something to do with the BPS Pro ARQ Cron Job that automatically turns ARQ back On is being interfered with by something.  Not sure what why you received 37 email alerts in 7 minutes.  The email alerts are coded to be sent once every 5 minutes.  That problem is probably related to whatever is interfering with the BPS Pro ARQ Cron Job that automatically turns ARQ back On.

    Are you doing anything with WP Standard Default Cron Jobs in your wp-config.php file or anywhere else (Plugin or other code somewhere)?  Does SiteGround disable WP Standard Default Cron Jobs?

    #35525

    Mohamad Hegazy
    Participant

    if i disabled default wp corn job and i uses external easycorn.com service to trigger calls every minute to wp-corn.php do i need to trigger special functionality to trigger bps pro corn jobs ?

    #35526

    AITpro Admin
    Keymaster

    @ Mohamad Hegazy – Are you running into a problem?  In theory if you have a Direct Cron setup to hit the wp-cron.php file every minute then the BPS ARQ Cron should run fine.  As far as all other BPS Cron Jobs they should also work fine.  Problems tend to occur when someone sets Direct Cron Jobs to 15+ minutes.

    #35552

    Mohamad Hegazy
    Participant

    @ AITpro Admin yes definitely now i’m sure i have a problem

    bps corn jobs doesn’t execute automatically hence other plugin’s like woocommerce exchange rate and other wp-corns are executed normally on time

    i noticed that some of my plugins js and php files are blocked from frontend
    u check bps auto whitelist and i found that it’s never done it’s job http://prntscr.com/izfblr even when i set it to run each 1 min
    those times never changed since i tried to run auto-wizard and after that i tried to run whitelist test mod,
    any suggestions?

    also i think this forum have a mailing problem as i didn’t recive any e mails when you replay back 🙁

    #35553

    AITpro Admin
    Keymaster

    The Plugin Firewall AutoPilot Mode also runs using a Standard WordPress Cron.  So I guess that Cron Job is also being broken/not running/not working.

    Suggestions:  Use WordPress Standard Crons and do not disable them or use Direct Crons instead.  If you want to continue to use Direct Crons then I guess you would need to figure out why they are not working on your server/website.  You can also not use some BPS Pro security features like:  ARQ IDPS or the Plugin Firewall, etc.

    The forum sends automated emails.  The forum emails are working normally.  If you are not receiving the automated forum emails then either they are being sent to your Junk or Spam email folder or your server has anti-spam software such as Spam Assassin installed, which is known to reject/block about 40% of good/legitimate automated emails.  Contact your web host support folks and ask them not to block/reject automated emails.

    #35557

    Mohamad Hegazy
    Participant

    hello again,

    good day!

    yes indeed i’m using direct corn from external services called easycorn.com and i setup a corn job task to trigger wp-corn every min on that link https://mywebsite.com/wp-cron.php?doing_wp_cron

    and it did trigger successfully according to easycorn logs and as per other plugin corn tasks like woocommerce exchange rate that required to be updated every hour and yes i receive emails every hour that the rate is successfully updated via api call

    here in bps it’s not doing it’s corn but if i enabled embeded wp corn calls again via wp-config true, it works normally,
    so i think it’s an issue with the plugin corn job as it’s not triggered via external calls can you please check it
    easycorn.com can provide free accounts to test same as corn-job.org
    i’ll do further testing on another test site to demonstrate the issue  and come with a feed back

    #35558

    AITpro Admin
    Keymaster

    BPS does work with Direct Crons. I’ve never tested the easy cron site/service before, but since other cron jobs are working then I assume all wp cron jobs should work. I will test the easy cron site/service tomorrow and see if I get the same results.

    #35560

    Mohamad Hegazy
    Participant

    dear aitPRO,

    thanks for taking care of this ticket, but it’s my website issue as i tested it on a fresh install test site, and it worked as expected
    hence i was digging further, and i came to know that my wp-corn.php calls was cached with my server caching so it wasn’t triggered at all
    what makes me though that exchange rate was triggered as it was triggered by a different url call via ajax-admin.php call

    i solved it from easy corn by adding the follow placeholder which puts a random numbers each wp-corn call
    like that https://mywebsite.com/wp-cron.php?doing_wp_cron?__RANDOM__

    thank you and sorry for your time

    it’s always a pleasure to have a conversation with you and as Always have a great day!

    #35561

    AITpro Admin
    Keymaster

    Great!  Well done.  I almost mentioned checking cache/caching plugin 3 times, but chose not to mention that for whatever dumb reason. 😉  The Query String you posted has a second “?”.  ?doing_wp_cron?__RANDOM__  Any question marks following the first “?” in a Query String are treated literally (a literal “?” character) instead of being processed like the first “?” in a Query String, which tells a Browser that the String is a Query String.  Query Strings are cached as you found out from this issue.  😉

    #35562

    AITpro Admin
    Keymaster

    Typically Query Strings use this format:  http://example.com/path/to/page?name=ferret&color=purple. I’m not sure if a Direct Cron Query String is different than a typical/common Query String request.

    https://en.wikipedia.org/wiki/Query_string

    Maybe this is better: https://mywebsite.com/wp-cron.php?action=doing_wp_cron&number=123456. I assume you are using something like MD5 to randomly generate a unique random number on each Cron run?

    #35563

    Mohamad Hegazy
    Participant

    you are correct ?__RANDOM__  this placeholder have random value from easycorn.com it’s coded as if it saw any wp-corn triggered with such a placeholder then it will replace __RANDOM__  it with any md5 random hash

    https://www.easycron.com/faq/what-placeholders-you-could-use-in-cron-job-url

    i think i should use & instead of ?

    #35564

    AITpro Admin
    Keymaster

    I would try using “&” instead of “?”.  If it does not work then you can just not use the second “?”.

    #35565

    Living Miracles
    Participant

    Sorry for the late response. Thanks so much for the thorough investigation.

    As far as I know, there’s nothing special being done in terms of cron jobs. We did actually use custom cron jobs at some point, but we’ve reverted that back and are using standard WP crons. However, I will check in with SiteGround and see if they can tell me anything I don’t already know.

    Also, as far as I know, none of the plugins I use should interfere with crons running properly either.

    Will keep you posted about what I find. So far, still seeing the same behavior with ARQ turning off completely and not coming back on during theme/plugin updates.

    Oh, one thing to mention: As far as I can see, ARQ runs through its normal process (goes to pending for a little bit, then turns back on) when I update plugins from the WP Plugins area. However, when doing the same process via ManageWP, that’s when ARQ turns off completely. Is that a clue, maybe?

    Thanks!

    #35566

    AITpro Admin
    Keymaster

    The last time we checked ManageWP and BPS Pro ARQ compatibility was about a year ago and plugin updates from ManageWP worked fine with ARQ.  See this forum topic for more information:  https://forum.ait-pro.com/forums/topic/managewp-read-me-first/.  It is always possible that something has changed with ManageWP and how it does plugin updates remotely.  Previously both ManageWP and BPS Pro hook into the WordPress Upgrader classes.  So when ManageWP updated a plugin then it triggers the WordPress Upgrader class, which in turn triggers ARQ.  One person in the forum link above mentioned they were doing some kind of bulk upgrade using ManageWP that was causing problems.  Maybe the issue has to do with something like that?

Viewing 15 posts - 1 through 15 (of 18 total)

You must be logged in to reply to this topic.