indextwo

Yup, this seems to be an issue when certain conditions are met: PHP8 became a lot more strict with error reporting, and depending on the environment (e.g. if your host hasn’t locked down E_NOTICE & E_WARNING messages), you might get these with a shortcode like the one you mentioned.

I had to modify my environment to get this to show, but it did after I restarted. I’ve updated the code and tested it, eliminating a couple of other undefined warnings that were showing too. Once I’ve finished the PHPCS tests, I’ll release an updated version, hopefully later today.

As there’s been no new activity on here for a few weeks (and a new version of the plugin is going to be released shortly) I’m closing closing this thread.

This issue stems from the SoundCloud player widget enqueued from soundcloud.com, so you’ll need to contact them about it directly.

No one from SoundCloud is directly involved in the development at the moment, but it is still the official SoundCloud shortcode plugin; however shortcodes have been superseded by Gutenberg-style embeds, so this is more of a legacy-support plugin now.

No idea why the update is showing for you on one site but not another. We did have some confusion over the update versioning (again, switching from a legacy versioning tag to the recommended one, hence the bump from 4.0.0 to 4.0.1 over 2 days); but if it’s stubbornly not budging, I’d recommend downloading the plugin and replacing it manually, either via SFTP or uploading via the WordPress->Add Plugin->Upload process.

Thanks for this – I had originally changed it from trunk to 4.0.0, as I was sure trunk wasn’t correct, but it didn’t seem to take, hence why I changed it back.

I just changed it back again (from trunk to 4.0.0), and then did another minor version update to 4.0.1 (I tweaked a couple of field descriptions and added the Requires PHP tag), and that seems to have worked. No idea why it didn’t the first time.

Hi there, and thanks for the heads-up. I don’t know why, but we didn’t receive a notification about your post, or about the CVE that’s referenced by WordFence.

We’ve just released a new major version update that should address the ‘sanitization’ issues that were raised in the CVE/WordFence; and at the same time, refactored a lot of the code, removing some old minor bugs, defunct code (don’t think we need to support Flash anymore…), added support for more SoundCloud widget features, and completely revamped the admin section.

It’s also worth mentioning that the CVE stated that the vulnerability could only be executed by a bad actor with admin-level permissions. It goes without saying that properly sanitizing user inputs is absolutely correct (and that has been addressed with this update); but at the same time, if a site has a hacked/rogue user with admin-level permissions… they’ve got a lot more problems ??

I came here because I was looking for a solution to exactly this issue – excluding certain products by category.

It turns out there absolutely is a way to do it: by modifying the XML that gets generated and sent to Pinterest.

When generating the XML product feed, the plugin uses a filter for the XML of each product: pinterest_for_woocommerce_feed_item_xml

So I hooked into this filter and created an exclusion for any parent products that were in the category I wanted to exclude (since my site only has variations).

function vnmWooExtend_pinterestFilterItem($xml, $product) {
	// I'm only using variation products, so I check if the current product has a parent, as its only the parent that actually belongs to a given category

	$parentProduct = wc_get_product($product->get_parent_id());

	// Make sure it exists & isn't an error

	if ($parentProduct && !is_wp_error($parentProduct)) {
		//	Term ID 123 = The category I want to exclude: so if a product is in category 123, then return nothing to the feed

		if (has_term(123, 'product_cat', $product->get_parent_id())) {
			return '';
		}
	}

	return $xml;
}

add_filter('pinterest_for_woocommerce_feed_item_xml', 'vnmWooExtend_pinterestFilterItem', 10, 2);

To do the same for simple products, simply remove the check for get_parent_id() and change the conditional to if (has_term(123, 'product_cat', $product->get_id()))

Do note that the feed is only generated once a day (you can see when by looking at the action scheduler), so you may have to wait for it to be generated, but after that, you’re good to go.

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

Super-late response, but: Safe SVG makes use of the Enshrined SVG Sanitizer, which has a list of allowed tags & attributes. If you are animating your SVG with native SMIL (Synchronized Multimedia Integration Language) with tags like animate, they will get stripped out by default. Fortunately, it’s pretty easy to deal with, as Safe SVG adds filters for these.

In your theme’s functions.php, add the following code:

function allow_safe_svg_animation($array) {
	$array[] = 'animate';

	return $array;
}

add_filter('svg_allowed_tags', 'allow_safe_svg_animation', 10, 1);
add_filter('svg_allowed_attributes', 'allow_safe_svg_animation', 10, 1);

All this does is add the animate tag to the allowable list of SVG tags that now _won’t_ get stripped out. (I also added the svg_allowed_attributes filter in there too, as the format & return are identical).

Thank you! ?? I’m super-happy StyleBidet has been so helpful. And your response to clients is perfect – I might update the FAQ to include this as a response! ????

@darkallman I couldn’t close it either – unless you come at that close-cross on the banner from the right-hand side VERY quickly, the actual banner link overtakes it.

You can dismiss it by adding ?yst_dismiss_bf=1 to the end of your /wp-admin/ URL.

(that is, until Yoast does another plugin update and adds their Christmas sale banner in there…)

I came here to say the exact same thing. Not only is it wildly intrusive on every. single. page. of wp-admin in all client sites with Yoast installed, but it’s also impossible to dismiss. The little X in the corner doesn’t register a closing click; it just acts as if I’d clicked on the banner (at least in FF 70). So I have no way of dismissing it, despite several clients complaining about it.

I was hoping to find a filter but (obviously) they didn’t put one in. So there are 3 4 ways of dealing with this:

1. Add this filter:

function vnmFunc_removeYoastAds() {
	WPSEO_Options::set('bf_banner_2019_dismissed', true);
}

add_action('admin_init', 'vnmFunc_removeYoastAds');

This will immediately set the dismissed trigger of the banner so that it won’t even try to appear again (that is, until the next time Yoast updates and adds a Christmas sale banner)

2. Add ?yst_dismiss_bf=1 to the end of the /wp-admin/ URL – this has the same effect as adding the filter.

3. Implement xsonic’s CSS suggestion. Arguably this will hide it for as long as Yoast use the same class to display their ads; however I don’t know if they’re also adding tracking via the images (and my guess is they most likely are).

4. Uninstall Yoast. And I won’t be at all surprised if this is what a lot of people end up doing.

For shame, Yoast. This is weak af.

?? Glad it helped!

Great! Thanks for the awesome review!

@nicolamustone Great, thanks for the response.

I’m not sure what you mean here: are you saying that, when viewing your orders (via WooCommerce->Orders that you can’t search them by ID? If that’s the case, then I’m afraid that’s being caused by something other than this plugin; and it’s not something that this plugin can fix.

Order Search Repair is a one-use plugin: it searches for any order posts that don’t have a _billing_address_index meta key and updates them (along with the _shipping_address_index, if applicable). If you clicked the button labelled Retrieve the total number of orders that do not have a searchable index and it’s returning zero, then it looks like there are no orders matching that criteria in your system. If your store is new (i.e. it’s been running at least WooCommerce v3 since it went live), then all of your orders should have those searchable address indexes, and so Order Search Repair won’t find any orders that need updating (hence the 0 orders found).

Like I said, if you can’t search your orders by ID, then that’s a completely different issue. I would recommend disabling all plugins except for WooCommerce and seeing if that fixes it. Then start enabling them one by one until you find the plugin that’s causing the issue.