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).
