ClassicPress is a community-led project. As such, this roadmap might change based on the community needs and desires.
It’s extremely important to note that version 1.x of ClassicPress will be fully backwards compatible with WordPress 4.9.x. We won’t introduce any changes or features that would cause plugins or themes to break.
WordPress 4.9 itself will be maintained for the next few years and plugin / theme authors will need to remain compatible with this version. As such we can confidently say that the vast majority of plugins and themes will continue to work with ClassicPress for many years to come.
Preamble: The first version of ClassicPress will be 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:
We want ClassicPress to build on the foundations of WordPress and deliver a development experience that will be a joy to work with.
In version 1 we’re keeping full backwards compatibility with WordPress, so we’re starting with the basics:
composer install classicpress/classicpress.
svnfor version control.
We have a lot more planned for future versions. Some possibilities include custom fields and object relationships built into the core software. Stay tuned, and help us set the direction as a community member!
In this instance, bloat refers to defaults added to WordPress that our community feels are unnecessary. We have started by removing default plugins such as Hello Dolly and Akismet. In Version 2 we’ll continue this by moving older or less-used features like XML-RPC out into core plugins that can be disabled or deleted.
Keeping our focus firmly on what best serves our business community, we have begun identifying and removing those features and functionalities that provide little to no benefit or may even be a hindrance.
There are many improvements already implemented or planned, including removing dashboard widgets, promoted WordPress plugins, and various other WordPress promotions that add no value to the ClassicPress experience.
Removing those “quirky” things that business users don’t need or appreciate is one of many ways our attention to detail sets us apart from our predecessor. We’ve already started: you won’t see “Howdy” in ClassicPress, and “Cheatin’ uh?” is next on the chopping block.
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 into ClassicPress core when they are finished, but it’s important to note that the projects are experimental and come with no guarantees.
Preamble: Work will start in early 2019, with completion in the second half of the year.
Version 2 may start 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.
The upgrade from v1 to v2 will be opt-in, and we already have commitments from major plugin developers to support ClassicPress v2.
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.
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).
In our quest for creating a CMS that is streamlined, fast and secure we will introduce the concept of core plugins. These plugins will move “core” features into plugins that are turned on by default. Developers can then selectively disable and delete these plugins based on the needs of their customers. Some example core plugins could include:
WordPress has been burdened with the need to maintain compatibility with PHP versions below 7.x. This has led, through no fault of their own, to poor quality and bloated code.
We will take a measured approach to introducing PHP 7, as follows:
If this approach works well going from v1 to v2, it should be an approach that we can repeat with each major version of ClassicPress.
Do you want to shape the future of ClassicPress?
Ready to make the switch to ClassicPress?
Watch the video below to see how easy it is to switch to ClassicPress