WordPress

From WebarchDocs
Jump to navigation Jump to search

Information about running WordPress on Webarchitects servers.

We have a low-volume announcement email list for clients using WordPress.

Our newer Webarchitects servers, have an option of an automatic WordPress install when hosting accounts are created.

See also the other pages in the Category:WordPress on this wiki.

SSH access and WP-CLI

If you would like to use the WP-CLI command line application you need to request SSH access to the servers, by default clients have SFTP access only.

Following are some common use cases for WP-CLI, see complete list of commands, also note that we have installed tab completion so you can just type wp and hit tab twice, quickly, and a list of options will appear.

WP-CLI Update WordPress

Change into the directory your site is in and check if an update is available and then update the site: 

cd sites/default
wp core check-update
wp core update

WP-CLI Update Plugins

Change into the directory your site is in and check the status of the plugins and them all: 

cd sites/default
wp plugin list
wp plugin update --all

WP-CLI Install and Activate Plugin

Change into the directory your site is in and download and activate a plugin: 

cd sites/default
wp plugin install foo
wp plugin activate foo

WP-CLI Install and Activate Theme

Change into the directory your site is in and download and activate a theme: 

cd sites/default
wp theme install bar
wp theme activate bar

WP-CLI Add Administrator User

Change into the directory your site is in, set an environmental variables for the new username and email address and generate a random password (which you will need to pass to the user, or they can simply do a password reset using their email address) and send the user an email about their account being created: 

cd sites/default
export WP_USER="username"
export WP_USER_EMAIL="username@example.org"
export WP_USER_PASSWD=$(pwgen -n 16 1)
echo "${WP_USER_PASSWD}"
wp user create "${WP_USER}" "${WP_USER_EMAIL}" --role=administrator --user_pass="${WP_USER_PASSWD}" --send-email

WP-CLI Change Users Password

cd sites/default
export WP_USER="username"
export WP_USER_PASSWD=$(pwgen -n 16 1)
echo "${WP_USER_PASSWD}"
wp user update "${WP_USER}" --user_pass="${WP_USER_PASSWD}"

WP-CLI Delete Unapproved Comments

If your site comments have been spammed you can delete the unapproved ones by creating a ~/bin/wp-trash-unapproved-comments file containing the following: 

#!/bin/bash

# Get the unapproved comment IDs
UNAPPROVED_COMMENTS=$(wp comment list --fields=comment_ID,comment_approved --format=csv | grep -v "1$" | grep -v "comment_ID" | awk -F, '{print $1}')

# Count the number of unapproved comments
UNAPPROVED_COMMENTS_NO=$(echo "${UNAPPROVED_COMMENTS}" | wc -l )

echo "There are ${UNAPPROVED_COMMENTS_NO} unapproved comments"

if [[ ${UNAPPROVED_COMMENTS_NO} > 0 ]]; then
  echo "About to trash ${UNAPPROVED_COMMENTS_NO} comments"
  for id in ${UNAPPROVED_COMMENTS}; do
    wp comment trash ${id}
  done
  echo "${UNAPPROVED_COMMENTS_NO} trashed"
fi

And then run it: 

cd ~/sites/default
bash ~/bin/wp-trash-unapproved-comments

WP-CLI Login Server

The wp-cli-login-command package can be used to generate login links, install and activate it: 

wp package install aaemnnosttv/wp-cli-login-command:^1.4
wp login install --activate --yes

Generate a login link for the first Administrator account: 

wp login as $(wp --no-color user list --role=administrator --field=user_login | head -n1)

WP-CLI create .htaccess file

Create (or re-create) the .htaccess file: 

wp rewrite flush --hard

WP-CLI reset all passwords

#!/usr/bin/env bash

users=$(wp user list --field=user_login)
for u in $users;
do
  wp user reset-password --skip-email "${u}" || exit
done

Changing the site URL

When WordPress sites are automatically installed on our new servers they are initially set up on sub-domains based on usernames, for example http://user.webarch6.co.uk/. This is fine for development purposes but when a site is to be made live the main domain name for the site needs to be changed. There is an article on the WordPress site which documents various ways to do this, changing the siteurl and home options should be all that is needed, when using SSH and wp-cli: 

wp option update home 'https://www.example.org.uk'
wp option update siteurl 'https://www.example.org.uk'

However a wp-cli search and replace over the whole database is sometimes necessary (when, for example, updating HTTP URLs to HTTPS URLs or adding or removing a www. suffix): 

wp search-replace "https://user.webarch6.co.uk" "https://www.example.org.uk"

There are other options for editing serialized entries in the database, which you can use without our help, listed on the WordPress documentation site.

Caching

We have found that WP Super Cache works well and urge all clients to install and enable it on their sites to speed them up and reduce the load on the servers.

Cloudflare

If you enable Cloudflare for your WordPress site the key things you need to check are:

  • That the "WordPress Address (URL)" and the "Site Address (URL)" on the General Settings page are set to use HTTPS.
  • That you are not redirecting HTTP requests to HTTPS requests in the .htaccess file for the site.

If you don't have the settings right Cloudflare will cache pages fetched using HTTP and serve them using HTTPS and this will result in clients getting mixed content warnings.

HTTPS

If your WordPress site doesn't use HTTPS then your password is vulnerable to being compromised, especially if you login to your site from un-encrypted public WIFI hotspots.

Since 2014 Google have been ranking sites that use HTTPS higher and since 2015 free HTTPS certificates from Let's Encrypt have been available.

Starting in 2017 Google will be marking HTTP pages with password forms as non-secure and they plan to eventually:

label all HTTP pages as non-secure, and change the HTTP security indicator to the red triangle that we use for broken HTTPS

Due to these factors it makes sense to use HTTPS for your WordPress site, all our new WordPress hosting comes with HTTPS enabled by default.

The simple way to set up a WordPress site so that unathenticated users (people who simply read the site without a login) get a HTTP version and authenticated users only use HTTPS is to add this variable to wp-config.php: 

// https://codex.wordpress.org/Administration_Over_SSL#To_Force_SSL_Logins_and_SSL_Admin_Access
define('FORCE_SSL_ADMIN', true);

Note that this should come before wp-settings.php is required, but there are limitations to this approach:

Assuming the front end is using non-secure http protocol, this can result in mixed protocol usage. Further, any cookies returned by AJAX calls to URLs built using admin_url('admin-ajax.php') will be secure and thus unavailable to other parts of the front end.

For this reason we strongly suggest you make your WordPress site HTTPS only (with a redirect for people accessing it using HTTP).

Once the HTTPS certificate has been installed (we need to do this, it can't be done by clients) the ~/.htaccess file can have the rules documented on the htaccess wiki page added to the start of it. The other step that needs to be done is to update the WordPress internal links, we find the easiest way to do this is using the wp-cli search-replace function, you need to ask us to undertake this task, for example: 

su - user -s /bin/bash
cd sites/default
wp search-replace "http://example.org/" "https://example.org/"

WordPress Multisites

A WordPress multisite is one WordPress instance which hosts multiple seperate sites, if you would like us to host a multisite please get in touch and we would be happy to set this up for you. See the documentation on WordPress.org for more infomation.

WordPress Table Prefix

You can host multiple WordPress sites using one MySQL database if each site has a different table prefix. The advantage of this is that it can dramatically reduce your hosting costs, however it is not without drawbacks.

The primary problem with this approach is when one site is compromised (we see several sites compromised a year) either via an insecure plugin, or brute force attack on the main admin account (these are the most usual causes) — often one site being compromised results in all the others on the same hosting also being compromised and then rolling back to the version of files and database prior to the breach becomes an awful lot more complicated and therefore expensive. We would advise against this approach for these reasons unless you are running very secure sites (using HTTTP authentication for logins) with minimal, well maintained and updated plugins to mitigate the risk of compromise.

If you want to have a development copy of your WordPress site to do things like work on the theme and test plugins then you are also better off with a separate database as you will no doubt want to copy the live database to the development site more than once and it would be safer doing this with separate database.

Piwik

We have a Piwik server available for use by members of our co-operative, if you would like to use it please get in contact to ask for an account to be set up and then install the WP-Piwik plugin.

Brute Force Attacks

WordPress sites are vulnerable to brute force attacks on admin accounts via the wp-login.php page and the XML-RPC interface, this is where botnets try multiple password combinations against the admin username (they are able to find this out) to try to gain access to sites in order to post spam to them. This is why it is important to make sure you use good passwords.

WP Disable XML-RPC Pingback

On our newest servers we have configured support for wp-disable-xml-rpc-pingback, this prevents the abuse of your site's XML-RPC by simply removing some methods used by attackers.

WP Stop XML-RPC Attack

On our newest servers we have configured support for stop XML-RPC Attacks, this disables all access to your xmlrpc.php, except for JetPack and Automattic and checks with ARIN for Automattic's subnets and updates your .htaccess file.

WP Fail2Ban

On our newest servers we have configured support for the WP-fail2ban plugin and we automatically install and configure this with each WordPress site install. The result of this is that if there are more than 5 failed login attempts on one site on the server then the remote IP address is banned from accessing any site on the server for 24 hours

If you believe an IP address has been blocked in error please contact us to unblock it.

There is a danger of false positives and malicious side effects of banning IP addresses, if for example someone or several people make more than 5 failed login attempts from the same IP address it will be banned, or if someone deliberately makes login attempts which fail in order to get a IP address banned, this is especially a danger with shared proxy servers, for example Tor exit nodes or if you set your site up to use CloudFlare.

The best way to mitigate the danger of false positives is to use HTTP Authentication to add an additional layer of security, a username and password you can share with other editors of the site, this isn't an option if your site allows anyone to create accounts to post content, it is only suitable when there is a small number of trusted editors, see the instructions for password protecting wp-login.php.

For servers which don't have WP-fail2ban support configured we suggest that you install a plugin to limit the rate at which these attacks can be run (though note that there is still the danger of false positives, as mentioned above, with these), for example:

Brute Force Login Protection

Brute Force Login Protection writes to your .htaccess file however there are reports of it failing when servers are under high load, this shouldn't be an issue with our servers and the developer is working on a solution, but create a backup of your .htaccess file and revert to it if your site starts displaying server errors.

BruteProtect

BruteProtect is used to track every failed login attempt across all installed users of the plugin and it blocks that IP across the entire BruteProtect network.

All In One WP Security & Firewall

All In One WP Security & Firewall has lots of options, some which have the potential to break your site, if in doubt only enable the brute force login attack prevention feature.

WordFence Security

WordFence Security has lots of features (don't install this if you want something simple) including two factor authentication with the Premium (paid for) version.

However there have been some issues with WordFence — it can create a wp-content/uploads/.htaccess file containing the following: 

# BEGIN Wordfence code execution protection
<IfModule mod_php5.c>
php_flag engine 0
</IfModule>
<IfModule mod_php7.c>
php_flag engine 0
</IfModule>

AddHandler cgi-script .php .phtml .php3 .pl .py .jsp .asp .htm .shtml .sh .cgi
Options -ExecCGI
# END Wordfence code execution protection

This will cause internal server errors when files are accessed as we don't allow any php_ options or Options to be set by clients in HTAccess files for security reasons, furthermore we disable PHP code from running in the uploads directory at an Apache config file level for WordPress sites with the following directives, so the WordFence .htaccess file is unnecessary: 

  <Directory /home/example/sites/default/wp-content/uploads/>
    Options None +SymLinksifOwnerMatch
    SetHandler None
    <Files *>
      SetHandler None
    </Files>
    <IfModule mod_php5.c>
      php_flag engine off
    </IfModule>
    AddType text/plain .php .phtml .cgi .pl
  </Directory>

If in doubt best not use the WordFence plugin, we configure sites to use HTTPS for logins and deploy wp-disable-xml-rpc-pingback, WordPress#WP_Stop_XML-RPC_Attackwp-stop-xmlrpc-attack]] and wp-fail2ban, and these mitigate the thread caused by brute force attacks.

Bedrock

If you want to use Composer, SSH and git to manage your WordPress site then the Bedrock layout is a project you can use for this. The advantage is that it makes having separate development, staging and production sites for development and testing a lot easier.

However with a Bedrock based WordPress site you can't update it using the web interface and if you don't have the necessary development skills then it can be expensive, as a result we have been asked on a few occasions to convert Bedrock based WordPress sites into regular ones and following are some notes based on this experience.

  1. rsync the files from app/ to wp-content/
  2. Do a search and replace along these lines: 
    wp search-replace --verbose "http://bedrock.example.org/wp" "https://wordpress.example.org/" --log --dry-run
  3. And also: 
    wp search-replace --verbose "http://bedrock.example.org/app/" "https://wordpress.example.org/wp-content/" --log --dry-run
  4. Update the home and siteurl options if needs be
Retrieved from "https://docs.webarch.net/w/index.php?title=WordPress&oldid=1557"