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.

Conflicts

Possible Conflicts

Compatibility with plugins and themes
As there is relatively very little difference in code between WordPress 4.9.x and calmPress 0.9.x we expect that 99% of the plugins and themes should “just work”.

Two areas that might be problematic are:

  • Security type plugins, such as Wordfence, that try to verify that you are running WordPress will fail.
  • Any plugin that assumes that automatic updates work, will most likely not function fully.

Should work but not properly tested
Some things have not been tested, but should work:

  • Multisite (although this site runs on such a configuration)
  • Nginx web server

Compatibility with 3rd party tools and other utilities
WP-CLI – Compatibility was not tested. Some things related to update of core might or might not work, but it is very likely that things like plugin and theme updates will work as expected.

Long Term Support
As we are going to backport changes from whatever releases WordPress will make on the 4.9.x line, it is hard to provide commitments written in stone, but this is what we are planning to have:

  • Patch releases will be published ASAP after WordPress publishes a new release on the 4.9.x line. The intention is to have only major bug fixes in the patch releases, but we might introduce also non critical fixes and changes added to the relevant 4.9.x WordPress releases.
  • End of support for the 0.9.x version is scheduled for the 31st of December 2021. At that time, the 1.0.x version will be the stable version.

Forum

Forum breadcrumbs - You are here:Forum
You need to log in to create posts and topics.

Forum

GeneralLast post
General DiscussionFeel free to discuss anything about calmPress0 Topics · 0 PostsNo topics yet!
No topics yet!
SupportLast post
Alpha Version 1.xIssues concerning the 1.0 releases.1 Topic · 2 PostsLast post: Update not found · 5 years ago · Rowland
Beta Version 0.9.xIssues concerning the 0.9 releases.0 Topics · 0 PostsNo topics yet!
No topics yet!
Installation or MigrationDiscussion about installing or migrating your site.1 Topic · 2 PostsLast post: Updating Plugins without WP-CLI · 5 years ago · Rowland
DevelopmentLast post
Feature RequestsWhat features could we add.0 Topics · 0 PostsNo topics yet!
No topics yet!
ThemesWhat themes work or don't work.0 Topics · 0 PostsNo topics yet!
No topics yet!
PluginsWhat plugins work or don't work.0 Topics · 0 PostsNo topics yet!
No topics yet!
MarketingHow can we market calmPress0 Topics · 0 PostsNo topics yet!
No topics yet!
Statistics
2
Topics
4
Posts
3,750
Views
6
Users
0
Online
Newest Member: Printablepib · Currently nobody is online.