WP_Meta_Box

[koopersmith]

Ryan, Nacin, and I would like to see a Meta Box class in 3.3. Let's make it happen.

Attached is a first pass (in plugin form, for ease). It provides a basic API and supports multiple instances. Instances are stored in a static meta box registry, which should require minimal interaction.

Keep in mind that meta boxes are not just registered on CPT pages — they are also used on the dashboard, in menus, and in custom UIs. The parent class should be suitable for each of these cases.

I think we should move caps to the main Meta Box class (and allow subclasses/instances to specify/override the cap through $args), and also provide $args to enable/disable any checks we perform before saving (e.g. autosave, etc).

It would also be interesting to integrate this with the proposed metadata API improvements.

See #15066 for prior discussion.

[hakre]

Just some feedback while quickly scanning over the code:

WP_Meta_Box::registry()->add( $this ); - takes object instance

WP_Meta_Box::registry()->remove( get_class( $this ), $this->screen, $this->slug ); - has a totally different parameter setup.

It's easier if the correlating methods share the same parameter types and order.

And if you store the object instances hashed (e.g. spl_object_hash) inside the registry, it will reduce the code in the remove part drastically because you always have the right instance to remove by it's hash.

[hakre]

If you need the flexibility to search by class and/or slug in the registry, create another function that can return that result as an array of object instances (e.g. find()). Then it's even more flexible and does provide the tool you're probably looking for.

[hakre]

Some example code making the registry a singleton and more fluent.

[hakre]

I've added some example code which does show this. Aditionally I've moved the singleton logic from the meta box base class into the registry itself in case this makes sense.

If you want to make extending classes of the base class to call the parents constructor class you can make use of the following methodology:

• Make the base constructor final
• Make the base constructor call an init() method of the same instance.
• Make that init() method within the base class an abstract method.

Extending classes then can initialize themselves inside the init() method instead of the constructor and must not take care any longer for initialization of the parent class.

[kawauso]

Related: #17515

[wpsmith]

added

[WraithKenny]

On the revision check of WP_CPT_Meta_Box: Sometimes authors intend revisions to receive metadata updates and restore metadata on post restore. It'd be nice to have a built in functionality for this in the API (or at least account for it).

Also, if the WP_CPT_Meta_Box is on an Edit screen with a nonce, the cap check wouldn't be necessary as Edit screen checks current_user_can( 'edit_post' ) prior to save_post and any other situations (Quick Edit, for example) won't pass the nonce check.

[WraithKenny]

It'd be nice to include an optional Update/Save Ajax button and Ajax-handler registration.

Being able to specify whether the Meta Box should be added to default_hidden_meta_boxes should be incorporated.

[nathanrice]

I'd like to try to contribute to this, somehow. This has been one of the larger pains in the process of building plugins and themes for us at StudioPress, I definitely concur that there is a need.

The only thing I'm unclear about is the scope. What exactly are you guys thinking in terms of what the class should actually do and handle? I feel like I might be able to work something up based on my experience, but a clear list of features would be a lot better than "let's just make it better."

Thoughts?

[ryanduff]

Well with non-lead feature freeze originally slated for 9/14 and complete feature freeze on 9/21 this needs to move now. I agree that it its either a yes/no at this point and if something needs to be reworked, now is the time. If I can help out in any way to help get ensure this gets in for 3.3 let me know.

[nacin]

What exactly are you guys thinking in terms of what the class should actually do and handle?

This is what I was thinking.

Since we now have register_meta(), which includes both sanitization and authorization callbacks, it would be nifty if a method of WP_Meta_Box could wrap register_meta() and then register those pieces of meta against the meta box. We could even enforce sanitization callbacks. Then, there's no need to have anything that hooks into save_post -- whatever gets sent back will automatically be saved.

We'd also want form rendering, but that doesn't need to be too complex. Basic form fields are fine. Likewise, registering a field could potentially mean that A) basic fields are handled and B) so is the corresponding sanitization depending on the field and desired data type.

If all goes well though, there's no need to hook into add_meta_boxes(_$post_type), call add_meta_box(), write your own function to render things, then hook into save_post too. As much as I've gotten used to those steps, it can be tedious and has basically no abstraction.

Not a whole lot of iteration went into this ticket, especially since koopersmith has been on UI stuff for most of the cycle. We're going to need to punt this to 3.4, but I would love it if work started and continued uninterrupted during beta and RC, then the moment we branch, we can commit something awesome.

[koopersmith]

In [19320]:

Add reset CSS (clear) to the admin bar. props scribu. fixes #19260, see #18179.

[koopersmith]

[19320]: Fail. See #18197.

[dwenaus]

Is this going to make it into 3.4? it would be great to get this in there.

About adding form element rendering, as nacin mentions, this would be great to have. The ​| WPAlchemy MetaBox PHP Class seems to be the most mature in this respect, but maybe overkill as well. Do we pull the good stuff from there or write something new for form handling?

A number of other custom field / meta box libraries and plugins exist also:

• ​| Advanced Custom Fields
• ​| Types
• ​| Content Construction Kit (CCK) for Drupal
• ​| Custom Field Template
• ​| More Fields Plugin
• ​| Custom Metaboxes and Fields
• ​| Meta Box Script
• ​| Easy Custom Field Types
• ​| Simple Fields
• ​| another library, etc.

A common need seems to be repeatable fields. It's such a common need it would be great if we could get that into the API. Beyond that repeatable field groups would be stellar, but maybe not for the first go.

And what about front end display (ie. ​| Views or ​| the loops) I'm guessing that is separate, but related.

[dwenaus]

and here is a very well put together elegant and simple plugin that might be just the thing: ​http://wordpress.org/extend/plugins/custom-field-suite/

[lumpysimon]

and here is a very well put together elegant and simple plugin that might be just the thing: ​http://wordpress.org/extend/plugins/custom-field-suite/

I agree that plugin does have a nice UI and provides a very quick way to add custom fields, including the much-needed repeating fields, but it also adds six database queries per page and two new database tables (one of which duplicates data from the postmeta table), so is extremely unlikely to make it into core in anything like its current form.

[jb510]

What is the goal of this ticket at this point? There is a patch for registering a metabox, but nothing for building the actual box which is what I at least thought the goal was. I guess I'm wondering if "has-patch" is the right category for this at this point?

Personally I was hoping for something like the @norcross, @jaredatch, @billerickson CMB Class or maybe even some of the features from the WP Alchemy Class. Both of which are awesome tools but I'm sure need work to be core compatible.

I personally don't think it needs a UI for creating and adding CMB's to posts like Type and Views or Custom Field Suite does, at least not in it's first iteration.

[ryanduff]

Replying to jb510:

I personally don't think it needs a UI for creating and adding CMB's to posts like Type and Views or Custom Field Suite does, at least not in it's first iteration.

Agreed on lack of UI. There's no UI to generate post types or taxonomies in core, why should there be one for meta?

All that's needed is a simple, extendable way to show/process the field types (and possibly hook in and add new ones) as well as a way to define field sets as meta boxes.

[billerickson]

As described by others, I think the required features should be:

• An easy way to create metaboxes
• Common fields built-in
• Easy way to extend them to add new fields

There shouldn't be any UI for creating metaboxes or fields. That's plugin territory.

I think we've done a pretty good job with our code library ( ​code | ​wiki ) and would love to see something similar make it into core.

[dwenaus]

Agreed, axe the UI.

The Custom Metaboxes and Fields code has a nice balance of just enough features with clean code. Also, their way of implementing the meta box array is intuitive. I believe you guys are working on field cloning/repeating right now, right? I would like to see this in the first iteration as well.

The WP_Alchemy class, while more powerful, has a codebase 5 times as large. Also, it doesn't generate the html elements, it just supports it. This approach is more flexible but it's also less intuitive and more work to setup. Special cases are better dealt with using filters.

[ryanduff]

Keep in mind that GaryJ is working on a complete rewrite of CMB so I'd be curious as to how that pans out and what may be gained from it as far as this ticket goes.

[billerickson]

Correct, a rewrite is underway, but it's just a refactoring (at least that's my understanding). I was commenting more that the features of CMB would be a good fit for this ticket rather than the actual code. I'd assume it would be rewritten again for inclusion in WP core (like Menus).

dwenaus, yes I believe repeatable fields is at the top of our feature list and is definitely something we'd like to include, but at the moment we're working on bug fixes and refactoring the code.

[dwenaus]

i wonder if the rewrite should change direction towards a core inclusion rewrite? How does that decision get made?

[ericlewis]

In 18179.php, I've added a register_meta() method to WP_Meta_Box, which can be called for any meta field associated with the meta box, and will store it in an instance array variable for displaying, saving, and sanitization/auth callbacks. I've created an optional array of arguments, one of them which is "default_display," which defaults to true. This will output a standard form field for the meta entry, and can be easily overridden by setting this option to false, and implementing your own form field rendering. I devved out just a basic text field for now, as I'm not sure how we want to build custom HTML elements and how much control should be in the API. I was thinking an array parameter 'attrs' which would build the attributes for the form field element.

Replying to WraithKenny:

On the revision check of WP_CPT_Meta_Box: Sometimes authors intend revisions to receive metadata updates and restore metadata on post restore. It'd be nice to have a built in functionality for this in the API (or at least account for it).

Also, I think the class WP_Meta_Box should have a basic save() method, which would check autosave and privileges, which could easily be overridden by a subclass as WraithKenny describes.

[WraithKenny]

Potentially related to this is all of koopersmith's work on the theme customizer. If you're interested in this ticket, you should read the code for that, as I assume many of those conventions would be useful here.

Also, I definitely think UI should be handled. Once the base classes are worked out, generic and generally useful field types (like Color, Email, or whatever) can be extended that handle the typical markup style and behaviors. WordPress has valitation, sanitation, and conventions for markup, style, and behaivor. They wouldn't be required for plugin authors, but they should be available and probably used by WordPress for its own boxes (dogfood).

[ericlewis]

Related: #18909. Adding a post meta entry type such as date can easily be performed with the jQuery UI datepicker plugin, but would require jQuery UI CSS in core.

[ericlewis]

Custom sanitization callback support added, with a default for generic form field types. Basic text and wp_editor meta field types added to begin with. Authorization callbacks supported, with a default of automatic authorization (if the user already has edit_published_post cap). Form rendering has defaults that can be overridden in a subclass.

[ericlewis]

add missing check for nonce existence before validating.

[ericlewis]

Move meta field types into classes, which include their own rendering, sanitization, authorization, and script enqueueing methods.

[nacin]

#30058 was marked as a duplicate.

[ericlewis]

The ​Fields API project has been looking at a broader solution to this problem for the last two years. The scope of this problem is quite large, and the eventual implementation will be worked out in a feature plugin before introducing into core. For that reason, I'm going to close this ticket out, and leave it to the Fields API project team to open new issues when they're ready.