Scott Kingsley Clark 5:22 pm on January 9, 2023
Tags: , , ,   

Fields API Kick-off Chat Summary: January 5th, 2023

It’s been over 4 years since the Fields API project has been active and many things have changed for WordPress in that period.

Since then, many things were introduced into WordPress itself including things like:

  • BlockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. Editor
  • Full Site Editing has replaced the CustomizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings. (which is now only used for classic themes)
  • New Navigation editing
  • Widgets are now legacy and have been replaced with new blocks and a new WidgetWidget A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user. editor
  • Newer PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher compatibility (testing still in progress for PHP 8.0+) and talks of upping the minimum PHP version

All of that has led to @joedolson approaching me to determine if it’s worth bringing Fields APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. back with a new vision.

After some initial discussion, the passion reignited within me to get this going again and we ended up having our first kick-off meeting today to discuss where we’ve been, where we’re at, and where we want to go in 2023. This and future work will be organized through our SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel #core-fields

Read below for what we discussed and here’s a link to watch the video from our initial meeting.

Video recording

The kick-off discussion

Meeting notes

Introductions

  • @sc0ttkclark – Scott Kingsley Clark
    • Senior Software Engineer at Pagely / GoDaddy
    • Lead Developer of the Pods Framework
    • Previously Co-Lead of the Fields API project from 2013-2016 with @ericlewis and then Lead Developer from 2016-2017
  • @borkweb – Matthew Batchelder
    • Been working with WordPress since ~2004
    • Worked with The Events Calendar and now Director of Engineering at StellarWP overseeing their products and initiatives
  • @joedolson – Joe Dolson
    • Contributing to WordPress since about 2006
    • WP CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Committercommitter A developer with commit access. WordPress has five lead developers and four permanent core developers with commit access. Additionally, the project usually has a few guest or component committers - a developer receiving commit access, generally for a single release cycle (sometimes renewed) and/or for a specific component.
    • Working on the AccessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) team
    • Reached out to Scott about Fields API from the perspective of improving accessibility for the Settings page
  • @jason_the_adams – Jason Adams
    • Manager of Development at GiveWP
    • Matt and him want to get together about how to help create unified libraries for multiple projects across StellarWP and other companies
    • GiveWP has it’s own Field API that it’s been pushing forward as well
  • @peteringersoll – Peter Ingersoll
    • Worked with WP for about 10 years
    • Not a developer but a user/self-titled user advocate
    • Coming at this as a perspective as a user who is interested in how this will work

Overview of Fields API – where we started

  • Started work in November 2013 with @ericlewis as lead and @sc0ttkclark as co-lead
  • Started holding meetings back when Freenode IRCIRC Internet Relay Chat, a network where users can have conversations online. IRC channels are used widely by open source projects, and by WordPress. The primary WordPress channels are #wordpress and #wordpress-dev, on irc.freenode.net. was being used before Slack
  • Initial focus was around Post metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. fields and meta boxes in the Post Editor
  • Expanded over time to cover a generalized API to work with
    • Post meta boxes and their fields
    • Settings fields (replacing the Settings API)
    • User profile fields (edit profile, add new user)
    • Term fields (add term, edit term)
    • Comment fields (add comment on frontend, edit comment in dashboard)
    • Media fields (modal)
    • Customizer (allowing the Customizer to see Fields API configurations)
  • We built 3 different prototypes over time
  • Hundred of plugins in WP have their own Fields API and lots of devs have their own preference on code structure so there were lots of voices with different opinions for what the Fields API should look like
  • WP Core team (committers and contributors) were somewhat receptive but we couldn’t gain momentum
  • The block editor and other projects started up which reduced priority for getting Fields API into WP especially since it wasn’t just one small part of WP
  • @sc0ttkclark reached out for anyone else to take over the project as lead (while Scott supported) but couldn’t find anyone so the project became inactive

Rebooting Fields API – where we’re at

  • @joedolson approached @courane01 and @sc0ttkclark to see if we wanted to tackle Accessibility as a goal for a smaller reboot of the Fields API
  • The GitHub repository has been unarchived and is ready to start the next steps of getting things going again
  • Lots of test coverage for the API itself
  • A number of examples of how to work with the API
  • Implementations that were covered at the time (in WP 4.5)
  • Things that were in progress at the time (in WP 4.5)
  • @jason_the_adams gave a demo of the GiveWP Fields API
    • Uses a mid-level API to register the configurations
    • Implementations handle rendering those
    • The primary implementation is a Block Editor powered form editing experience
    • @borkweb and @sc0ttkclark provided positive feedback about the PHP side of things

Where we’re going

  • @sc0ttkclark What PHP version should we target?
    • PHP 5.6 is the current minimum and we’ll stick to that unless progress is made on upping the minimum WP version
    • If the minimum version is upped, we can revisit this and adjust our code to follow suit
  • @borkweb How we approach things in WP now is much different than back when the Fields API started
    • Is there merit in separation of data and output like what GiveWP is doing versus what the very coupled approach that the Fields API has right now
  • @joedolson Whether this can be potentially be used for the Block Editor may have a big impact on whether it has traction, though there are plenty places where it could be useful
  • @sc0ttkclark
    • Content areas like Posts and Terms, we’ll likely see more expansion of the Block Editor
    • There are a few places in WP that may not make sense to be in the block editor itself
      • Settings
      • User profile
      • Maybe others?
    • Those areas may eventually use ReactReact React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org/. components to render but won’t live in the “Block Editor” that we know of today
    • We could separate the Fields API focus into specific component implementations, not unlike what we had before but with the goal being that we are registering structure – whether or not that is the same exact input used for each screen (some screens will need their own form implementations for their inputs that may not be HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. renders)
    • If we wanted to implement Fields API for the Block Editor, it could help register Components for the Inspector Panel for Blocks, which is currently an area with high copy/paste
      • Fields API could register Inspector Panel sections and components
    • PHP has grown up and it may be better to use objects than straight PHP arrays especially since that can work with IDEs and help with autocomplete for a better developer experience
    • With the Fields API, I want to make possible the idea that you can interact with the configuration of a form and add/change fields by registering new fields or adjusting their configurations
    • Knowing what the structure of a page is (outside of just basic actions that people use now to render HTML) gives devs the ability to take those configurations and consume them through WP-CLIWP-CLI WP-CLI is the Command Line Interface for WordPress, used to do administrative and development tasks in a programmatic way. The project page is http://wp-cli.org/ https://make.wordpress.org/cli/, the REST APIREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/., and PHP for custom implementations like the WordPress iOSiOS The operating system used on iPhones and iPads. app and many other apps that need to represent the various edit screens
  • @borkweb So the Fields API project would morph into a data layer and one or more rendering implementations to consume that
  • @sc0ttkclark
    • We can focus on Settings page at first and go from there into the User profile, but leave everything else out until we gain traction and get something into Core
    • Don’t focus on legacy things like the Classic Editor or Customizer or the Widget forms
  • @joedolson Getting this built out and implemented is a challenge but I’m game
  • @sc0ttkclark We should figure out what we want to structure the Fields API off of, but use object oriented as much as possible and make the focus on better developer experience so we can help level up working with WP
    • We could look at the structure of GiveWP’s Fields API and other modern Fields APIs from other plugins/libraries
    • Avoid looking back at older/legacy plugins and libraries
    • Find a consensus on what makes sense that most people will be familiar with based on what’s popular/modern
    • The current Fields API is based on the Customizer API which has become antiquated already

Next steps

  • Meetings: Figure out the frequency of meetings and when our next meeting is
  • Viability: Get a gut-check from WP core dev team in the core meeting and through responses to this post on direction and our focus
  • Spec: Look at modern Fields APIs in modern plugins/libraries and figure out how we want that structure to look like through a new spec doc
  • Code: Start with a Settings API implementation collaborating with @joedolson and the Accessibility team to ensure that side is accessible
  • Testing: Ensure the API is well tested with unit tests
#feature-plugins, #fields-api, #options-meta, #summary