13 Comments


  1. There are so many development frameworks now – and I’m sure this one is a great addition to the list. That said: I wish the framework developers would work together to create something awesome for core, which is where much of this really needs to be.

    Core needs standard markup for option data types, to be output via do_settings_sections(), standard sanitization/validation callbacks for option data types, and the same for custom post meta boxes and meta data. I think the best people to make that happen are the developers who have put so much time and effort into defining all of those things for their frameworks.

    Maybe we can lock Benjamin, Devin Price, et al in a room, and tell them they can’t come out until they have a patch? :)

    Reply

    1. That would be interesting, WordPress core containing everything developers need thus making frameworks obsolete. Or, would frameworks never be obsolete because core would never be able to satisfy everyone?

      Reply

      1. As with everything in core, it should be extensible (via filters), but could feasibly cover the vast majority of use-cases.

        Reviewing Themes, I’ve seen so many ways to reinvent the same wheel; it’s wasted effort for something that can and should be standardized.

        Reply

        1. That’s the thing with Open Source. There are virtually no standards but people don’t want to be constrained or restrained with standards. Standards provide reasonable expectations of a specific kind of behavior but it seems no one wants that. Great example is Post Formats. Talk about something that needs standardized :P

          Reply

          1. Most of the big wins are at a low-enough level that personal coding preference would have little bearing on the “standard”. There are only so many ways that you can create form field markup for a given data type, and only so many ways that you can properly sanitize that data type.

            And don’t even get me started on Post Formats; I’m still crying over Mark Jaquith ripping my heart out when he pulled out the standard from WordPress 3.6 during beta…


          2. Standards are good, so long as they don’t restrict what you are able to do. There’s an API for adding an options page to WordPress now, but it’s not restrictive as you can bypass it if you really need to (which you do need to for some edge cases), so people don’t mind that type of thing. It’s when the standard stops you from doing things that you want to, or at least actively discourages you from doing something outside of the box, which begins to annoy people.

            All this talk of standardising things is motivating me to try to figure out a patch for core which would setup a (reusable) API to implement header images (rather than the current system which seems to be hard coded in). Then we could use that same API to implement other theme wide images, things like banner images, footer images, sidebar images etc. rather than having to custom code them all.


    2. This could be done in bits perhaps, as implementing all of this stuff for core in one hit would be quite an undertaking.

      The thing which annoys me the most, is how much jumping through hoops I need to do to create a simple meta box. But having said, there are a huge number of different types of potential meta boxes, so anything created to do that would need to be fairly extensible in itself. I’m not sure off the top of my head what the best approach to doing that would be, but it must be possible to at least make a system which handles validation callbacks and nonces automatically to ensure developers aren’t bypassing security systems (which often happens due to developers not figuring out how to handle those things correctly).

      Do you have any ideas on how you would go about implementing this type of thing Chip?

      Reply

    3. I think the current core APIs really would benefit greatly if they were standardized. As @Ryan Hellyer mentioned, creating a simple meta box required a lot of different code. Same goes with the customizer.

      Reply

  2. I’d rather use a code generator at this point that spits out code according to the official API, vs adding an additional 3rd party API that tries to cover all these areas. Reason being is that it adds an additional API to learn. So far the track record of these solutions isn’t overwhelming, they all tend to get stale (right?). And I know it’s very minor and trivial, but it looks like the naming conventions don’t follow the recommendations set out by the PHP coding standards page.

    Or, like Chip said, something that can land in core at some point that helps to make common operations easier. The post meta api is already getting worked on by a fantastic group, it seems like a lot of things that will come out of that could be used across these other settings areas. Maybe Benjamin should join them?

    Reply

    1. A code generator would be a good idea, but isn’t that sort of the same thing with frameworks like Titan? A benefit with a framework is that when a new feature is added to it, you can benefit from it readily with just an update. Unlike with a generated code where you might want to re-generate it again.

      Yes there’s a new API to learn, although Titan tries to minimize the learning curve. A code generator that spits out code for Titan might be a good idea :)

      Reply

      1. That’s a good point in terms of new features and having to regenerate. It would be interesting if the code generator were to save a user’s setup and then when adding a new feature you’d quickly regenerate it.

        Reply
  3. Bora Yalçın

    for embedded version, it might be a good idea to use it as a composer package. So updates and bug fixes can be handled (at least on developer level it can be updated via composer)

    Reply

Leave a Reply