ClassicPress is a community-led project. This roadmap might be adjusted periodically to remain aligned with community needs and desires.
It’s extremely important to note that Version 1.x of ClassicPress will be fully backward compatible with WordPress 4.9.x. We won’t introduce any changes or features that would cause plugins or themes to break.
Based on information made available by WordPress to the general public, WordPress 4.9 will be maintained for the next few years. To meet the needs of WordPress 4.9 users, plugin and theme authors will need to maintain compatibility with this version. As long as these developers maintain compatibility with WordPress 4.9, we can confidently say that the vast majority of plugins and themes will continue to work with ClassicPress for years to come.
Version 1 Roadmap
Preamble: ClassicPress Version 1.x is a long-term support (LTS) version. If you choose to, you can stay on this version for years to come. We won’t introduce any changes that could break compatibility with themes or plugins that support WordPress 4.9.x.
ClassicPress has a “security first” approach. No matter how shiny or exciting a new feature is, if it’s not secure, it won’t be added to the platform.
We’re putting a lot of thought into security, but actions are more important than words. Some improvements we’ve already made include:
- All API communication must happen over SSL
- Signed releases on GitHub using GPG
- Support for PHP lower than 5.6 has been dropped
Improvements for Developers
We want ClassicPress to build on the foundations of WordPress and deliver a development experience that will be a joy to work with.
- We’ve introduced a modern industry standard versioning scheme.
- We’re constantly keeping all build dependencies up to date.
- You can install ClassicPress using
composer install classicpress/classicpress.
- And of course, we’re using
svnfor version control.
There is much more planned for future versions. Current discussions include custom fields and object relationships built into the core software. As a community member, you will help us set the direction of future version releases!
For Version 1, “bloat” refers to defaults added to WordPress that our community feels are undesirable or unnecessary. We have started by removing default plugins such as Hello Dolly and Akismet. We’ll continue reducing bloat in Version 2 by moving older or less-used features like XML-RPC out into core plugins that can be disabled or deleted if so desired.
Keeping our focus firmly on what best serves our business community, we have begun identifying and removing features and functionalities that provide no significant benefit or may even be a hindrance.
Many improvements have been planned and/or implemented, including the removal of dashboard widgets, promoted WordPress plugins, and various other WordPress promotions that add no value to the ClassicPress experience.
Removing “quirky” things that business users don’t need or appreciate is one of many ways our attention to detail sets us apart. We’ve already started: you won’t see “Howdy” in ClassicPress, and “Cheatin’ uh?” is next on the chopping block.
Research / Experiment Repository
The ClassicPress Research organization on GitHub allows community members to collaborate on projects that they believe will benefit the ClassicPress ecosystem, both in the short and long term. Most often, these projects stem from popular petitions and it is an effective way to discover whether the ideas proposed are actually feasible.
Plugins and projects added to this repository might be considered for official recommendation or included in ClassicPress core when they are finished, but it’s important to note that the projects are experimental and come with no guarantees.
Version 2 Roadmap
Preamble: Work on Version 2 began in early 2019, and we plan to launch in the second half of the year.
Version 2 may begin to introduce changes that may break compatibility with plugins and themes that only support WordPress 4.9.x. However, we expect incompatibilities to be limited to uncommon edge cases, and we will do our best to maintain compatibility. We will only make breaking changes when it is absolutely necessary, and we will communicate them clearly during the upgrade process, so users can make an informed decision on how best to proceed.
An upgrade from Version 1 to Version 2 will be by opt-in, so users won’t have to worry about being automatically updated to a version they aren’t yet ready to adopt.
We’ll launch an independent plugin directory for ClassicPress that will rethink and modernise plugin discovery, updates and promotion. An equal footing will be available for all plugin authors to reach the ClassicPress audience that might be interested in their solutions.
We already have commitments from major plugin developers to support ClassicPress v2.
The plugin directory will also be used as an avenue to introduce and test out new features in the future (see the list of projects under ClassicPress Research for some examples). See and participate in ongoing discussion about the ClassicPress Plugin Directory.
In service of our mission to create a CMS that is streamlined, fast, and secure, Version 2 will introduce the concept of core plugins. These plugins will move some “core” features into plugins that are enabled by default. Developers can then selectively disable and delete these plugins based on the needs of their clients. Some example core plugins could include:
- REST API
Increase the Minimum PHP Version to 7.x
WordPress has been burdened with the need to maintain compatibility with PHP versions below 7.x. This has led to lower quality, bloated code.
ClassicPress is taking a measured approach to introducing PHP 7, as follows:
- We will use a PHP version check to make sure the site being upgraded is compatible with the new version. If the version check doesn’t pass, then we’ll block the upgrade, similar to how the migration plugin works today.
- As we get closer to version 2 release, we’ll take a look at the distribution of PHP versions on ClassicPress 1.x sites.
- In a ClassicPress 1.x release, we’ll include a prompt to upgrade older PHP versions. This should help move the needle further and encourage more users to upgrade.
- We’ll use the results from the active installation numbers, as well as the PHP support timeline, to decide on a minimum PHP version for ClassicPress v2.x. It may be as high as PHP 7.2 or 7.3, but we need more information about active installations and support timelines before any decisions are made.
If this approach works well as we move from Version 1 to Version 2, it should be an approach that we can repeat with each major version of ClassicPress.
Do you want to shape the future of ClassicPress? Start a Petition