Posted on

Past and short term future

A little explenation why there was no 1.0 release and what are the tentative plans for the near future.

Past

In 2019 I was looking to stop freelancing and re-join the ranks of office inhabiting mindless code monkeys. Even found a position in a startup which developed a wordpress based in flight entretainment system with an agreed work load which should have left enough time to me to get calmPress kicking.

Life has a tendency of disrupting the best “on the paper” plans. In addition to various off-line events it turns out that no matter how well you plan to separate work and hobby, work has always a bigger priority and even when you have an official plan to dedicate time for the hobby you might not have the mental capacity to dedicate to it after you spent it on a paying job.

And then came covid and the startup was an early casualty, and like many others, I could not concentrate on anything. Only after the two vaccine shots with general life all around returning to some kind of a more relaxed normality I could find the mental capacity to return to calmPress.

Near term future

I would like to have a 1.0 release based on wordpress 5.9, so probably at january 2022. The main feature that needs to be implemented is safe mode which requires a working built-in backup system. The backup actually mostly works right now but I took a break from finishing it to handle other “must haves” like built-in APCu support hoping that when I return to the backup I will have a better holistic understanding of how it should work in practice instead of focusing on coding details.

What 1.0 will hopefully be

I expect that at that point interested people will be willing to take it for a ride, hopefully use it on some test sites. I don’t envision a huge migration out of wordpress drive from the start which is why I do not invest into a migration plugin right now. Will put effort into it when there will be an actual demand.

 

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

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.

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

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.

Posted on

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.

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

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.

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.

Posted on

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 https://core.trac.wordpress.org/changeset/43727 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.