How to maintain safely a WordPress Blog

1. Background

• Tweeps from #lrnchat exchanged their concerns on maintaining their blogs. Since I have some background on the topic I felt I could share a few pro tips. Also, since WordPress is Kneaver preferred way to publish, it will interest Kneaver users.
• It is also an experiment for me to write something useful in a way people from #lrnchat can understand it. Neither marketing, neither too technical. So feel free to comment on my style.
• Fits also in our next week topic on #PKMChat on “Learning from experience”.

2. First the conversation that took place:

Proactive update:

Rachel did update her theme but experienced a bad surprise:

Rachel was lucky that the update came quickly and was easy to install. Open source or not I encountered many experiences where updates required other updates (PHP for example) eventually putting my server in a total mess. Or the update may come after a few days.

Before that Rachel made changes on her theme using direct access to CSS. CSS may have a global impact causing the site to be totally unreadable for a while. Having a dedicated test server reduces this risk and gives peace of mind.

Visit her blog it is superb (http://www.ohthatrachel.com/2014/11/21/writing-effective-task-oriented-learning-objectives/).

Late Adopter strategy

Dave suggested another strategy:

Dave Blogs: http://www.ensampler.com/ and http://www.daveswhiteboard.com/

So this is surely a very conservative and careful approach but may end up being even more risky.

1. Each new version comes with security fixes ( see: Version 4.0.1 addressed some security issues and fixed 23 bugs)

Usually, there is a consensus to disclose security holes and leaks only after the developers are informed. They have a few days to find a fix before it goes in the wild. Once the security hole is know, hackers will try to take advantage of it to gain access to your site. It takes about 2 days before you see constant probes of your site in the logs. They will try again and again if you site is vulnerable. Even if you don’t care to loose your site and give access to it, hackers can find tons of benefits like redirecting traffic, trick your visitors to share their email address and names, launch more attack causing your server to become blacklisted, etc..

2. The upgrade path on a regular basis is well detailed and explained. Peer to peer support is available as Rachel demonstrate it. Should you upgrade later, you may find out that an intermediate version of a plugin or a theme is no more available. You will not be able to reach out to peer support.

3. The site declines as new browsers reach the market because rules, tricks, workarounds are based on how browsers announce themselves. A new browser will be treated as a very old browser and your visitor may have a terrible experience. You will not know unless you use the very same browser.

So how to get the best of both worlds without enjoying any risk?

3. The safe way to maintain yourself a WordPress Site

Most of this loose its interest if you don’t host your WordPress site yourself. Jump to 3.3 for an interesting use of it.

The benefit of hosting yourself a WordPress blog is that you have full accesss to all the options for a flat price and you are being able to install all the plugins available.

3.1 Install a daily backup of your database.

This is a feature of WordPress, use settings menus. Have this backup sent on your email and saved locally on the server.

3.2 Create a new server.

Of course, we want something at zero cost or very limited.

3.2.1 Choose a provider.

• My typical choice is to use a virtual machine on my own computer. For this I use VMWare Player. I download an image and start a server completely hidden. To do my tests, I just create zip files of the image.
• You can start a server on services running instances on an hour basis. I use DigitalOcean, Codero, Azure and EC2 Amazon.
  • EC2 as a free offer but be careful if you ever forget to stop it and drop it because they will charge you and it can climb to outrageously high prices if you didn’t make the right choices of configuration.
  • Azure and Codero are more for pros.
  • I really like DigitalOcean. Clean UI, very cheap (One month starts at USD5 but if you just use it for testing you pay per hour at $0.007 /hour 🙂
• They have WordPress images ready, but it may not be suitable for the purpose of replicating the exact conditions of an existing server.
• Plug: You get US10 credit if you use this link https://www.digitalocean.com/?refcode=468bbd48e117 and I get as much 🙂

3.2.2. Prepare the server.

Try to mimic as much as possible the existing one. Follow exact release numbers.

• Same operating system ( a Linux favor usually)
• Same web server (Apache, nginx),
• Same SQL database (MySQL or Progress).
• Same PHP

3.2.3 Install WordPress

Kind of boring but not worst that installing updates.

• Create a database. Use as much as possible the same names, users, password you have on your original site.
• Import your backup
• Download and install wordpress https://wordpress.org/download/
• Make sure you mimic as much as possible all settings. Why not just downloading them for the original site? They are in wp-config.php
• I use scp to copy between servers. rsync is also a good option. Forgot ftp it’s unsecure.

When you start WordPress it may complain that Plugins and Themes are not activated. Activate again what you need based on your original configuration.

At this stage you have already a HUGE benefit. You are prepared for the worst case scenario. Not only you have a backup but you tested it and you know how to use it.

All together it should not take you more than 2 hours and a few cents.

3.2.4 Take a snapshot of your server.

This snapshot will allow you to return to this stage if an upgrade fails. With DigitalOcean you can also create new images and download them. Great feature.

3.2.5 Maintain this server

– You fire it up only when you need to test upgrades or a new plugin or a new css, stop it afterward (place a reminder somewhere 🙂 ).

– You upgrade it exactly as you would upgrade the main server but before and you do some tests before applying the same upgrade to your main server.

– If you experience difficulties you can either wait a few days for a fix or rool back to the snapshot and wait for a better time or try to fix yourself.

– Take more snapshots or backups when you need to try completely new ideas. It becomes very safe to try new plugins from any origin and finally wipe out all the evaluations by reverting to a snapshot and do a clean setup.

– Update the database regularly by importing more recent backups. I do it every 2 weeks only. The most important is to test the infrastructure not the contents.

3.3 Development setup

I use a similar setup to develop new themes and new plugins but with WordPress directly installed on my computer. Like this all the files are directly reachable and can be modified.

This setup cannot replace the predeployement server described above. Imagine the case where a new upgrade imposed for security reasons is urgent while you are precisely heavily redesigning your site. If you test on your development server it doesn’t prove anything since you use a different setup.  The risk would be that you end up pushing your changes earlier because you want to upgrade your server.

Final Security remark.

I, Bruno Winck, appear to be the author of this post, but it is not my user name. My user name will be a random string choosen using Strong password generator and it will have again a password generated with the same service. This user can only create and modify posts. Another user has the admin rights and not the editor rights.