cagsmith

Our customer deactivated and reactivated this plugin and then this error (most recent one) showed up. Apparently they were requested to do… something… by the plugin (they didn’t enlarge upon what exactly that was) but that error then stopped. Deactivating and reactivating also appears to have created the originally missing table, wpsf_ip_rules, and no more errors are being logged, so this appears fine now! Thank you for your time ??

Hi there, I see this error now – you wanted to be notified in the event there were any create errors:

[29-Mar-2023 13:47:04 UTC] WordPress database error Can't create table database_wor1.edh_icwp_wpsf_scanresults (errno: 150 "Foreign key constraint is incorrectly formed") for query CREATE TABLE edh_icwp_wpsf_scanresults (
                id int(11) UNSIGNED NOT NULL AUTO_INCREMENT  COMMENT 'Primary ID', 
scan_ref int(11) UNSIGNED NOT NULL  COMMENT 'Foreign Key For Primary ID', 
resultitem_ref int(11) UNSIGNED NOT NULL  COMMENT 'Foreign Key For Primary ID', 
created_at int(15) UNSIGNED NOT NULL DEFAULT 0 COMMENT 'Created', 
PRIMARY KEY  (id), 
FOREIGN KEY (scan_ref) REFERENCES edh_icwp_wpsf_scans(id) ON DELETE CASCADE ON UPDATE CASCADE, 
FOREIGN KEY (resultitem_ref) REFERENCES edh_icwp_wpsf_resultitems(id) ON DELETE CASCADE ON UPDATE CASCADE
			) DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; made by require('wp-blog-header.php'), require_once('wp-load.php'), require_once('wp-config.php'), require_once('wp-settings.php'), do_action('plugins_loaded'), WP_Hook->do_action, WP_Hook->apply_filters, icwp_wpsf_init, require_once('/plugins/wp-simple-firewall/plugin_init.php'), ICWP_WPSF_Shield_Security->start, FernleafSystems\Wordpress\Plugin\Shield\Controller\Controller->boot, FernleafSystems\Wordpress\Plugin\Shield\Controller\Controller->loadModules, FernleafSystems\Wordpress\Plugin\Shield\Controller\Checks\PreModulesBootCheck->run, FernleafSystems\Wordpress\Plugin\Shield\Modules\Base\Databases->loadAllDbHandlers, FernleafSystems\Wordpress\Plugin\Shield\Modules\Base\Databases->loadDbH, FernleafSystems\Wordpress\Plugin\Core\Databases\Base\Handler->execute, FernleafSystems\Wordpress\Plugin\Core\Databases\Base\Handler->run, FernleafSystems\Wordpress\Plugin\Core\Databases\Base\Handler->tableInit, FernleafSystems\Wordpress\Plugin\Core\Databases\Common\AlignTableWithSchema->align, FernleafSystems\Wordpress\Services\Core\Db->doSql

Hey there,

Right… but this doesn’t actually address the issue at hand, where the missing table is causing hundreds and hundreds of errors to spew into error_log.

So, is there a way to trigger the plugin to check for and create (if not existing) the tables that it needs?

I did install this plugin on an external staging site (not related to the specific site with this problem) and figured I could get around the issue by exporting and importing the specific missing table, but I get this when importing the table:

Foreign key constraint is incorrectly formed

Hi there,

Thanks for the reply! It was necessary to remove the error log unfortunately because the log was causing the account to max out their available disk space so we’re unable to look for any historic CREATE errors.

Disk space is presently normal – including for MySQL and there’s no reason why a new table wouldn’t have been able to be created.

It is conceivable that this table might have been created (or tried to have been created) at a time when the account had previously exhausted their available disk space, thus resulting in this error.

Can confirm – have tested on a number of our customers and updating WP Recipe Maker appears to resolve the issue! Thank you for the investigation and resolution!

Hey there,

Sorry, life got in the way, I completely forgot about this. Thank you for your reply. One way you could check if APO is active or not is to curl the homepage URL and check the headers. The following will be present if the page is cached via APO

CF-Cache-Status: HIT
cf-apo-via: tcache

I completely agree – if someone is *not* using APO then they can equally use the CloudFlare integration in LSCWP – no argument from me there.

I understand as well the desire to not have it break certain features in LSCWP – perhaps it would be possible to change the wording of the message which appears in the dashboard?

Something like:

It appears that you are using the official CloudFlare plugin. Unless you are using CloudFlare’s Automatic Platform Optimization feature you may wish to consider using LiteSpeed Cache’s built-in CloudFlare integration module.

You can check if you are using CloudFlare’s APO feature here [LINK TO CLOUDFLARE SETTINGS PAGE] – check if the switch is toggled to “On”. Click here to disable the CloudFlare plugin and then go here [LINK TO LSCWP CLOUDFLARE SETTINGS PAGE] to connect LiteSpeed Cache with CloudFlare

It’s certainly more verbose, but a more helpful message in my opinion.

if I recall correctly , last time I check the APO is needed/used for WP page caching, so by APO activation present , that would determine the site is running on CF APO , therefore give a reminder the possible conflict and suggest to disable

Sorry, I don’t quite understand what you mean here.

However, you don’t need to do any checks about whether or not APO is active in CloudFlare. The only thing you need to check is whether CloudFlare API details are filled out in LiteSpeed Cache. If they are *not* then such a message should not be shown. It’s not useful and is misleading and confusing to end-users. More than one of our users has already disabled the official CloudFlare plugin and killed the ability for CloudFlare to purge it’s cache because they followed the advice in this notification.

These are users who are not using CloudFlare functionality in LiteSpeed Cache.

If what you are saying is that you’re already checking if APO is active and telling users that this may interfere with page caching from LiteSpeed Cache then from a user experience perspective it makes *more* sense to let them know exactly what/where this conflict may be, and to actually recommend them to disable page caching in LiteSpeed Cache. Since CloudFlare APO is a paid feature which is proven to offer incredibly fast response times on cached pages (usually around 40ms-50ms) that seems like the better solution.

Further – I’m aware that the notice can be dismissed, but I’ve seen several times when it’s dismissed and shows right back up again later.

Thanks Kyle – I can confirm the update appears to have corrected this issue now!

Hi Peter,

I think we tracked this down now – the new way that Wordfence 2FA now works appears to conflict with a firewall rule we have in place and was returning a 402 response on wp-login.php for affected users.

I’ve disabled this rule presently – we’ll see how it plays out but this should hopefully now be resolved.

Hi there,

There is a caching plugin, but this gets cleared whenever a plugin is updated.

The issue persists when using a new browser/incognito mode.

Additionally, the issue goes away immediately when reverting to a previous version of wordfence.

Incidentally, in case anyone else has this issue, the secondary 2FA screen can be bypassed by entering the OTP after the password on the main login screen (for example, if your password is Secret123, and your OTP is 123456, you’ll enter your password as: Secret123123456) – this will permit login until Wordfence can review/address this.

Have you verified that the firewall is in “learning mode”? If you immediately set it to active it doesn’t “know” your site yet and may well block needed features.

Also – it sounds like you may be using something like Autoptimize, or a caching plugin which manipulates CSS/JS… be sure to purge any caching and so forth.

I understand this, but the issue is not with Imagify. Imagify works fine under all circumstances… except when this plugin is activated – and then the button action fails to work.

Can confirm here too. Updated this plugin on a customer’s site on the 7th – since then admin-ajax requests have been completely out of control. Took me a while to identify the cause but this was indeed it.

I’ve also seen about 7 reports of this through today from some of my customers… Problem seems to be that the .htaccess file in wp-content/cache/Autoptimize has permissions 0600 instead of 0644 but other than this, this is new to me – nothing on the servers were changed and there were no updates overnight.

Thought it might be a conflict with W3 Total Cache at first but then saw some users who didn’t have this plugin and only Autoptimize…