Proposal: Retiring Older Default Themes – Make WordPress Core

Proposal: Retiring Older Default Themes – Make WordPress Core
Skip to content
Make WordPress Core
Welcome!
The WordPress
core
Core
Core is the set of software required to run WordPress. The Core Development Team builds WordPress.
development team builds WordPress! Follow this site for general updates, status reports, and the occasional code debate. There’s lots of ways to contribute:
Found a
bug
bug
A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority.
Create a ticket
in the bug tracker.
Want to contribute?
Get started quickly with tickets marked as
good first bugs
for new contributors or join a
bug scrub
. There’s more on the
reports page
, like
patches needing testing
, and on
feature projects page
Other questions?
Here is a detailed
handbook for contributors
, complete with tutorials.
Communication
Core uses
Slack
for real-time communication. Contributors live all over the world, so there are discussions happening at all hours of the day.
Core development meetings are every Wednesday at
15:00 UTC
in the
#core
channel on
Slack
. Anyone can join and participate or listen in!
Since 2010, WordPress has released a new default theme every year but one. Each default theme (though sometimes stylistically opinionated) is meant to provide a solid and flexible foundation that site owners can use to build out their new WordPress site.
Though only the
three most recent bundled themes are included in new WordPress installs
, all 13 of the default “Twenty” themes are currently actively maintained. The level of effort to support 13 themes is not insignificant, especially in the times of the rapidly evolving
block
Block
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. The burden of maintaining these themes has historically fallen on the
Core
Core
Core is the set of software required to run WordPress. The Core Development Team builds WordPress.
team to ensure they continue to receive any needed updates.
Because there are so many, it’s not uncommon for it to take several months before older default themes properly support newer features added in WordPress Core. Additionally, themes created prior to the existence of certain APIs are often unable to fully take advantage of these new features (global styles, block patterns, etc.).
Trimming the number of default themes actively supported will allow contributors to be more effective at providing the best possible experience in modern WordPress through the block editor for sites using newer default themes. It also helps clear the path for work on new block theme-focused experiments and initiatives (such as the
Community Themes Initiative
) attempting to refine the role that themes will have in the block editor era.
This post summarizes the current state of bundled themes in WordPress before proposing new support states for bundled themes, as well as two potential ways to decrease the total number of themes receiving regular updates.
Documentation and Data
Before proposing any changes to the bundled theme support policy, it’s important to fully document the current state of bundled themes, how they are maintained, and the bundled theme life cycle (which can roughly be divided into three stages).
Bundled Theme Life Cycle
Build Out
: Once per year, a new default theme is
announced
and
planned
in coordination with a major version of WordPress (typically the final one of the calendar year). A small team of contributors
build
each
theme
out
on
GitHub
GitHub
GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged by the repository owner.
over the course of 1-3 months before it’s merged into the WordPress Core
SVN
SVN
Subversion, the popular version control system (VCS) by the Apache project, used by WordPress to manage changes to its codebase.
code base for release and future maintenance.
Active Default Theme:
The theme is released with the next major version of WordPress where it receives its time in the spotlight being activated as the default for all new sites. The original theme authors typically continue to work on improving the theme and fixing bugs during this stage. Active default themes are usually the first bundled theme to receive support for new features added to Core. Every effort is made to ensure full support when the next version of WP is released within reason and where appropriate. The active default theme ideally shows the full
capability
capability
capability
is permission to perform one or more types of task. Checking if a user has a capability is performed by the
current_user_can
function. Each user of a WordPress site might have some permissions but not others, depending on their role. For example, users who have the Author role usually have permission to edit their own posts (the “edit_posts” capability), but not permission to edit other users’ posts (the “edit_others_posts” capability).
of what WordPress can do.
Note:
“active” default theme is currently not an officially recognized designation.
Maintenance
: The next default theme is built and merged into Core and activated for new sites. The previous theme continues to be maintained, but those involved with creating it often are not able to keep up with maintaining it long term, or are assigned to other projects and initiatives. Bundled Theme component maintainers and other
Core contributors
Core Contributors
Core contributors are those who have worked on a release of WordPress, by creating the functions or finding and patching bugs. These contributions are done through Trac.
become almost entirely responsible for maintaining the theme, in addition to all others that came before it.
Defining Maintenance
Maintenance means many things in different contexts. Here is an incomplete list of typical maintenance currently required by and performed on bundled themes in no particular order:
Ensuring compatibility with new versions of
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
Fixing reported bugs.
Adjustments to code utilizing pre-existing WordPress APIs and functions to prevent additional bugs.
Deprecations related to jQuery and other
JavaScript
JavaScript
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.
Library updates.
Utilizing new functions, APIs, or best practices as necessary.
Changes required to adhere to new and more modern web standards and requirements.
Adding support for new features in the block editor and throughout Core.
Updating npm dependencies and build scripts.
Security updates.
Curating changelog updates.
Bundling, testing, and pushing releases to the theme directory.
Along with these maintenance tasks, there are some factors that need to be considered and make
When themes are built, they target support for specific browsers and versions. This does not change over time and the support policy is “locked in” for the life of the theme. As an example, older bundled themes likely still contain code that specifically targets IE6-9. It’s usually not worth the effort and risk to remove this code because it’s impossible to anticipate the impact in the wild, especially for any child themes that have been created.
The minimum version of WordPress required for default theme when released is set to the version of WordPress it is initially released with and does not change. As an example, Twenty Ten still technically supports back to WordPress 3.0.
Shipping patterns in themes that support WordPress 5.0 and up is particularly complicated since valid block syntax changes over time (see
#53617
for an example).
Adding support for new features is not always straightforward and takes a substantial amount of time to test, especially for older themes (see
#56487
for an example).
Current Default Theme Usage
Another important factor to consider before making any changes to a support policy is overall usage. Here is a rough breakdown of the active install counts for the “Twenty” default themes (according to
WordPress.org
WordPress.org
The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization.
) as of April 26, 2023 (note: this does not include sites running child themes of any “Twenty” themes):
Twenty Ten:
90,000+ installs (~0.3%)
Twenty Eleven:
100,000+ installs (~0.4%)
Twenty Twelve:
90,000+ installs (~0.3%)
Twenty Thirteen:
50,000+ installs (~0.2%)
Twenty Fourteen:
100,000+ installs (~0.35%)
Twenty Fifteen:
100,000+ installs (~0.45%)
Twenty Sixteen:
100,000+ installs (~0.7%)
Twenty Seventeen:
700,000+ installs (~2.5%)
Twenty Nineteen:
200,000+ installs (~1%)
Twenty Twenty:
600,000+ installs (~2%)
Twenty Twenty-One:
800,000+ installs (~3%)
Twenty Twenty-Two:
800,000+ installs (~3%)
Twenty Twenty-Three:
1M+ installs (~3.5%)
Some interesting findings:
Twenty Thirteen is the least used default theme at roughly 50,000 installs (0.2%).
Twenty Fifteen and older are all active on less than 0.5% of all WordPress sites each. Cumulatively they account for slightly more than 2% of all sites.
Twenty Sixteen and older all have less than 1% of all installs.
Twenty Twenty-Three is currently the most used default theme active on 1M+ sites.
Twenty Twenty through Twenty Twenty-Three all have roughly 2% of all sites or more each, cumulatively accounting for nearly 12% of all sites.
Twenty Seventeen through Twenty Twenty-Three accounts for 15% of all sites.
Defining and clarifying the different default theme states
This proposal is also a good opportunity to refine and clarify what the different states of bundled themes are before deciding if any default themes should be retired. Currently, there is only “actively maintained”. In order to retire older themes, there needs to be a new retired state defined. It would also help to have an intermediary state (similar to long-term support or LTS) where some support and maintenance is performed, but not all.
Actively supported state
This state is for all themes included with new WordPress installs (three most recent). Ensuring the themes in this state are fully compatible with the latest version of WordPress when released is top priority. Themes in this state will receive:
All types of
bug
bug
A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority.
fixes.
All types of compatibility fixes (PHP, WP, etc.).
Support for all new features added to WordPress (when they are relevant).
Security updates.
Changes to utilize new functions or APIs.
Changes to adhere to best practices or modern web standards.
Maintained state
This state is for all themes that have not yet met the requirements for retirement but are no longer included with new WordPress installs. Themes in this state will receive:
All types of bug fixes.
All types of compatibility fixes (PHP, WP, etc.).
Security updates.
Retired theme state
These themes have met the requirements for retirement and are no longer actively maintained. Themes in this state will receive:
No new enhancements, features, or bug fixes.
Security updates.
In addition, the “Tested up to:” value will no longer be updated with each WordPress release. Any tickets currently open on
Trac
Trac
An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress.
for a theme being placed in the retired state will be scrubbed and closed.
Retiring older bundled themes
Regardless of which methodology is used to identify when themes should be retired, the following points should be considered:
Policies can always be altered as themes and WordPress continue to evolve
. What constitutes a theme currently evolving being re-explored. Any support policy set after discussion can always be revisited in the future with new context.
A review of the actively supported themes will be conducted annually.
After a new default theme is built and released, the list of default themes will be reviewed using the criteria chosen from this proposal. When a theme qualifies for retirement, a proposal will be made on the Making WordPress
blog
blog
(versus network, site)
. Barring any compelling evidence that the theme should continue to remain in maintenance state, the open tickets for it will be scrubbed and closed appropriately and the theme will be retired after the next major WordPress release.
Proposed Criteria for retiring bundled themes
The following criteria is proposed as the requirements to retire a bundled theme:
Themes must be supported for a minimum of 5 years.
Even if a bundled theme is not widely used, it must be actively supported for at least 5 years.
Themes must be active on fewer than 1% of all WordPress sites (as determined by WordPress.org data)
Themes that would be retired today with this criteria:
Twenty Ten
Twenty Eleven
Twenty Twelve
Twenty Thirteen
Twenty Fourteen
Twenty Fifteen
Twenty Sixteen
Themes that would be moved to maintained status
Twenty Seventeen
Twenty Nineteen
Twenty Twenty
Themes that are actively maintained (currently shipped with WordPress)
Twenty Twenty-One
Twenty Twenty-Two
Twenty Twenty-Three
This proposal uses a minimum percentage of active installs as the criteria for retiring default themes.
While percentages like 1% may seem low, it’s important to call out that when applied to WordPress installs, even 1% equates to a few hundred thousand sites. As more new WordPress sites are created and this number is greater, the policy can be revisited and altered if necessary (see above).
Pros
Brings the number of actively supported themes from 13 to 6.
Drops support for themes with an outdated aesthetic (less emphasis on visual elements, content visually “contained” within a boxed layout, etc.).
Results in both fully block-based themes (2) and some classic-style themes (4) being actively supported or maintained.
Establishes a clear criteria for an annual review going forward.
Reduces the maintenance burden for 3 themes by refining what it means to be maintained vs. actively maintained.
Cons
A non-zero number of WordPress sites currently use these themes (roughly 730,000).
Conclusion
This post presents a thoroughly refined recommendation as a result of feedback from several contributors listed below. However, it is only a proposal and is not concrete. Adjustments can be made to this proposal based on feedback from contributors in the comments below. If you have any thoughts, please do leave them below!
Unless there is a need to republish a modified version of this proposal for further feedback, after a consensus is reached and any needed approval from leadership to implement this proposal is received, the following action items would need to be addressed:
The Making WordPress Core handbook should be updated in the appropriate places to outline the annual process to review for retirement candidates.
Contributors should scrub all tickets for themes being retired and either close them out with a message why, or complete them before the theme retirement date.
A post on WordPress.org/news announcing the retirement of any themes being retired and clarifying what that means.
Any other action items identified while discussing this proposal.
Props
jeffpaul
flixos90
poena
annezazu
jorbin
chanthaboune
joemcgill
azaozz
for contributing to this post through providing feedback and proof reading.
bundled-theme
themes
Share this:
Share on Threads (Opens in new window)
Threads
Share on Mastodon (Opens in new window)
Mastodon
Share on Bluesky (Opens in new window)
Bluesky
Share on X (Opens in new window)
Share on Facebook (Opens in new window)
Share on LinkedIn (Opens in new window)
+make.wordpress.org/themes/
+make.wordpress.org/hosting/
+make.wordpress.org/support/
+make.wordpress.org/test/
Cross posting to teams that may have thoughts on this proposal.
Seems reasonable. I might prefer going back 8 years (4+4) and a o.5% threshold rather than (3+3) and a 1% threshold, but sounds like a sound policy and reasoning.
One thing I’d like to see cross referenced in this data is “actively maintained” sites. I imagine a good chunk of those sites running very old themes, are also still on servers running php 5.6 and that haven’t seen a plug-in (or theme) update in years. Or how many just have “hello world” and no other content.
I know I personally have a half dozen domains parked on sites with the default theme and bothering beyond default content either… but I will someday… or so,I’ve been saying for 10 years….
I might prefer going back 8 years (4+4) and a o.5% threshold rather than (3+3) and a 1% threshold, but sounds like a sound policy and reasoning.
Can you clarify where where the 3+3 and 4+4 comes from? If a theme is included with WordPress for 3 years (unless a default theme is skipped like Twenty Eighteen, though unlikely to happen again unless themes drastically change), it would always be 3+2 minimum in this proposal, or 3+5 with your suggestion.
If we apply your suggested methodology to the current data, the only difference would be Twenty Sixteen moving to maintenance state instead of being retired. It’s on the edge of 8 years being supported, but is sitting at just over 0.5% usage. Twenty Eighteen would have been included already with the proposed criteria had it been created and assuming that it was still over the 1% threshold.
I’ll admit that 5 years was an arbitrary number chosen. However, it seemed to line up well with the data as to when a theme generally drops below that threshold. For example, Twenty Nineteen is sitting right at the 1% threshold and is also at the year 5-6 mark. I think that it’s safe to call Twenty Seventeen an outlier to this since it was the active theme when WordPress 4.9 was released. Roughly 16% of the sites running this theme are unfortunately holding out from updating to the
block
Block
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 and using that version of WordPress.
One thing I’d like to see cross referenced in this data is “actively maintained” sites.
As far as I know,
WordPress.org
WordPress.org
The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization.
does not use any data to classify a site as actively maintained or not. The only requirement for a site to be included in data is that the site has pinged the .org APIs within the previous 2 months. The distribution of versions in use for a theme is also not available like it is for plugins (see the
top of a plugin’s advanced tab
).
For what it’s worth, I have seen the data comparing the distribution of sites running each theme (regardless of version) on each version of WordPress, though the data has not been updated since just before 6.1 was released. It is not directly related to this proposal, so I chose to leave it out. But I’ll include some findings here as it’s somewhat related to your question.
I was actually quite surprised at the data. I was personally expecting sites running older default themes to also be stuck on older versions of WordPress. In reality, that was not the case. For every theme:
at least 25% of sites were running the latest version of WordPress (6.0 at the time)
at least 37% were running a WordPress version less than a year old (5.8-6.0)
older versions were significantly less (single percentage points each).
at least 58% of sites were running a version of WordPress with the block editor (5.0-6.0)
The number of sites running the latest version of WordPress also jumped substantially for Twenty Twenty-One and newer with 75%+ running the latest version of WordPress due to auto-updates for major versions being enabled by default for new sites.
While we cannot conclude that these sites are “actively maintained” even though they are running the latest versions of WordPress, I personally found it interesting that my hunch of
sites running older themes = sites running older versions of WordPress
was incorrect. More and more hosting companies are force updating
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
versions and turning on auto-updates for plugins and themes by default (and
Core through the changes in 5.6
), so I think that it’s fair to think “zombie” sites not maintaining underlying technology are declining. Though that’s also an assumption of mine not based on data but just what I’ve been seeing, so that could also be proven incorrect. 🙈
TY for this info Jonathan, some of it is really surprising to me too.
Aligned with my comment below, I think it’s more about
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
version compatibility and continuing to “function as-is”, rather than being on the latest major WP version with all the new features.
In that context, 3+3 years just seems to short. For example I use twentyseventeen with a
child theme
Child theme
A Child Theme is a customized theme based upon a Parent Theme. It’s considered best practice to create a child theme if you want to modify the CSS of your theme.
on a personal site idycabin_com, and I wouldn’t want it to stop working next year. The server it is on (private) is running PHP 8.2.
I wasn’t 100% clear before on “actively maintained” vs “maintained”. Re-reading that, I would say 3+5 seems more reasonable to me. With the sincere hope that it’d really be more like 3+7 for 10 years of PHP compatibility. And again, would be totally fine being stuck on an older version of WP. I recall there has been talk about WP dropping 5.6 support, and wish I could find it to think about aligning theme retirement with the WP version that is current on the day the theme is retired.
Anyway, as someone that often advocates for WP dropping support for older versions of PHP, 3+3 on themes just seems too short if it’s about “no longer functioning” with current php/wp.
While it’s important to consider the maintenance status of websites, the specific data you mentioned regarding actively maintained sites, outdated themes,
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
versions, and
plugin
Plugin
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
or can be cost-based plugin from a third-party.
/theme updates is not something I have access to. However, it is true that some websites may be running outdated software versions and may not receive regular updates, potentially making them more vulnerable to security risks.
If you have concerns about the maintenance status of your own websites or want to assess the status of specific websites, it’s recommended to review the version of the software being used (e.g., WordPress, plugins, themes) and ensure they are kept up to date. Regularly updating software and implementing security measures can help mitigate potential risks.
Remember to always have a reliable backup system in place for your websites and consider seeking professional assistance if needed.
Regards;
David
This comment was deleted.
I look after two sites using the 2013 template (plus a few others using later default templates). In both cases 2013 was chosen as the most suitable for a web site (as opposed to a
blog
blog
(versus network, site)
) with a members’ area available via user id and password. The sites are very active and provide a backbone for the two volunteer-run organisations involved. All plugins are up to date. Both are running
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
6.1.1 (I’m waiting for 6.2.1 before our next upgrade). Both are running PHP 8.1 (having been forced off PHP 7 by an IONOS policy).
Moving to a later theme would cause us a lot of work and disruption. We are resistant to moving to a blocks theme at present for a number of reasons. The main one is that both sites are run day-to-day by well over a dozen people in each case. Virtually all are over retirement age. We got to that point by creating web forms to replace the WP editor. Those forms match the overall style of the site (to make them less intimidating), use the minimum of controls (we use various techniques to hide/reveal controls as necessary) and include guidance built into the forms. For free text we use the wp_editor() routine which – as I understand it – has no blocks equivalent. If we were forced to return to using the WP editor, we’d be back to one or two people making all the changes which would be a huge shame.
I just wanted to make the point that dropping themes like 2013 might ‘only’ effect a small percentage of sites but it would have a massive impact on some of them.
It doesn’t mean that the theme will not be available for your website.
It means the theme will not be updated to work better with new
block
Block
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.
features, which you are not using. In your scenario, I wonder if making that type of block related updates wouldn’t be *more* disruptive.
To add to this, the
changes included in updates to Twenty Thirteen over the last 2-3 years
are all relatively minor. And while they are not irrelevant and unnecessary, I wouldn’t classify any of them as important or absolutely necessary. They’re mostly small nit changes or refinements.
These small tweaks would just stop going forward.
I doubt people running ancient themes care about blocks or any other new features. However, I do suspect some folks are like Andy and do care a lot about continuing to function as-is on newer versions of
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
I similarly doubt they care about being on the latest major version of WordPress, 6.1.x, and would be perfectly happy on a still-supported older version like 4.9.22 or whatever.
I similarly doubt they care about being on the latest major version of WordPress, 6.1.x, and would be perfectly happy on a still-supported older version like 4.9.22 or whatever.
Appreciate I represent just 2 sites but, in both cases, support for recent
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
versions is important to us:
We are currently forced by IONOS policy onto PHPv8 (it doubles our monthly cost to stay on v7)
We use third party plugins that require later versions
The
minimum
required
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
versions of these old themes can not be changed because it would cause problems for those users who are still using the old PHP versions.
I just wanted to note that I deleted comment that this one is threaded under because it was the exact same comment as the other one by the same user. But I inadvertently deleted the wrong one.
I recommend an edit for the Retired theme state: allow a
limited
selection of
bug
bug
A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority.
fixes. A few fixes should be worth making in addition to security patches. Last release even had an important
enhancement
enhancement
Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature.
ticket
ticket
Created for both bug reports and feature development on the bug tracker.
, though any future enhancements could require approval of release leads (as a ‘task’).
One way to limit bug fixes is to close any old-theme tickets without an owner and still open after the WordPress 6.3 release (or release candidates). Tickets could be marked with the ‘close’ suggestion before then, too, which could prompt somebody to claim one.
sabernhardt
Could you share the examples of the
enhancement
enhancement
Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature.
tickets you’re referencing just to make sure it’s obvious what you’re suggesting be considered?
I originally had “very limited severe bugs” in the list for retired, but ended up removing it based on feedback. There has really only been very minor changes to the older themes the last few release cycles.
If we allow some bugs, where do we draw the line? And it ultimately limits the effectiveness of this proposal. I think that it may be fair to say “any changes required to prevent the theme from encountering a fatal error.” But even that introduces a gray area.
Enhancements:
1. Last release, the
Google Fonts were removed
to avoid getting some theme users in legal trouble.
2. I just reclassified the skip link focus fix
ticket
ticket
Created for both bug reports and feature development on the bug tracker.
#54421
) as a
bug
bug
A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority.
because the script can cause problems in some of the themes. And hopefully that will be completed for the upcoming release.
3. I like a few other enhancements, such as removing legacy IE support (
#56699
) or maybe splitting the Inter font from the stylesheet in Twenty Twenty (
#48630
), though I would not mind if either of those would be closed without any change.
Bugs:
With a quick glance at summaries in the list of
bugs for themes older than Twenty Seventeen
, I did not notice any obvious bugs that would require an exception. One situation other than fatal errors, or even warnings, would be when the
block
Block
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’s front-end output changes without considering all of these themes
before
merging the pull request. If a
core
Core
Core is the set of software required to run WordPress. The Core Development Team builds WordPress.
change causes a problem,
core contributors
Core Contributors
Core contributors are those who have worked on a release of WordPress, by creating the functions or finding and patching bugs. These contributions are done through Trac.
should be responsible for fixing it. Then other theme authors would have an example to follow (or modify as needed).
Right, for some kind of changes, old bundled themes may have to receive an update (good example: the legal issues with Google Fonts).
But this can be done outside of
core
Core
Core is the set of software required to run WordPress. The Core Development Team builds WordPress.
. If old default themes are unbundled, we can still update them directly from the repository.
The change proposal would probably be reported on
Meta
Meta
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.
Trac
Trac
An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress.
and be triaged so only very important changes are handled 🙂
To be clear, this post is not recommending or advocating for any changes to how the themes are currently managed. They will remain canonically managed on
SVN
SVN
Subversion, the popular version control system (VCS) by the Apache project, used by WordPress to manage changes to its codebase.
through
Trac
Trac
An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress.
One situation other than fatal errors, or even warnings, would be when the
block
Block
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’s front-end output changes without considering all of these themes before merging the pull request. If a
core
Core
Core is the set of software required to run WordPress. The Core Development Team builds WordPress.
change causes a problem,
core contributors
Core Contributors
Core contributors are those who have worked on a release of WordPress, by creating the functions or finding and patching bugs. These contributions are done through Trac.
should be responsible for fixing it. Then other theme authors would have an example to follow (or modify as needed).
While I think this is reasonable, can we not push to resolve issues like this in Core itself rather than requiring theme authors to take action, only to have sites maybe never update to the patched version?
Yes, resolving a problem like those within
Core
Core
Core is the set of software required to run WordPress. The Core Development Team builds WordPress.
would be better, if possible 🙂
My two cents: This is a good thing.
If I’m using a theme that’s very old then security updates only (no new enhancements, features, etc) seems like a good thing. When I push that update button button, I have no idea what it’s really going to do. I can read the
patch
patch
A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a
diff
. A patch can be
applied
to a codebase for testing.
notes, but that doesn’t tell me what will definitely happen on my website. Best case scenario for me, when I click that update button, it does seemingly nothing. Worst case scenario, it does anything else. Having new features and rapid changes is great if I’m using a new theme, and trying to adopt cutting edge
block
Block
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.
capabilities
capability
capability
is permission to perform one or more types of task. Checking if a user has a capability is performed by the
current_user_can
function. Each user of a WordPress site might have some permissions but not others, depending on their role. For example, users who have the Author role usually have permission to edit their own posts (the “edit_posts” capability), but not permission to edit other users’ posts (the “edit_others_posts” capability).
. But if my theme is very old, then the principle of least astonishment applies.
The question also is, how many websites actually USE the theme and not have it installed as a fallback theme when their main theme fails?
All of the statistics listed in this post are sites where the theme is installed and activated as the current theme.
I like the proposal.
Would be great to have this kind of status also for all themes inside the WP.org repo. There are themes like Yoko that are practically retired but still serve on some websites. Would like to see a way for all themes authors to set the status on there themes to communicate the expected behavior.
For the statistics I would also include the data for all the sites where the default theme is the parent theme. Maybe as an extra column.
I use child themes in all my projects as default to prevent trouble down range. Many times there are just tiny changes inside the functions.php. This sites are still depended on the parent theme and should be included in the Consideration.
Good point!
I think this is a great proposal to reduce the number of default themes that are actively supported.
Happy to offer my support where needed.
Totally agree except with Twenty Ten, because it could be maintained as a proof that WordPress works fine with oldest theme available
That would be the classic theme, which still works!
Thanks a lot to all those who put this proposal together! The idea behind the proposal makes total sense to me, though I have a few thoughts:
I’m concerned that the stats don’t include sites using child themes. This might have quite an impact on the number of potentially “affected” sites. Do we have any
capability
capability
capability
is permission to perform one or more types of task. Checking if a user has a capability is performed by the
current_user_can
function. Each user of a WordPress site might have some permissions but not others, depending on their role. For example, users who have the Author role usually have permission to edit their own posts (the “edit_posts” capability), but not permission to edit other users’ posts (the “edit_others_posts” capability).
to get active installs of themes with the “Template”
header
Header
The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes.
set to a “Twenty” theme? Failing that, what if we added the active installs of themes hosted on the Theme Directory whose “Template” header is set to each “Twenty” theme, at least to give a slightly improved sense of usage? My main concern there surrounds
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
compatibility updates for those we might leave behind, given that the PHP version is very much outside the user’s control, and fixes may be outside their skillset/budget.
In terms of security updates,
Core
Core
Core is the set of software required to run WordPress. The Core Development Team builds WordPress.
currently provides these going back to WordPress 4.1. This is currently sitting at 0.2% usage, and introduced the Twenty Fifteen theme. I wonder if we might consider providing security updates only as far back as “the latest theme at the time of the release of the oldest WordPress version receiving security updates”. That way, we’d have consistent security support between Core and Themes, and it would let us have “bundled”, “maintained”, “secured”, and (truly) “retired” states.
Thanks again to
desrosj
and everyone who put this together!
Do we have any
capability
capability
capability
is permission to perform one or more types of task. Checking if a user has a capability is performed by the
current_user_can
function. Each user of a WordPress site might have some permissions but not others, depending on their role. For example, users who have the Author role usually have permission to edit their own posts (the “edit_posts” capability), but not permission to edit other users’ posts (the “edit_others_posts” capability).
to get active installs of themes with the “Template”
header
Header
The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes.
set to a “Twenty” theme?
I don’t think that we have the ability to calculate this. I’ll double check though.
I wonder if we might consider providing security updates only as far back as “the latest theme at the time of the release of the oldest WordPress version receiving security updates”.
I don’t hate this as an alternative approach.
This seems like one of those complex, “no perfect options” kind of discussions. I got a gut check from Matt and he also has raised a few of the types of concerns y’all have here.
desrosj
– What are the chances we can have a high bandwidth discussion on this at the community summit?
I think that would be a perfect forum for discussing options further! Happy to submit that.
I recently switched back to a 2013-based theme and really liking it, though it needs to be modernized for blocks. I think a theme (or all of them!) fully supporting post formats is interesting as people are looking for alternatives to Twitter, or there’s a demand for something where you can post title-free entries to your
blog
blog
(versus network, site)
and it cross-posts to Threads, Tumblr, Twitter, etc, as we’re in an age of further social balkanization. If maintenance is a burden, we should think about other approaches than shutting down including recruiting more help, or making changes to the code base to make them easier to maintain, more future-compatible or automated.
The intention with the introduction of yearly default themes, the promise we were making, was that they would be maintained forever, just like
core
Core
Core is the set of software required to run WordPress. The Core Development Team builds WordPress.
Something else to keep in mind is better auto-update of themes (and plugins), opted-in by default.
I just realized that I never responded directly to this, but there were some follow up tasks that were taken away from this proposal and this specific comment. I just wanted to circle back and make the connections for anyone who was curious where this landed, or where it ended up.
To explore some alternatives to dropping support for these less used themes, I submitted a
discussion topic that was accepted for the Community Summit
in August.
After reflecting on that
great session
and discussing with others, I’ve followed up with a n
ew proposal to assemble a group of contributors
who are interested in working through the
ticket
ticket
Created for both bug reports and feature development on the bug tracker.
backlog for default themes while auditing the state of
block
Block
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 support within each one. Before we can evaluate new workflows, tools, or frameworks for default themes, we first need to clean up our own house.
These older themes have also been used so extensively over the last decade that it’s likely most of the bugs with existing functionality have already been discovered. If we can close out all of the existing
bug
bug
A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority.
tickets, it’s reasonable to assume that any new will most likely be related to properly supporting new features in WordPress, new
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
versions, etc. This should cut down on some of the perceived burden to maintain these themes and set the stage for more discussions around future-proofing them.
Comments are closed.
Site resources
Email Updates
Enter your email address to subscribe to this blog and receive notifications of new posts by email.
Join 6,695 other subscribers
Recent Updates
Recent Comments
No Replies
Current Release
The current release in progress is
WordPress 7.0
. Planned future releases are listed on
the Project Roadmap
. Feature projects not tied to specific releases can be found on
the Features page.
Regular Chats
Note:
All chats happen on
Slack
Weekly Developer Meetings
: [time relative]Wednesday 15:00 UTC[/time] in
#core
About the Dev Chat
Agendas
Summaries
Performance Weekly Chat
[time relative]Tuesday 15:00 UTC[/time] in
#core-performance
New Contributors Chat
The 2nd and 4th Wednesday of every month at 17:00 UTC in
#core
See all meetings →
Recent Posts and Comments
Team Pledges
2664 people
have pledged time to contribute to Core Team efforts! When looking for help on a project or program, try starting by reaching out to them!
compose new post
reply
edit
go to top
go to the next post or comment
go to the previous post or comment
toggle comment visibility
esc
cancel edit post or comment