This procedure is a proposal for large projects in which there are many people involved, and in which some control of updates is required.
Different teams are involved in the proposal, although they will be summarized in 2 or 3, such as technology, security and the editorial team. In any case, we can separate it into two, the technical team and the editorial.
As I say, it is a proposal, based on a specific project, so it should be adapted to each specific case.
Table of Contents
- Environments
- Infrastructure Upgrade
- WordPress Core Update
- Updating WordPress Plugins
- Access
- WordPress System Administration Services
Environments
We will have 3 environments when working with WordPress.
Development environment (devel)
The development environment will be an obsolete environment in terms of content (by default) but aligned in terms of configurations.
This environment will have, whenever possible, the latest applied versions of any part of WordPress, be it infrastructure, WordPress or plugins.
Here we can find versions higher than those that are going to be applied in production, so, although it is a public version, it does not have to be taken as a reference for the production passes.
Staging environment
This environment is proposed as a version prior to going to production. It will be generated with a copy as current as possible of the production site, to be able to compare contents.
This release will apply the changes that are documented in the Move-to-Production Version Changelog.
On a timeline we would have:
To –3 days, with the collection of all the changes and the presentation of the Changelog.
A –2 days creation of the staging environment and a public URL to analyze the changes.
Production environment (pro)
The production environment is the environment that end users access. The system has automatic copies in various places and formats.
Prior to updates, a local and remote backup will be performed for quick recovery.
Updates will be applied as designed in the Changelog and therefore approved according to the pre-production environment.
Infrastructure Upgrade
Let’s define infrastructure as the part that can reference everything that affects WordPress, but it’s not WordPress.
This would mainly affect the machines and configurations of virtual machines, or cloud environments, where we find the configurations of MariaDB, nginx, PHP, Redis and other elements that make up WordPress.
Infrastructure upgrades are planned as follows.
Operating System Security Updates
The Linux operating system (in this case Ubuntu) is configured so that critical security updates are applied automatically.
Service Security Updates
In case there is a security update that may affect any of the WordPress components, such as nginx, PHP or Redis, a notice will be given and within 24 hours the update procedure is proposed. It will be a procedure of administrative silence, so if no one says anything against it, patches will be applied.
Normal updates
On the first Monday of each month, the infrastructure update will be planned as normal.
WordPress Core Update
This section refers exclusively to the updates of WordPress itself, that is, its core.
WordPress works by a system of major and minor versions (or patches). Major versions are those that are identified by the first two digits (e.g., 5.8, 5.9, or 6.0). Minor versions (or patches) are defined by a third digit (5.9.1, 5.9.2, 5.9.3).
Major versions, among their changes, can include new functionality, add or remove files or make changes to the structure of the database.
Minor versions are limited to making changes and improvements to existing functionalities, in addition to the application of security patches.
Minor updates
By default WordPress applies automatic updates in minor versions, as they carry minimal risk, and usually involve bug fixes or security patches.
The default configuration will be the application of these patches automatically by WordPress itself automatically.
Major updates
Major WordPress updates usually have a schedule planned about 3 months before their release. In addition, as a general rule, at least one beta version, and one candidate version, are included prior to launch.
Major updates will be applied in a candidate version in the development environment at the time they are available and therefore any potential incompatibilities or improvements that are pending can be observed.
The objective is that, on the day on which the major version officially appears, the update can be applied in a planned way and already with a compatibility review of the add-ons.
Updating WordPress Plugins
WordPress has two types of plugins: plugins and themes.
The way to manage both is similar, since they can be updated from the official WordPress repository and, therefore, with a click from the panel. They can also be updated from external sites that allow updating from the panel, usually under license, or they can be updated manually by uploading a ZIP with the plugin from the Upload plugin area, or Upload theme, of the administration panel itself.
Although plugins typically follow the same semantic form of versions as WordPress, each developer applies their own methods.
Topics
Themes refer to the elements that are displayed to users, the frontend of the site. A characteristic of themes is that they do not have to include functionalities that can be used in other themes. For these cases, a complementary plugin must be included to certain functionalities, since, if you change the theme, they must continue to work.
Minor updates
A minor update of a theme is considered one that refers to the improvement, correction or change of some element of the front, but without including new functionalities. This in itself means that there are only small changes in the code, corrections, but that the files are not added or modified in a large way or that generates incompatibilities. For example, a minor version should not adapt to a new version of PHP.
Minor updates will be made on a weekly basis, every Monday.
The procedure will be to present the Changelog on A –1 day. Changes will be applied to the last available pre-production environment. On day A the changes will be applied.
Major updates
A major update of a theme is considered one that refers to the expansion of functionalities or change of compatibility of the theme with WordPress or infrastructure. This change may include adding or removing files, or rewriting entire functions or elements, for example, to adapt to a new version of WordPress.
Major updates will be included in the main update cycle, currently on the third Monday of each month, and changes will be included in the main Changelog.
Emergency and security updates
In the event that a security problem is detected in any of the topics, mainly those developed to measure, a specific minor version can be generated that fixes that part of the code, without including any changes that may fall within the minor updates.
In that case, the file will be generated, the changes will be presented, and within 24 hours it will be applied as a security update.
Plugins
Plugins refer to plugins that can be included in WordPress, which can affect both the front and the admin panel or other components and add specific functionality to the system.
Plugins there are many types, although to a greater extent we can separate them into two. Those that refer to intrinsic functionalities of the platform, such as security plugins, cache plugins, or tools that interact with the infrastructure, and those that add functionalities to improve the site, its edition or non-native functionalities of the system.
Minor updates
A minor update of a plugin is considered one that refers to the improvement, correction or change of some element, but without including new functionalities. This in itself means that there are only small changes in the code, revisions, but that the files are not added or modified in a large way or that generates incompatibilities. For example, a minor version should not adapt to a new version of PHP.
Minor updates will be made on a weekly basis.
The procedure will be to present the Changelog on A –1 day. Changes will be applied to the last available pre-production environment. On day A the changes will be applied.
Major updates
A major update of a plugin is considered one that refers to the expansion of functionalities or change of compatibilities with WordPress or the infrastructure. This change may include adding or removing files, or rewriting entire functions or elements, for example, to adapt to a new version of WordPress.
Major updates will be included in the main update cycle, currently on the third Monday of each month, and changes will be included in the main Changelog.
Emergency and security updates
In the event that a security problem is detected in any of the plugins, mainly those developed to measure, a specific minor version can be generated that fixes that part of the code, without including any changes that may fall within the minor updates.
In that case, the file will be generated, the changes will be presented, and within 24 hours it will be applied as a security update.
Access
Access to the system that allows a user to connect to any of the systems of use of WordPress, either the infrastructure (SSH, SFTP, Git) or the WordPress itself (username and password of the administration panel) is considered.
Access to Infrastructure
There will be two levels of access to the infrastructure.
Access to development machines will be open access to all systems and development teams, including root access to the machine if necessary.
The development infrastructure is configured to be a machine 100% independent of the rest of the systems.
Access to pre-production and production machines shall be limited exclusively to systems and safety equipment.
Access to WordPress
WordPress has its own access level system, of which we can highlight 3 levels.
Access levels
Collaborator
Those users who have to manage their content in WordPress but do not have to edit third-party content. An example might be an external collaborator.
Editor
Publishers are those users who have access to the complete management of the contents (add, modify and delete). Among the contents we can include entries, pages and multimedia (photographs, videos, audios).
Administrator
The administrator is that user who can manage and maintain the WordPress, but it is not proposed that he is part of the editorial team (that is, his user should not have any published content).
Management of users in pre-production and production
In pre-production and production environments, the administrator users who will have access are those who manage the platform at the systems level, that is, the systems and security teams.
Those people who are simply dedicated to the creation of content will have Access to Collaborator.
Those who perform the review, publication and programming of the contents, including the SEO teams, will have an Editor level.
All users with Administrator and Editor access will have to have a 2FA system activated, either by validating an email, through an App or a hardware device (for example, FIDO). In addition, it will be recommended that everyone has their unique self-destructible security keys.
WordPress System Administration Services
Do you have a high traffic WordPress website? Are you an Agency with servers with cPanel, Plesk or other panel on which you maintain WordPress for your clients?
If so, and you are interested in a professional WordPress infrastructure maintenance and performance improvement service for your or your clients’ websites, contact me.