`wp_sitemaps_post_types` vs `the_seo_framework_sitemap_supported_post_types` hook
Opened this issue · 3 comments
Is there a reason that TSF uses its own custom filter:
the_seo_framework_sitemap_supported_post_types
Instead of simply honoring the wp core hook:
wp_sitemaps_post_types
?
The short answer is that wp_sitemaps_post_types came a year later.
For now, I recommend filtering both for the full effect.
Is there any use case you need both filters for? Often, if a developer needs this, they or some plugin did something else wrong.
I am inclined to merge the filter, but I'm on the fence. Seeing how many bad implementations there are of the filter to hide improperly coded post types, I think it's good to have these exposed so that plugin authors can fix them appropriately.
Thanks for the rapid response @sybrew 🚀
You make a valid point for sure.
Case in point, I'm here due to another plug's incorrect implementation (soflyy/oxygen-bugs-and-features#3506).
Merging seems like the obvious solution, yet I do agree more attention could be drawn to correctly implementing post types in the first instance. Perhaps this is worthy of mention in the TSF docs somewhere?
We have documentation on the settings page at "SEO Settings > General Settings > Exclusions."
However, I recommend using "noindex" because that post type appears to be completely publicly queryable and probably is already indexed.
Excluding post types from SEO support or the sitemap won't combat indexing. The sitemap is redundant; if the post/template is found via any link, search engines will index it and keep crawling it until told off.
Excluding post types via the Exclusion settings will remove all of TSF's title filters, metadata, redirects, sitemap support, and admin interface. It will, therefore, also remove the robots-meta tag.
Still, it shouldn't need documenting and this functionality wouldn't exist if developers did their due diligence. The largest offender is Elementor. Almost every other plugin fixed it properly when Core sitemaps came.