Category: Core Development

Introducing ClassicPress 1.1.0

We are excited to announce the release of ClassicPress 1.1.0, available now. This update comes with the addition of a new top-level Security page to the admin screen. The new Security page is a centralized place for plugins to register their security-related settings, making it easier for users to find and audit all security settings on the site (documentation).

Along with the addition of the new top-level Security page, version 1.1.0 also includes some minor changes and fixes.

For a full list of the changes in this release, along with update and installation instructions, see our 1.1.0 release notes post on the forums.

In this release we had also hoped to include an option to show the site’s custom logo on the login page instead of the ClassicPress logo (petition). After we released a preview of this feature to the community, some issues with our current implementation became apparent (discussion), so we’ll be backing this feature out and revisiting it for a potential future version of ClassicPress.

As always, we’ll be around if you need any help, just make a new thread on our support forum.

Development Update: September 2019

Since our August development update, work has continued on the upcoming ClassicPress version 1.1.0 – see the previous post for more details. At our last Core development meeting this past Thursday, discussion was centered around the tasks left to do. Based on our progress so far, we set an updated release date of Thursday, September 19, 2019 for version 1.1.0.

As always, we welcome developers who would like to contribute to ClassicPress. If you’d like to help, please see our contribution guidelines for the ClassicPress core code and then head over to the project milestone on GitHub.

If you want to follow along, join us in Slack in the #core channel. The channel is always open to ask questions about the status of any tasks, and we also have scheduled meetings roughly every two weeks.

We’ll see you there!

Update your site to ClassicPress 1.0.2 now!

ClassicPress 1.0.2 is a security release to match the security changes in WordPress versions 5.2.3 and 4.9.11. It is available now.

This is best thought of as a “defense in depth” update. The vulnerabilities fixed here are not enough to let attackers into your site by themselves, but it is still a good idea to make sure your sites are updated as soon as possible since issues like these are often exploited together with other vulnerabilities in plugins or themes.

For a full list of the changes in this release, along with update and installation instructions, see our 1.0.2 release notes post on the forums.

As always, we’ll be around if you need any help, just make a new thread on our support forum.

Development Update: August 2019

As we near our first birthday as an organization, ClassicPress is finalizing work on version 1.1.0 to make sure it represents the stability and quality that our users love. Read on for more details.

Updated timeline

Since the original announcement of version 1.1.0, we have faced some growing pains within our community and our team leads are working in a number of areas, one of which is improved and more frequent communication. Our original target date for version 1.1.0 was at the end of July. The changes planned to be included were not yet ready for production, so the date was postponed.

Missing our original release date is not ideal, but we think quality and stability are the most important things for any new release. Our new anticipated release date is mid-September and we’ll keep you informed as more progress is made.

If you have questions about our development process or would like to contribute, the best place to do so is in our development meetings in Slack (more information).

Headline changes

Along with some other minor bugfixes and changes, there are two main changes planned for the 1.1.0 release.

An option to use the website’s custom logo on the login page (petition, GitHub). We’re adding an option to use the site logo (usually defined in the Customizer) on the login page. This option will be disabled by default for compatibility with any existing login page customizations, but this should provide an easy way to begin branding your site without requiring any plugins.

A new top-level Security page in the admin dashboard (petition, GitHub). We want to deliver a CMS that makes security a priority. As part of that mission, we are adding a “Security” page to the ClassicPress admin interface. As ClassicPress continues to evolve, the Security page will become the hub for all security features for ClassicPress core and 3rd party plugins that choose to support it.

  • For ClassicPress users, having all core and plugin security settings in one place will reduce confusion (which plugin had that setting I need to change?) and help the user to understand at a glance the measures taken to keep their site secure.
  • For ClassicPress developers, the Security page provides a space to show plugin security features and demonstrate a shared focus on security for the end user.

We are excited to roll out these new features to help businesses more easily brand their sites and help plugin developers continue to make ClassicPress even more secure for the community.

Other minor changes

We also have a few other minor bugfixes and enhancements that are already finished and set to be included in the 1.1.0 release.

XML-RPC API bugfix: Previously, when writing a blog post using the XML-RPC API, if you saved the post as a draft, then came back and published it at a later date, the post published with the original draft date, rather than the publish date. We have changed this behavior and now blog post dates correspond to the actual publish date. Our thanks to Daniel Jalkut, who wrote about this issue and wrote the patches for WordPress that we accepted in this release, and to Laurence Bahiirwa for proposing the patch for ClassicPress. Note that this issue does not apply to normal edits from within the ClassicPress dashboard, only when using the XML-RPC API, which is usually seen when writing posts with external editors.

In progress

We have a few other changes in the works and welcome community contribution to the following open items:

How you can help

As the CMS landscape evolves and changes, our commitment to the success of ClassicPress is stronger than ever.

We’ve also added a set of contribution guidelines for contributing to ClassicPress core code – thanks to Laurence Bahiirwa and Daniele Scasciafratte for getting this document started, and please have a look if you’d like to help ClassicPress succeed with us but aren’t sure where to start.

These guidelines are a work in progress rather than a finalized document, and comments/suggestions are welcome. We hope this will help clarify how to contribute to ClassicPress core and how we make decisions about what gets included in ClassicPress.

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

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.

ClassicPress 1.0.0-rc2 is live!

Today we’re excited to announce the release of ClassicPress 1.0.0-rc2, available immediately.

Here is a list of the minor changes in this release, as compared to our last one, 1.0.0-rc1:

  • Remove files that were accidentally included in rc1
  • Avoid duplicated rewrite rules (WordPress and ClassicPress) in .htaccess after migration
  • Remove WP-only themes features, continuing from changes in rc1 (details)
  • Add some explanatory messages for the default themes, since both parent and child themes are included (details)
  • Use a consistent header for all About tabs in the dashboard (details)
  • Fix a PHP notice in the dashboard petitions widget (details)

Next steps

Testing is critical during the RC phase — if we have any new bugs in ClassicPress 1.0.0-rc2, we need to know now so that we can get them fixed before the final release!  Otherwise, the final release will be out on Tuesday, March 5, as previously mentioned.

We invite you to put your new or existing ClassicPress sites on rc2 as soon as possible, and let us know if you see any issues, especially with regard to any of the areas that we changed.

For more information, including links to download the release, installation instructions, and a more specific list of changes, please see the release announcement on our forums.

ClassicPress 1.0.0 Release Update

Thanks to careful testing and reporting from our users, we’ve become aware of several minor issues with last week’s 1.0.0-rc1 release.  None of these issues will affect the functionality of new or existing sites, but they are still worth fixing:

  • wp-content/languages/es_ES files were accidentally included in the release (details)
  • wp-content/plugins/classic-editor was accidentally included in the release (details)
  • We removed the “favorite plugins” feature linked to a WP.org account, but not the corresponding “favorite themes” feature (details)

There is also one other minor issue that was not new to 1.0.0-rc1:

  • .htaccess gets 2 sets of rewrite rules (WordPress and ClassicPress) after migration and re-saving permalinks (details)

In light of the above issues, we’ve decided to release version 1.0.0-rc2 (release candidate 2) with the fixes.  This release will happen on Wednesday, February 27, and we’ll also update our release procedures to prevent extra files from being unintentionally included in the future.

The new target date for the 1.0.0 final release is Tuesday, March 5.

ClassicPress core development update

Current status of ClassicPress v1

It has taken us longer than we originally planned to get the final, official ClassicPress 1.0.0 version released, but we’re making steady progress. I’m providing a quick update from the core development team so that everyone remains aware of the current status of the project.

Right now, ClassicPress is in stable beta status and it is safe to use it on your sites. We started our fork from the WordPress 4.9 branch, and we have not and will not be making any changes to the platform’s core functionality in the version 1 release series. (You can find more information about our medium- to long-term plans for the platform on our roadmap page.)

What’s still left to do for v1

We’ll release the final version 1.0.0 when we’ve replaced or removed all WordPress-specific functionality from the ClassicPress dashboard and addressed all known bugs. Roughly, there are a few categories of changes we’re still looking to complete in the next few weeks:

  • Finish porting changes from WordPress for PHP 7.3 compatibility.
  • Remove most links to WordPress.org and features that use WordPress.org accounts.
  • Fix any known bugs that are new to ClassicPress.
  • Miscellaneous other “polish” such as better organization for new files and improving the experience around ClassicPress default themes.

For an up-to-date list of specific tasks remaining for the release, see the v1.0.0-rc1 milestone on GitHub. If you see a task there that you can help us with, please jump in!

After these tasks are completed, the v1.0.0 release will come in two stages. First, version 1.0.0-rc1 (release candidate 1) will be made available for testing for about a week. Then, if there are no new issues, we’ll release ClassicPress 1.0.0 with essentially the same code.

Updated launch dates

We are currently targeting Wednesday, February 20, 2019 for the 1.0.0-rc1 release, and Tuesday, February 26, 2019 for the 1.0.0 release.

These dates are a current best estimate, and they are subject to change if absolutely necessary.

If you’d like to help push ClassicPress over the finish line, please take a look at the task list on GitHub. Feel free to ask questions there on the individual issues, in the core development forum, or in Slack.

What else is going on

We all knew when we got involved with ClassicPress that successfully forking WordPress would be a huge amount of work. That is still very clear (perhaps even more clear) after many valuable contributions from ClassicPress leadership and community members, not just in core development but also in many other areas.

To point out just a few: marketing, design, internationalization, technical infrastructure, organizational structure, ClassicPress-first plugins, keeping our community running smoothly including an active support forum, and many other activities that are helping to make ClassicPress the best CMS platform for business and professional-quality websites everywhere.