1.0.0-alpha14 was released

This release is based on the WordPress 5.2 release and includes the newly introduced features in it, WSOD recovery, site health page, and enhanced signature verification for themes and plugins being downloaded from wordpress.org where applicable.

We do not expect to port any new features from WordPress for the 1.0 release, only bug fixes.

Other major changes include:

Elimination of Gravatar as a source for comment and user avatars

Gravatar is a source of obvious privacy violations, as it lets Auttomatic track people surfing the sites that use it. It can also be used for the deception of who is the actual author of a comment, and it is relatively easy to extract the actual email address from its URLs.

Two different methods are employed to generate avatars that can be used in the places where gravatar is currently being used

  • As a default, use the modern approach to generating avatars based on the commenter/user name with some background color which can be used as a “random” factor to help differentiate between people with the same name.
    The current implementation goes with a simple color scheme that ensures high contrast.
  • Each registered user which can upload images can set its own image avatar which will be used on the admin side and for the comment he leaves. An admin can upload and configure an image for users who do not have upload files permission.
    The future goal is to relax the restriction and let all users upload their own avatar image.

Explicitly enable other sites to embed content from your site

The functionality should have probably just been moved to a core plugin, but as first step there is now a possibility to control the feature from the “reading” setting screen, with the default state being “off”.

Disable comments feeds, outdated feed protocols, and allow turning feeds off

Comment feeds never made much sense, and with all browsers deprecating support for “life” feeds, its questionable utility had dropped to zero.

Out of the post feed types, RSS2 seems to be the most widely used, with easy integration with critical services like MailChimp, which seems to be a good reason to keep it in the core. Other feed types, with the exception of ATOM, are just an anachronism not being used by anyone and were removed. ATOM might still have value to someone and therefore it is not removed but relegated to a core plugin.

In addition, under the belief that nothing except for web publishing should be “on” by default, the ability to control whether the site has feeds at all was added and it is implemented by setting the number of posts in a feed to zero (which is the default setting).

The RSS widget and the simplepie library moved into the core plugin

RSS is just not a very flexible way to get infomation from external sites which limits the ability to do anything which is not very trivial with it.

As it is still easier to use over designing your own data exchange protocol and therefore has some utility, we keep supporting the functionality, but as a plugin and not in the core itself.

Setting post excerpts moved to a core plugin

Real life experience shows that you want to show different excerpts in different contexts, therefore the idea that a post has one canonical excerpt is just a fail.

Keeping the functionality as a core plugin for people that migrate from sites that already have the excerpt set and need to be able to manage it.

Get it now

1.0.0-alpha12 was released

This release starts to highlight the changes between calmPress and WordPress. It is based on WordPress 5.1.1

The concept of user name is dead

User authentication and all UI which display information on the currently logged-in user were switched to use the user’s email address instead of user name. This brings user identification in calmPress to be more aligned with how users are being identified on big web sites.

The user’s “display name” functionality was enhanced to allow it to be used to customize the text that is being used at the places where the user name used to be for the users which will prefer to see some nickname instead of their email address.

Backward compatibility and backstage

The change is mostly UX related. The DB still includes a username field and the users can still use it to identify themselves when logging in, but from now on new users will have it generated automatically for them based on their email address.

DecouplingĀ of users and authors

People that have worked in a setting in which an agency or IT department is managing a site on behalf of a company know that whoever has permissions to access the admin is rarely the actual author of the content.

In a blog kind of setup, having an indication of who is the author is usually redundant (which is probably why the post author setting is hidden by default).

And then there is the edge case of multiple authors for which having just one possible author is just not enough.

In 1.0.0-alpha12 we are addressing those issues by creating a distinction between the person who had authored the content and the one who has the permissions to actually edit it on the site.

For the authors, a new taxonomy was created in which the terms are the names of the authors and some additional information about them. The taxonomy is managed just like tags are, and all posts, pages, and media are associated with it, and just like with tags, there is an “archive” type of page in which content authored by the author will be displayed.

For each author, it is possible to control the name, the slug of the archive page, some description text and an avatar to be associated with the author.

Users who have the permission to edit a specific content are no more its authors, but editors and the relevant UI changes in the admin have been done to reflect that. In addition, users never have an archive page associated with them, and if such functionality is needed they have to be explicitly specified as the authors of the content.

You might need to modify your theme if you would like to take advantage of the “no author” and “multiple authors” possibilities of this change.

Backward compatibility and backstage

When upgrading to 1.0.0-alpha12 or above the author’s taxonomy is automatically created and populated with the author information based on the relevant user’s profile, then the posts are associated with the newly created author terms.

Author archive pages will be displayed in a different URL than under the old scheme.

On the code level, code that filters or searches based on the author’s user name will continue to work, but semantically the result will be related to the post publisher rather than the post author.

If your code doing anything fancy on the author’s archive page you might need to adjust it for the taxonomy based scheme. More specifically, the is_author function will always return false and the author-xxx.php type template pages will never be run.

Simplified User Profile

As a result of the changes described above the username field became irrelevant and was removed.

The functionality of first name, last name and nickname were merged in the display name field which became much more flexible in the input it accepts.

The visual editor toggle is gone, as we do not see the point of using a CMS to write raw HTML.

The Website field is gone as well as it never made much sense.

Backward compatibility and backstage

Removal of the visual editor setting is not just a UI thing, and the relevant functionality of disabling TinyMCE is removed from all the places which were impact by that setting. We believe that if you systematically prefer to write raw HTML, you are using the wrong tool.

The first name and last name information is still part of the DB and will be returned by the relevant APIs, but this information is too culturally biased (both in the offline life in which people might have a name which is hard to break into first and last parts, and online many times people prefer a single word nickname) to be useful in the context of calmPress core, and if plugins require such an information they will need to make sure the user provides it and store it in the DB.

Four Minutes install šŸ˜‰

In addition to the removal of the username field, two heuristicsĀ  are applied to make the install process even easier

  • Assume by default that the DB is located on the same server
  • Automatically generate a table prefix

Those two settings are still configurable but are displayed only when the user asks to enter an advanced mode.

The end result is much less friction especially due to the removal of the username and prefix fields, for which the average user is unlikely to be able to come up with any good value by himself.

Control the content of the .htaccess file from the admin

A new settings page .htaccess was introduced to have better fine-grained control of the .htaccess file than it was possible to get under the Permalinks settings page. It enables the user to add and modify rules without having to use FTP software.

Performance Improvements

“Out of the box” the .htaccess file is generated with best practice settings for compression and browser caching.

HTML, JavaScript, CSS, SVG, and generic XML are served compressed.

Browsers are suggested to cache Javascript, CSS, and media files for a month.

Prevention of user name and user email leakage

Three factors for user name leakage have been eliminated

  • Since authors are decoupled from being users, the author’s posts archive does not disclose the username anymore.
  • The error messages displayed (and in case of XML-RPC, returned) after unsuccessful login attempt and user registration were changed to be a generic failure message from which it is impossible to figure out if the login failed due to a bad username or password, and if a specific email belongs to someone which is registered in the site.
  • The Rest-API was changed to not disclosed user information to anyone which is not a super admin.

Prevention of direct access and execution of non-explicitly public facing PHP code

The .htaccess file generated when running on the Apache web server prevents access to directories which has a name starting with a . (dot). This means that if you are using a workflow that includes pulling changes from GIT, the .git directory itself will not be accessible from the web.

In addition, the .htaccess rules had been changed to prevent running PHP scripts from the plugins, themes, and uploads directories. This will help to prevent direct exploits of plugin and theme code which assumes that it is invoked only by core and do not take enough care to protect against direct access.
Preventing execution of PHP script from the upload directory provide some more depth to the protection against users being able to run code on your server by “sneaking” an evil PHP script into the uploads directory (which usually has much more relaxed permission than other directories).

Version 0.9.11 is available šŸŽ‰

Version 0.9.11 is a security and bug fix version that incorporates the security and bug fixes introduced in WordPress 0.9.10 into the 0.9 line. The WordPress page describes the changes as following

These changes include a pair of security fixes that handle how comments are filtered and then stored in the database.

The changes were incorporated “as is” and there are no further impacts to calmPress.

Get the full install of 0.9.11 or the upgrade.

Alpha 5 of the 1.0.0 release is available

The fifth 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Ā .

Simplification of the user profile
All fields that do not make much sense were 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 the username is not mandatory anymore. When creating a new user, 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 that post formats feature were 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!Ā Ā Just be aware that PHP 7.0 is a minimum requirement to run it.

Version 0.9.10 is 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 is 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 who wanted to stay on the 4.9.x release line longer until Gutenberg stabilized had to chose one of the following bad choices:

  • Upgrade to 5.0.1 although they do not want to use Gutenberg and 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.

Get it Now!Ā Just be aware that PHP 5.2 is a minimum requirement to run it.