jakeparis

Thank you. You are correct that the wsblc_options row in the database was causing the problem. Simply deleting that row so the plugin could re-create its options solved the issue.

The data was stored in an incorrect format which was probably caused from the plugin being activated a long time ago and then turned off for many years.

Thank you for the helpful information.

Actually, I’m incorrect. Adding that to wordfence-waf.php stopped the errors during cli commands, but now there are plenty of errors (the same error) in our regular php logs. So I re-added

if( ! defined(‘WFWAF_STORAGE_ENGINE’)) {
define(‘WFWAF_STORAGE_ENGINE’, ‘mysqli’);
}

to our wp-config.php (so now I have both), but still the errors persist.

Hello @wfpeter . I just wanted to close the loop on this. My error was that I added the define('WFWAF_STORAGE_ENGINE', 'mysqli'); line to my wp-config.php. Which is ok, only if there is no wordfence-waf.php file. Since I had the wordfence-waf.php file, I should have added the constant there.

I moved the constant definition to wordfence-waf.php and all the cli errors are gone.

Thanks for your response @wfpeter . I confirmed we are running both mysqli and mysqlnd extensions in both web server and cli environments, and they are the same configs and version on both.

One possibility problem I can think of is that we are running an older version of MariaDB (10.3.27). I wonder if there are things that are not available in this earlier version Mariadb that might causing the problem. I do think that’s a long shot, however, due to the fact that WF seems to be running just fine from the UI.

Would it make sense to attempt to bypass WF if the wp-cli is running? Or is wordfence providing some level of protection from there as well?

This is a custom shortcode for the theme. You can see it here. You can see on line 47 where I’ve added the “publish” post_status to make it work as expected.

And they are using it like this: [news-posts categoryid="2" count="6"]

Thanks @shawfactor , I can confirm that explicitly adding the post_status="publish" does solve the problem. This is odd however, because the default for WP_Query is supposed to be only items with the “publish” status (unless you’re logged in, then you get “private” too).

The client has your config set to “Can Archived Posts be read publicly”:”Yes, but not in the main loop, frontpage, or feed”. I would expect this to apply to any loop of posts, including the core “Recent Posts” block (which I haven’t checked to see how this applies to that).

Is there perhaps a tweak needed in your plugin, so that your added “archive” status doesn’t get added to the default list of statuses when making a query? I haven’t investigated the code, so I wouldn’t know where to make a suggestion, but maybe this rings a bell for you.

My query loop is happening inside a shortcode. So, yes, you are correct, this isn’t the main loop, but I would expect the archiving to “just work” in that context anyway.

Thanks for your help and time.

• This reply was modified 2 years, 3 months ago by jakeparis.

Made an issue in Gitlab for this.

It looks like the default login input fields are being hidden with some css:

.login #loginform p {
      display: none;
}

But the password is not in a <p>. Its markup is like this:

<div class="user-pass-wrap">
	<label for="user_pass">Password</label>
	<div class="wp-pwd">
		<input type="password" name="pwd" id="user_pass" class="input password-input" value="" size="20">
		<button type="button" class="button button-secondary wp-hide-pw hide-if-no-js" data-toggle="0" aria-label="Show password">
			<span class="dashicons dashicons-visibility" aria-hidden="true"></span>
		</button>
	</div>
</div>

• This reply was modified 3 years, 3 months ago by jakeparis.

Just for future readers, this one-star rating is silly; the plugin does what it advertises, which is to provide a block allowing an iframe.

Thank you for your help. We believe the issue was due to aggressive php caching on the server. We cleared the opcache and the issue was resolved.

Yes, I deleted all the folders/files as stated above, and I removed all the #w3tc .htaccess blocks. Noting also that this site is hosted on AWS and php5x if that makes any difference.

I’m had this same issue upon upgrading from 0.13.1 to 0.13.2. I’ve tried the above steps. Upon trying to re-activate the plugin, I get the following fatal error:

Fatal error: Class 'W3TC\LazyLoad_Plugin_Admin' not found in /var/www/html/wp-content/plugins/w3-total-cache/Root_Loader.php on line 49

I tried to activate the plugin from wp-cli, and the whole site goes down with a 500 error.

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

Coming back to this later… It’s true that the type: shortcode doesn’t work with a transform key function. The best solution I came up with was to use the type: block and manually parse the shortcode attributes and innerContent.

I wrote a post about it here: https://www.bates.edu/webtech/2019/10/07/switching-from-shortcodes-to-blocks-part2/

Fixed. This had to do with upgrading; the newer version required different javascript paths, for example:
wp-seo-modal-1180.min.js (version 11.8)
wp-seo-modal-1170.min.js (version 11.7)

And the php cache hadn’t cleared after update, so the php was still asking for the 1170 version of the file, but it didn’t exist anymore. Fixed this by clearing php cache.