Have you ever thought WordPress could use a particular new feature or capability to make it better? As an open source CMS powered by community contributions, WordPress highly values user feedback and input for shaping future development priorities.
In my 15 years as a webmaster participating in the WordPress open source ecosystem, I‘ve seen firsthand how user-driven feature requests have gradually evolved WordPress from a simple blogging platform into the powerful content management system it is today.
If there is a feature you think would help millions of other WordPress users, there are pathways for proposing it directly to the core development team for consideration. In this comprehensive guide, I‘ll walk you through everything you need to know as a user to make effective feature suggestions, drawing on my insider experience.
Contents
The Growth and Evolution of WordPress Features
To understand how new features make their way into WordPress, let‘s look at a bit of history.
WordPress was originally created in 2003 as a simple open source blogging system. But over the years, contributors from the community helped shape it into a full content management system capable of powering everything from personal blogs to enterprise websites.
Some key stats on WordPress growth:
-
Now powers over 43% of all websites globally, up from just 8% in 2011.
-
Gets downloaded over 500 times per day.
-
Supports a plugin ecosystem with over 55,000 plugins.
This massive growth was fueled by the continual enhancement of features to serve user needs.
Unlike closed source systems controlled by a single company, the evolution of WordPress is driven by feedback and feature requests from its users. If enough people want a new capability added and contributors are interested in implementing it, it can make its way into core.
For example, a turning point was the introduction of custom post types in WordPress 3.0, paving the way for Custom Post Type UI and other plugins that made WordPress far more flexible for webmasters. This originated from many users requesting the capability to easily create custom post types beyond the default posts and pages. After gauging strong demand, core developers [Matt Mullenweg and Ryan Boren] added the major enhancement to WordPress core in response.
That user-responsive process continues today, as WordPress receives hundreds of feature requests annually. But how do they decide what makes the cut?
How New Features Are Evaluated for Inclusion in Core
For a feature request to be considered for WordPress core, it should meet certain criteria:
-
Broad user appeal – It needs to help a substantial portion of the WordPress user base. Niche requests better served by a plugin are typically not included.
-
Difficult to implement via plugin – There must be a compelling reason why it cannot be easily added through a plugin, which supports more niche capabilities.
-
Aligns with WordPress direction – It must fit with WordPress philosophies and its direction for the future.
-
Feasible to implement – There must be a reasonable path to add the new functionality from a technical perspective.
If a feature only appeals to a smaller subset of users, or could be easily offered through a plugin, the core team often declines such requests in favor of enhancements that benefit the majority of the WordPress community.
This measured approach allows WordPress core to remain clean and focused on broader functionalities used by most sites. Specific niche features can still be achieved by tapping into the 55,000+ plugins.
Contrast With Other Open Source CMS Projects
The open nature of WordPress development contrasts with other leading content management systems. For example:
-
Drupal tends to incorporate more bleeding edge features requested by early adopter developers, resulting in higher complexity and learning curve.
-
Joomla development is more insular, dominated by the core team rather than the community. This results in a more limited evolution of capabilities.
The WordPress balance of community-driven development with a careful gatekeeping process by core committers allows it to enhance major features gradually without veering outside its guiding philosophies.
Next let‘s look at the main methods you as a user can directly propose new features.
How to Submit Feature Requests to the WordPress Core Team
WordPress provides two primary channels for users to suggest ideas directly to developers:
1. WordPress Trac
Trac is the official site used by the core team for tracking feature requests, bug reports, and general project management. It has been used since 2005.
Here is a high level overview of how Trac works:
Let‘s walk through the step-by-step process of submitting a feature request on Trac:
Ensure Your Request Is Relevant
Trac is intended for proposing core features only. Don‘t use it for themes/plugins or support requests – instead use the WordPress forums.
Search for Similar Requests
Before submitting, please search thoroughly in case your suggestion was already proposed. This avoids duplicating existing tickets.
Create a New Trac Ticket
If you don‘t find a similar request, create a new ticket by selecting "New Ticket" and signing in with your WordPress.org account:
Enter Details on Feature Request
On the ticket submission form, provide:
- Clear summary of the feature
- Full description including use cases
- Select "Feature Request" as the type
- Choose relevant component, version, focus
Preview and Submit Your Ticket
Before submitting, carefully preview your ticket to ensure all details are accurate. Then click "Create Ticket".
Once submitted, your request will be visible to the WordPress community for consideration.
2. GitHub
In addition to Trac, you can also use the WordPress GitHub repositories to submit feature ideas by creating a new issue on the relevant repo.
Here is an overview of that workflow:
And here are more details on proposing a new feature with GitHub:
Sign Up for a Free GitHub Account
You‘ll need to create a GitHub account if you don‘t have one yet.
Find the Right GitHub Repository
Browse to the repo associated with the feature area you want to improve. For example, the block editor repo for Gutenberg suggestions.
Check for Similar Existing Issues
Search the "Issues" tab to ensure your suggestion hasn‘t already been proposed.
Open a New Feature Request Issue
If you don‘t see it already suggested, open a new feature request issue:
Submit Your Feature Request
Provide a title and description detailing your feature suggestion, then click "Submit new issue" to post it.
Once posted, your request will be publicly viewable for input from the community.
Now that you know how to submit feature ideas on Trac and GitHub, let‘s look at what happens after you post a request.
What Happens After Submitting a Feature Request?
The pathway for a feature request after you submit it can vary substantially depending on how it resonates with the WordPress community:
-
A core committer may label and categorize your ticket for proper triaging.
-
Other contributors may join the discussion with feedback on your proposal.
-
If there is interest in your suggestion, a developer may submit a patch to implement it.
-
Submitted patches go through a review process before they can be committed.
-
If/when accepted, your feature could get bundled into an upcoming WordPress release.
-
Requests perceived as invalid or not fitting WordPress direction may simply get closed.
So in other words – submitting a request is just the beginning! Your proposal may go through quite an evolution based on community feedback before potentially becoming part of core.
Some feature requests take days to implement, while more complex suggestions may take months or even years before getting implemented. For example, the idea of a "customizer" section for live site editing was first proposed in a Trac ticket in 2011, but development took years before it eventually landed in WordPress 4.0 after a sustained campaign led by core contributor Weston Ruter.
My point is: getting a new feature into core often requires persistence. But it‘s very rewarding to see your contribution positively impact millions of WordPress users when it finally does make it in!
Next let‘s go over some tips for crafting effective feature requests.
How to Create Valuable Feature Requests
Here are my top tips for maximizing your chances of success when proposing new functionality based on my many years participating in the WordPress open source community:
Clearly Articulate the User Needs
Rather than jumping into technical details, focus first on articulating the user needs and problems your feature aims to address. Speak directly to the challenges WordPress users face to make a compelling case.
Provide Specific Use Cases
Back up your explanation of the user need with concrete examples and use cases of how real users would benefit from your proposed enhancement. This helps demonstrate tangible value.
Suggest a Thoughtful Technical Solution
While not essential, proposing at least a high level vision for how your feature could be implemented technically often helps move the discussion forward productively.
Familiarize Yourself with WordPress Direction
Understanding WordPress philosophies and priorities will allow you to frame requests that are more likely to align with core goals and be accepted.
Mock Up Visual Depictions
Mockups, diagrams, flowcharts and screenshots are a great way to communicate your vision visually. This grabs attention and conveys your idea quickly.
Engage in the Discussion
Participate in the Trac or GitHub discussion thread to share further details, respond to questions, and help build momentum for your request.
Monitor and Follow Up on Progress
Periodically check back on the status of your proposal. If it stalls, consider rallying support from others in the community to revitalize interest from developers.
While not every feature request gets implemented, following these tips will give yours the greatest chance of success and potentially improving WordPress for millions of users.
So if you have a suggestion – start a discussion and propose it today! I highly recommend contributing ideas to help guide the future of WordPress we all use and love.
