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]
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]
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)
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.
UPDATE:
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.
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.
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:
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?
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.
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.
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.
