Best way to prep for this to be in core?

[jonathanstegall]

I'm curious if there are ways we who are building very large plugins, for example, or new themes, can prep for this if we need to incorporate custom fields from a data/retrieval perspective. Is there a plugin that will be most compatible (ie ACF) as a model we could use in the interim, or are we better off just using whatever works the best and retrofitting it later?

[sc0ttkclark]

Right now we're on a bit of a hold. I've been the primary person putting time into the project for the past two years and the lack of additional contributors has worn me down. I'm currently seeking additional help to continue the project (collaboration can really help move a project forward). Further, we still need core contributors to sign off on our structure and approach.

[cloudstoneme]

@sc0ttkclark I feel a little sad and guilty to hear you say that, I'm looking for Fields API for a long time, but did not do anything for it, I really want to do something, but it's a little complicated for me. You know, this is big feature, it's not really easy to familiar with it. Anyway, I will try to dig codebase deeply and hoping can do something for this API.

At the same time, I was thinking about that maybe it will be better to change the direction of this project to a "Third Party Plugin" instead of "Core Merge Proposal ". I know, it's already a plugin for now, what I mean is "A plugin ready to merge into core", not "A feature proposal for core only".

Sure, the final goal is merging it to core, and the project should always consider core compatibility, But if we start this feature as a standalone plugin, we can got some end-users for Testing/Improving/Suggesting..., and it's will also be easier to other developer whose would like to contribute.

[lukecav]

I would be happy help on this project, it still seems like the Fields API could help the new Editor project for content storage.

[citelao]

@sc0ttkclark @cloudstoneme Wordpress has the Beta plugins section—could this be a target? Especially since I feel like low-level API & developer-focused development is not a priority for most of the existing "make metaboxes" plugins.

I was about to start my own type system for personal use, but a team working towards inclusion is probably the better basis :)

[cloudstoneme]

@citelao What I expected is exactly a low-level API which can be used for any type of forms, from backend to frontend, including php-level rendering and js-level rendering. The Fields API is really close, I just think that it's might not good idea that any wp project stuck on "Core Proposal".

[citelao]

I just think that it's might not good idea that any wp project stuck on "Core Proposal".

I'm not sure I understand, but if you mean that it's not a good idea to leave a great project stuck at "core proprosal," I completely agree.

However, there is a non-third-party way of deploying "plugins/features", the Beta Plugin section, and I think that serves as a better target. Especially since @sc0ttkclark is an active WP dev, that direction makes the most sense to me 😁

Thoughts?

[sc0ttkclark]

I'm open to moving this into a plugin project kind of like how REST API operated, but there was some direction a while back saying we should not create a plugin and treat this like a library.

Any thoughts on how best to move forward @helen?

[citelao]

@sc0ttkclark I think I understand why this could be viewed as a library change, since it will/could eventually override almost every form in Wordpress core.

But, correct me if I'm wrong, I assume that this is part of the reason you've had such a maintenance headache with this project. You've had to keep copies of all the wp-admin/ pages, updating them manually with every change, and the plugin architecture is not conducive to diffs.

I understand why you developed the API like this: it's really important that this change is tested against real core pages to make sure it is feature-complete, but I don't think this will ever be deploy-ready if that's its target. The API seems pretty ready; from a plugin dev's standpoint I would start using this today. But the ever-moving target of overriding every major form seems unreachable.

I'm really excited about this core change; I found it referenced in a bunch of recent posts on the Wordpress dev blogs, so I think there's a lot of interest in it that we could ride to a deploy. It is something that will help me and tons of others immediately, and you've had long-term commitment from all of the major form-editing plugins (#21).

I think it might be worth considering multiple, smaller, targets. For example:

1. The API as a Beta Plugin (get the API into the big devs' hands)
2. The wp-admin/ (etc) overrides as an optional component (to ensure the API remains reasonable)

This would let people start piloting the API; when it reaches critical mass, the API could be merged into core, and then admin page rewrites could be done directly on core code.

No matter what, this API change basically means modifying every form in Wordpress core. The plugin target (with attached, optional wp-admin/ modifications) seems like a much smaller, more approachable target.

I am, of course, completely unfamiliar with the WP dev process, but I have been using WP for almost a 8 years and this is a new feature I feel cannot come soon enough. Accessible, standardized, extensible client- and admin-side forms and fields will let me build custom types so much easier.

Let me know where I can help.

[sc0ttkclark]

You hit the nail on the head with what's becoming very difficult to pour time into every WP release. I'm still waiting to hear what @helen thinks about us moving forward with a beta plugin approach.

[overclokk]

I'm for "beta plugin/composer package" approach, this way I can start using this awesome project without waiting WordPress merge approval, with using this fields in real project will be more simple to contribute to it, maybe.

[lukecav]

Most of the main form plugins has already taken extra dev time, to build their own API solutions. If the Fields API was in WP core, then the main form plugins could use that instead.
https://www.gravityhelp.com/documentation/article/gravity-forms-api/
https://formidableforms.com/knowledgebase/formidable-api/
http://docs.ninjaforms.com/customer/portal/topics/798123-developer-api/articles

[marsjaninzmarsa]

I think it might be worth considering multiple, smaller, targets. For example:

1. The API as a Beta Plugin (get the API into the big devs' hands)
2. The wp-admin/ (etc) overrides as an optional component (to ensure the API remains reasonable)

This would let people start piloting the API; when it reaches critical mass, the API could be merged into core, and then admin page rewrites could be done directly on core code.

Correct me if I'm wrong, but I think that this would be very similar approach to REST API integration - plugin with API and sample endpoints first, then core integration (only for infrastructure, without endpoints, but with support for theme/plugin authors), then endpoints and rewriting core functions for new API.

So +1.

[lukecav]

Push up a version on the WP Repo and try to get it added to say beta?

https://wordpress.org/plugins/browse/beta/

[citelao]

@lukecav I think @sc0ttkclark is just waiting for @helen for the go ahead?

[sc0ttkclark]

That's right, but I think it's safe to say if we hear nothing back this week we will move forward anyways.

[citelao]

@sc0ttkclark What's the game plan for such a transition? What needs to change?

[sc0ttkclark]

1. We integrate with existing WP hooks for adding fields/sections/etc to different places in core (where supported)

2. We attempt to get any new hooks we need to make this all work added to core, since many of the things we're doing require core file changes

3. We wrap the code up into a plugin meant to be a plugin (not as it currently stands which is meant to be a prototype of core functionality)

Stuff like that

[citelao]

@sc0ttkclark I'd like to help, and I have some time to do so.

What's the most helpful thing I could do? I was thinking maybe Composer compatibility.

[sc0ttkclark]

Sounds great, shoot a PR this way and I'll review

[citelao]

See #91

[lukecav]

Nice question during the state of the word keynote.

[sc0ttkclark]

I’m very happy with the answer, it’s validation for what we are trying to do. And of course Matt stipulated that it’s not a focus for 2018, but we are more than just the core leads and Matt. I think we have work to do this upcoming year, and I’m very very very excited after the conversations I had at WCUS about Fields API.

There is hope once more, there is significant interest by big WP companies to help bring it to fruition and keep contributors moving forward.