Last updated September 1, 2017.
When I was learning to program, I was taught that 80% of the project can be implemented with 20% of the effort. To realize the additional 20% of the features would take 80% of the effort. This is one version of the 80-20 rule.
The Pareto principle, as it is called, has many different variations as applied to different disciplines and circumstances. According to the WordPress Philosophy, the 80-20 rule says that WordPress core should include features that 80% or more of the end-users would use:
The core of WordPress will always provide a solid array of basic features. It’s designed to be lean and fast and will always stay that way. We are constantly asked “when will X feature be built” or “why isn’t X plugin integrated into the core”. The rule of thumb is that the core should provide features that 80% or more of end users will actually appreciate and use. If the next version of WordPress comes with a feature that the majority of users immediately want to turn off, or think they’ll never use, then we’ve blown it. If we stick to the 80% principle then this should never happen.
We are able to do this because we have a very capable theme and plugin system and a fantastic developer community. Different people have different needs, and having the sheer number of quality WordPress plugins and themes allows users to customize their installations to their taste. That should allow all users to find the remaining 20% and make all WordPress features those they appreciate and use.
By extension, the other 20% of the functionality, that would vary by special needs, could be found by extending WordPress using plugins and themes.
There has been some good discussion about collecting WordPress usage data to help guide decisions about what features to add to WordPress. The idea here is, for instance, to provide factual data on usage. For instance, “We want to simplify the editor interface: should we remove the editor button for underlining?” If we had actual data then we would know, do 2%, 20%, 50%, 80% or what percentage use this feature. As it is, developers use their best guess and those who follow such discussions chime in, but no one really knows.
While it would be helpful and interesting to have opt-in data collection, there are some metrics available that seem to be ignored: install numbers for plugins in the WordPress directory!
Let’s look at a few cases that apply to almost 100% of sites:
Anyone who has a WordPress website knows about the importance of a good backup. Go to the WordPress plugin directory, type in the word “Backup” and you will see a list of plugins that provide backup options. There are millions of active installs, and this is just for the free version of those plugins. Many of the popular ones also have premium versions that would not be counted.
I think that WordPress gets a bad rap on security because most of the security fire drills are related to 3rd party plugins and themes. Keeping everything up to date goes a long way in keeping your site secure. But there are a number of “vectors of attack” that need some attention. Stopping brute force logins and enabling two-factor authentication are two important steps in securing a site. There are also a number of other steps you can take. Again, searching the plugin directory turns up millions of security related plugin installs.
Almost every public facing website needs a contact form. Again, searching the plugin directory turns up millions of installs.
Pretty much every WordPress site uses a theme. It is best practice to use a child theme. While there are some child theme generator plugins, there are not millions, but there are tens of thousands of forum discussions across the Internet telling people how to create a child theme.
Let’s look at some cases that are not 100% needed, but that represent large black holes in the platform:
The current WordPress editor is pretty basic and getting long in the tooth. There are millions of installs of WordPress page builders plugins or themes that include page builder functionality. This is being addressed with Project Gutenberg and I think that something along the lines of Gutenberg is long overdue.
Custom Post Types and Custom Fields
WordPress has support for custom post types but does not include a UI for creating them. The result is that there are many plugins that offer this functionality and again, there are many installs.
The Case for Following the 80-20 Rule
I’m sure if you looked further you would find more instances where common functionality is widely needed. Why should we stick with the 80-20 rule:
- New user onboarding: every new user has to go through the process of searching for a backup solution, a contact form, security the site, instructions on creating a child theme, and so on. If these were built into core then they could use their time learning how WordPress works instead of navigating a bewildering array of free and premium options.
- Implementing these widely used features in core could be done in a manner that provides good options for plugin authors to build on. This would provide standardization and a base level of functionality.
- Undertaking tasks like providing a modern editor with page builder functionality and a User Interface for custom fields and custom post types would likewise provide standardization and a solid basis for expansion.
But wait, this type of functionality is hard, the environments provided by differing hosting solutions vary, and users may have preferences that would be too cumbersome to accommodate! True, but somehow those plugin authors have found ways to overcome and accommodate those differences. In fact, I imagine, if asked, it would be possible to find some plugin authors who would donate their code to core as a starting point.
But, but wait, there are multi-million dollar business that would be destroyed if these features were added to core! True, though if these features were added intelligently, with lots of hooks and filters for customization and expansion, then there would still remain many opportunities to provide extra value. Also, if we don’t address these “black holes” in WordPress then we leave WordPress open to competitors who provide these features.