WSOD protection planned for WordPress 5.1 is a poor replacement to a proper safe mode

Seems like WordPress 5.1 release is having problem with its main feature – WSOD (White Screen Of Death) protection.

The feature is intended to provide a recovery path for people that upgrade the PHP version and run into trouble due to their themes and plugins not being compatible with the new version. In extreme cases, this kind of incompatibility might lead to the admin not being able to log in at all and therefore no way to perform the most basic recovery attempt of shutting down the offending plugin.

There are a few philosophical problems with this kind of feature:

  • If a software has bugs you can not trust it for anything. Since all themes and plugins share the same “execution space” with core, if a plugin is buggy it might be buggy in such a way that will disable the WSOD protection itself.
    The only reliable way to implement it is to have a different software which monitors the state of WordPress and can disable by itself the relevant plugins.
  • Sites rarely have plugins active just because the bring “joy” to the admin. In every well maintained site each plugin has some functionality which is vital to the site and disabling a plugin will most likely mean that the site is going to be down. This kind of decision should not be made by a generic automated process as it might happen that even if at some point an admin can’t log in, it is still more important to keep the front end up.
  • It assumes people do not use bloated themes (and if the theme is site specific it might be the right thing to do to develope one).  With bloated theme there is a very good chance that the failure happens in the theme and not in a plugin, so what are you supposed to do in that situation? as disabling a theme is equivalent to bringing the site down.
  • It is targeted at people that have very little knowledge in how to technically maintain a site, but what exactly are they expected to do if WSOD protection kicks in? It is not likely they have enough PHP knowledge to solve the problems by themselves,  and this false sense of security is just going to put them in a situation in which their site is down and they will have to rush to find a developer to fix it ASAP. Totally not calm.

The right way to go about PHP upgrades is to educate users to first test upgrades on a staging site and provide facilities in core to make creation and synchronization with such sites easier.

For the cases where a mistake happened (and we know that s**t is bound to happen from time to time), the better way is to have a “safe mode” like functionality that is fully controlled by the user. Safe mode can’t by itself avoid the problems listed above, but being a user-controlled process the site owner can at least try to plan and bring help before getting into such mode.

Safe mode is planned for version 1.0 of calmPress, but maybe it will be kicked to 2.0 as while it is something very nice to have it is not essential and there are many nontrivial things to do as part of 1.0 as is.

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.

Version 0.9.10 is generally available 🎉

This is the first real step in providing site owners a better experience in operating a web oriented CMS.

For this release the focus was on giving the site owner a choice on when to upgrade. The importance of this was exemplified in the WordPress’ 5.0.1 security focused release. People which wanted to stay on the 4.9.x release line longer until gutenberg will stabilize had to chose one of the following bad choices

  • Upgrade to 5.0.1 although they do not want to use gutenberg and neither have the hassle of installing plugins to disable it
  • Stay on 4.9.8 with publicly known security vulnerabilities

Although WordPress released 4.9.9 which solved the security issues on the 4.9.x release line, users did not get any indication in the admin UI that such an upgrade path is possible at all.

There are some other small changes, mostly revolving around deprecation of small obsolete features.

You can learn more about requirements, expected support time frame and differences from WordPress from the 0.9.x release user guides.

Get it now!

To report bugs or add suggestions, please use our GitHub issue tracker.

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.