Ben1098765

Done with thanks @qriouslad ??

Hi @wpmansour – thanks for the response! Unfortunately that didn’t work for me either. Logging out capabilities using Query Monitor and the admin_notices hook, I was able to determine that the capability was being set for the Editor role, but the top button just wasn’t showing.

However, in case anyone may find this useful, I ended up fiddling around and came up with the following, which does work:

// Function to add "Clear Cache" option to Editors
function add_clear_cache_for_editors()
{
	if (current_user_can('editor')) {
		// Add custom "Clear Cache" item in the Admin Bar
		add_action('admin_bar_menu', function ($wp_admin_bar) {
			$wp_admin_bar->add_node([
				'id'    => 'clear-cache',
				'title' => 'Clear Cache',
				'href'  => wp_nonce_url(admin_url('?action=editor_clear_cache'), 'editor_clear_cache_nonce')
			]);
		}, 100);
	}
}
add_action('admin_init', 'add_clear_cache_for_editors');

// Handle the cache clearing action
function handle_editor_clear_cache()
{
	if (isset($_GET['action']) && $_GET['action'] === 'editor_clear_cache' && current_user_can('editor')) {
		// Verify nonce for security
		check_admin_referer('editor_clear_cache_nonce');

		// Trigger WP Optimize cache-clearing function if available
		if (function_exists('wpo_cache_flush')) {
			wpo_cache_flush();
			wp_redirect(admin_url()); // Redirect to avoid repeat action on refresh
			exit;
		} else {
			wp_die('Cache clearing function not available.');
		}
	}
}
add_action('admin_init', 'handle_editor_clear_cache');

I did use a smattering of chatgpt to help me to get this point, so no guarantees on the quality, but it works for me in this instance.

Hi – I have the same requirement. I’ve added the above script to functions.php, but it didn’t work (nothing showing in the top admin bar). I then tried it with a completely separate and fresh installation of WordPress, and again nothing showed when logged in as Editor.

I also tried the User Role Editor plugin in the the fresh installation as you also suggested, adding the “wpo_manage_cache” to the Editor role. That didn’t work either.

In all cases “Enable the caching menu in the admin bar” was enabled in the settings, and “Enable page caching” was turned on.

Any ideas what may be wrong? Are you able to make this work in a fresh installation?

Thanks in advance!

Oh sorry, you know what, I misread your comment Bowo; I thought 7.4.7 was the fix. My bad. I downloaded the fixed plugin you referred to and the error has indeed gone.

If it helps, I’m using LocalWP on a Mac, wp-config in the root folder as standard, and no, DISALLOW_FILE_EDIT is not defined in there.

So what whatever you did gets the green-light from me! Thanks for the great plugin ?? Made my life a lot easier over the past 8 months!

FYI, appears Media Library is also broken unless I deactivate ASE: https://ibb.co/gF0FGR9

I’ve just had this show up in my admin too. I was previously working on a staging instance, ported the site back to a local instance (using All-in-One Migration if relevant), and found this in the local instance. Both the staging and local were on 7.4.7.

The staging still doesn’t have the message.

Sorry, changing to defer in class-lazy-load.php didn’t make any difference. It blanked the thumbnails about as often as previously. Interesting point about the script order though. That’s useful to know for the future as I do build a lot of my own functionality.

I do have access to the visible “on-page” original HTML as that’s custom built. What I don’t have access to is the lightbox HTML, which is generated by LightGallery.js at runtime, using the original HTML as a reference for the elements to create.

I’m happy to leave this as it stands though. I expect my issue is so niche that it’s probably not worth spending much more time on. Your initial thoughts lead me to a workaround that works satisfactorily for now, even if it is a little clumsy, so thank you! ??

Right, so I’m pretty certain it is a race condition. I’ve added a 150ms delay to the initialisation of the gallery code, and it seems to be loading most of the time (very occasionally it won’t load).

I originally tried calling the plugin as a dependency of the theme script, but that didn’t seem to work; in brief:

wp_enqueue_script(‘my-script’, $js_file, array(“eio-lazy-load”);

Any reason why that didn’t work? That would obviously be the preferable solution to get working, but my workaround is fine if not.

Hey, thanks for the swift response.

I’ve added those exclusions, but it doesn’t seem to have an effect. Here’s the current exclusion list:

data-lg-item-id
lg-image
lg-object

I assume I don’t need to prepend periods for the class names, etc?

I hadn’t actually noticed the occasional loading of the images. You’re right; if I refresh the page often enough, one in five or six times it will actually load the thumbnails.

I think you’re right that it’s a race condition in play. So, do I need the gallery to load its JS prior to the EWWW plugin initialising, or is it the other way round? Is there an elegant way to handle the load ordering, assuming the all the gallery and general theme JS is bundled in a single theme ‘script.js’ file?

Sorry, no solution, just chiming in with support as I’ve just run into this myself.

My client wishes to use email for 2FA, which Wordfence no longer supports (I understand the reasoning, but clients be clients). So we’re now using a different 2FA solution, but it’s really confusing for them to now have both options available, which is terrible UX.

Wordfence really needs a simple toggle off in the settings to completely remove 2FA from all areas of the dashboard.

Wow, that was fast. Thanks John, very much appreciated!

Hi both

Thanks for the responses – echo file_get_contents( get_attached_file( $file_id ) ) fixed the problem perfectly. I don’t know why include worked when I manually removed the XML version tag from the uploaded file, but that’s a query for another day (probably something along the lines of <?xml being interpreted as PHP at a guess).

It’s great to know that get_file_contents(get_attached_file is a more robust approach anyway; thanks for the article Daryll.

As for the use case, I have the client being able to upload SVGs, which then get certain styles on interaction using CSS. That obviously can’t be done with an img, only inlined. And they’re being loaded from the media library, not the theme. These are project specific, but a more general example would be uploading SVG social icons to the media library, which you’d typically want to get a colour change on rollover/focus.

Anyway, thanks again – great support. Nice to be able to draw a line under it! ??

Ben

Hey, no probs Tarek, thanks for confirming!

(Resolved)

Following up on this for anyone that it may assist.

Our IIS server (Plesk) had placed its error rules before the WordPress rewrite rules within the web.config file.

So by moving the <httpErrors> block after the <rewrite> block, the plugin was able to do its thing before being intercepted by the 404 page.

Many thanks to Emre – your patience and help was hugely appreciated! ??