Make WordPress Core

Updates from Scott Kingsley Clark Toggle Comment Threads | Keyboard Shortcuts

  • Scott Kingsley Clark 3:10 pm on March 14, 2016 Permalink
    Tags: , ,   

    Fields API — Where we’re at 

    Over the past few months, we’ve been working towards one of the most wide-reaching API’s to be suggested for core inclusion, apart from the REST API. It has the potential to touch nearly every area of WordPress that deals with forms and fields. The Fields API is nearly there, and we’re seeking more feedback on a number of areas we need to tie down before we go into the official proposal stage for core inclusion.

    What is the Fields API?

    We just published a specification for the Fields API last week and we’re seeking constructive feedback on that now. Please take a moment to read about it, ask questions, and voice your concerns with us so we can address those things before we go to the next official stage.

    There’s also some helpful docs which include TerminologyRegistration of fields, and example code.

    What can you do with the Fields API right now?

    We’ve put together a number of implementations to show the potential of what the Fields API can accomplish inside of core. Each implementation is an example of what could end up in WordPress core, should the Fields API itself be merged.

    • Edit User screen (@sc0ttkclark, @technosailor)
      • Our internal implementation of the Edit User screen replaces core’s entirely using the Fields API.
      • Here’s a code example to add more fields (and sections and controls) to the Edit User screen
      • Backwards compatibility hooks
      • To-do: Further custom markup and/or styling to match uniform layout
    • Edit Post screen (@sc0ttkclark, @brentvr)
      • Our internal implementation of the Edit Post screen will replace core’s entirely using the Fields API, we only have support for adding new sections / controls right now
      • To-do: Register sections / controls based on what’s on the Post Editor screen currently (@brentvr is working on this now)
      • To-do: Add additional output types (no meta box, etc)
      • To-do: Backwards compatibility hooks
    • Term Add / Edit (@sc0ttkclark, @technosailor)
      • Our internal implementations of the Add Term and Edit Term screen replaces core’s entirely using the Fields API
      • Backwards compatibility hooks
    • Comment Edit (@sc0ttkclark)
      • Our internal implementation of the Edit Comment screen will replace core’s entirely using the Fields API, we only have support for adding new sections / controls right now
      • To-do: Register sections / controls based on what’s on the Comment Editor screen currently
      • To-do: Add additional output types (no meta box, etc)
      • To-do: Backwards compatibility hooks
    • Settings Pages (@sc0ttkclark, @technosailor)
    • Widget Forms (@nicholasio, @sc0ttkclark)
      • Our internal implementation of the Widget forms will integrate with WP_Widget to allow form fields to be registered for widgets and rendered/saved automatically without the custom code every widget ends up needing currently.
      • To-do: WP_Widget integration (@nicholasio is working on this now)
    • Nav Menu Items (@diddledan, @sc0ttkclark)
      • Our internal implementation of the Nav Menu Items overrides the core Walker class used for building the Nav Menu Item forms, and uses the Fields API to output registered controls.
      • To-do: More compatibility work for CSS
      • To-do: Look into Customizer integration
      • To-do: Getting/saving values for nav menu item fields
    • Media
      • We do not currently have an implementation for this yet, but one was proposed by @wpsmith, and we are seeking additional help from anyone looking to make this happen
      • To-do: Add sections and controls to Media Edit
      • To-do: Add sections and controls to Media Modal Add/Edit
    • REST API
      • We currently have limited direct integration with the REST API, but we’d like to work with the REST API team towards implementing REST API options and building in addition configurations the REST API can consume for it’s endpoint(s)
      • register_rest_field integration

    Possible Roadmap to Merge

    Here’s an example of how Fields API could eventually be merged into core, along with other implementations.

    • Release 1: Merge Fields API into core
    • Release 2: Merge Implementation 1 into core
    • etc..

    So each release could focus on a different implementation, which of course is a great time to coincide to UX / design work on each area, like the User Profile screen. There’s lots of options here, but hey, let’s discuss it!

    How to help

    If you’d like to help anywhere, please just reach out and I’ll get you into it. Every area needs review, some areas still need more work to finish, but any area could use additional help.

    So who do you contact or where do you go to help?

    Next Meeting Agenda – March 14th, 2016

    Our next meeting is Monday 20:00 UTC 2015 and it promises to be eventful. We plan on discussing a number of things including:

    • mrpritchett 3:16 pm on March 14, 2016 Permalink | Log in to Reply

      Great job Scott and team! Super excited about this! I guess my only question is if the REST API is integrated completely before this, would integration of the REST API with the Fields API not be a requirement to merging?

      • Scott Kingsley Clark 3:18 pm on March 14, 2016 Permalink | Log in to Reply

        Good question, because both aren’t fully implemented yet (REST API meta endpoints, etc), that question remains unanswered until we get some feedback and direction from the movers and shakers I suppose. 🙂

    • Weston Ruter 4:00 pm on March 14, 2016 Permalink | Log in to Reply

      @sc0ttkclark re: Widget Forms, this integration would be closely related to #35574. If the REST API JSON schema were rich enough, there could be a default WP_Widget::form() implementation that just output fields based on the associated schema. But since it isn’t, I understand this is where the Fields API will come into play. But there seems to be some key overlap.

      • Scott Kingsley Clark 4:02 pm on March 14, 2016 Permalink | Log in to Reply

        Certainly! I’d love to see the Fields API enable this ability in the REST API, I think it’s a natural fit and plays into other things we’re planning to do to give REST API the information it seeks about these configurations.

      • Scott Kingsley Clark 4:04 pm on March 14, 2016 Permalink | Log in to Reply

        I definitely think a method that defines the widget’s properties in more detail would be useful, which is where Fields API could be utilized too. So I think overlap can be reduced if we hold on #35574 for Fields API to play a part.

    • Ahmad Awais 6:32 am on March 15, 2016 Permalink | Log in to Reply

      Incredible job, Scott and all the contributors. I am looking forward to this project and almost feel guilty for not contributing.

    • Ryan Boren 3:08 pm on March 15, 2016 Permalink | Log in to Reply

      How about some screenshots of the implementations?

  • Scott Kingsley Clark 11:31 pm on January 12, 2016 Permalink
    Tags: , ,   

    Fields API updates from Q4 of 2015 

    It’s been a while since I updated everyone here about progress on the Fields API. I’ve been hard at work in the code and haven’t come up for air until now, but I’m planning on more regular updates in the coming weeks 🙂

    Lots of progress since our last chat summary in early October, here’s a bird’s eye view of what we’ve been up to:

    Where can we use help right now?

    • Review our User Profile screen implementation, let us know if it makes sense to you as a developer. It’s the kind of code you’ll be looking at needing for any custom screens you want to implement in plugins or themes, and it’s the kind of code we’re looking at using for other WordPress screens too (Post editor screen, Term editor screen, etc..)
    • Help us create use-cases for each type of object (Custom Post Types, Custom Taxonomies, Users, Comments, Media, Widgets, Nav Menu Items, etc..) — we’re specifically looking for what custom fields you could create for these use-cases and how it could make sense in real world scenarios. You can start out with just the structure, we can help you build the code for it.
    • We’re getting ready to release this on WordPress.org as a plugin, we could use some help to write up a good readme and ensure it directs people to the correct places for involvement

    So who do you contact or where do you go to help?

    Oh and did I mention that every minute you help us, you make someone really really really happy in the future? It could be your future self that gets to reap the rewards of your hard work!

    • eddr 12:47 am on January 13, 2016 Permalink | Log in to Reply

      Hi Scott – great stuff. That’s a good feeling to see all the people and community involved

      Like many, I’ve been using custom fields intensively and probably one thing that comes to mind for some is the database structure / efficiency. Querying meta fields/values is kind of a disaster for big sites with complex data. I know that most implementations create dedicated tables, but still – any thoughts about it?

      • Scott Kingsley Clark 5:10 pm on January 13, 2016 Permalink | Log in to Reply

        A few optimizations I do on bigger projects:

        • Separate large sets of data not needed across a site, but only within a specialized section of the site into it’s own multisite blog tables
        • Add post_type column to wp_postmeta, add more indexes to wp_postmeta (post_id, meta_key(30), meta_value(30); and other combinations you may want), use custom SQL queries to do meta lookups to SELECT post_id where the meta_key + meta_value match for post_type; and when inserting your meta via add_post_meta, take the return value of $meta_id and update post_type to the correct value)
        • Using a plugin like Pods, I can extend a post type to be a table for specific custom fields, this allows me to add indexes to that table and do more complicated lookups more easily without use of CAST() or LONGTEXT on custom field data (correctly have them MySQL-typed)
        • Use ElasticSearch / ElasticPress (or any other ElasticSearch plugin for WP) that allows you to do meta lookups more quickly than expensive SQL queries in WP_Query, some plugins like EP even integrate with WP_Query.
        • Kochhase 6:39 pm on January 13, 2016 Permalink | Log in to Reply

          Using a plugin like Pods, I can extend a post type to be a table for specific custom fields, this allows me to add indexes to that table and do more complicated lookups more easily without use of CAST() or LONGTEXT on custom field data (correctly have them MySQL-typed)

          Hi Scott, why do we have not pods in core? Many people need a tool to extend wordpress to an CMS as drupal. In combination with the field api this would make sence.

          I hope for that in WP 4.6

          regards Henryk

          • Scott Kingsley Clark 6:41 pm on January 13, 2016 Permalink | Log in to Reply

            Some things don’t belong in WP core, and that’s alright. WP can’t be everything to everyone. Plus Pods does a whole lot more than just that one thing 🙂

    • Ahmad Awais 7:57 am on January 13, 2016 Permalink | Log in to Reply

      Hey, Scott!

      I was thinking, what if we could have mini customizer instances?
      E.g. I created a form and I want to design it different from all other forms. In theory, I’d click a Customize button that will redirect me to the front end with customizer instance (only with the options that are needed to design that particular form). After I am done designing it, I’ll get to save it and get back to where I was in the form plugin.

      Right now, this UX and flow doesn’t exist. Customizer’s class is defined as final, there is not much we can do. But with Fields API, what if instead of creating forms inside widgets, we could get such mini customizer instances?

      Did it make any sense at all? I hope it does.

    • leemon 10:08 am on January 13, 2016 Permalink | Log in to Reply

      Great to see this moving forward! Thanks!

    • Hans-Helge Buerger 11:00 am on January 13, 2016 Permalink | Log in to Reply

      Hey Scott, I just did a quick read up about the Field API b/c I didn’t know what it is or what it’s about. Great stuff. I’m looking forward to see this in core.

    • Najum Rahim 12:44 pm on January 13, 2016 Permalink | Log in to Reply

      Ahmad,You have great idea

    • Marcus 5:03 pm on January 13, 2016 Permalink | Log in to Reply

      Looking forward to seeing the plugin. The specification and structure looks good to me at a glance.

      r.e. use cases, what about a simple skeleton plugin/snippet creating some generic set of custom fields, so we can modify that? for example, users:

      section – address

      • address 1 (text)
      • address 2 (text)
      • town/city (text)
      • county/state (text)
      • Zip (text)
      • country (DDM)

      you could go further and showcase every field type, maybe ditch a use case like the above and just create fields named literally e.g.

      section – custom form

      • text field
      • textarea
      • checkbox
      • etc.
    • Tran Ngoc Tuan Anh 8:58 am on January 22, 2016 Permalink | Log in to Reply

      Very nice idea. From years working on Meta Box plugin, I see the APIs are very different when implement fields for posts, terms, settings pages. It’s really helpful when everything is merged into 1 common API.

      I also want WordPress does this in core, e.g no another layer of abstraction code. Right now, plugins like Meta Box, ACF, Pods already add a layer for users/developers to work with custom fields. I just don’t want more layer in between.

  • Scott Kingsley Clark 7:29 am on October 8, 2015 Permalink
    Tags: , , , ,   

    Fields API chat summary – October 5th, 2015 

    Present: @sc0ttkclark, @nicholas_io, @tomharrigan, @ericlewis, @potatomaster

    Logs: https://wordpress.slack.com/archives/core-fields/s1444021200000000

    • I just got 100 hours from 10up to work on Fields API!
    • I will be working on getting the WP 4.3 Customizer changes put into the Fields API, my first pass doesn’t have unit tests passing yet
    • We’ll be fleshing out Control classes, based on Customizer control classes and expand the main control class into individual classes as opposed to a ‘switch’
    • We laid out a few implementations we’d like to get into prototyping
      • User profile fields (piggy backing existing UI of section heading + fields) @sc0ttkclark
      • Settings API (cue the oooh’s and aaah’s sound effect) @sc0ttkclark
      • Post editor (meta boxes + fields) @tomharrigan
      • Widget forms @nicholas_io
      • Future: Term editor (sections + fields)
      • Future: Comment forms?
    • We want to improve the main Fields API readme to better explain the project, offer more links to information about the Customizer API since it’s what we based the Fields API on, and flesh out more examples
    • We need more examples, so any use-cases we can put together for any object type, would be handy to start putting that code together (structures, not custom implementations or overrides)

    We certainly could use additional contributors involved with the project, especially as we seek to start more implementation prototypes of how things could work. Just hop into Slack #core-fields or check out our Github repo. Over the next 5 weeks my involvement in the project will be greatly increased, so if you are going to get involved — now would be the right timing!

    Next chat: Monday 20:00 UTC 2015 (every Monday)

  • Scott Kingsley Clark 4:15 pm on August 3, 2015 Permalink
    Tags: ,   

    Fields API: Request for review of direction 

    Over the past many months this year, I have been working with guidance from @helen on the new Fields API with the intention of inclusion into WordPress core. It’s based on the Customizer API, so those who have experience with it will see a lot of similarities. The goal isn’t to create a duplicate API though, and in our proposal we would be implementing the Fields API within the Customizer API.

    What does that bring to core as a whole? It gives core a very real and far reaching API to add fields to any type of object in a standard interface. Given the growth of the Customizer API and its inclusion of fields, @helen and I both agreed it’d be great to leverage everything it can do in our efforts here. The goal isn’t focused on the actual Customizer UI or editing on the front-end, it’s all data-oriented.

    We would create implementations behind the scenes in the various existing APIs such as the Customizer API (now) and Settings API (later) while maintaining backwards compatibility. We’re also hoping to implement the Fields API within the User profile screen. This would give core more flexibility towards revamping the User profile screen in the future, without having to tackle even more than just a UI refresh. That’s also not mentioning the fact that plugin and theme authors could leverage this API to extend WordPress with their own fields in the various areas. Future places we’d look at integrating Fields API with would be the Post editor, which I’ve pegged as our third focus, behind User profile fields and the Customizer API.

    Anyways, that leads us to the point we’re at now, we have an API but we don’t have all of the built-in Field Types (control types) yet or the latest Customizer API changes from 4.3 merged upstream into the Fields API. There are unit tests that are running (and passing!) so that is going to help us on our road towards core for sure.

    We need developers to give their feedback on the direction we’re heading. Here are the relevant links for those reviewing:

    I’d love more feedback from anyone contributing to WordPress, or the *countless* plugin and theme developers who would use the Fields API. Please comment on this post, or if you’d like to discuss further, you can hop into our weekly meetings on Mondays (Monday 20:00 UTC 2015) in the WP Slack #core-fields channel, or ping me there anytime.

    Update – 08/10/2015:

    We now also have a growing list of developers who are behind this project and would implement it in their projects if it were merged into core.

    • Matt Gibbs 4:48 pm on August 3, 2015 Permalink | Log in to Reply

      Thanks for all the hard work, Scott and Helen! The specifications doc looks very detailed. I’d like to see more usage examples though. Similar to the one on https://make.wordpress.org/core/2015/05/27/metadata-api-project-reborn-the-new-fields-api-project/

      1. How to create custom field types (or Controls as its called now)?
      2. Does a field require a section?
      3. What happens if the field capability isn’t set? Does it fallback to the parent section / screen?
      4. How are repeatable fields handled in the current spec?
      5. Is the field API itself concerned about field order? Should it be?
      6. How granular are field sections? E.g. can a field be added to a single post item (or user) only?

      • Scott Kingsley Clark 5:55 pm on August 3, 2015 Permalink | Log in to Reply

        1. We’re still ironing that part out, control types / field types is the next area of the spec we have to nail down. Feel free to join us on Mondays for our weekly meetings if you want to help us get that part finished.

        2. Currently, it functions the same as the Customizer API, which allows you to add as many fields as you want, without sections or screens (panels). The differentiation is when you add a control, you specify the section or screen you want to add it to.

        3. Fields don’t require capabilities, controls don’t either. We handle the same capabilities checks as the Customizer API does right now — https://core.trac.wordpress.org/browser/trunk/src/wp-includes/class-wp-customize-setting.php#L439 — which is to say, if you don’t provide a capability check, it is wide open. We should nail this down further and I think it’d be good to default to no-access. We need dev input on that.

        4. There is no preparations for repeatable fields or repeatable groups at the moment, that’s something we want to nail down in the control types / field types discussion, as there may be things we want to do there. The existing Fields API spec is almost entirely based off of the Customizer API and no additional functionality has been added for that yet. It’s on our list though, we want to ensure any effort we put forth into core does not limit developers or the common ‘loop field’ use-cases. Whether ‘loop fields’ go into core or not, that’s not something I can speak to at this point.

        5. Yes, the spec makes use of the ‘priority’ option for screens, sections, and controls. Works just like filter/action priorities do.

        6. Screens, sections, controls, and fields are all added to a specific object type / name (for example: post type : post). Further definition based on a conditional like a specific ID, capability, etc, could all be handled through an additional callback or filter that we can add inside of the check_capability methods for screens / sections / fields.

    • Brent Jett 8:23 pm on August 3, 2015 Permalink | Log in to Reply

      Cool spec! I like the idea of a broad-reaching common syntax for adding fields from themes/plugins, but I’m wondering if there isn’t a more modern/human-readable format or syntax for this. My immediate thought was JSON files (OOP code underneath obviously). WordPress exposed object oriented API so late in it’s relative lifespan that OOP code like the customizer API still looks very foreign to themers. Given that most app platforms now use JSON manifest files to declare things like configuration, it would seem to me very natural for WP to look at adding a more approachable syntax like that to it’s theme configuration APIs.
      But I could be way off. Nice work either way.

    • Mike Nelson 10:14 pm on August 3, 2015 Permalink | Log in to Reply

      In Event Espresso we created a similar system called the “Forms System”, inspired primarily by Django’s forms. EE Forms basically define how to display an HTML form, how to validate the user-provided input on both the client-and-server side, and how to sanitize/normalize the data for use in the PHP code. (It leaves the job of saving data to either our models system, wp options api, and sometimes direct wpdb).
      EE “form sections” are roughly equivalent to your “screens” and “sections”, and EE “inputs” are roughly equivalent to your “controls”.
      Some differences that might spark some ideas for you:

      1. EE form-sections are nestable; so you can have sub-sub-sub-sections etc. This has allowed for more re-use. Eg, say you wanted to have screen section for multiple post custom fields: the “custom fields” would be a section, and then it would have a different sub-section for each post custom field.
      2. Each form section can have its own “layout strategy”, a separate class that dictates how to layout the form section’s inputs in the HTML, and its sub-form-sections. So if you want to layout your form’s inputs in a very standard way, you’d select one of the pre-set layout strategies.
      3. If you want to layout your forms input in the HTML in a very custom way, template code can be passed a form section which gives the template code access to the sub-sections and inputs and the template code can dictate where to place what
      4. sub-sections can actually just be chunks of HTML, “html subsections”. These have been good for extra stuff that’s important for the display of the form, but aren’t necessarily related to form-data
      5. the EE forms system is separate from our “model system”, although they’re sometimes related. The forms system is primarily focused on displaying HTML forms, and then validating and sanitizing the user’s input; whereas the models system focused on defining the underlying data stored in the database, how that data is related to other data, how to save and retrieve that data, etc. We have a form section base type that can automatically create sub-sections and inputs based on a particular model.

      Other than that, it’s really quite similar.

      Also it’s not that clear: is the fields API intended for use in the frontend too?
      Also it seems if this is intended primarily for defining the HTML forms and how they get validated/sanitized. I think having a separate API for defining the underlying data would be beneficial, in cases where you don’t want every attribute of the data to necessarily be represented in HTML forms, or you might want to provide different forms for editing the same underlying data.

      • Scott Kingsley Clark 4:16 pm on August 4, 2015 Permalink | Log in to Reply

        1. I’d like to explore the idea of sub-sections and sub-fields (sections that can have sections in them, fields that can have fields in them) in our class architecture. Even if they’re not utilized in core, the ability to use them or for plugins to enable their use would be a big thing.

        2. We’re looking at something similar, though not really, it’s mainly that each screen will have it’s own fields display and saving implementation, much like the Customizer itself has one.

        3. There are filters and actions in place for this right now in the Customizer and the Fields API

        4. I don’t doubt someone could extend the Fields API with a new control type or a custom section class that would be able to output just HTML as set in the definition options. That could be useful for some cases.

        5. Fields API is based on the Customizer API, it’s somewhat split up between modeling and display, but it’s not entirely MVC at the moment.

        6. You can use the Fields API anywhere, you would write your own implementation to display fields and process the $_POST data accordingly, utilizing the underlying Fields API to access the data structures and field types input HTML etc. You could even use the Fields API for any object type you want to build into it, there are hooks in place that support custom object types, for purposes of plugin developers to utilize the Fields API for their own things (Gravity Forms, Pods, NextGen Galleries, etc).

        7. Each implementation can override the core output, to do whatever it wishes. For instance, Customizer API supports previews and makes heavy use of JS to do what it does. Our Customizer API implementation extends the Fields API but does not limit the ability for those things, and many others for other implementation needs.

    • thomask 11:02 pm on August 3, 2015 Permalink | Log in to Reply

      I am really looking forwards to this, actually for me this is the second most crucial missing feature for WP – the first is multilanguage support. I use Advanced Custom Fields for almost every web i do, and however it is very nicely written and easy to use, i would prefer some build-in support.
      I have read it all just briefly and will have to try it, from my experience what is important is
      1. support for multilanguage fields (so that i can have common field for all languages version of one post, as well as translatable field) – but this is i guess more question on the multilanguage plugin (or future WP multilanguage support)
      2. text field (just simple text), term fields and post field (N:N relation field), wysiwyg field, user selection field … and/or easy way how to create new field types with standardised look, values control etc.
      3. allowed values control and definition, read only possibility, required field possibility
      4. possibility to add fields also to terms (!!!) – imo terms (edit-tags.php) are currently very stupidly different from the posts – it should have the same look, so that we could use the same fields and functions.
      5. easy definition of post types and other conditions, that are required for field to be displayed
      6. advanced feature, but very usefull in many cases – possibility to set-up condition for field, that should be calculated live on the post screen depending on some live changes – e.g. “this field should be visible only when category is “blabla”).
      7. field could be added also to attachments – but dont forget, that it does not have only the standard post.php, but that the fields are displayed also on the attachments popup screen
      8. dont forget the field versioning (with older version of post you see also older version of its fields)
      9. posibility to create groups of the fields with their conditions
      10. possibility to e.g. display fields in two columns
      11. very advanced field – repeater field (e.g. something like this http://www.advancedcustomfields.com/add-ons/repeater-field/) – possibility to create field table. This is very complex, but very often this is the only way how some things can be solved, as currently there is only simple ID->key->value in WP, but very often you need ID->key->array(subkeyN->valueN), so without this field type many users will still have to use some solution as advanced custom fields.

      • Scott Kingsley Clark 5:26 pm on August 4, 2015 Permalink | Log in to Reply

        1. That sounds great, it sounds like Fields API could enable this through the options you pass into the configurations. A plugin could pick that up and change how the fields work from there, per language.

        2. That’s on the list at the moment

        3. Good ideas, we’re still nailing down the specs but those are two I’d like to see us tackle if possible — it’s just going to be difficult.

        4. Not currently possible, but when Term meta makes it’s way into core, this Fields API will be there to utilize 🙂

        5. Sounds great, I’m not sure how much of this we’ll tackle in the Fields API itself, but it’ll definitely be doable by a plugin.

        6. That also sounds great, plugin material though — but enabled by our extensible code.

        7. This sounds great too, it’s not part of our initial focus but there are hooks in place that we could implement this for media fields as well.

        8. This isn’t a problem, everything operates by ID, revisions get their own ID, so everything should continue to work there, even when post meta revisions makes it’s way into core.

        9. Groups of fields are possible, but conditions is currently plugin territory.

        10. That sounds like plugin territory, but totally possible because we have hooks for that.

        11. I love the idea of a loop field or some basic repeatable field in core, not sure if we’ll include the field type itself in core but we’ll do everything in our power to enable developers to make use of it in the numerous plugins that have this field type as an option.

    • camu 1:16 pm on August 4, 2015 Permalink | Log in to Reply

      Thank you for all this work. I was wondering, why not just merge Advanced Custom Fields into core? It’s a robust plugin that already does most of the things listed here above. I’ve been using it for years now, and it has always delivered.

      • Scott Kingsley Clark 4:04 pm on August 4, 2015 Permalink | Log in to Reply

        There aren’t any plugins that could be a candidate to merge into WordPress core right now as they are, this Fields API effort is our focus right now to make a better API for custom fields plugins out there to utilize for a better standard when developing for WordPress. What we’re doing here wouldn’t replace custom fields plugins for many developers, they add features that are useful for some projects and offer an admin UI to manage these things. At this point, the focus is not on creating an admin UI to manage custom fields for objects in WordPress, but to offer up a unified API to interact with fields for all object types.

        • khromov 4:53 pm on August 4, 2015 Permalink | Log in to Reply

          From reading the post, the proposed direction is very similar to what ACF offers. There will be edge cases that the new API won’t fill right away (ie. repeatable fields), but it’s something the community is going to want and build.

          My point is, don’t understimate the will of the community to bend this to their particular use case. A good design (which it looks like so far), enables that.

          • Scott Kingsley Clark 4:57 pm on August 4, 2015 Permalink | Log in to Reply

            Totally agree, this is actually the result of lots of communication between many developers of plugins / libraries for building custom fields. There’s no way I would underestimate this community, was just noting that none of the plugins were a direct fit.

    • christopherabalos 7:49 pm on August 4, 2015 Permalink | Log in to Reply

      Very interesting take on a much needed API. The WordPress API for creating metaboxes, post types, taxonomies, customizer fields, widgets, etc are in need of a uniform API. I’ve been attempting to tackle this the last few months in my own projects. My implementation revolves around new manager classes for things like post types and settings that follow a pattern similar to the Customizer API. My manager classes have been written to accept WP_Customize_Control objects.

      I’d also like to see the ability to create fields for widgets, which is something I’ve included in my implementation.

      I’m curious to hear more about the decision to wrap the fields API into a single manager vs. having separate managers that all accept the same field objects.

      Keep up the great work Scott!

      • Scott Kingsley Clark 3:21 pm on August 5, 2015 Permalink | Log in to Reply

        Widgets is totally a logical next step in this, I would love to see Fields API used for Widgets, for the Shortcode UI project, etc.

      • Scott Kingsley Clark 3:24 pm on August 5, 2015 Permalink | Log in to Reply

        One manager class is based on the Customizer API structure. I ended up going with one class so that there was one class things would be used to interact with, stored screens/sections/fields/controls in, etc.

    • Chris Lema 3:43 am on August 5, 2015 Permalink | Log in to Reply

      My question may be silly, but assuming that a field has been created and attached to a post type, and then populated for all those posts, is there an expected facility in the API to be able to return a list of posts where the field is populated with a specific value? Additionally, are their collection operations where I could get a count of all those posts with the value of a specific field matching what I’m submitting?

      • Scott Kingsley Clark 3:20 pm on August 5, 2015 Permalink | Log in to Reply

        WP_Query / meta_query already do this 🙂

        The Fields API is not meant for querying for data, it’s to register the structures of information a site needs for it’s content / data types.

        • jbmanos 11:38 pm on August 7, 2015 Permalink | Log in to Reply

          So if I’m understanding this correctly, I could register fields I’ve developed for a particular site and the core will know what fields it needs to show the data it has? In other words, this would be a manifest of information types available?

          If so, I like it! I already get a little nervous that if I lose a piece of php that registered the fields to begin with, how many SQL queries and guess it’ll take to recover the data.

          • Scott Kingsley Clark 6:50 am on August 10, 2015 Permalink | Log in to Reply

            Basically, yes. A standardized API to register fields for different objects. An API that would eventually be the under pinning of all other Form UI, in that — a plugin, theme, or app (as exposed by a REST API) could know everything about your WP site, what content types it has (already possible), down to what fields it has (already possible) but more importantly — what types of fields it has. More in-depth information about the fields, where they are, how they’re used.

            If you lose the PHP side of this, you’re back to where you were before, which is to say, the same place you’d find yourself if you lost the config in any other plugin that builds fields. So there’s not really anything to get around that 🙂

    • Paul de Wouters 6:35 am on August 5, 2015 Permalink | Log in to Reply

      Not sure if it has been mentioned, but custom fields for menu items would be useful too.

      • Scott Kingsley Clark 3:20 pm on August 5, 2015 Permalink | Log in to Reply

        That’s a whole other story for another time, but I agree. Menu item custom fields are currently a very big affair to deal with given the lack of actions/filters in that area of the UI.

    • Eric Andrew Lewis 7:24 pm on August 14, 2015 Permalink | Log in to Reply

      Defining a spec for this project is a great way to go.

      The spec can be drawn out in some places. e.g. What is a field, and how does it relate to object metadata? How does this relate to prior HTML form HTTP POST submissions? This would help describe the problem space.

      The cross-platform usage of self-describing fields/metadata for rendering custom views (e.g. rendering a color-picker in the iOS app, or rendering custom media fields in Attachment Details) is a major plus, which should be explained in Community Benefits.

      The “Background” section (as-is) doesn’t seem relevant in spec, as it describes the history of the project, not specification.

  • Scott Kingsley Clark 10:12 pm on May 27, 2015 Permalink
    Tags: , , ,   

    Metadata API project reborn: The new Fields API project 

    Many of you will remember that a couple of years ago, @ericlewis and a group of us set out to start a project to make sense of all of the different APIs that arose from third party plugins and themes to build custom field solutions on top of WordPress. That project was nicknamed “Metamorphosis” and subsequently went by the “Metadata UI/API” project. As plugin authors dealing with and using custom fields and content types, we had been tackling the issues of developing for multiple object types in WordPress for years prior to getting together.

    Now, @helen and I are pleased to (re)introduce to you what we’re hoping to be the fruits of all of this labor: Meet the new Fields API project.

    function fields_api_example_post_field_register( $wp_fields ) {
       // 1. Define a new section (meta box) for fields to appear in
       $wp_fields->add_section( 'post_type', 'my_cpt', 'my_meta_box',
             // Visible title of section
             'title'       => __( 'My Meta Box', 'mytheme' ),
             // Determines what order this appears in
             'priority'    => 'high',
             // Determines what order this appears in
             'context'     => 'side',
             // Capability needed to tweak
             'capability'  => 'my_custom_capability'
       // 2. Register new fields
       $wp_fields->add_field( 'post_type', 'my_cpt', 'my_custom_field',
             // Default field/value to save
             'default'    => 'All about that post',
             // Optional. Special permissions for accessing this field.
             'capability' => 'my_custom_capability',
             // Optional. Add an associated control (otherwise it won't show up in the UI)
             'control' => array(
                // Don't set 'id' and it will automatically be generated for you as
                'id' => 'mysite_my_custom_field',
                // Admin-visible name of the control
                'label'   => __( 'My Custom Field', 'mytheme' ),
                // ID of the section this control should render in (can be one of yours, or a WordPress default section)
                'section' => 'my_meta_box',
                // Control type
                'type'    => 'text'
    add_action( 'fields_register', 'fields_api_example_post_field_register' );

    (Please note: The code above may not be the same as the final implementation, it will especially change over the next few weeks)

    First of all, we split off the UI side of the project to focus solely on the API. This way, we’re not held up by anything as we move towards implementation inside of core. We can tackle each UI separately and that helps us keep the project nimble and on track.

    The goals of this new API proposal will be to be implemented across WordPress objects as an API to register fields and sections for. We aim to cover these objects (not necessarily in this order):

    • Customizer (retrofitting it beneath the existing Customizer API)
    • User profile screen
    • Post editor
    • Settings screens (retrofitting it beneath the existing Settings API)
    • And other areas in the future (Comment editor, Network Settings screens [see #15691], Media modals, etc)

    This API offers a great deal of standardization across all of WordPress and code reusability. It’s paramount for third-party developers, who will be able to utilize these structures in their own plugins and themes, build apps and give access to other developers so they can contextually see what a site really contains. I see the biggest use-case being able to expose the entirety of WordPress to the REST API and giving apps like the WordPress iOS app access to meta boxes and custom fields to display real editor screens with field inputs based on the control types natively.

    Areas we need help currently:

    • Examples and use cases for Customizer, User profile screen, Post editor, and Settings screens (submit issues in GitHub with your ideas, coordinate with us to refine them if you want)
    • Unit tests for core
    • Testing Customizer implementation, you’ll find the core files to replace under the /implementations/ folder in the repo
    • Brainstorming implementation classes for other object types to implement in the UI, starting with User profile screen

    If you’re interested in joining our merry crew which includes @helen and a few of us, hop into Slack #core-fields and join our weekly meetings every Monday (Monday 20:00 UTC 2015). You can check out the Fields API and submit PRs on GitHub, or ping us in #core-fields throughout the week with questions or concerns.

  • Scott Kingsley Clark 5:20 pm on August 22, 2014 Permalink
    Tags: ,   

    WP Metadata UI / API project update and new meeting time/place 

    It’s been a few weeks since we’ve posted an update, @mikeschinkel has been working hard on some new commits to give us some shortcuts for option arrays and things have stabilized there finally. We’re now focused on documenting field type development so we can get some contributors in there fleshing out the remaining field types.

    We are also moving our “Office Hours” time and place, to Mondays @ 1800 UTC , but instead of IRC where people can’t sync up and collaborate, we’re moving it to our public Gitter room. Some other WP projects are using it and we’ve found it incredibly helpful to keep up with GitHub activity along with chat that can happen at all times of the day and it sticks around for you to read anytime you want to.

    Our Gitter chat can be found here: https://gitter.im/wordpress-metadata/metadata-ui-api

    Anyone can see the chat messages, and if you want to participate it’s just a GitHub login away. They have iOS / Mac apps too, so that’s helpful to some people as well.

    If you’re interested in contributing, or if you want to check out what we’ve got and need some insight, just ping us — anytime — in Gitter 🙂

  • Scott Kingsley Clark 6:06 pm on June 22, 2014 Permalink
    Tags: ,   

    WP Metadata API / UI office hours this Friday 

    We will continue our weekly meetings this Friday. As no other suggestions have been made, it will remain at 18:00 UTC on Fridays in #wordpress-core-plugins on Freenode IRC.

    We may be transitioning from meeting into office hours as we haven’t had as many contributors joining us at the meetings as we had hoped. We will continue developing some awesomeness over at https://github.com/wordpress-metadata/metadata-ui-api

    Feel free to hop into the issues and take ownership of new field types or documentation. We’re also looking for help with styling of the form fields and JS in relation to support for repeatable fields.

    • Slobodan Manic 7:47 pm on June 22, 2014 Permalink | Log in to Reply

      Fridays work for me. I can continue working on field types, submitted a PR with four new input fields (email, range, number, color).

    • nofearinc 7:56 pm on June 22, 2014 Permalink | Log in to Reply

      9pm EEST on Fridays is not really the best timing for some of us either, which is 8pm for CEST (Central Europe) folks too (sorry for not being available, but that timing is a bit off here).

    • Ryan McCue 1:21 am on June 23, 2014 Permalink | Log in to Reply

      We may be transitioning from meeting into office hours as we haven’t had as many contributors joining us at the meetings as we had hoped.

      I think that’s just a common thing with feature-as-a-plugin teams; don’t be disheartened! 🙂

    • deltafactory 2:06 pm on June 23, 2014 Permalink | Log in to Reply

      Was last week’s cancelled? I was there and tried to get the conversation started but no one answered.

      • Scott Kingsley Clark 2:11 pm on June 23, 2014 Permalink | Log in to Reply

        Saw you and someone else were there, unfortunately Mike couldn’t make it and I was stuck in traffic trying to get home. We are all currently planning to be there this Friday, I won’t be cutting it so close with my plans on Friday either 🙂

    • Scott Kingsley Clark 8:32 pm on June 27, 2014 Permalink | Log in to Reply

      It turned out that Mike Schinkel couldn’t make it this week and I once again was stuck in traffic trying to get back from a WP lunch meetup.

      I think we’re going to try and push the ‘office hours’ a little earlier in the day so we can get some of our european contributors more involved.

      But going forward, I think in general, Fridays in #wordpress-core-plugins, I’ll be in there, and if you want to chat, we can chat, not sure if an hour long meeting slot is best while we’re in the current stage, until we have more movement and planning to be done as a group. Right now we’re just executing plans as we’ve laid them out.

  • Scott Kingsley Clark 4:00 pm on June 5, 2014 Permalink
    Tags: ,   

    WP Metadata API / UI team meeting hours vote 

    It was brought up that our current meeting time at 18:00 UTC on Fridays in #wordpress-core-plugins on Freenode IRC is not necessarily the best for everyone.

    What day would be better? Around what time would be better?

    This week’s meeting will continue as planned at the existing time on Friday, but next Friday’s meeting will be postponed due to a scheduling conflict with @mikeschinkel and I.

    • Slobodan Manic 6:25 pm on June 6, 2014 Permalink | Log in to Reply

      Hi. No one around for the meeting this week?

      • Scott Kingsley Clark 6:35 pm on June 6, 2014 Permalink | Log in to Reply

        We’re usually just hanging in #wordpress-core-plugins during that time frame, lately we’ve just been working through issues and code together. Not a whole lot of discussion during this period beyond “I’m working on this” 🙂

  • Scott Kingsley Clark 12:46 am on May 24, 2014 Permalink
    Tags: ,   

    We’re ready for more contributors to join us on the WP Metadata UI / API project 

    Where we need help most

    • Field Types – We need help building new field types, we currently have a few basic fields to start off with including the Text, Textarea, URL, Date, and Hidden field types.
    • Actions / Filters – We are now seeking to add in the hooks necessary to extend things further, feel free to request hooks anywhere you see a need for them.
    • Repeatable Fields – We are architecting a solution for repeatable fields, in which you can take a single field and make it have repeatable inputs that let someone add multiple values. These values would be stored in multiple meta values for the same meta key for the specific object ID.
    • Unit Testing – If your UT fu is strong, then strong would the use of your fu be on our team!

    Have any other ideas you’d like to help out with? Hop in, the world is your oyster and we’re eager to help you get those pearls!

    Join us in #wordpress-core-plugins on Freenode IRC and seek out @sc0ttkclark or @mikeschinkel if you need anything to help you get started, or open up an issue on our GitHub with your questions/feedback.

    We’re also still meeting 18:00 UTC on Fridays in #wordpress-core-plugins on Freenode IRC, feel free to search IRC logs for <#metadata> for a history of our previous conversations.

    So… ready to start? Head over to the WordPress Metadata UI / API GitHub now, see you there! Happy coding!

  • Scott Kingsley Clark 7:33 pm on May 13, 2014 Permalink
    Tags: ,   

    Metadata UI / API status update 

    We’ve been hard at work the past many weeks on getting something ready for contributors to start adding their PR’s against. @mikeschinkel took the helm for the initial base, after many discussions came up with a brilliant first code PR to the project. In our Friday meeting, we presented the PR and merged it into the official master for the project.

    You can start browsing through it now over at: https://github.com/wordpress-metadata/metadata-ui-api

    Some notable items from this initial first draft:

    • Global functions to access class/method based architecture (register_*)
    • register_post_form( ‘meta_box_name’, ‘post_type’, $args ) — Add new forms to a post type (like meta boxes)
    • register_post_field( ‘meta_key’, ‘post_type’, $args ) — Add new fields to a post type
    • Initial support to expand the API for use with Comment types, Option Groups, and Users
    • Support for custom object types that aren’t WP object types, like for plugins that have their own custom tables
    • Very efficient registration limits ‘fixups’ until fields are called, so registering hundreds of fields won’t detrimentally affect timing (confirmed by initial benchmarking)
    • Storage handling broken up into meta, options, taxonomy terms, can be extended by plugins to add additional storage options (like in Pods, we have custom tables/columns available for custom fields)
    • WP_Html_Element class methods handle html element building and auto-sanitization for attributes

    Our next steps are to continue testing the API and start having contributors join in (read: yes, YOU!). We’d like to start getting PR’s that add new field types and start working on unit testing next.

    Also, a call-out to our UI / JS team, we’re ready for you now 🙂

    • Scott Taylor 7:44 pm on May 13, 2014 Permalink | Log in to Reply

      Is there an example of this implemented somewhere?

      • Scott Kingsley Clark 7:45 pm on May 13, 2014 Permalink | Log in to Reply

        There’s a quick example in the README.md on GitHub, we’re working on getting together a full example we’ll be using for the unit testing as well.

    • Jon Brown 7:51 pm on May 13, 2014 Permalink | Log in to Reply

      Is this targeting 4.0 or is this still “future release”? (assuming the later, but always hoping)

      Aside, from that, looks awesome and looking forward to starting to bang around on it.

      I notice that only date, text, textarea & url fields are currently defined. I assume more are coming, is there roadmap? (I recall hearing of a roadmap, just not finding it anywhere).

      • Scott Kingsley Clark 8:01 pm on May 13, 2014 Permalink | Log in to Reply

        I’d love for it to mature enough to make 4.1, that’s my personal goal.

        More are coming, we just needed a couple to work with and test, starting small and adding more as we go. Contributors are welcome to suggest and add pull requests with others.

        I’ll be sure we update our readme with the current roadmap for upcoming things.

    • Jose Castaneda 9:08 pm on May 13, 2014 Permalink | Log in to Reply

      I really like the progress! Can’t wait to see the end result of it all. 🙂

    • Chris Van Patten 9:43 pm on May 13, 2014 Permalink | Log in to Reply

      This looks awesome. I have questions/concerns, but I’m going to try to play with it before asking them. Things might become clearer after I’ve had a chance to test it out!

      • Scott Kingsley Clark 2:34 am on May 14, 2014 Permalink | Log in to Reply

        Feel free to hit us up in #wordpress-core-plugins, I’m usually in there every day, but we can chat any time you’d like if you want to ping me for a specific time. We are definitely open to ideas to improve things.

    • sirjonathan 11:24 pm on May 13, 2014 Permalink | Log in to Reply

      Pardon my ignorance.. How would this effort compare / contrast with an effort like Elliot Condon’s “Advanced Custom Fields”? (I use it heavily and have beta tested the 5.0 release, which I’m highly impressed with).

      • Scott Kingsley Clark 2:30 am on May 14, 2014 Permalink | Log in to Reply

        ACF is one of a large and always growing list of plugins that lets you create custom fields for WordPress. It adds an Admin UI, like many (but not all) to help you define and manage those custom fields on your site.

        Plugins like these aren’t replaced by what we’re doing here, this is merely an API and standardized Form UI for what they all end up doing. This project scope does not include adding a management screen to manage the fields and forms (meta boxes).

        We hope that the result of this being implemented in core would be for these plugins to utilize this API, extending it to suit their needs, while giving a standard structure to post types that other plugins can integrate better with.

      • Mike Manger 9:37 am on May 14, 2014 Permalink | Log in to Reply

        I am looking forward to not having to exporting/importing plugin settings after each deploy.. ACF (and others) are great, but relying on functions like get_field( ‘my_field’ ) has always felt strange to me because you can’t guarantee ‘my_field’ will always exist in each setup.

        • Scott Kingsley Clark 4:40 pm on May 15, 2014 Permalink | Log in to Reply

          Also, global functions like get_field and others with no standard prefix from the plugin creates problems of their own for potential core inclusion of similar functions too.

    • Florian Girardey 7:23 am on May 14, 2014 Permalink | Log in to Reply

      Just waw !
      “Initial support to expand the API for use with Comment types, Option Groups, and Users”
      That’s fu**ing awesome.
      Does it means that the default WordPress options will be rework with this API ?
      I see there a pretty good way to make WordPress more secure even in third-part themes and plugins.

    • Scott Kingsley Clark 7:54 am on May 14, 2014 Permalink | Log in to Reply

      @fgirardey Our goal is to implement this as the standard API across WordPress for fields and option groups. I think it’s a lofty goal, but if we can get it accepted for post meta, we’re halfway there to get it in for the rest by adding a few more interfaces.

    • Roger Coathup 10:36 am on May 16, 2014 Permalink | Log in to Reply

      Are you planning to allow the forms to be rendered front end as well as in wp-admin (Something that Webdev’s Custom MetaBox API can now support)?

      • Scott Kingsley Clark 4:22 pm on May 16, 2014 Permalink | Log in to Reply

        Yes, that’s already possible now in the code, there’s no default form UI output handler yet, it’s all per implementation (currently just for post editor)

    • Weston Ruter 8:29 pm on May 21, 2014 Permalink | Log in to Reply

      Chiming in here for the first time. Regarding post/postmeta, I wanted to mention a prototype plugin—Customize Posts—I’ve been working on which adds support for editing a post’s data fields and post meta within the Customizer, allowing you to preview changes before saving.

      For example, currently when hitting Preview Changes when editing a post, you currently cannot preview a change to a page template, which only goes into effect when saving a post. Likewise, when you change the featured image, it updates the postmeta via Ajax immediately upon selecting the image, so you cannot preview that change either. All such postmeta changes should be fully previewable so you can see what will happen if you make a change. This is what bringing post/postmeta management to the Customizer will make possible.

      I see some nice overlap with Metadata project here, as the Customizer currently only has builtin support for registering settings for options and theme mods. It would be great if additional areas of WordPress could be easily registered for management in the Customizer.

compose new post
next post/next comment
previous post/previous comment
show/hide comments
go to top
go to login
show/hide help
shift + esc
Skip to toolbar