FAQ: What will be new/different in ClassicPress V1?

What will be new, improved or different in ClassicPress v1 compared to WordPress v5? This list should represent where we want to be for v1, and not where we currently are with the alpha/beta versions.

Leave your comments below, and as new items are discussed, I’ll update this list:

  • No Gutenberg: Keep the editing experience you know and love [complete]

  • Improved security:

    • All API communications must happen over SSL [complete]
    • GPG used on GitHub to sign the tags that publish our releases. This is a first step towards full verification of the contents of a release build, and a more secure approach to updates [complete]
    • Support for PHP <= 5.5 dropped [complete]
  • Developer improvements / changes:

    • Full support of semantic versioning (https://semver.org/) [complete]
    • All build dependencies updated. This mostly makes it easier for developers working on ClassicPress itself, and also people doing custom builds. [complete]
    • Git used instead of Subversion for version control [complete]
    • ClassicPress release on packagist for use with composer (We’re shipping a composer.json file with 1.0.0-beta1 , but this feature may need some further refinement.)
    • Automated nightly builds [complete]
    • Automated dependancy updates [complete]
    • New constant LOAD_CONFIG_ONLY which will load wp-config.php without it loading wp-settings.php. Great for allowing external PHP apps (such as automated tools) to load the ClassicPress config (e.g. to get db credentials) without it trying to load all of Classicpress. It also paves the way for web hosts to decouple wp-config.php from their page load bootstrap process
  • Less bloat:

    • “Akismet” and “Hello Dolly” plugins removed from the default installation (which are usually the first plugins to be removed for a business website) [complete]
  • Interface improvements:

    • ClassicPress branding replaces WordPress branding [complete]
    • Removal of WordPress-specific plugin promotions [complete]
    • Removal of quirky language such as “Howdy [name]” which doesn’t portray a professional image [complete]
    • Removal of Dashboard widgets that are not useful for business users (e.g. upcoming WordPress events will be replaced with widgets that allow people to vote on features proposed by the community)

Better performance. Security. Cleaner code. Accessibility. Democracy.

1 Like

If possible, can we have specifics? Eg if you say better performance, how exactly was this achieved? I’d like this thread to be as detailed as possible

Option to load wp-config.php without it loading wp-settings.php — by define()ing LOAD_CONFIG_ONLY equals true — in which case wp-load.php will load wp-settings.php instead.


  • Allows external non-ClassicPress PHP apps to load ClassicPress config to get database credentials without it trying to load all of ClassicPress.
  • Will hopefully encourage managed web hosts to decouple wp-config.php from their page load bootstrap process.
1 Like

Needs more info about why: this will make it much easier to write automated tools that load and parse wp-config.php without jumping through so many hoops.

Here is the best starting point for what’s changed from WordPress: https://github.com/ClassicPress/ClassicPress-release/releases/tag/1.0.0-alpha1

We’ll put together a similar changelog for each release. In the meantime you can also look at the commit log here: https://github.com/ClassicPress/ClassicPress/compare/1.0.0-alpha1+dev...develop

1 Like

@james - Done.

1 Like

Signed updates

Starting with the 2018-11-16 nightly build and the 1.0.0-beta1 release, we are using git and gpg to sign the tags that publish our releases. As an end user this means you will see a Verified badge on GitHub:

In summary, if you trust GitHub, then you can verify that a build came from us.

More info: https://help.github.com/articles/about-commit-signature-verification/

This is a first step towards full verification of the contents of a release build.


All dependencies updated

All build dependencies updated. This mostly makes it easier for developers working on ClassicPress itself, and also people doing custom builds.

This is a big difference: updating to the latest jQuery (for example) would break untold numbers of sites.

This is not complete, and will not be making it into beta1.

ClassicPress has its own auto-updates. Release packages are served directly from GitHub tags. This functionality is shipping in 1.0.0-beta1.

1 Like

Interface improvements

Under this section, add “removal of WP-specific plugin promotions”.


Developer improvements / changes

Under this section, add "release ClassicPress on packagist for use with composer".

This helps automate installation and updating workflows, especially for sites where all changes are made on a development/staging server and then deployed to production, which is otherwise read-only. More info: https://docs.classicpress.net/installing-classicpress/installing-with-composer/

We’re shipping a composer.json file with 1.0.0-beta1, but this feature may need some further refinement.

Super - amendments made

1 Like

Just as an aside, you could also use the “upcoming WordPress events” space to inform CP users of meetups that use CP and cater to it (like mine) and of upcoming releases, and CP news. Only if that’s easy to do and doesn’t potentially damage any other function. If it would make CP lighter and faster in any measurable noticeable way to remove it altogether, I’d choose that route.

Also, I know in the HTACCESS file there is a way to remove the visibility of the wp-contents folder page that shows all a site’s folders. I’ve done this on all client sites. Would it be a good idea to add that line of code to HTACCESS in future CP installs? Or could it cause issues with over-writing WP with CP?

1 Like

That would be interesting, we would need an api in place to handle that though. Something like a news section for now might be good though, push good news stories about CP, upcoming releases, and anything of value (especially while we don’t have the events).


I’m presuming you’re referring to the Options -Indexes directive. I do this, also. Unfortunately, it’s not supported by all servers. AFAIK, it’s just for Apache and Lightspeed servers.

1 Like

This should be an option at least. Can you create a new issue at https://github.com/ClassicPress/ClassicPress/issues please?

Are there any potential negatives to that change? I’ve installed CP over several sites now that had that change made in them and the HTACCESS line of of code preventing access to the folders, and the change remains, so if someone were to not know and install CP over that, with that code in it, could there be any errors or issues? I just thought it might be a good idea - as I don’t know why WP thought it would okay for the public to be able to see a page of a website with hundreds of files clearly visible unprotected.

1 Like

I don’t know how to answer that, since all I know is that I found wp-contents on all my sites and client sites and then just got instructions on how to go into the HTACCESS file through my host Cpanel and add a line of code that would make that page inaccessbiel and show it as “forbidden.” that’s all I know about it. I was very surprised when I found that so many folders were clearly visible through one unprotected page so thought I should make the change so site folders are not so easily exposed.

So if current WP allows for that, and it’s not good, why not just add that line of code into CP so that vulnerability is not there any more - was my thinking…unless there is a reason why they never did that (which I don’t know). Maybe I’ll ask on the WP forum somewhere and see if anyone responds.