Antony Booker

@praderj glad that fixed it! It should work as expected if a new image is uploaded and added.

It seems to only occur in rare cases in certain circumstances as I’ve only seen it happen on one site.

I’ll do some further debugging to see if I can replicate the issue again. From memory it happens when Yoast is having trouble getting the meta details for that image in the media library.

I’ve experienced the same issue here on one site, thought it was a very rare edge case but it might be similar. It would cache the page fine but clear it a second later, I managed to trace it down to the company logo in the Yoast SEO settings.

If you have an image in the organization logo section under the Search Appearance > General tab, can you see if removing it stops the cache being cleared prematurely?

A client is getting this issue on the Chrome browser. Interestingly the delay is very similar at 10s between opening the text editor and being able to edit text.

Strange thing is I’m not able to replicate it either. The client has traced it down to only occurring when Yoast SEO is active with Avada (with no browser extensions), and doesn’t occur on much older versions of Avada.

I have a performance profile from the client and can see the very long task but it doesn’t show what’s causing it. Perhaps some sort of TinyMCE conflict?

Please do follow up if you come across any solutions to this.

Just following up regarding this issue and if it has been fixed yet? A patch has been sent through so it should be fairly quick to implement.

Thanks for making that change so quickly. The WC blocks must load the products outside of a loop, this will fix that issue though.

Much appreciated.

Will the scheduled post also fire from a cron job in case an author closes the window?

Thanks for the response. There weren’t any errors in the log but I’ve done a bit of debugging and found the culprit.

The plugins folder was renamed from the default ‘plugins’, and on line #379 in the class-wt-import-export-for-woo-admin.php it requests the modules with a hardcoded “plugins” path so the wt_iew_exporter_post_types_basic filter was never called to add the post types.

Replacing:
$module_file=WP_CONTENT_DIR."/plugins/{$module_path}/admin/modules/$module_key/$module_key.php";

With:
$module_file=plugin_dir_path( __DIR__)."admin/modules/$module_key/$module_key.php";

Or even:
$module_file=dirname(__FILE__)."/modules/$module_key/$module_key.php";

Made it compatible with the custom plugins folder name, if you wanted to add that to the plugin.

@biplob018 Thanks for patching this quickly.

I noticed there are some capability checks in the permission_callback added to deal with this that I’d recommend reworking.

The plugin now has an option for changing the role of the user that has permission to edit the plugin’s settings. However the get_permissions_check function grants permissions based on the first key in the capability array for the role rather than against the user role selected in the plugin options.

The original vulnerability would still be possible for any user with the same capability. For example if shop manager was chosen as a role that could update the plugin’s settings, they would be able to update any admin options and potentially gain admin access.

I’d recommend changing the get_permissions_check to check for the manage_options capability only, so only admins can update the settings. For further protection you could whitelist/hardcode the options that are updated.

I’d also check any input fields used by the plugin are escaping data before outputting it to the user to prevent XSS attacks.

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

The message was sent via the contact form on your website codemenschen.at/contact/

I have sent another message directly to the email address on that page.

I’ve reached out via the contact form on your website with a potential fix.

Please do let me know if this is not received.

Thanks for the reply. I had previously downgraded but disabling the Extendify Library under Settings > Redux worked on 4.3 to stop the performance impact of the autoloader.

Here is the thread on Github:
https://github.com/composer/composer/issues/10205#issuecomment-949387699

Thanks for the reply. I have asked the composer team on github regarding the best practice for this and they recommended using authoritative autoloading as per https://getcomposer.org/doc/articles/autoloader-optimization.md#optimization-level-2-a-authoritative-class-maps

This will set a classmap defining the location of all classes it handles, rather than looping through all classes.

If you could please look into this for a future release it will be really appreciated as this can have a large impact on performance.

As this is very easy to replicate on a default WordPress install you should be able to see the error on the testing environment you have. This is using the contact form module in elementor.

It’s been replaced with another contact form on the site but I was able to replicate the issue on a fresh WordPress install with the Elementor and Elementor Pack Lite plugins installed.

Here’s a fix for the issue. The product data should be added to the woocommerce_quantity_input_min filter arguments, and retrieved that way rather than using get_the_ID() which will get the ID of the cart page instead of the product.

function wcmmq_s_set_min_for_single($min_quantity, $product){
    //$product_id = get_the_ID();
    //$product = wc_get_product( $product_id );
    $min_quantity = get_post_meta($product_id, '_wcmmq_s_min_quantity', true);
    $min_quantity = !empty( $min_quantity ) ? $min_quantity : WC_MMQ_S::getOption( '_wcmmq_s_min_quantity' ); //Regenerate from Default
    if( !$product->is_sold_individually() && ( !empty( $min_quantity ) || !$min_quantity ) && is_numeric($min_quantity) ){
       return $min_quantity;
    }
    return 1;
}
add_filter('woocommerce_quantity_input_min','wcmmq_s_set_min_for_single', 10, 2);