Information about running WordPress on Webarchitects, Ecohost and Ecodissident 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.
- 1 Changing the site URL
- 2 HTTPS
- 3 WordPress Multisites
- 4 WordPress Table Prefix
- 5 Piwik
- 6 Brute Force Attacks
Changing the site URL
When WordPress sites are automatically installed on the
host2.webarch.net servers they are set up on sub-domains based on usernames, for example
http://user.host2.webarch.net/. 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, however we find that the easiest thing is if clients ask us to do it.
The method we use is a wp-cli search and replace, this updates serialized entries in the WordPress database, for example:
su - user -s /bin/bash cd sites/default wp search-replace "user.host2.webarch.net" "example.org"
There are other options for editing serialized entries in the database, which you can use without our help, listed on the WordPress documentation site.
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
// 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/"
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.
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 wp-disable-xml-rpc-pingback, this disables all access to your
xmlrpc.php, except for JetPack and Automattic and checks with ARIN for Automattic's subnets and updates your
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 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 haso 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 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.