Matt Bernhardt

We recently noticed that this message is being generated quite often (on the order of every page load, it seems – which for us is a few hundred thousand messages per month). Looking through the plugin code for the last few versions, and reviewing the message, I see the following:

Release 1.6.12 introduced a log_error() method to the GalleryPlugin class. This class is then extended by the SlideshowErrorHandler class, which re-implements its own log_error() method – but with different arguments. This is the cause of the problem, because the child class’ definition conflicts with that of the parent class.

Looking further through the plugin code, I don’t actually see anything that would call the parent object’s log_error() method – so it may be that the solution to this is to remove the log_error() method from GalleryPlugin.

I also wonder whether reverting to the last release of the plugin (1.6.11 as I type this) would resolve the problem. The code I’m finding here appears to have been introduced in 1.6.12 specifically.

Marking this as closed…

Sigh…nevermind. This was a problem with our we were implementing the custom field. In case anyone later ends up making this mistake, the problem was that we were invoking the custom field with the tag only, not the tag and a name. So instead of

[select_dlc department]

We were using just

[select_dlc]

Once we added the field name explicitly, the field started appearing in the expected places.

Sigh…nevermind. This was a problem with our we were implementing the custom field. In case anyone later ends up making this mistake, the problem was that we were invoking the custom field with the tag only, not the tag and a name. So instead of

[select_dlc department]

We were using just

[select_dlc]

Once we added the field name explicitly, the field started appearing in the expected places.

Takayuki, would you be open to my sending in a patch for this plugin to add this step? Or should this continue to be something that we implement via a custom plugin on our site?

In case others find this thread, this is the custom validation function that I’m hoping to deploy later this week (it still needs to pass code review, but tests so far have shown that it works to prevent hijacking of select and radio fields)

/**
 * Implements custom validation for radio fields.
 *
 * @param object $result A WPCF7_Validation object.
 * @param object $tag    A WPCF7_FormTag object.
 * @link https://contactform7.com/2015/03/28/custom-validation/
 * @link https://www.ads-software.com/support/topic/protection-against-form-hijacking/
 */
function validate_options( $result, $tag ) {
	// Check if the field value is not empty.
	if ( ! empty( $_POST[ $tag->name ] ) ) {
		// Look up the received value in the array of expected values.
		$value = sanitize_text_field( wp_unslash( $_POST[ $tag->name ] ) );
		if ( ! in_array( $value, $tag->values ) ) {
			$result->invalidate( $tag, 'Unexpected value received' );
		}
	}
	return $result;
}
add_filter( 'wpcf7_validate_radio', 'validate_options', 20, 2 );
add_filter( 'wpcf7_validate_select', 'validate_options', 20, 2 );
add_filter( 'wpcf7_validate_select*', 'validate_options', 20, 2 );

• This reply was modified 6 years, 6 months ago by Matt Bernhardt. Reason: edited for typo in function comment

Fair enough – after code review with another developer here, we’ve chosen to remove the nonce check entirely anyway, and just add the failing test to our whitelist.

Thanks for your quick responses! I’m marking this as closed now.

So should I ignore the code validation errors on a validation function like this?

function validate_dlc_filter( $result, $tag ) {
	// Check if the field is marked as required.
	if ( 'select_dlc*' == $tag->type ) {
		// Has the DLC name been set?
		if ( empty( $_POST['department'] ) || '' == sanitize_text_field( wp_unslash( $_POST['department'] ) ) ) {
			$result->invalidate( $tag, 'Please specify your department, lab, or center.' );
		}
	}
	return $result;
}
add_filter( 'wpcf7_validate_select_dlc*', 'validate_dlc_filter', 20, 2 );

When I run this through PHPCS using the WordPress coding standards, I get flagged for “Processing form data without nonce verification.” – the actual standard mentioned is WordPress.CSRF.NonceVerification.NoNonceVerification

That worked! Adding the .wie file extension as application/json to Media Library Assistant allows the upload and import to proceed correctly with all plugins enabled.

Thanks for all your help – I’m marking this as resolved at this point.

Great! I’ll look into that as an option. Thanks for all your help so far.

Enabling the network-level plugins one at a time seems to indicate that the issue is with Media Library Assistant ( https://www.ads-software.com/plugins/media-library-assistant/ ). The import happened without incident with the other four enabled, but as soon as that was added to the mix, I got the error message.

I’m still looking to see if other plugins on our network are also the problem, or just this one.

I was able to import the .wie file after disabling all the network-level plugins on my local server. It appears that the widgets provided by disabled plugins are not imported however, nor are settings provided by disabled plugins?

This is tricky to move forward, if this is the case. In order to successfully transfer the widgets, I need to identify which plugins provide all the settings – and hope that none of them are the ones that prevented the original import from happening.

My next steps are going to be to delete the widgets and re-run the import with each plugin enabled – to try and identify which network-level plugin(s) caused the problem.

Yes, the file has the .wie extension. The full name is “wordpress-giving-widgets.wie” as downloaded. And yes, I remembered to upload the file using the “Choose File” button. I don’t see a way to easily post a screenshot.

I’ll email the file momentarily, but for the sake of posterity I’ve also posted it as a GitHub Gist: https://gist.github.com/matt-bernhardt/e9544d740bd7b687e8f220ca99d98772 . There are two revisions there, the first is the minified file as downloaded (with five widgets, so still using the all the plugins). The second version was de-minified using JSONlint – but that is for readability only. The version I’ve uploaded is the originally-downloaded version.

I would like to echo this question. We have a multisite installation with about two dozen sites, and clearing caches across the network is getting to be cumbersome. While the option to do so only for a single site is a useful feature, I’m also looking for a way to clear the entire network.

It looks like we’ve got 4.0.7 in place. This looks like the final version in the 4.x branch?

I’m guessing that you’ll recommend upgrading to the 5.x branch? I haven’t been active in the WordPress community for long enough to know what the implications of major plugin versions are.