Jon

Yah, that’s at least one win for v4. ??

OK, and can you confirm it works when using a manual UA code? Your documentation here shows settings/toggles for it: https://www.monsterinsights.com/how-to-properly-setup-google-analytics-in-wordpress/

Image: https://www.monsterinsights.com/wp-content/uploads/2019/05/mirecommendedsettings.png

For Pete’s sake, please make it an option within the settings to disable the emails.

All I can say is that I agree with @martinpwph . This was one of my favorite plugins, and was a pleasure to use. It had everything we needed, and nothing we didn’t. Since v4, it seems to have gone downhill. But that seems the case with a lot of SEO and GA plugins lately, unfortunately.

Instead of developers trying to re-invent their plugin to such a degree, that has obviously frustrated a lot of users, it may be beneficial to make a separate plugin entirely. Though, I realize the nightmare that may be, trying to maintain two separate (though similar) plugins.

Understood. Though, I feel like every few months, it asks again?

Either way, it’s still an annoying practice to show this on various admin backend pages. Especially when we host 1,000+ sites. It gets a bit tiresome to see this all the time. In my opinion, it should only be on the actual AIOSEO pages.

I agree, it seems bad practice to take away certain filters without giving more of a notice. There should be a few versions where BOTH work, otherwise, our custom code breaks after updating plugin. If we change our code before updating plugin, then it still breaks because the old plugin doesn’t support the new filters.

Things seem to be getting a little sloppy here. Better documentation and better changelogs to say what exactly was changed and to what (especially for filters/hooks).

Agreed! 1.10.3 is released, but the changelog only goes up to 1.10.0.

My guess is that, by adding dnt=1, that Vimeo is no longer able to tell if you are already playing a Vimeo video in the same browser/tab/session… so it isn’t able to pause the other one before playing the new one.

I determined the parameter was responsible for the issue, by banging my head a few times, and removing various parameters from the URL to test. I happened to narrow it down to the dnt=1 parameter. As mentioned, when removing it, the videos are handled as expected. I think it should be removed from core, with some sort of filter to add if desired.

We’ve also been noticing this issue lately. In particular, on SiteGround servers.

It seems to be an issue with how Divi Builder is styling its content. When the page has a Popup in it, that uses the Divi Builder, it causes a “count” issue with the Divi Builder classes that Divi uses for their customizations.

For example, on a page, they may have added a class of et_pb_text_2 if you modified the 2nd text module’s styling. But if you add a popup with Divi Builder in it, then it causes the text module numbers to change within the actual page content (outside of the Popup content). This causes Divi’s compiled stylesheet to assign their styling to the wrong elements, since the element classes were changed as a result of the popup.

E.g., when no popup is on the page, et_pb_text_2 element is fine. But when a popup is added, it changes that elements class to et_pb_text_3. This therefore causes no styling to be applied to that element anymore.

As the plugin developer, I recommend you do some further testing with Divi Builder, or reach out to the theme. Considering it’s one of the most popular premium themes out there, it would be nice if your plugin worked well with it its builder.

Email sent.

What sort of transfer info would you be looking for? We’re basically just interested in getting the plugin fixed, so we can test it out on various installs.

For now, I’m using jQuery to remove that parameter from the src. I’m sure there’s a better way though…

<script>
	// replace the dnt=1 parameter that WordPress adds to the Vimeo player when using oEmbed
	jQuery(document).ready(function($){
		// find any Vimeo iframe
		$('iframe[src*="player.vimeo.com"]').each(function(){
			// get the src
			var src = $(this).attr('src');
			// replace parameters with nothing
			$(this).attr('src',src.replace('dnt=1&', ''));
		});
	});
</script>

Any update here? We have this same issue. Things look OK in the Customizer “preview”, but even if we adjust the page size within the preview (e.g., make the browser window smaller) the colors go back to the default blue within the preview. And then, either way, the changed colors do not show on the frontend at all.