Gather list of plugins and themes who would implement Fields API if it were in core

[sc0ttkclark]

It'd be great to have a list on-hand of developers (and their GitHub usernames if possible) for themes and plugins so that we can know who to work with on spreading the use of the Fields API. It'd be great to have a large number of them to reference in our official proposal when it comes time for that.

• [ ] Add to readme

[brianlayman]

For certain, I would. I'm BrianLayman just about everywhere.

[JDGrimes]

I'd definitely use it. :smile:

[sc0ttkclark]

@brianlayman @JDGrimes for which plugins/themes (specifically looking for ones that are distributed, free or commercial)

[JDGrimes]

Mainly WordPoints. EDIT: But I'd use it anywhere else too.

[brianlayman]

I'd start by updating these public plugins: Spam Destroyer 27,662 downloads http:BL WordPress Plugin 9,803 downloads WP Multi Network 23,504 downloads Mobile Image Tool Tips 131 downloads Word Filter Plus 4,027 downloads SCuD - The ShortCode Disabler 406 downloads Spam Catharsis 702 downloads

The rest of the plugins and all my themes I make are per customer and that's where it would really help.

[tomharrigan]

Fieldmanager plugin would use it

[amirhelzer]

Types (and other Toolset plugins) will be interested too. We've recently had a wave of unexpected work due to WordPress 4.2.3 update, but now we're back to normal development and can join this initiative.

[jtsternberg]

Absolutely CMB2.

[sc0ttkclark]

That's a great list of high profile responses already! Thanks all, I'm still working on getting a few more on-board. I think most contention right now is whether or not the post editor and other screens will have implementations for Fields API once it initially would go into core. That makes sense to me, since many plugins don't just do custom fields for posts or users. They cover custom fields for many things.

Theoretically, you could still use the Fields API for anything you want, even if core doesn't utilize it for posts / comments / etc. But there would be no established standard for how each Screen / Section is used, since core would not have implemented them for those screens.

That's something to tackle down the road as we get past finishing up the main core of Fields API and move onto the User profile implementation. I'm going to look at getting some contributors on board who can start putting together additional 'mini-plugins' that could be tested to show how Fields API would implement the Post edit screen and any others developers would be willing to implement. Even if the UI isn't nailed down, the implementation itself would be a great start at getting some of those other things visible for core folks to at least start figuring out what the UI should look like.

[sbruner]

Piklist does things the WordPress way, so if this is going into core, Piklist would use it.

[sc0ttkclark]

I should also note that Pods will be using CMB2, which would in turn be extending the Fields API. So Pods would be using Fields API for it's fields, and the Fields API directly for it's own internal object types as well.

[mgibbs189]

Custom Field Suite too, as long as the performance trade-offs are negligable. No pressure ;)

[sc0ttkclark]

I've communicated with one of the most popular custom fields plugins' developer, he's initially on board but he said before he would make it official, it depends on the API itself and how easily it could handle and be extensible for his plugins' own functionality.

[aristath]

Kirki and a couple of themes I'm building could use it too... If it were in-core

[JustinSainton]

@sc0ttkclark I could see us using the Fields API directly (potentially CMB2, once it uses it) in WP eCommerce.

[mAAdhaTTah]

I would use this in WP-Gistpen. Currently using CMB2, which may be overkill for the size of that plugin's settings page.

[overclokk]

I would use in my theme ItalyStrap and my plugin ItalyStrap, for now I'm working with CMB2 in my Dev branch.