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.

• • Removed a “role” attribute that caused HTML5 markup validation to fail.
  • Fixed a PHP notice in the code for a dashboard widget.
  • Removed a stray CSS map reference from TinyMCE skin.min.css file.
  • Backported all code changes from WordPress related to emoji, updating to the Twemoji v12 image set.
  • Added ClassicPress changelog links to the admin dashboard, so changes between ClassicPress versions can be viewed more easily.
  • Modernized the code for the ClassicPress build scripts.

In progress

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

• Improve wording for plugin compatibility with the current ClassicPress version.
• Update of the list of files to remove after migration from WordPress to ClassicPress.
• Clean up theme notices in admin to eliminate overlapping/excessive length in non-English languages. This is an open pull request that needs review and testing from one or more contributors.

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.

About Michelle Coe

Design Team Lead and Marketing Co-Lead at ClassicPress. Entrepreneur, strategist, and artist devoted to small businesses, big dogs and Volkswagens.

View all posts by Michelle Coe | Website