Paul

Can you reproduce the problem then immediately look at Shield’s Activity Log. If Shield blocks anything, it’ll be detailed in there and what it’s blocking and why.

Hi,

From the reference article, you’ll see that our CAPTCHA system uses the “proof of work” model. This basically means we present a complex task – something that is compute intensive – to the visitor, and ask them to solve the problem/challenge.

The complexity of the challenge is as it sounds – how hard or how much effort/work will it take to solve the challenge. Ideally you’ll want the challenge to be a challenging as possible, but legitimate visitors with slow/old devices may take longer to solve the challenge. So if you expect your normal visitors to be predominantly running on mobile, or older devices, choose a lower challenge complexity.

If you choose “adaptive”, then Shield will present a challenge complexity based on how the visitor is presenting (typically the useragent).

Hope that helps.

I’m afraid I don’t know – you’ll need to chat with the plugin developer on why it’s not delete it.

Yep, these are from much older versions of Shield, so it’s safe to delete them. The aptoweb entries are probably ours, but I know there is another plugin out there that uses the apto prefix, so worth double-checking. And the entry apto-dbs-ready-status is also from Shield.

Hi,

Shield has never put in hundreds of autoload option in the plugin, ever. We’ve always grouped our plugin options in arrays stored them in the DB to reduce the number of entries in the DB. So if you’re seeing “hundreds”, then you’re attributing something to Shield that isn’t Shield.

There could well be options leftover from years ago, particularly if you removed Shield without the “Delete on Deactivate” option enabled. In that case, look for options with icwp-wpsf- or icwp_wpsf_ in the name and that would indicate a Shield option.

Also, installing Shield’s latest version today won’t necessary remove options from earlier versions of Shield as the structure of how Shield store options has changed quite a lot.

I hope that helps.

Nope, this will take time to investigate and debug, and will require a patch release to fix it in all likelihood, if we can find the cause. We’ll do this as quickly as we can allocate resources.

To be entirely transparent, we fix bugs as a priority wherever possible, but we generally elevate priority for support requests made by our ShieldPRO customers – that’s not to say bugs get immediate priority, however.

I’m raising that point to set expectations, and as we can’t get into details about our paid solutions in this forum, if supporting our work is something you’re interested in, you can learn more about that here.

Thanks.

Gotcha, that’s perfect, thank you for sharing that.

And just to clarify, these URLs are in-fact completely valid?

We’re going to have to investigate why this would be happening. Is there any particularly configuration of the youzify plugin we should pay attention to, in order to be able to reproduce this?

Hi

Okay, this helps me know that you’re not using multiple logging systems. When you’re looking at the Activity Log, the meta data (such as HTTP response code) is based on the underlying traffic log data – they use the same data. We need to be sure we’re looking at the correct data.

The best thing here is to show an example of what you’re seeing.

So on your Activity Log, if you can locate an entry that you feel is “incorrect”, can you take a screenshot of it – feel free to blur the IP, it doesn’t matter here. I’d like to seen the log message and also if you click on the little “meta” icon on the right-hand side of the row, this will display your traffic log meta data. Can you take a screenshot of this and display it somewhere for me to see exactly what you’re seeing?

So your screenshot would show:

• The activity log entry message
• The corresponding traffic log meta box

e.g.

Hi,

I’m not sure I understand what exactly you’re saying. If Shield is saying they’re 200 in the log, then they’re not triggering false 404s in the logs.

You said “but showing response 200 in the traffic log” – which traffic log is that? If it’s Shield, then it’s not considered a false 404. Shield relies on WordPress’ own determination of what is a 404. It doesn’t try to make this determination on its own.

If you could clarify exactly what you’re seeing, and with what tools, that’d help us narrow down if there’s a bug somewhere.

If you’re using 2 separate WP activity log plugins, this isn’t something we can fix. 2 different plugins may log things slightly differently and we can’t mitigate for that.

In Shield’s own traffic log, where it says 404, have you tried accessing the URL that triggered this? Is it really a 404? Does it matter if you’re logged-in, or not?

Thanks,

Hi,

Thanks for reaching out to us about this.

So we need to be clear about what exactly we’re looking for when we’re looking at the logs. There are 2 types of logs: WordPress Activity logs, and Traffic/Request logs.

The traffic and pages requested would only be showing up in the Traffic/Request logs if:

• you’d enabled the Traffic logging option
• and the requests weren’t excluded. If you’re in-doubt, turn off all traffic logging exclusions
• typically normal browsing requests won’t show up, as they’re excluded by default.

The actual user activity relating to WordPress would show up in the activity log only if:

• the logging is enabled (which it is, since you said your activity was being recorded)
• perhaps your store is creating/logging in users in an irregular manner. Shield will do its best to capture all logins, but sometimes a store will create a new user & log them in all in the one the request, and this can be done outside normal WordPress flows. Shield will try to capture this also.

Have you tried opening the Activity Log and under the Events filter, filtering by “user registered” or “User Login” ?

I would find it entirely strange that Shield didn’t capture this activity.

Remember, you’ll need to use the correctly logging type depending on what you’re trying to review: WordPress Activity or Traffic/Requests.

Also, as Jelena has mentioned, if you’re making heavy use of Page Caching, these may also not show up in the Request Logs as they won’t trigger WordPress or Shield.

Great, very glad you were able to solve the issues! ??

Hi,

Is there a reason you didn’t post on the support forum first to see if there was a way to mitigate that?

You may be using the security option to prevent iFrames – if that’s the case, the plugin is working as expected. Other than the HTTP Headers option, there’s nothing in Shield that would directly cause that.

Hi,

Thanks for reaching out to us about this. If Shield is blocking anything, it’ll be detailed in-full in the Activity Logs. This is the best way to discover where you might need to tweak your settings. My suggestion is to reproduce the issue, then go immediately to the logs and see what’s in there. If you need help to interpret what you see, let us know, but it’s usually self-explanatory.

Shield never blocks access to writing to the .htaccess file, or any files for that matter.

Let us know what you find.

Thanks!

I’m glad to hear the issues are resolved, at least for now.

We’ll continue to do everything we can to optimise Shield’s performance, but I’m confident that contributing to the autoload won’t be directly causing you Gateway Errors.

Let me know if you do see the issues again and what you do to resolve it or identify the cause.

Thanks!

Hi Rebecca, ??

It’s interesting you say you’re hosting with WP Engine and you’re seeing Gateway Errors. We had another customer that is in the same position as you, with the same problem. They run 90+ websites on Shield and this is their only site showing the errors.

The WPE team again pointed to autoloading. We explained to our customer and this is not what causes the problems you’re seeing. Certainly since 90 other sites don’t show this Gateway Error. Our client did share another error they’re seeing and they’re running WooCommerce and this is more likely to be the issue as it’s hitting access denied errors when trying to read files that they appears they shouldn’t be:

[2024-05-02T14:46:38.759504+00:00] PHP Warning: parse_ini_file(/etc/php/8.2/fpm/php.ini): Failed to open stream: Permission denied in /wp-content/plugins/woocommerce-square/vendor/apimatic/jsonmapper/src/JsonMapper.php on line 130
[2024-05-02T14:51:15.571001+00:00] message repeated 3 times: [ PHP Warning: parse_ini_file(/etc/php/8.2/fpm/php.ini): Failed to open stream: Permission denied in /wp-content/plugins/woocommerce-square/vendor/apimatic/jsonmapper/src/JsonMapper.php on line 130]

Are you also running the “Woocommerce Square” plugin (I don’t know the name, just the slug of the plugin).

For some reason WPE support staff are pointing to the autoloads. This isn’t likely the problem… a gateway error is a critical error in the web host and will likely populate the logs. My suggestion is to respond to the support staff and ask them to provide you with any errors, not “guesses” about the state of the site, which is what they’re doing.

If your autoload is too high and beyond their ability to handle, then you wouldn’t be able to load your WordPress site at all… since autoloads are on every page load.

There were some changes brought into Shield to optimise options storage which would ultimately reduce autoload size, but the post-changes-cleanup isn’t in the Shield plugin yet as we want as many people to complete the upgrade to 19.1 as possible before we clean-up old data.

So to summarise, I understand you’re being told something by WPE support, but it’s a good idea to push back and ask them that, since their hosting is throwing out Gateway Errors, their hosting should also be logging this and they should point to the actual errors logs they’re seeing.

We’ll probably include some cleanup of the older Shield data options in our next release, but again, we’re highly doubtful that this is the problem and it’s interesting that only WooCommerce + WP Engine are the only reports of this issue.

Let me know how you get on, and thanks for reporting this.
Thanks, Paul.