consultant1027

This I think is part of the Advanced Reporting plugin?

Hmm.. installed advanced reporting and see no change!

At a loss.

• This reply was modified 5 years ago by consultant1027.

Huh? I don’t understand how this reply is relevant to the discussion as the question/discussion has nothing to do with Litespeed or whether or not .htaccess IP banning works in the first place. This is a discussion about IThemes Security regardless of the webserver type.

What is strange is I have several websites running iThemes that get a lot more traffic, have Local Brute Force Protection enabled and none of them have IP exclusions in the .htaccess file.

There’s a database table: wp_itsec_lockouts and it appears it puts all the lockout IP addresses in that table and not in the .htaccess file.

So either it’s another feature in iThemes that does it and maybe I don’t have it enabled on those other sites, or, has to do with another setting change.

This brings up the question… there’s quite a few lockout settings and most are understandable but I’m not really clear on whether IPs in the wp_itsec_lockouts are permanent and never removed unless manually removed or will they be cleared from that table eventually based on which setting?

I see now iThemes added malware scanning and is actually using Sucuri for it. So I think Sucuri would overkill if you run iThemes, however I like the Dashboard and logging displayed much better on Sucuri so I have most everything turned off except some of the hardening functions os iTheme. They seem to work fine together.

What does “automatically scheduled” mean? Does that mean I have no control over the schedule and if so, how does Wordfence decide when to schedule a scan?

Note that this will only result in a marginal speed increase (if you’re doing this for speed reasons).

If this results in only a marginal speed increase either this is inferring (a) Wordfence has a negligible decrease in speed with all the options turned on, or, (b) Wordfence is still doing decreasing the speed (as opposed to no Wordfence installed) despite turning off the options? If the answer is (b), what is it doing to decrease the speed?

Thanks for the quick reply. I already have H1 coded, but I’m wondering how the Google Search Engine Bot would pick up the WordPress Page/Post Title, through what tags does it read these?

I searched the entire source code of the page for the WordPress Page Title and it’s nowhere in the source code. I thought, maybe it’s being used in the sitemap, nope. So I fail to see how the internal WordPress Post/Page title has any SEO significant if that data can’t be access by Googlebot?

I found a similar thread that used CSS but it was using the wrong class. By adding this right before the shortcode you can hide the category title.

<style>
.ufaq-faq-category-title { display: none; }
</style>

Being a developer for 30 years and user of hundreds of software applications, after 5 months of use of iThemes Security, I would not describe it as a “well maintained” product. Several quirky/buggy things I’ve observed in a just the first few months. However it’s more configurable than other security plugins allowing me to turn off a lot of unnecessary stuff, some of which duplicates what my firewall (CSF/LFD) already does. Gotta take the good with the bad.

Being a developer myself, I can’t understand why a developer would not patch a serious bug like this in all versions as the core code would be the same.

I like iThemes Security because I have other security (CSF LFD Firewall) and needed a solution that I can configure to be lightweight and not duplicate security functions I already have but to be honest I have seen many strange themes with this plugin in the 5 months I’ve used it like this error being discussed and periodically (no pattern) getting database backup emails, 5 in a row, when I have database backup disabled and have not made any settings changes. It is worrisome when a security plugin is behaving inconsistently and even more worrisome that they are not applying bug fixes consistently across all versions.

• This reply was modified 7 years, 4 months ago by consultant1027.

It just happened again for me and I can confirm it is indeed iThemes Security and only when using the Hide Backend feature, and only with Chrome as discussed here:

https://www.ads-software.com/support/topic/hide-backend-causes-500-error/

The Pro version has been fixed but not the free version yet which is strange.

There are multiple temporary fixes – the keyword being TEMPORARY.

– Clear Chome cookies (not recommended as other user’s using Chrome could experience the same issue (I suspect it might only have to previously logged in users but not sure.)

– Rename better-wp-security folder in wp-content/plugins, login and go to plug-ins admin page, rename folder back, refresh plugins page

NOTE: Simply deactivating and reactivating the plugin (via Firefox or Chrome with cookies cleared) did NOT fix the problem for me, only the folder rename method.

PERMANENT FIX

For now, I have disabled Hide Backend until I hear the Free version has been fixed.

I like iThemes Security because I have other security (CSF LFD FIrewall) and needed a solution that I can configure to be lightweight and not duplicate security functions I already have but to be honest I have seen many strange themes with this plugin in the 5 months I’ve used it like this error and getting database backup emails, 5 in a row, when I have database backup disabled and have not made any settings changes. It is worrisome when a security plugin is behaving inconsistently!

I don’t think I found those memory errors, where is the location of the log?

A similar symptom is being discussed here and seems to be leading to iThemes Security as the cause but no solution yet.

https://www.ads-software.com/support/topic/500-error-only-with-chrome

Something similar being discussed here which appears to be leading towards iThemes Security as the culprit. No solution yet.

https://www.ads-software.com/support/topic/500-error-only-with-chrome

• This reply was modified 7 years, 4 months ago by consultant1027.

Good point. I believe I read somewhere, that is another method to rename the folders. It would be the option for those who are not developers like myself familiar with using something like PHPMYAdmin to access the database.

So for now the problem hasn’t resumed. Not sure if something updated to fix it (I have automatic non-core updates)

I’m wondering if people in this discussion who have experienced the problem can confirm if the do or don’t have Divi Theme or iThemes security. If there’s even one user that does NOT have both of them and experienced the problem, that it would be a bug in WordPress 4.8. My suspicion is that it is iThemes security since disabling all plug-ins fixed the issue which would indicate it’s not a WordPress bug. Divi theme I don’t think is doing anything unusual with cookies. So that leaves iThemes Security. Maybe I will pose the question in the iThemes forum too.

Out of the plug-ins you listed I have:

Divi Theme
iThemes Security

However as I mentioned, when I disabled all plugins, I could get back in, but then I renabled all plug-ins one by one and error 500 did not return! So I was unable to identify a plug-in causing it even though going into the wp_options table and deleting the active_plugins record to disable everything seems to fix it!

So it seems if it is a plug-in causing it, disabling and re-enabling plugin also clears the problem.

So next task when it happens again would be to disable plug-ins via database record, one by one.

I am having the exact same problem. It started happening shortly after upgrading to version 4.8. However it is very strange. Mine was happening on any page, like home page. I found that if I went into the database and deleted the active add-ons record to deactivate all add-ons, that solved it. But then I re-enabled each add-on one by one and tested and none of them broke the system.

A couple days later, Error 500 again. So I loaded Firefox, no Error 500. Went back to Chrome, cleared my cookies, Error 500 gone. Here’s the main concern though, I searched the Apache error log and the error is [core:error] End of script output before headers: index.php. I’m a developer and know how to track down Error 500 errors (or at least I thought so). There is no PHP error log showing the error and turning on Worpress debugging also created no log events. So I was never able to determine the cause.

My BIG concern is if I search my logs I will find that same error but from other IPs which means other end users could be getting this error! A major disaster for my business this website is advertising if that is happening. Unfortunately Google Analytics isn’t going to give accurate 500 stats unless I create a custom error 500 page and add the analytics code to it I guess.