ClassicPress Roadmap

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.

Version 1 Roadmap

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.

Improved Security

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.

In version 1 we’re keeping full backwards compatibility with WordPress, so we’re starting with the basics:

  • We’ve introduced a full, well-thought-out versioning scheme based on a modern industry standard.
  • 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 git instead of svn for 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!

Less Bloat

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.

Interface improvements

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.

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 into 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 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.

Plugin Directory

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).

Core Plugins

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:

  • Gravatars
  • Emojis

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, through no fault of their own, to poor quality and bloated code.

We will take 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).
  • When 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 push more people 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 first.

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

Play Video

Have questions?