Shield Security plugin issues

I upgraded to CP 2.2.0 on September 19; on September 20, 24, 26, 28, I received the following identical error message from the “built-in feature that detects when a plugin or theme causes a fatal error on your site”:

An error of type E_ERROR was caused in line 102 of the file /home/carolin5/public_html/wp-content/plugins/wp-simple-firewall/src/lib/src/Components/CompCons/AutoUpdatesCon.php. Error message: Uncaught ArgumentCountError: Too few arguments to function FernleafSystems\Wordpress\Plugin\Shield\Components\CompCons\AutoUpdatesCon::autoupdate_core(), 1 passed in /home/carolin5/public_html/wp-includes/class-wp-hook.php on line 308 and exactly 2 expected in /home/carolin5/public_html/wp-content/plugins/wp-simple-firewall/src/lib/src/Components/CompCons/AutoUpdatesCon.php:102
Stack trace:
#0 /home/carolin5/public_html/wp-includes/class-wp-hook.php(308): FernleafSystems\Wordpress\Plugin\Shield\Components\CompCons\AutoUpdatesCon->autoupdate_core(true)
#1 /home/carolin5/public_html/wp-includes/plugin.php(205): WP_Hook->apply_filters(true, Array)
#2 /home/carolin5/public_html/wp-admin/update-core.php(227): apply_filters(‘auto_update_cor…’, true)
#3 /home/carolin5/public_html/wp-admin/update-core.php(909): core_upgrade_preamble()
#4 {main}
thrown

I contacted Shield support and heard back from Paul:

Thanks for sending that through.

We dropped full support for ClassicPress quite some time ago. I don’t have the exact release to-hand, but the distance between ClassicPress and WordPress was growing too great, and the userbase of ClassicPress so small, that it didn’t make much sense keeping it going.

Part of the issue was actually with the automatic updates system… CP made was significant semantic changes that keeping the 2 aligned wasn’t going to work.

I can look for the next release to adjust our code to detect CP and not apply any automatic update filters which might ease this issue for you, but ongoing support for CP isn’t something we can commit to, sorry.

Let me know if you have any further questions about that, and apologies for any disappointment around this.

I tried but could not find a post in which Paul announced that they were no longer supporting CP. I did, however, respond to him with a couple of questions, including:

Otherwise, and apparently despite the semantic changes in CP, Shield has nonetheless seemed to have worked flawlessly until this one error message — if your proposed coding tweak works, I’d probably continue using Shield. Am I correct in assuming I would need to update manually? I’d be willing to do that. Is that what you meant by “ease the issue”?

But he never responded.

I checked the upgrade notes for CPO 2.2.0 but found nothing that would seem to trigger this update error, and my site seems still to be functioning fine.

(FWIW my only other issue with 2.2.0 is that it seems now to take an inordinately long to to update edits to pages after hitting the update button. Is that related?)

I don’t understand the error message or how to stop it or what in general it means for continuing to use Shield as a firewall; BTW I long ago stopped having Shield check for changes to core code.

I have always read all the posts here on security and realize that there are options in both plugins and code changes, but I don’t look forward to going through the whole setup and testing process yet again for a new security plugin and even then still risk the same error arising.

Although I have tried a couple of the suggestions in coding (e.g., to htaccess) and wish I could rely more on such coding rather than a plugin, there is such a profusion of suggestions both here and online that it’s difficult with my skill set to decide which to implement. I tried a couple, and, in at least one instance, it shut my site down. I reloaded the original file and all was well, but the coding changes are, I’m afraid, not something I should be doing on my own.

Can anyone help? I’m open to suggestions and certainly explanations.

Thanks.

Let’s take things step by step.

  1. Your issue with editing pages taking a long time is not caused by ClassicPress core, so I’d first suggest deactivating Shield to see if the problem persists. If it doesn’t, Shield is the culprit. If it does, try deactivating all your plugins and then reactivating them one by one to find the culprit.
  2. Who hosts your site, and who logs into it? If you’re with a reputable host, are on CP v2.2, and you’re the only person who logs in, you really don’t need a security plugin. I don’t use one, for example.

Everything you’re describing here is a security plugin run amuck. We’ve even seen this on occasion with WordFence on WP sites. Paul has already indicated support is dropped for it so that is probably the culprit. That and older PHP version?

Try deactivating the plugin as Tim suggested and clear any caching (if you have any). That will tell you pretty quick what is going on.

1 Like

Many thanks for the swift responses. I did the deactivation with all plugins but found little difference.

The odd thing about the page-update saving (after edits) is that it comes and goes. Some pages are considerably longer than others (more text), and those have always taken longer after clicking update. But the recent issue with sluggishness has occurred only since I upgraded to 2.2.0 — and today, to add insult to injury, the page-updates are generally normal, i.e., faster than during the odd sluggish period of this past week or so.

@timkaye I’m on LightningBase as well and am the only person who ever logs in. That notwithstanding, with all the discussion here about htaccess rules I have never been quite sure I understand why the htaccess changes are being advocated or in which site circumstances, and not just on this forum. Are you suggesting that the server (e.g., here: LB) is already covering that area? Or something like BitNinja Server Security?

@Web242 My site currently uses PHP 8.2.23 and has been on 8+ for a long time. I notice that elsewhere you remark that even with BitNinja you “still encourage clients to have some kind of security software at their site level.” Do you have any thoughts about the htaccess changes that have lately been advocated in several topics here?

It’s clear that since Paul is no longer supporting CP and I’m being alerted to the errors every couple of days, I need to make a change. I am still curious, however, what the error message is all about. Does can anyone explain why it is being triggered? Even Paul was vague.

Thanks again for the responses.

@Doug In that case, I would ignore all the suggestions for the .htaccess file. I have. The best security for CP (and WP) is performed from outside CP (or WP), and that’s what Lightningbase does.

My experience of Wordfence, for example, is that it’s great for extracting your data for its own purposes but not much good at providing meaningful protection.

So my suggestion is to delete Shield and leave it at that.

If your site is still going fast and slow periodically even after that, I’d put in a support ticket to LB.

I have seen several differing opinions regarding security (plugins) lately, so figured I would throw my 2 cents into the fountain also.

Is it true that the vast majority of security problems with WP/CP sites stem from login / password combinations that are not secure, yes. Is it true that if you are using a reputable host, they should be protecting you, ok - but I am not going to bet my life on it and run with no backups or anything, especially if you are not the only person with a login to your site.

While we are on that subject, even if you are the only login and it is secure, unless you do not use any 3rd party themes or plugins, then the possibility that insecure 3rd party code could allow a breach directly or allow an account to be created outside the normal path without your consent does exist. If you have other users, the risk of a breach increases significantly, and if you host on your own equipment or the hosting service is breached (guess what, they can have insecure logins or protection that is not actually up to the task also, you hear about breaches everyday, so relying on someone else to cover your ass is not always going to work out like you hoped).

All security solutions are not equal either, some may not actually protect you from every possible attack, in fact most may not be able to protect you from a true targeted attack or will only be able to tell you that something bad already happened, then help you fix it, for a fee of course, plus the damage has already been done.

Adding a WAF (Web Application Firewall) is never really a bad idea, but if you are running on a shared server, then some of these apps end up adding a lot of overhead and again, a good hosting server should have that covered, so it becomes more important if you self host or something like that.

Adding Brute Force Protection is another way to protect yourself by limiting the amount of login guessing that can be done - most of those apps can also inform you anytime a user logs in, so if you are the only user and did not login, then it is time to check what happened fast.

A lot of security advise is scattered around this site, mostly by people with a lot of experience, but it is important to remember that security is not a one size fits all thing, and being overtly cautious is better that just hoping for the best.

Backups are one thing, and in the case of a site where you are the only user and no information is collected about your visitors, they can be the most important piece of the puzzle, allowing you to go back to a time before things went south. However, if you collect user information, then being naive about security is not an option, if someone grabs your user data, that cannot be undone.

Of course backups are a good idea. But I wouldn’t define that as security; backups are useful for many other reasons too.

I agree there Tim, I have never needed to use a backup due to a security issue (knock wood).
So far they have only protected me from myself…

@Doug I would follow Tim’s advice - he knows ClassicPress. As Tim and I have suggested, deactivate the Shield Security. If the plugin hasn’t been supported in a while (as Paul explained), then the code may not be compatible with PHP 8+ versions. You may have other plugin conflicts as well.

As per the PHP errors you displayed… You can temporarily rollback your PHP version to 7.4 to test that. Regardless the Shield Security plugin is unsupported now, so best not to use it.

I haven’t seen the posts on htaccess. It shouldn’t be necessary, and you shouldn’t mess with the htaccess file unless you know exactly what you are doing.

It’s great to have additional security if you can. But security plugins can also cause more issues than they are worth. I haven’t been in the ClassicPress community for a while, so I can’t advise you on other security plugins for CP. But it doesn’t make sense to use an older plugin causing site issues.

Just as an FYI, we’ve been very impressed with BitNinja for our server security. So much so we may swap out WordFence for their cPanel plugin - this is useful information for me when I start on-boarding ClassicPress clients.

Regards,
Avrom

Many thanks to @timkaye @EliteStarServices and @Web242 for the informative and helpful responses; I appreciate your taking the time to help me sort through this thing. I also found the brief remark from @ElisabettaCarrara helfpul in the topic on Word Fence, namely

First layer is the server, second is the code, third is the admin and their behavior, fourth is the eventual user/site visitor and lastly the devices involved in managing/visiting the site.

@EliteStarServices Your overview is worth considerably more than 2 cents; many thanks.

@Web242 Slight correction: Paul at Shield said that they no longer support ClassicPress specifically, not that they no longer support the plugin as such.

The Shield plugin in not only not abandoned, it also is aggressively maintained and updated. They even have weekly “missives” to users concerning particularly egregious compromises to various popular plugins. It is a robust and nuanced security plugin that can be a bit intimidating because of the granular control it offers. As I point out to Paul in my response, I’ve never really had issues with it apart from a tweak here and there, and it has never seemed to cause any latency in the site. My only issue is the curious error messages I’m getting, and I still don’t understand those.

Of course, it has never proplerly checked CP core code.

One up-side of the plugin for me has been the chance — given the granular control — to learn more about the details of site security and threats.

Re: php:

Requires PHP Version:** 7.2.5 or higher

@Doug, did you try to disable automatic updates for that plugin?
There is not really a specific reason that CP would be so different to cause a problem, CP should act like WP v6.4 is many respects and the plugin says 5.7 is minimum. I use a lot of plugins that indicate they may not work in CP without issues.

@EliteStarServices An interesting question insofar as I have been unable to enable automatic updates on any plugins since upgrading CP to 2.2.0, even for Shield. And Shield itself is preventing this (deactivating it makes it possible to enable automatic updates).

I have, of course, admin privileges for myself set up inside Shield, so this should not be happening (i.e., I have not disallowed myself as admin from changing automatic update settings for plugins). But I’ll go in an check that again. Thanks for the headzup.

Good point about the core checks; I hadn’t thought of that. I have not had Shield check core files on CP since 2.2.0 either, so you may very well be correct about WP 6.4 checks. Previously I just found that Shield found so many small CP changes to core earlier that it became circumstantial whitelisting them constantly.

And recently when Paul indicated that the two codes had diverged too far for them (Shield) to try to keep them aligned, I took that as a sign that the same errors would continue or get worse.

CP may indeed act like WP 6.4 in many respects, but for some reason Paul decided no longer to try to keep the two aligned, and for some reason I’m getting these error messages regularly (after some chron operation? I’m not entirely sure even Paul knows). So it’s difficult to know what to do.

There are times when you can chase your tail until you get dizzy and pass out…

I also know that opinions vary on WordFence, have you ever tired it?
It is another option, the settings allow you to ignore changes in core, probably making it a bit less secure, but I have tried a lot of security apps and so far none have impressed me enough to stop using WF. My setup is essentially dedicated servers though, so they have more than enough overhead to handle running heavy apps, where shared hosting can start to choke, especially on the first load when all your jobs try to run.

@EliteStarServices

There are times when you can chase your tail until you get dizzy and pass out

I’m willing to chase my tail to a certain point, since it’s part of site management in any case :wink:, but I usually know when I’m at a dead end at least for my skillset.

I used WF once upon a time and forget exactly why I left it — I do remember that they, too, after the initial-wait-and-see, declined to support CP directly, whereas Shield at least tried for a time to do so. Perhaps I’ll look at WF again.

BTW the settings in Shield similarly allow the user to ignore changes in core and to turn off auto file repair for core, which is how I have scans set. As I said, I’ve not had issues until these peculiar error messages.

I only mentioned WF because they seem very similar.
A big part of selecting software is personal preference.

The code in CP v2.2.0 is now very different in quite a few files from that in WP, and we also have some files that WP does not have. Using a file scanner designed for WP on CP is going to cause all sorts of unnecessary scares.

Yes. I tried a new scan of core today in Shield and did indeed get “all sorts of unnecessary scares.” A whole slew of them, in fact.

I feel I should clarify that (as Tim Stated), many CP core files are different and any scan designed for WP will alert on that if not disabled.

However, when I said that CP should act like WP 6.4 I meant that the vast majority of plugins that do not need block support work fine with CP, even many that say they don’t, or don’t support CP.

1 Like

If I remember correctly, this was one of the arguments for updating CP as a fork to 6.4, so your point is well taken.

1 Like