efc

This was on a popup.

Yes, I discovered the CSS work-around already. However, that is not documented and the need for this outside the CSS customization you make available in the plugin itself is very odd.

Instead, the plugin really should leave this mask in place even for “vanilla” themes.

Ah, Brady, perfect!

It might be nice to mention that more clearly in the readme or include a screenshot of that manage sidebar page.

Thanks for this great plugin.

Sucuri is great and all, but this is a terrible way to clear this cache. Since the file was created by Sucuri and the Sucuri plugin is running on the server, this is really a problem that should be resolved BY THE PLUGIN!

That “Site is not clean” box should include a button labeled “Recheck” that forces the plugin to delete the local file and run the Sucuri check again, then reloads the dashboard.

• This reply was modified 6 years, 8 months ago by efc.

(sorry, I put this in a new topic)

This appears to be a consequence of WP 4.5 adding the singular class to the body for itself. TwentyEleven assumes that it can prevent the singular class from being present on certain page templates, but this is no longer the case. For now this can be fixed by using a child theme of TwentyEleven and adding this to your child theme’s functions.php file:

function twentyeleven_body_classes_fix( $classes ) {

	if ( is_home() || is_page_template( 'showcase.php' ) || is_page_template( 'sidebar-page.php' ) ) {
		$index = array_search('singular', $classes);
		if ( $index !== false ) unset($classes[$index]);
	}

	return $classes;
}
add_filter( 'body_class', 'twentyeleven_body_classes_fix' );

See ticket #36510 for more information.

This appears to be a consequence of WP 4.5 adding the singular class to the body for itself. TwentyEleven assumes that it can prevent the singular class from being present on certain page templates, but this is no longer the case. For now this can be fixed by using a child theme of TwentyEleven and adding this to your child theme’s functions.php file:

function twentyeleven_body_classes_fix( $classes ) {

	if ( is_home() || is_page_template( 'showcase.php' ) || is_page_template( 'sidebar-page.php' ) ) {
		$index = array_search('singular', $classes);
		if ( $index !== false ) unset($classes[$index]);
	}

	return $classes;
}
add_filter( 'body_class', 'twentyeleven_body_classes_fix' );

Yup, me too. Something in the twentyeleven theme’s “Sidebar Template” design was messed up in the upgrade to 4.5. I can use both v2.3 of the theme and v2.4 of the theme and see the same problem. No solution yet, but this makes it pretty clear the damage was done by something new in WP itself, not by a change to the theme.

There are a couple plugins that will disable this emoji insertion. This disable emojis plugin is one of them.

In my case I cannot use such a solution. My plugin is itself very minimal and should not be doing anything like disabling emojis for the site on which it is installed.

All in all, this seems like a terrible decision on the part of the WordPress team. I just don’t understand either the decision (which seems to date back to WordPress 4.2) or why it seems to have expanded in scope with WordPress 4.4.1.

Oh sweet irony. I just noticed that the umbrella code '☂' (that’s '&#9730') renders as proper unicode here on this site.

So WordPress has decided to force all our sites to translate this character into a crummy img version, but here at www.remarpro.com they will let unicode keep rendering properly?

This should tell us something, but I’m not quite sure what!

Taking a closer look I find the following two changes resolve WP_DEBUG warnings. Someone with deeper knowledge of the plugin should verify these and commit them to the plugin source.

Fixing script enqueuing… on line 253 of zotpress.php…

if (!isset( $GLOBALS['wp_scripts']->registered[ "jquery" ] )) wp_enqueue_script("jquery");

…replace with…

function Zotpress_enqueue_scripts() { if (!isset( $GLOBALS['wp_scripts']->registered[ "jquery" ] )) wp_enqueue_script("jquery"); } add_action( 'wp_enqueue_scripts','Zotpress_enqueue_scripts' );

Dealing with has_cap deprecation… on line 161 of zotpress.php…

add_menu_page("Zotpress", "Zotpress", 3, "Zotpress", "Zotpress_options", ZOTPRESS_PLUGIN_URL."images/icon.png");

…replace with…

add_menu_page("Zotpress", "Zotpress", "edit_posts", "Zotpress", "Zotpress_options", ZOTPRESS_PLUGIN_URL."images/icon.png");

Once I fixed these, the warnings went away and Zotpress appeared to still function.

Clifford, thanks for this temporary fix. I ran across this too, and the other thread did not mention how to fix the error. Ron, I hope this can become part of an update to the plugin.

I could not get get_current_site() to work, but I did find that commenting out two lines of sunrise.php as specified here does the trick. Since sunrise seems to set the $current_site variable twice, there don’t seem to be ill effects to eliminating the redundant code.

It would be nice if the plugin were updated with this fix.

5.0.4 broke our WP 3.8.2 multisite “network” install with error messages like those described by @photomaldives. A quick rollback to 5.0.3 resolved the problem.

Thanks, Ben. You’ve been busy!

Thank you, Ben.