First alpha of the 1.0.0 release

The first release of the 1.0 line is here. Among many somewhat esoteric improvements, the  1.0.0-alpha1 release handles 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.

Joining the huge crowd rejecting gutenberg

Till this day I thought that Gutenberg is a failure, but just because I do not like it do not mean it is totally worthless. Maybe, I thought, there is a place for it as an “opt in” editor which users that do not care that much about all of its UX, a11y, and performance problems can use.

But today came the commit and proved me wrong from two angles:

  • You just cannot trust code that is being developed under time pressure because of marketing. The security relaxation around the data attributes, might be okay in the end, but any such thing should be announced in advanced to give time to get comments from people who are security professionals. The fact that the reason for the commit is literally to “make Gutenberg work for users with restricted permissions” and nothing more, is far from being trust inspiring.
  • The fact that Gutenberg needs special significant markup in the HTML generated by it just shows it is a page builder and not an editor.
    There is nothing wrong with page builders as long as they are being used for a “one off” for content, but they should never be used as the main editor in a CMS.

So it is not going to included in version 1.0.x. Maybe I will revisit this decision in a year, maybe by then it will mature enough and will become useful. Right now it is too “untested” to be used on production sites.

Tentative roadmap for the 0.9.x and 1.0.x releases

Since the idea behind calmPress is to create and maintain an improved version of WordPress over time and not just to divorce WordPress here and now, we are (and will always be) dependent in some way on the release schedule of WordPress itself.

Now that there is an actual roadmap for versions 4.9.9 and 5.0 of WordPress, it is possible to at least get some ballpark dates for the release of versions 0.9.x and 1.0.x

This version is meant to provide a simple migration step from WordPress to calmPress. The most important feature of it is changing the software update mechanism from getting core updates from to getting them from

There were some other changes, but they were mostly focused on branding related changes.

The current status of the version is that it is a beta quality software, all planned features were coded and no new features will be added.

The plan was to release it when WordPress 4.9.9 version will be released, but the recent changes to the WordPress roadmap due to the release of Gutenberg in version 5.0 “pulled the rag” from under the 4.9.9 planning and at this time it is not clear if and when such a version will be released (although it is needed if WordPress wants to support PHP 7.3 for the 4.9 branch).

As we have no idea about when WordPress will have such a release, we will just go ahead and release 0.9.9 on the the 2nd of November 2018.

The first release in which we will start to show our long term vision. It will have the following focuses

  • Essential and easy implemented security improvements. They are going to be about removing XML-RPC, preventing external access to places to where there is no reason to have such access, and removing the exposure of user names.
  • Introduction of a core plugins concept. Those plugins will be an answer to the situation where many people need a feature, but not enough to justify having it in core, and they will be maintained directly or indirectly by core.
  • Deprecation of code and features that should have died long time ago. Starting with the generator tag, emojis,  code editing from the admin, XML-RPC, RSS feeds, own oEmbed support, and more. Some of them will be moved to core plugins, some will be removed and most likely there will be no one that will shed a tear.

We will try to release this as a stable version by the 8th of February 2019.

The agitation created with the WordPress 5.0 roadmap is exactly what we want to avoid

Change is hard, and no matter what some people say, no one likes unsolicited change.

But change is also a fact of life. You will never grow and improve if you just blindly reject change.

The question is always about the balance which you need to keep between investing in change while still staying sufficiently safely in your comfort zone, and how you facilitate change.

We think that the roadmap for WordPress 5.0 is a great example of how not to facilitate change and a total antithesis to what we believe in.

You should read the roadmap first if you are not familiar with it. It is important for context that while everybody was aware that there will be a 5.0 release at some point, too many promised deadlines had passed, leaving everybody wondering when will that happen.

One day out of the blue, there is an announcement that version 5.0 will be ready for production (RC milestone) in less than 4 weeks, it will not include features that were already worked on in trunk (and people might have expected them to be in 5.0), but will include updates to all core themes, and a new theme that no one ever talked about before.

Time to General Availability from announcement? About six weeks.

People complain about dates coinciding with the busy holiday and shopping season in the USA and, while it is true (as core contributors pointed out) that it is always a holiday or shopping rush somewhere in the world, the real issue is that two months time is relatively short and people might have already made commitments for that period of time and they just do not have the available time to invest into checking their software’s compatibility with the new version and produce fixes if needed.

And it gets even worse, because in case it will be needed, the time to GA might end up being four months in the future instead of the promised two. No one can realistically plan anything based on such a fuzzy schedule.

In calmPress we simply reject this kind of planning. For us it is not the issue of the kind of change (yes, I personally hate Gutenberg as much as the other 50% of WordPress users do), but the realization that users should be provided with as many tools as possible to both prepare for a change, and postpone it until they can make the time to deal with it.

We do expect a few relatively fast release cycles while we are working on transforming a vision into actual code, but the ultimate goal is to have a slow release cycle, maybe even as slow as having no more than one major release a year like PHP itself has. We know that people become nervous and agitated when they need to confront a change, especially if they are not very technical, and we want to keep them as calm as possible and let them focus on content creation and not on site maintenance.

Hello calm world!

Hi there,

It is unlikely that we have ever met before as I am just so so young, just few weeks old.

Right now I am mostly a clone (AKA fork) of WordPress, but when I grow up I want to become a much more focused and relaxed than it is right now.

You can learn more about me from the menu links, or just take me for a ride.