macgeekgab

For anyone driving by, we solved this simply went to Dashboard > Performance > Minify > Advanced > Never minify the following pages and put /amp/ in there. That seems to have done it.

Ahh, gotchya. THanks, @vmarko –?I posted here thinking it was the right place, and thinking others may have a similar issue.

Out of curiosity, how large are your CSS? A better way to ask that question: how many lines down is it before the Facebook Debugger shows your OG tags? Ours were in the ~4500 range.

Thanks, @vmarko –?I’m confused as to what other plugin would be causing this problem? Can you help clarify for us what issue you think we should be investigating?

From looking at the OG Debugger, it seems pretty clear that Facebook is just stopping its parsing at a certain point, and since we have ~47K of CSS, it’s not going past that to get to the META OG tags. I’m not sure what other plugin would be at play here, but obviously I could be misinterpreting something?

Thanks!

(P.S. We are paid Pro members, if that helps! ??

Hi @vmarko! Thanks for this. HTML Minify didn’t seem to affect this in my testing. The only thing that seemed to matter was the “Eliminate render-blocking CSS by moving it to HTTP body”, unfortunately.

I looked at the Facebook debugger with all the permutations I could manage, and I’m pretty sure this was the only one that worked,

Thanks, @jeherve. That’ll do it! ??

@jeherve Ahh, perfect. Thank you! Either the page ID or is_feed conditional would be brilliant for us. Thanks so much. We’ll get to work!

@jeherve Ahh, perfect. Either the page ID or is_feed conditional would be brilliant for us. Thanks so much. We’ll get to work!

• This reply was modified 4 years, 10 months ago by macgeekgab.

Thanks @sterndata –?They told me to come and ask here. ?? https://www.ads-software.com/support/topic/jetpacks-photon-breaks-rss/#post-12755784

Thanks for your help!

I re-enabled site accelerator and I think you might have gotten us down the right path. Because… the images in /feed/ also have the parameters after them:

src="https://i1.wp.com/www.macobserver.com/wp-content/uploads/2019/03/workfeatured-spotify.png?resize=1200%2C630&ssl=1"

…but it validates, whereas our /feed/everything/ does NOT. And now I think I know why. We are *also* using the media:content for our images, and it seems the namespace for that does not support URLs with parameters. But… I can remove that and work around it. (we use custom fields and custom post types, hence the need for custom RSS creation).

However… we’re also podcasters, and this image is required atop every single podcast feed:

<image>
 <title>Mac Geek Gab</title>
 <link>https://www.macobserver.com/show/mac-geek-gab</link>
 <url>https://i0.wp.com/www.macobserver.com/wp-content/uploads/2020/03/macgeekgab_logo_sans_Finder-600px.png?fit=600%2C600&ssl=1</url>
 <width>144</width>
 <height>144</height>
 <description>Mac Geek Gab Podcast</description>
</image>

Unfortunately, having those parameters in the <url> breaks every podcast validator in existence, and we can’t have that. So… same problem, different place. Is there a way to invoke an image without having Site Accelerator affect it?

So… we’ve had to turn off Site Accelerator for now. If you’d like to setup a specific time to check it out, I’m happy to do that for you, but we can’t leave it like this, unfortunately.

Thanks for helping!

The site is https://www.macobserver.com/ and our RSS is https://www.macobserver.com/feed/everything — But we have Photon disabled right now because it breaks our RSS.

Happy to do whatever we can to show you what’s going on. Just let me know what you need and we’ll take it from there.

I believe this error appears when you have an   in the HTML of the post. There are other support requests that say this is fixed, though my testing is in line with yours: it’s still broken at some level.

Hopefully a fix is forthcoming.

Thanks for this clarification. Just to be clear, if we’re already running self-hosted Matomo and running the WP-Matomo (WP-Piwik) plugin, there’s no benefit in moving to the Matomo Analytics plugin, correct?

We’re definitely still seeing this here, as well. Would love a fix, and are happy to provide any details we need.

We have an annual subscription to this, and aren’t using the free product. Didn’t realize support for the product was bifurcated. I’ll file in the other channel.

Perhaps a better way to address this issue:

We (now) know that W3TC’s object cache gets in the way of wp-cron for some amount of users. There’s clearly an incompatibility here.

With that in mind, wouldn’t it be better for you to simply patch W3TC’s Object Cache so as not to mess with the doing_cron transient?

It seems like that would be the best solution here, especially given that it seems like troubleshooting this is made very difficult for whatever reason.

We’ve pinpointed a very specific problem. If you want to give us a debug build or something that logs in a way that’s valuable for you, that’s one thing. But to ask users to edit code and hack together their own debug builds seems really dangerous, and probably not entirely helpful for your troubleshooting, either.