Features as Plugins

The Features as Plugins model was introduced in 3.7 as the way for features to be developed for inclusion in WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.. This model allows a feature to be built, tested, refined, and polished before it is considered as a merge candidate. Features as plugins in progress can be tracked on a dedicated page of the Make WordPress Core blog.

A community member or new contributor, such as yourself, can propose an idea for a new feature pluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins. during the Feature Plugin Chat, usually held around the time a new release cycle starts.

The chat is for putting forward an idea you have, and plan on taking an active and primary role in developing. Other contributors who are interested in your idea can join the effort. The date and time of the chat are announced in a post on the Make/Core blog, and ideas are added in the comments in the form of a short proposal:

  • A brief (one paragraph) overview of your feature plugin proposal.
  • Current pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party status (idea stage, planning stage, under development, existing feature plugin, prior work, etc).
  • A list of those involved or already interested in your feature plugin (including you).
  • What you would like help with (scoping, planning, wireframing, development, design, etc).

The feature plugin development period allows for experimentation and, depending on the complexity of the plugin, may take multiple release cycles to complete before being ready to present to the Core team as a merge candidate.

Without experimentation, some ideas might not otherwise be developed into potential features. But experimentation can also lead to a fully-scoped or even fully-developed feature that never makes it into core because, after hashing out the details, it’s realized the feature isn’t something that belongs in core.

Don’t let that discourage you – trial and error is part of the process, and will result in better features, and a better WordPress. Features that don’t get included in core can continue to live on as awesome plugins, and the whole ecosystem benefits. In the past, the Core team would have suggested that a feature start as a plugin anyway; this process is now formalized.

Ultimately, the decision on whether a feature makes it into core rests in the hands of the Core team. To ensure you’re on the right track, keep in contact with the lead developers and the upcoming release leadRelease Lead The community member ultimately responsible for the Release. to ensure they understand what problem you’re trying to solve, and why the direction you chose is the appropriate one to solve that problem.


For feature plugins to be included in a release, they must be proposed during the kickoff of a release and be ready to merge at the beginning of the merge window. At that point, the release lead will review current feature plugins, and along with core developers, determine if they’re fully baked and ready for merging into core.

The release lead will look for a number of things (see the checklist below), including a strong and well-tested user experience, fully-baked design, positive feedback from the community, core-quality code, no major bugs or issues, and a belief that the feature belongs in WordPress core. Every feature is different, so “ready” will mean different things depending on the specific feature. Ultimately, a release lead must feel comfortable taking on primary responsibility for a feature, and the Core team must be comfortable taking on responsibility for the long term.

If the core developers decide a feature isn’t ready for core, they’ll let the feature lead know why, and what can be done to prepare the feature for a future release.

Features that have been approved for inclusion will have a merge window of about two weeks to get their code into core and wrestle with any latent issues getting it merged. However, as stated above, features must be ready for merging at the start of the merge window.

Top ↑

Who is responsible for features?

After a feature gets merged into core, the feature team remains responsible for the feature, with added support from the Core team. As with any part of WordPress, feedback will come in from the entire community, more so after a feature is merged into core. The increased visibility requires the feature team to be more focused to ensure the feature ships.

Keep in mind that while the team remains responsible for the feature in core, ultimate decision-making rests in the hands of the Core team, as with any part of core. The release lead will work closely with the feature lead and entire team.

Top ↑

Feature Plugin Merge Criteria

Below is a list of some of the requirements a feature plugin team should meet when developing a plugin to be merged into core. Keep in mind each feature is different and requirements will vary.

  • A plugin exists in the official WordPress plugin repository, is updated regularly, and is used/tested by the community.
  • Weekly chats are taking place on 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/., and the feature lead is attending the weekly core dev chat.
  • A kickoff post and regular update posts are published publicly, tracking the progress and major decisions of the feature plugin.
  • The feature works in all of the browsers that WordPress officially supports.
  • Touch devices can use the entire feature with no hindrance, with visual records for major flows through all new interfaces on all devices posted on Make/Flow. Make sure it functions properly on mobile by asking the Flow team to review it.
  • Visual records comparing old flow with new flow are provided for any feature that changes or replaces existing interfaces.
  • The code conforms to the WordPress coding standards.
  • Similarly, the code is well-tested, and has unit tests.
  • The code is well-documented. (Be sure to ask the Inline Docs team to review it.)
  • The code follows the plugin security best practices, and has undergone a security audit.
  • The user interface/experience has been tested through user testing, and appropriate feedback was incorporated. (Be sure and ask the Design team to review it.)
  • The design is fully responsive, displaying properly on any mobile device, and using graphics that are ready for hi-dpi/retina displays.
  • HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. validates to the proper doctype.
  • The code has all of the proper hooksHooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same. in place for localization. (Be sure to ask the Polyglots team to review it.)
  • WordPress continues to function, and the feature is still usable, with JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. turned off.
  • The feature can be used with just a keyboard.
  • Any required 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) support has been added, including (but not limited to) off-screen text, ARIA, and JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors.-assisted. (Be sure to ask the Accessibility team to review it.)
  • A merge proposal has been published on the Make/Core blog once the plugin is ready.

Top ↑

Feature Plugin Merge Checklist

  • Make sure the feature plugin noops once the feature is merged. This means the plugin won’t break with a Fatal Error after code is merged from the plugin to core. (Use (class|function)_exists() for example.)
  • If code from another plugin is used, make sure there are no clashes with that plugin once the feature merges.


Last updated: