mrboats

@dabrolga, true that, hadn’t paid attention so that detail. So seems that http: might be the culprit here. @gioni, shouldn’t http requests be blocked as well?

That is the challenge here that these seems spurious and I cannot see any pattern. As I said, mostly the REST calls get blocked as should but then there are these random occurrences that get passed through incorrectly.

In my case, WordPress is in the root.

Sorry, but you are wrong @bikku, they are exactly the same size! Only the image nr 6 is different.

File name: Hamina-Rampsi.jpg
File type: image/jpeg
Uploaded on: April 22, 2021
File size: 224 KB
Dimensions: 1200 by 675 pixels

File name: Sj?l?-new-marina.jpg
File type: image/jpeg
Uploaded on: September 8, 2020
File size: 190 KB
Dimensions: 1200 by 675 pixels

ping @bikku

Hi,

Now enabled 6 posts so the second row shows. Note that the last one (nr 6) still has an “old” small featured image so don’t care about that one, the problems are related to 4 and 5 (the first two on the second row).

As you can see, the small thumbs (1-5) all look great but the big ones (once highlighted) are the ones that cause concern.

Sure: site.

The TG1 widget now only has the top 3 posts/images set to avoid the usability problem caused by the image handling problem.

Thanks, this did solve the problem! No need to update the plugin at this time, but staging and live are now fixed. But thankful if you include this in your next regular update so it is not lost when updating!

pps: what does the “self::$page” expand to, from my brute force testing something other than “post” or “product”?

Also, on this page, what would be the equivalent of your admin page to the ‘wporg_cpt’ screen name? Using something more specific instead of the self::$page (or are they the same, don’t know codign well enough to know what’s going on here, just a guess).

1) The problem occurs when a vendor edits a product with this plugin: Vendor plugin, not sure if the free version has the same behavior?

2) Just migrated my site to a new hosting which recreated the staging site from live which unfortunately means I have full customer info still on that site so cannot provide externals access at this time :-(.

3) The plugin did not perform very well ?? as you can see from this screen grab and this screen grab 2.

I even tried this for fun:

  public static function add_meta_boxes()
    {        global $wp_settings_sections;	
		if (is_admin()) {

but even this did not prevent the metaboxes from appearing.

So is there some way for the Vendor plugin to query what metaboxes might be needed to support editing the product and then calls those metaboxes? If yes, why would the mcb metaboxes then be identified as something linked to products?

I tried to “brute force” the problem:

function remove_my_post_metaboxes() {
remove_meta_box( ‘mcb-section-model’,’post’,’side’ ); 
remove_meta_box( ‘mcb-section-model’,’product’,’side’ ); 
remove_meta_box( ‘mcb-section-bar’,’post’,’normal’ ); 
remove_meta_box( ‘mcb-section-bar’,’product’,’normal’ ); 
}
add_action(‘add_meta_boxes’,’remove_my_post_metaboxes’,50);

but that did not work either.

So for some reason, the vendor product page picks up your meta boxes, do you limit the visibility with the add_meta_box() $screen parameter?

Sorry, seems the elements are meta boxes, not widgets.

Hi,

Installed a plugin to analyze the capabilities and the Vendor does not have manage_options capabilities, just the basics of read, upload_files, edit_posts and some woocommerce capabilities.

The Mobile contact bar does not show up in the menu, it only appears as the widgets when editing a product, the edit url is: wp-admin/post.php?post=xxxx&action=edit

The mobile contact bar “widgets” show up in the display settings: (image here) and the edit page: (25% page view here) in the product edit page.

Is it possible that the menu item is controlled by the capability but the Vendor plugin somehow “rounds up available widgets” and they are not controlled/limited by the capability?

+ 1 for this request!