ClassicPress Development Update

Curious about the current state of ClassicPress?

We released stable versions 1.0.0 and 1.0.1 in March, and they are still actively providing a production-quality alternative to WordPress for over 1,600 active sites. Since then, we’ve been planning for the next versions of ClassicPress, and we’re here for the long term to ensure the success of ClassicPress as an excellent option for business and professional-quality websites.

ClassicPress is produced by volunteers, and building and launching a new release is a time-intensive endeavor. Many of the key people involved (myself included) have been focusing on our existing businesses and clients since our initial release in March. We are passionate about ClassicPress and about keeping it free for all users, but none of us are currently in a position to dedicate 100% time to ClassicPress.

Short-term

Right now, the development team is working on ClassicPress 1.1.0.

The target date for this release is Wednesday, July 24, 2019. We’ll be updating our GitHub milestone regularly as we prepare for the release – feel free to check in there or in the #corechannel in Slack for updates.

The due date and exact feature list are subject to change as time and availability permit, but the current plan is for this release to contain some minor bugfixes and a couple of small new features:

Bugfixes

• Update the latest emoji code from WordPress.  This was necessary to continue ClassicPress development with working automated tests, and it also adds support for the new emoji in Twemoji v12.
• Remove an invalid CSS map reference from TinyMCE code.  This was causing a browser warning in Firefox and potentially other browsers when editing posts/pages.
• Fix an issue with editing post dates via XML-RPC.  This issue affects users of external editing software such as MarsEdit, more details on the author’s site.
• Improve file upload validation.  This change will permit uploads of several file types such as CSV where they may have been previously blocked, though no issues of this type have been reported against ClassicPress so far.
• Improve changelog display in site admin.  ClassicPress sites should show an accurate log of the changes from past versions of ClassicPress.
• Improve notices related to Twenty * child themes in non-English languages or when using large font sizes.
• Fix an edge case with the update process on outdated server software.  Server administrators can easily fix this  issue, so we’ll evaluate the impact of this change first and determine if it is worth it given the number of users (still) affected.

New feature: Site logo on login screen

More info on the petitions site.  This is a feature request that is a minor change, relatively straightforward and provides clear value to business and professional sites without the possibility of breaking sites or introducing unexpected behavior.

New feature: Security screen

More info on the petitions site.  We plan to add a new admin screen for security-related settings.  In the future this will be the place to opt-in to new ClassicPress core security settings, and also the standard place for ClassicPress plugins that have a few security-related settings (we expect larger plugins will want to keep their own screens which is fine too).  This will provide a clear place for both users and developers to find and manage basic security-related configuration.

Long-term

Beyond the upcoming release of ClassicPress 1.1.0, we’ve started planning for the ClassicPress plugin directory which will allow us to execute the version 2 roadmap of moving some less-used core features out into plugins. This is a large project that will coincide with the release of ClassicPress version 2.0.0, currently planned to be released by the end of 2019.

Current status is best reflected in the plugin directory subforum, in particular the specification thread.  We’ll post updates and major milestones here as they occur.

Note, we will not be hosting plugin files ourselves (like WordPress.org does), we will only be indexing plugins that people submit to the directory. This is why we use the term plugin directory instead of plugin repository.

Plugins will be hosted on GitHub and potentially other git providers like Gitlab, and ClassicPress will build a service to allow finding and installing plugins registered on our directory.

The architecture of the plugin directory will be roughly split into 3 components:

• A website that allows browsing the available plugins and submitting a new plugin.
• The client code that lives inside ClassicPress core. Most likely a separate tab in the plugins installation section.
• The backend APIs to support searching, installing, upgrading, etc. The architecture will likely be similar to our existing update API, using static JSON files that are regenerated as needed.

More details will be forthcoming as the implementation gets underway, and for now, good places to ask questions are in the plugin directory subforum or in the #plugins channel on Slack.

About James Nylen

I'm an American software developer with over 18 years of experience working with code. I like to keep software projects simple. They naturally tend to get complicated, but it helps to deeply understand and plan what we're working on.

View all posts by James Nylen | Website