A Content Audit

What Content Types?

• Pages
• Posts
• Attachments
• Custom Post Types

What About Archive Pages?

Custom post types and custom taxonomies may come with "surprise" archive pages

Also... don't forget these special pages:

• Search results page
• Author archive pages
• 404 page

Editor Features

Editor Features

WordPress is extremely customizable

• Ideally, get a walkthrough of the admin area
• Even better, talk to all past admins
• If that's not possible, build a sandbox* and roll up your sleeves...

*We'll get to this in a bit

Editor Features

• The Content Audit shows what content exists.
• The Editor Walkthrough shows how that content was constructed in the backend.
• Do certain changes require a developer or code deployment?
• How much control do editors have over layout?
• Are there special settings that might be hard to find because they are hidden in a plugin menu?
• Are there special shortcodes or other inline content blocks?

User Audit

Who has administrator access?

This is super important.

I wonder if Uncle Albert used a secure password?

Plugin & Theme Audit

Plugin Audit

• What plugins are installed and active*?
• What does each one do, and is it necessary?
• Are any plugins premium? If so, what are the serial numbers / access keys, and what contact information is used for support?
• Are any of the plugins custom-built or modified?

Theme Audit

• What is the currently active theme?
• Is the active theme custom or from a 3rd party?
• What custom post types are built into the theme?

3rd-party Themes

• Is it a premium theme? If so, access keys and support...
• Has it been customized without use of a child theme, making updates unsafe?
• Are any plugins necessary for the theme to work?

Custom Themes

• Is a task manager like Grunt or gulp used to compile assets? What is the build process?
• Are any front-end CSS frameworks used? (e.g. Bootstrap, Foundation)
• What javascript libraries besides jQuery are used?
• What assumptions does the theme make about WordPress configuration?

Credentials

Credentials You Need

1. WordPress Admin Access
2. Hosting Control Panel Access
3. SFTP/SSH Credentials
4. MySQL Credentials (look in wp-config.php)

Domain Registration

Domain Registration

• Where is the domain name registered?
• Where are the name servers?
• What's the account information?
• How long until it needs to be paid for again?
• What other services depend on the domain? (e.g. Email)

Backups

"Supos belusi buggerup..."

What's your Backup plan?

• Are backups made within the WordPress admin or through some other tool?*
• Are backups automated? If so, how often are they made, and have the backups been verified?
• What is the process like for restoring from a backup?

*My personal opinion is that you should never rely on a thing to backup or restore itself

What Gets Backed Up?

• The MySQL Database
• Uploaded media (the uploads folder)*
• The entire /wp-content/ folder
• The entire WordPress directory

* I like to use offsite storage like Amazon S3 for media uploads. Then, with proper version control for code files, the only thing left to backup is the database

Making a Plan

• Automated backups and restoration at the hosting level (e.g. with WP Engine)
• Automated backups to an offsite provider like VaultPress or Jetpack
• Automated backups of the database via some script on the server (stored offsite such as on S3)
• A WordPress plugin like Backup Buddy, connected to S3
• Manual backups (download the database and save it somewhere safe 🤣)*

*No but really, this works in a pinch. And you should be manually checking the automated backups anyways. You are checking your backups, right?

Two Final Notes

Backups
Save
Lives

Under no circumstances store your backups in your WordPress site files

Version Control

git it

Were the previous developers using Version Control?

If not, time to start

See my Introduction to git and WordPress presentation

• Download the entire site folder
• Initialize a git repository (don't commit yet)
• Add everything except for /wp-content/ to .gitignore
• Add /wp-content/uploads to .gitignore

• git add . && git commit -a -m "first commit"

If Yes, is it up-to-date?

• Clone the repository to your computer
• Download the /wp-content/ folder from the live site, and paste it over the wp-content folder in the repository
• If git reports no differences, you're good
• If there are differences, you have to decide if you want to rectify them or start with a fresh repository based on what's on the server

Setting up a Development Environment

Ways to make a sandbox

• Docker
• Vagrant / VVV
• MAMP/WAMP/XAMP
• A copy of the site on another hosting environment

Docker is my preferred method

See my example docker repository

Varying Vagrant Vagrants

VVV is a tool built to facilitate development on multiple wordpress websites from one vagrant virtual server

MAMP/WAMP are the easiest

Start here if you're not comfortable with a command line yet

Some hosts offer a built-in staging environment

I prefer to use staging for testing changes that were made in a development environment on my own computer, but if you're going with the "another copy of the site" method, this can be an easy way to do it.

Use your sandbox for code  changes. Use draft / hidden pages and posts to play with content changes.

Security Audit

This could be an entire talk

The quick version

• Know who your Administrator users are. Ensure they all have strong passwords.
• Use a plugin like iThemes Security to limit the number of login attempts to your admin area.
• Keep all plugins, themes, and WordPress core updated.
• Avoid theme and plugin vendors without a solid reputation and history.
• Keep backups.

Two easy additional steps

• Use a host dedicated to protecting you from WordPress-specific attacks, like WP Engine.
• Use Cloudflare to intercept many malicious attacks before they even reach your servers.

Deployment: Putting your code in place

Simplest method: SFTP

1. Make your changes to WordPress plugins and themes inside the wp-content folder
2. Use an SFTP client to upload the themes and plugins folders, making sure not to overwrite the uploads folder.
3. Update WordPress core using the built-in updater.

This is really not ideal — mistakes can easily leave your website broken or your changes lost. And everybody makes mistakes.

Getting more complicated: SSH/SCP

• Similar to the SFTP process
• Provides repeatability (reducing mistakes) when combined with bash scripting

Using GIt

• WP Engine and some other hosts let you deploy by pushing directly to the server using git.
• On a custom server, you can use git on the server to pull the latest changes from origin.

This method is safer and gives a process for undoing mistakes. However it has some drawbacks too... especially if you're using an asset builder like Grunt

My preferred method

• Changes are merged into master branch on github via pull request or push.
• A service like Circle CI or Codeship watches the github repository for changes, and starts a build.
• The build script compiles front-end assets.
• The code is automatically deployed to a staging environment via git or ssh, from the build service.
• Code is promoted to production from staging via a single command, which triggers an automated process.

Migrating Hosts

Migrating hosts

• Code migration is just like deployment
• Lower the TTL on your domain name
• Copy the database manually
• Edit your computer's hosts file (/etc/hosts on mac) to point to your new server for your website's domain name
• Test the site
• If everything looks good, change DNS settings