Support » Plugin: The SEO Framework » Previous filter breaks all post types with 3.1 update

  • Resolved thekendog

    (@thekendog)


    Prior to 3.1 I was using the ‘the_seo_framework_supported_post_type’ filter to exclude certain post types from having an SEO metabox/included in the sitemap. The most recent update has caused a huge issue for sites that use this filter. It breaks the SEO metaboxes on default posts and pages. The new settings tab stuff for post types is great and works properly, but if a site upgrades to the newest version and was using the previously mentioned filter, the SEO metabox disappears on all posts and pages. There should be some kind of backwards compatibility.

    • This topic was modified 1 year, 4 months ago by thekendog.
    • This topic was modified 1 year, 4 months ago by thekendog.
    • This topic was modified 1 year, 4 months ago by thekendog.
    • This topic was modified 1 year, 4 months ago by thekendog.
Viewing 3 replies - 1 through 3 (of 3 total)
  • Plugin Author Sybre Waaijer

    (@cybr)

    Hi @thekendog,

    I’m sorry for the inconvenience this update has brought you!

    The filter was badly documented, and I’ve “fixed” that in this patch. Previously, it supplied two parameters:

    @param string|bool $post_type The supported post type. Is boolean false if not supported.
    @param string $post_type_evaluated The evaluated post type.

    The first parameter could be a boolean (false) or a string (the post type name).
    The second parameter is always the post type name.

    The expected behavior of the filter was that you test for the second parameter, and return the post type name if it’s allowed. Otherwise, you return false.
    This behavior still holds true. However, the first parameter is now always a boolean: whether it’s supported (or not). Non-empty non-zero strings equate to boolean true, so this is the backward compatibility I had in mind.

    The documentation now states:

    @param bool   $post_type Whether the post type is supported. (this should be $supported)
    @param string $post_type_evaluated The evaluated post type.

    I understand that this change could’ve broken some use cases, but I didn’t expect that with the first variable being irregular.

    I apologize for making the wrong presumption.

    I also want to keep my promise, as posted on the foreword:

    …if you find that your filters or adjustments have stopped working after upgrading, feel free to reach out to us via the support forums. State your previous implementation (show the code!) and we’ll send an updated version back.

    Feel free to reach out to me if you can make use of that promise. I’ll happily oblige.

    About our versioning and backward compatibility:

    We take a “Semantic Versioning 2.0.0” approach, which states:

    • MAJOR version when you make incompatible API changes
    • MINOR version when you add functionality in a backward[s]-compatible manner, and
    • PATCH version when you make backward[s]-compatible bug fixes.

    However, like WordPress, we combine Minor and Patch.

    As with every major update, we change the inner working to be more concise, usable, and predictable. We (I…) simply don’t have the resources (note: one man army) to take a WordPress approach of unlimited backward compatibility in the API. Instead, we completely focus on “the many”, which are the users that don’t fiddle with filters, yet try our best to support developers, too. 🙂

    This is the last upgrade we’ve planned at this scale. I felt the plugin was inadequate in its interfacial behavior toward WordPress, and I’ve rewritten that on many levels. I’m now very proud of how TSF works, and I know I can now bring all the features users want with confidence and ease 😊

    Yeah I quickly figured out what the issue was. The new implementation of specifying post types is great and MUCH better. I mainly just wanted to post something on here in case others ran into the same issue. I understand that major updates break things, just wish this filter was the same between versions.

    • This reply was modified 1 year, 4 months ago by thekendog.
    Plugin Author Sybre Waaijer

    (@cybr)

    I’m happy you’ve got it straightened out so quickly on your own 🙂

    I understand that extra work isn’t welcomed and that some changes aren’t seen as warranted. I do hope you’ll find the plugin easier to work with henceforth!

    If you find any more issues, please don’t hesitate to share. Thanks for highlighting this issue!

Viewing 3 replies - 1 through 3 (of 3 total)
  • The topic ‘Previous filter breaks all post types with 3.1 update’ is closed to new replies.