Meta block sometimes not inserted?

Note, it is now not appearing for me on the homepage.

Meanwhile, various other pages do have the meta block from the plugin.

• This reply was modified 1 year, 10 months ago by cjyabraham.
• This reply was modified 1 year, 10 months ago by cjyabraham.

Hello!

Were you running an older version of TSF but updated WordPress?
WP 6.1 broke WP Query (details, it’s still broken), which I patched in TSF v4.2.6. This patch can be backported as-is down to TSF v4.1.4.

The patch made sure that TSF works again on custom post types, where method tsf()->query_supports_seo() no longer caches a query that should not exist. This method decides whether TSF should output the meta-block, change the title, handle redirects, etc.

We are running TSF v4.2.7.1. It is currently not showing the meta block. Earlier today, it was showing it. Hmm….

Here’s a vid showing what I’m seeing:
– meta block is present in the uncached logged in version of the cncf.io site
– meta block is not present in the cached version of the cncf.io site

Note that I just reset the cache and now the meta block is showing in the cached version. So it seems kind of random as to when it shows and when it does not. Is there some kind of race condition that might be at play here? Any other ideas?

I am interested in the type of caching plugin you are using and its configuration.

The issue might depend on how the cached pages are generated. Are some generated via a cronjob, and others Just In Time (as the user requests the page)? The latter should yield a correct version, whereas the former might be broken if the request simulation isn’t set accurately.

But, if the issue is permanently fixed henceforth — perhaps there was a bug in the caching system which was resolved in a plugin update; still, I cannot put my finger on the cause.

If you still find broken pages, you could try to force TSF to generate content and see what it would splurge out. This filter should do that, though I recommend using it only for debugging:

add_filter( 'the_seo_framework_query_supports_seo', '__return_true' );

I added the “query supports SEO” test to allow users to disable support for CMS-on-CMS plugins that don’t adhere to any WordPress coding guidelines (think Events Calendar and most forum software); when it fails to detect any coherent WordPress request that isn’t of an exploitable type, we’re likely dealing with such a plugin, and TSF will stop processing as not to produce incoherent titles and URLs.

We don’t actually use a cacheing plugin other than what is provided with the standard Pantheon infrastructure.

Currently the site appears to still be including the meta block. I’ll keep an eye on it in the coming days to see if it disappears again…

The meta block was present for several days but is now missing again. I will contact Pantheon to see if it’s something happening on their end.

Do you have any more insight into the conditions for which this might not be generated?

Hello!

Sorry for the belated reply.

I do not have more details to add than the stuff above — it is the query_supports_seo()-check that faults for a reason unknown to me.

In the link below, you can see a few tests it performs. When it sets $supported to false, TSF won’t output its metadata:
https://github.com/sybrew/the-seo-framework/blob/4.2.7/inc/classes/detect.class.php#L589-L594. It might erroneously set it because of a module enabled on Pantheon, but I have no details.

Hi,

Sorry to jump on another ones thread, but we are seeing this same issue on Kinsta, with only proprietary Kinsta cache activated. Almost all posts are without the OG meta -bit, unless we manually flush the page / object cache after we initially published the piece. And we see this happening on 3 different wp installs (pretty similar though, all on kinsta).

I’ve discussed this with niklo via email. I hope the resolution we find applies to Pantheon as well. Any information, such as the registered query variables during the cache-warming cycle, is greatly appreciated.

Great. Thanks. Keep us posted if you find a fix.

Hello!

I suspect some systems preload/warm page cache (by accident?) within WP Cron instead of pinging outward during WP Cron. The latter creates an actual request to your webpage as a browser would, whereas the former simulates one. This simulation of requests causes issues.

For example, in The Events Calendar, visitors can select a day to view all events; then, via WP JSON’s REST, The Events Calendar rebuilds the page title. To build the page title, they simulate an incomplete WordPress query, so whatever title The SEO Framework brews up is incorrect. They patched this to get something tangible, but TSF cannot reach that code.

Therefore, in TSF, I marked WP-JSON and REST queries as incompatible, and now The Events Calendar can generate its titles freely without TSF interfering. I foresaw other plugins building frantic queries via WP Cron as well, and in the same update, I also blocked WP Cron and WP AJAX.

With WordPress being evergreen (constantly changing), we shouldn’t build pages based on bespoke assumptions but only request pages as browsers would. Still, this isn’t an issue I’d like to see my users encounter.

So, this begs the question: What needs fixing? Is TSF wrong in blocking simulated queries, or are simulated queries harmful? Should I allow simulated queries once more and write an edge-case patch for The Events Calendar?

Before I make a decision, I think it’d be helpful to know the actual cause of these issues. This will help me understand what makes the breaking query and if we’re dealing with a bigger problem. So far, I’m going off of speculation.

@niklo I reached out to Kinsta for a dev environment, but I couldn’t replicate the problem; nothing indicated a cause for this issue. I’m still in talks with their developers about how the caching is warmed, so we may be able to resolve it on their side. But maybe another plugin on your website is trying to simulate queries, which might need fixing but certainly needs inspecting. Could you forward me a list of active plugins? I’ll request this as well in reply to an email from you.

@cjyabraham I couldn’t find at Pantheon anything specific that’d simulate queries inside WordPress. Did you hear back from them yet? Perhaps, as I suspect with niklo’s site, another plugin hits the pages via a cronjob or REST without performing an actual request. Could you please forward me a list of active plugins here https://tsf.fyi/contact? If some are bespoke, could you mention which don’t use WP-JSON/REST, WP Cron, or AJAX? Thank you!

Thanks again for looking into this. I didn’t get any useful info from Pantheon. Is there a specific question you’d like me to ask them?

Here are the active plugins we have. They are all publicly available, however, I don’t know off-hand which may use the various services you list. One particular one you may want to investigate is Flying Scripts as that pre-loads pages when a user hovers over links.

• Advanced Custom Fields PRO
• China Video Block
• Code Syntax Block
• Custom Twitter Feeds Pro Personal
• Flying Pages
• Flying Scripts
• HubSpot All-In-One Marketing – Forms, Popups, Live Chat
• LH HSTS
• Native PHP Sessions for WordPress
• Pantheon Advanced Page Cache
• Post Meta Controls
• Public Post Preview
• PublishPress Checklists
• Redirection
• Safe SVG
• Search & Filter Pro
• ShortPixel Image Optimizer
• SVG Autocrop
• The SEO Framework
• WP Mail SMTP

Jumping in here, as I provided a list by email. I do note a similar feature that we have in use through the plugin Perfmatters that we use. It’s called instant page that preloads the next page (https://perfmatters.io/docs/link-prefetch/) when hovering on a link.

Thank you both for sharing the list of plugins. None of the plugins are at fault.

Broken requests from random bots hit WordPress constantly, and those requests cause TSF to bail. During testing, I caught such a request every 7 seconds on TSF’s website; but we don’t use page caching, so I never spotted the problem.

When the cache of a page is stale, the caching plugins or edge server might store the broken request’s response (so without TSF’s meta output).

I will prepare the patch for release soon, but this might need to be delayed for reasons I cannot share.