Tutorials – WordPress 5

In 2018, WordPress [1] powered about 75 million websites [2]. WordPress knowledge is a valuable job skill, more future-proof than any "social media" expertise and generally the best answer when friends and family ask you to help them make a website.

When it was released in December 2018, WordPress 5 generated enough complaints and discussions to remind one of the "KDE vs. Gnome" feuds. Now, however, many tools have been ported to the new version, and many teething problems have been fixed. Learning WordPress 5, even if you are new to WordPress, is much easier now than it was six months ago. In this tutorial, I will describe how to install WordPress 5 on Linux, configure its main features, and use its new editor, Gutenberg, plus I'll highlight some lesser-known WordPress tools.

Installation

While WordPress boasts a five minute install, this will take a bit longer if your system doesn't have all the correct dependencies installed. Starting from scratch, the complete procedure to self-host WordPress on Linux requires the following steps:

1. Install and configure a recent version of the Apache or Nginx web servers.
2. Install and configure PHP v7.2 or higher.
3. Install MariaDB.
4. Create a WordPress database and database user.
5. Configure your web server to point to the WordPress folder.
6. Download and unpack the WordPress archive in the right folder, with the right permissions and ownership.
7. Point your browser at your website's URL to perform the five minute installation.

The last two steps do indeed take just five minutes and are all you need to install WordPress on any hosting service that officially supports it and provides a MySQL or MariaDB database.

To self-host on a barebones Linux server, you'll need the first five steps; this only takes 10 more minutes – unless you run into the same problem I encountered on my CentOS 7.6 server (which also may occur with other Linux distributions). Luckily, the solution is simple and distribution-independent.

The problem is that WordPress 5.x requires Apache v2.4 and PHP v7.2, which may be newer than the versions available in your distribution's default repositories, and adding optional ones may not be enough.

In my case, I had no problem enabling the EPEL repository for CentOS 7.6 and installing those packages from there. But when I pointed my browser to fabriziofioretti.com [3] after performing steps 3 to 6 above, Apache told me that the folder I wanted did not exist or was not accessible. The reason is that an Apache server only sees folders below the one defined as DocumentRoot in its own configuration file. I had put the WordPress files inside /var/www/html/fabrizio, but DocumentRoot's default value in the EPEL Apache 2.4 package is /opt/rh/httpd24/root/var/www/html. Once I set that variable to /var/www/html and restarted the server, everything was fine.

To create the database in step 4, launch the command-line mysql client as root in a terminal window:

#> mysql -u root

and then, at the SQL prompt, type the following:

#> create database wp_database;
#> grant all privileges on wp_database.* to wp_user@'localhost' identified by 'wp_password';
#> flush privileges;
#> exit;

changing wp_database, wp_user, and wp_password to suit your needs.

Step 5 (configuring Apache to serve the new website) was almost as fast. Thanks to the Let's Encrypt project [4], I created a self-signed SSL certificate for the domain with one call of the certbot command:

#> certbot -n --agree-tos --standalone certonly -d fabriziofioretti.com

and then added to Apache's httpd.conf file the VirtualHost section shown in Listing 1. Lines 1 to 4 tell all browsers connecting to fabriziofioretti.com through the default, unencrypted HTTP port (80) to use the secure HTTP protocol instead (HTTPS). Lines 6 to 9 tell Apache to use the files inside /var/www/html/fabrizio to handle all secure connections (on port 443) to the same website. Line 11 through line 15 specifies where to find the cryptographic certificates and keys created with certbot just for that purpose. Finally, line 17 sets the location of optional access control rules.

01 <VirtualHost fabriziofioretti.com:80>
02   ServerName fabriziofioretti.com
03   Redirect permanent / https://fabriziofioretti.com/
04 </VirtualHost>
05
06 <VirtualHost fabriziofioretti.com:443>
07 ServerAdmin mfioretti@nexaima.net
08 DocumentRoot /var/www/html/fabrizio
09 ServerName fabriziofioretti.com
10
11 SSLEngine on
12 Include /etc/letsencrypt/options-ssl-apache.conf
13 SSLCertificateFile /etc/letsencrypt/live/fabriziofioretti.com/cert.pem
14 SSLCertificateKeyFile /etc/letsencrypt/live/fabriziofioretti.com/privkey.pem
15 SSLCertificateChainFile /etc/letsencrypt/live/fabriziofioretti.com/chain.pem
16
17 AccessFileName .htaccess
18
19 </VirtualHost>

To copy the WordPress files on the server, unpack them, and change their ownership to the apache user running the web server, use the following:

#> cd /var/www/html/
#> wget https://wordpress.org/latest.tar.gz
#> tar xvf latest.tar.gz
#> mv wordpress fabrizio
#> rm latest.tar.gz
#> chown -R apache:apache fabrizio

Housekeeping

A word of warning: The WordPress installer automatically creates an administrator account. Never use this account to create content, even if you are sure you will be the website's only author. Instead, give the administrator account a hard to guess name and only use it for actual administrative tasks. Then create a separate account immediately after installation for publishing and managing content; give that account your real name and email address, but not administrator privileges! First of all, this makes brute force attacks on the most powerful account a bit harder than if it were named admin. Secondly, it will decrease the probability that you inadvertently will change some setting while using your author account.

After setting up accounts, go to Tools | Site Health for critical information about your WordPress setup (Figure 1); check out the status report and follow its advice. Repeat this procedure every week or so.

Figure 1: The Site Health Status report makes recommendations for improving your site security.

Getting Started

Before jumping into the WordPress dashboard, sketch out on paper your website's basic components and how visitors should access them, including things like menus, a search field, RSS news feeds, or a slider. Determine whether you want a home page with static content or a list of posts, with the newest first. Do you need a banner or a background image? Will you accept reader comments and for how long? The better you do this initial homework, the happier you will be with your finished product. However, do not worry about design or where to place those components at this stage.

Now you are ready to use WordPress' dashboard. Configure the components you have decided upon by going through the sections in the dashboard's left panel in order (with the exception of Appearance | Themes, as you can waste a lot of time checking out the various theme options before configuring the main components).

The first components that you will want to customize are the logo and site icon, under Appearance | Customize (Figure 2). The logo is what visitors see (depending on the chosen theme) somewhere in each page's header, and the site icon is the small picture that identifies the browser tab that contains your website pages.

Figure 2: You will want to customize the logo and site icon.

Next, define your homepage settings. As your homepage, WordPress can display the titles and abstracts of all your posts, in reverse chronological order, or a fixed, static page. In WordPress, pages should contain permanent, timeless general information (e.g., your mission or how to contribute), whereas posts are time-sensitive content (e.g., travel reports, announcements, etc.).

Menus, essential to navigating any website, are easy to create and rearrange in WordPress (Figure 3). You can also configure WordPress to automatically add each newly created page to the menus. Keep in mind that menu placement depends on the theme, and not all themes offer the same options.

Figure 3: Building WordPress site menus is a snap, but remember that their location depends on your chosen theme.

After its plugins and themes, the most flexible (and easy to abuse) WordPress building component is widgets, which are boxes that can contain static or dynamic content, from greetings or embedded videos to tag clouds and titles of most recent posts. Figure 4 shows WordPress's default widgets, but other plugins and themes add more options.

Figure 4: WordPress 5 widgets facilitate adding static or dynamic boxes to your pages.

Clicking on Settings in the dashboard loads the interface to configure variables like website URL, language, membership, date format, comment management, and more. An often overlooked part of these settings is Permalinks (the URL structure of each page or post of your website). You can tell WordPress to automatically include in each URL its category, author name, or the date, in several formats. Good permalinks improve the usability of your website and above all its forward-compatibility. Permalinks with a structure like mywebsite.com/YEAR/MONTH/post-title, for example, are supported by any CMS. Adopt that structure, and none of the links to your posts will break, even if you decided to replace WordPress with some other product. For more information on how WordPress handles permalinks, see [5].