Posted on

Roadmap for the release of version 1.0

Before talking about 1.0 it is probably a good idea to update on the current status of the project.

As part of completing the separation between authors and users, it became clear that unlike previous changes which focused on deprecating things, this needs to be properly tested to ensure backward compatibility at the API level, and the best way to do it is to utilize the WordPress unit tests. This wasn’t very easy and there was no fun in doing it, but it was done and now every code change is being automatically tested by Travis.

In addition a lot of time was spent on  rebasing calmPress 1.0 to use WordPress 5.1 as the reference point/origin for changes. This was not as trivial as anticipated especially since WordPress 5.1 includes many changes which are related to code styling and not to a new or changed functionality.

These experiences help quantify the amount of time that is likely to be required to have a 1.0 release with all the features in it. As the roadmap for WordPress 5.2 indicates that it is going to be released on April 30, it leaves too little time to release 1.0 before WordPress 5.2 gets released and since it is not a great idea to release something that will be outdated just a few days after the release, we are going to wait until it is released and base the 1.0 release on WordPress 5.2.

As it seems like rebasing to WordPress 5.2 can take two weeks, and time needs to be allocated for manual testing, the target date for releasing 1.0 is the end on May.

The current list of issues that should be resolved for 1.0

Posted on

Alpha5 of the 1.0.0 release is available

The fourth alpha release of the 1.0.0 line is here. In addition to continued development of calmPress itself, it incorporates changes from the WordPress 5.0.2 release which are not related to gutenberg .

Notable changes since alpha2:

Simplification of the user profile

All fields that do not make much sense where removed, and there is more flexibility in setting a display name.

Username is not being used anymore anywhere in the UI.

In all of the places where a username was expected as an input, or it was displayed, it is replaced by the user’s email address.

In the UI related to user registration, the user does not need to select a username, just specify a unique email address.

For backward compatibility, all places which used to accept either username or user’s email address as input (for example, login form) will still accept a username even if the UI indicates that an email address is expected.

From a developers perspective, there was no change in the user APIs, and the main change is that username is not mandatory anymore when creating a new user as it will be automatically generated from the email address.
Users will still have a username in the DB, it is just not going to be used anywhere in the core UI.

A category is not mandatory for posts

You do not have to have a hierarchical categorization of content if you do not want it.

Password protection of posts was removed

The main reason for removal is that it has bad UX for the author, reader, and developers. We are going to figure out better ways to manage restricted content, but this is so bad there is no point in keeping it around until we will have a better approach to the problem.

The relevant API to detect if a post is password protected is still there, it is just going to return a value indicating a password is not needed.

UI for post formats was removed

The general impression is that themes do not provide any significant distinction between the various formats and that custom post types are probably a better and more robust way to achieve the goals the post formats feature was trying to achieve.

From a developers perspective, there is no change, Attempts to change the post format via the API, are just going to be ignored.

Calendar and archive widgets were removed

It seems like navigating content based on its publishing date is an extreme edge case.

Get it now!

You can learn more about the issues which were closed, and we intend to handle as part of the final 1.0.0 release in the 1.0 release line page.

Posted on

Alpha2 of the 1.0.0 release is available

The second alpha release of the 1.0.0 line is here. In addition to incorporating the PHP 7.3 compatibility changes from the 0.9.9 release, the major change in this release is removal of all shims related to emoji.

From now on it is assumed that that for better or worse proper support for displaying emojis is up to the browsers and it does not require software based crutches (which many times produce a sub-optimal result). Just like with using text which is in a different language then the main language used on the site, it is up to the author to decide whether the target audience is likely to use software  that will properly display the emojis being used.
Our impression is that for the most used emojis there is a very broad support, and you are not likely to run into display problems unless you use some fringe or very new emoji in the content.

Get it now!, just be aware that PHP 7.0 is a minimum requirement to run it.

You can learn more about the issues which were closed, and we intend to handle as part of the final 1.0.0 release in the 1.0 release line page.

Posted on

First alpha of the 1.0.0 release

The first release of the 1.0 line is here. Among many somewhat isoteric improvements the  1.0.0-alpha1 release handle two major pain points that were bothering all WordPress users:

  • Trackback and Pingback spam. All of the code related to receiving and sending them was removed.
  • User name discovery through /author=id type of URLs. This is an intentional side affect of the decision to not support “plain” urls anymore as they tend to display in public private information that is just better kept secret even when there is no immediate security issue related to it.

Get it now!, just be aware that PHP 7.0 is a minimum requirement to run it.

You can learn more about the issues which were closed, and we intend to handle as part of the final 1.0.0 release in the 1.0 release line page.