Introducing the user guides sites ūüéĀ

While we all avoid reading documentations, at some point after we spent too much time trying to figure out things by ourselves, we do start to look for one.

So here come the user guides for calmPress. The site is focused on the bare essentials right now, installing, upgrading, migrating and specific  documentation on the difference between calmPress and WordPress.

A developers guide will also come at some point in the future.

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.

Beta 4 of the 0.9.9 release is ready for a test drive

Beta 4 is very likely to be the last test release before the full release of 0.9.9. The only thing left to do with it is to document and test migration path from WordPress installs.

There are two changes from beta3:

  • Compatibility with the upcoming PHP 7.3 version.
  • Fix for minor bug which in development enviroment caused JS errors as there was an attempt to use non existing unminified JS files.

You can download it for here, and read about the changes done in the 0.9 release line here.

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.

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

  1. You just can not trust code that is being developed under time pressure from marketing. The security relaxation around the data attributes, might be ok in the end, but any such thing should be announced in advanced to give time to get comments from people which 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.
  2. 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” content, but they should never be used as the main editor in a CMS software.

So not going to include it in version 1.0. Maybe 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.9 and 1.0.0 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.9 and 1.0.0


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.

Read the full release change log

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 implement 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 remove 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, emogies,¬† 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.

Read all the features we expect to push in version 1.0.0

We will try to release this version at 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 to not 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, but too many promised deadlines that had passed left everybody wandering 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 feature that were already worked on 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 busy holiday and shopping season in the US, and while it is true (as core contributor pointed out) that it is always a holiday or shopping rush somewhere in the world, the real issue is that a 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 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.