8 Comments

  1. jack rives
    · Reply

    Disappointing postponement. woff2 mime type would have become available, afaik.

    Report

  2. Peter Shaw
    · Reply

    The api itself is a fantastic idea but putting it in a feature plugin as an intermediate step is nonsensical.

    The rest api made sense as a feature plugin as there was a large number of people wanting to to use what was for WordPress a very powerful new feature which everyone knew was going to hit core eventually

    But the fonts api will simply be a better way of enqueueing fonts. That is great but won’t provide much incentive to test or standardise the api.

    Feature plugins are great in some circumstance but not others

    Report

  3. Thomas
    · Reply

    More disappointment for developers!
    WP are also blocking other developer value adds like logging.
    A mindset change is needed.

    Report

  4. Dario Frenzi
    · Reply

    Nice idea.

    Won’t stop plugins/themes to bypass the enqueue API, similar as with scripts now:

    https://wpdirectory.net/search/01FM9TN2H6EE49PWG8FHYZX45Y

    Report

  5. CW
    · Reply

    Immensely disappointing, and at least at the surface, it feels like another case of devs putting design features last. And shouldn’t the discussion about whether this is of value to WordPress have happened long before now? A bunch of people worked hard on this, but apparently it only takes one lead developer who for some reason doesn’t understand why it’s valuable to almost cancel the whole thing. If people didn’t specify clearly enough why this is needed, it’s because it feels obvious to everyone.

    If I’m missing something about this situation or why rolling out this API could be a bad idea, I’m happy to hear more.

    Thanks for the thoughtful coverage.

    Report

    • Daan van den Bergh
      · Reply

      I fully agree. In a time where performance is everything, I see some serious benefit to this feature, especially when it comes to duplicate requests. Granted that it’ll still take a long time before theme/plugin developers adapt this feature into their application.

      Report

    • Andrew
      · Reply

      Sorry for being late to the party, been having some health issues :)

      Yes, I hear you! It is a 100 times more frustrating to have to make these recommendations in the last moment (yes, these are/were recommendations although that’s not very clear).

      In your opinion what is better:
      1. Have a brand-new, pretty complex, virtually untested API that leaves some “unanswered questions” about the way it works. Once added to WordPress it will have to be supported and maintained “forever”.
      2. Make the current patch into a feature plugin that follows the standard WordPress development practices. Then have it tested well, any bugs or inconsistencies fixed, and any questions answered before adding it to core.

      Frankly I’d always go for 2. There is a reason feature plugins exist. This is the way to build better software.

      Report

  6. Andrew
    · Reply

    Just FYI for all that would like to continue following the development: https://github.com/WordPress/wordpress-develop/pull/1736#issuecomment-981976202

    Report

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: