This is a continuation of Part 1. If you haven’t looked at Part 1, I recommend that you do because it includes some additional setup for a secure install.
WP_DEBUG on local dev
I like to run my local dev version of WordPress in debug mode as that helps uncover issues while I’m doing theme or plugin development. Usually you do this by editing
wp-config.php and setting
WP_DEBUG to true, but I don’t want debug enabled in production.
I solve this by setting
environment.php (so that it is local to a particular server) then editing
wp-config.php to only set
WP_DEBUG to false if it’s not already set. You could make an argument for moving the
WP_DEBUG setup outside of the
wp-config.php and only having it in
environment.php but I like to keep the separation between
wp-config.php as clean as I can – only thing that must go in
environment.php go there.
You can see this change to
wp-config.php in a diff on GitHub
Database Setup, Keys, and Salts
Before you can execute the WordPress Install, you need to setup you database and update your keys and salts. I always use different keys and salts on each WordPress installation – even the “same site” will have different salts between development and production environments.
A standard best practice of WordPress is not to create a user named “admin”. This used to be (still is?) a very common username and having a known username makes it easier for people to try to attack your WordPress install. I usually pick a username like “[site]_admin” which is easy to remember but not default for someone guessing – a concrete example for a WordPress site configured to go with this post series would be
You should be using some kind of tool to manage and track your passwords and generating a new random password for every site. I always try to use a 30 character random password. This is especially important for administrator logins like the one that WordPress creates when you do the initial install.
Now that you have everything setup, it’s time to actually install WordPress. As you are no doubt familiar, this process is almost anticlimactic. One key thing is that I generally turn off search engine indexing when I do an initial install. This lets me get everything fine-tuned and ready to launch before “announcing to the world”.
Change “Admin” User ID
After the install, you should change the User ID of the first user that was created. The easiest way I have found to do this is to execute SQL statements against the database. Remember, this is a brand new WordPress install – there is no content or anything in the database. If you do something to mess up the database it’s not big deal – simply delete it and start over with the install.
You will need the database prefix that you setup in
wp-config.php. For example purposes, I’m going to use
[gist id=”3d80f8935c2d0a254348″ file=”change-admin-user-id.sql”]
There are several highly-rated WordPress plugins available but I prefer to use iThemes Security as it gives you a combination of recommendations for making your site more secure and protection from brute force attacks.
Once you get it installed, you can configure it to secure your website.
There are some recommendations that we have already handled:
- No user with ID 1
- No “admin” user
- Database table prefix is not “wp_”
- Change the default salts (though the plugin has trouble detecting it sometimes)
Some other changes I recommend making include:
- Protect login area from brute force attacks
- Enable malware scanning
- Enforce strong passwords
- Force user’s nickname to be different from display name
- Use a “safe” version of jQuery on the frontpage of you site
- Enable “hiding” the WordPress Dashboard and login
- Disable executing PHP from uploads folder
- Make .htaccess and wp-config.php and environment.php non-writable
There are lots of other protection methods available from iThemes Security that can make your site more secure.