LLAR update to 2.25.18 resulted in Critical Site Error: Could fix it wp-cli

  • Resolved abitofmind

    (@abitofmind)


    1 year, 6 months ago

    I accessed my website normally via web browser today and got a HTTP 503 rendered by WordPress with a minimal “Down for scheduled maintenance” message box.

    Tried again a few seconds later and it worked again.

    Immediately thereafter I got the automated WordPress email “Some plugins and themes have automatically updated”. Among the updated plugins:

    Limit Login Attempts Reloaded (from version 2.25.16 to 2.25.18)

    Soon later I access my website again and it only showed a minimal error box informing that there’s critical / fatal site error, an email got sent to the admin email address. Opened the email “Your Site is Experiencing a Technical Issue” and it and my server’s ~/log/php_error.log contained this:

    PHP Fatal error:  Uncaught Error: Failed opening required '/data/web/???/html/apps/??????/wp-content/plugins/limit-login-attempts-reloaded/core/App.php' (include_path='.') in /data/web/???/html/apps/??????/wp-content/plugins/limit-login-attempts-reloaded/limit-login-attempts-reloaded.php:40
Stack trace:
#0 /data/web/???/html/apps/??????/wp-settings.php(453): include_once()
#1 /data/web/???/html/apps/??????/wp-config.php(99): require_once('/data/web/e1291...')
#2 /data/web/???/html/apps/??????/wp-load.php(50): require_once('/data/web/e1291...')
#3 /data/web/???/html/apps/??????/wp-blog-header.php(13): require_once('/data/web/e1291...')
#4 /data/web/???/html/apps/??????/index.php(17): require('/data/web/e1291...')
#5 {main}
  thrown in /data/web/???/html/apps/??????/wp-content/plugins/limit-login-attempts-reloaded/limit-login-attempts-reloaded.php on line 40

    Rescue operation in wp-cli

    $ ssh webhost

$ wp plugin deactivate limit-login-attempts-reloaded
Plugin 'limit-login-attempts-reloaded' deactivated.
Success: Deactivated 1 of 1 plugins.
    • Cleared my browser cookies and logged in again to /wp-admin/. Worked fine.
    • Now re-enabling the plugin.
    $ wp plugin activate limit-login-attempts-reloaded
Plugin 'limit-login-attempts-reloaded' activated.
Success: Activated 1 of 1 plugins.
    • Accessing the website again both Logged-In and anonymous both works fine again.

    Followup

    • I have no issue currently, but wanted to inform you.
    • It’s interesting that simply deactivating and re-activating but doing nothing else, fixed the issue. Is LLAR performing some cleanup routines counter-resets / etc on (re)-activation, which may resolved this?
Viewing 14 replies - 1 through 14 (of 14 total)
  • Thread Starter abitofmind

    (@abitofmind)

    One more thing which came to mind after posting:

    • AFAIR I re-activated OPCache and cleared Object Cache (run by memcache) circa 15min before all this. Potentially also played a role in this.
    • But the time correlation to the update and the critical error 1min thereafter still seems the most plausible cause.
    Plugin Author WPChef

    (@wpchefgadget)

    The new version of the plugin checks if a specific file exists, and if doesn’t, it stops the plugin execution. This is a protection against double installations where the plugin is installed both in a regular plugins folder and in the MU folder. This situation seemed impossible until we deployed the previous version of the plugin and it showed that some users did have dual installations. So, it is possible that in your case that new check interfered with your caching software and that led to the error. Since the upcoming versions of the plugin will all have that new file, such situations in the future should not happen again. Thank you for letting us know about this and for your solution.

    Thread Starter abitofmind

    (@abitofmind)

    Thanks for sharing what happens in the update routine, and that this is a one time issue at most.

    I’m quite tech-savvy, and luckily had wp-cli up and running, so could resolve this quite easily. Although untested, I assume that this would without wp-cli: Access WordPress in recovery mode, then disable the plugin, then re-enable it. Same outcome hopefully.

    Glad that my reporting helped you to estimate how this can play out “in the field”. Maybe this find’s its way into your FAQ (if not already there).

    From my side this issue is resolved. Thanks!

    FYI I had the same issue today. WordPress email message indicating a critical error on my site. The site was down. I used the WordPress “safe mode” recovery link sent with the email message to login to admin, deleted LLAR plugin and all was good. Have not tried reinstalling it yet, will report back if any issues.

    Plugin Author WPChef

    (@wpchefgadget)

    In your case this article might be helpful.

    Thanks for the info, but my ISP (IONOS) does not appear to have installed a duplicate. There was nothing in the MU Folder. I have had this site up for about three years now. LLAR was installed initially by the IONOS assistant when I created the site, but just in the standard Plugins folder, and had been operating normally all that time until the automatic update a couple of days ago. Here is the error info from WordPress:

    WordPress version 6.0.5
    Active theme: Easy (version 1.9)
    Current plugin: Limit Login Attempts Reloaded (version 2.25.18)
    PHP version 8.1.19

    Error Details
    =============
    An error of type E_ERROR was caused in line 40 of the file /homepages/htdocs/clickandbuilds/eRVin/wp-content/plugins/limit-login-attempts-reloaded/limit-login-attempts-reloaded.php. Error message: Uncaught Error: Class “LLAR\Core\LimitLoginAttempts” not found in /homepages/htdocs/clickandbuilds/eRVin/wp-content/plugins/limit-login-attempts-reloaded/limit-login-attempts-reloaded.php:40

    Plugin Author WPChef

    (@wpchefgadget)

    It looks like your installation might contain incorrect paths to the plugin’s files. We’ll see how to detect that and let you know. We could not duplicate the issue on our end though.

    Thread Starter abitofmind

    (@abitofmind)

    @wpchefgadget

    • I had LLAR installed for over a year now.
    • It was not installed as a must use plugin (mu-plugin) but as a normal plugin.
    • It was set to auto-update.
    • I can rule out a duplicate installation.
    • I never ever touched a source code file in the plugin folder or in WordPress Core.
    • The only files I modified are those of my child-theme (Twenty Twenty Three is the parent theme).
    • I happen to have the error in the exact same file and line as @myervin which is limit-login-attempts-reloaded.php:40 That cannot be a co-incidence.
    • I have had OPCache ON for about 1 month now. I de-activated it shortly before the update and the subsequent critical error happened.
    • This reply was modified 1 year, 5 months ago by abitofmind.
    Thread Starter abitofmind

    (@abitofmind)

    1) @wpchefgadget Theoretically OPcache could lead to some inconsistencies.
    a) The cached file/variable instances not destroyed could potentially pose a “duplicate instance” to the fresh installation. Right?
    b) But at the time the update took place AFAIR the caching was already off long enough for all remained cached PHP objects to be gone. Could you think of another reason which lead to the critical error at limit-login-attempts-reloaded.php:40

    2) @myervin do you have some caching activate in your webhosting and/or WordPress caching plugins?

    3) I use this caching on the website which had been affected:

    WordPress plugin W3 Total Cache with these settings:

    • Page Cache: ON (to Disk (which is 100% SSD webhosting))
    • OPcache: ON, Zend Engine
    • Database Cache: OFF
    • Object Cache: ON (Memcached)
    • Browser Caching Policies for assets: ON with different policies and time to leave for different file/content types.

    Webhost settings:

    • PHP OPcache: ON, Zend Engine, 300secs timeout (but temporarily OFF for other reasons, shortly before the situation occurred, longer than those 300secs AFAIR)
    • Caching Pool: ON, memcached, 16MB
    • Varnish: OFF
    Plugin Author WPChef

    (@wpchefgadget)

    Hey guys, so we were looking into the issue on line #40 in limit-login-attempts-reloaded.php of the NEW version, but it looks like the problem was in the OLD one. The same line #40 is different in the old version (new – https://prnt.sc/JSRrFUhbLhDx vs old – https://prnt.sc/irsb5ZwyjuEO) and this error https://prnt.sc/de2Rj3B5-7sw from the OP post confirms that the issue is in the old code. The new version doesn’t have the App.php file anymore, yet the error says it was required but not found. We’re almost certain now that the root of the issue is caching.

    Thread Starter abitofmind

    (@abitofmind)

    Thanks for sharing your preliminary investigation learnings!

    Is there any function that a plugin can call when removing old files like App.php and adding new ones, all with their interdependencies, that this also get’s reliably destroyed in the OPcache? Flush the OPCache as a whole (brutal but most reliable probably) or something more fine grained like informing the OPCache about the file additions/changes/removals?

    As for caching, I have the a3 lazy load plugin running on myervin.com – ?? Don’t think anything else. FYI since I’ve deleted the old LLAR and reinstalled, all has been fine (except for the hundreds of failed login attempts every week LOL!). Also FWIW, I have another site, defsim.myervin.com, using the same template (Easy) and it does not have a3 lazy load installed, although it does have the Jetpack plugin. It auto updated LLAR to 2.25.18 and it did not have any issues.

    Thread Starter abitofmind

    (@abitofmind)

    1. Good news: On 2023-06-21 my “Limit Login Attempts Reloaded” plugin auto-updated from version 2.25.19 to 2.25.20 without any issue, while OPcache was ON.
    2. Does your plugin meanwhile follow best practises of handling OPCache invalidation on its own which is possible since WP 5.5? Before that this was solely manageable from the webhost’s settings.
    Plugin Author WPChef

    (@wpchefgadget)

    Thank you for your feedback guys! @abitofmind, we don’t do this at the moment, but will put this in the pipeline. Thank you for the tip!

Viewing 14 replies - 1 through 14 (of 14 total)
  • The topic ‘LLAR update to 2.25.18 resulted in Critical Site Error: Could fix it wp-cli’ is closed to new replies.