Recently, I had the pleasure of onboarding a few PHP Developers into an environment that included (amongst other things) several WordPress instances. To my surprise, none of these devs had ever worked in WordPress. (I may be dating myself here but WordPress skills were, at one time, the skills for a PHP developer.)

During that onboarding process I ran into three old tricks I’ve been using for WP Development forever that were both extremely helpful and surprising to my new devs. They are presented here for anyone else who hasn’t stumbled onto them yet.

1. Symlinking the Themes, Plugins, or Even WP-Content

In a perfect world, you’d only ever have to write code for the most recent version of WordPress. But we don’t live in a perfect world. If you’re in a mixed environment where every WP instance isn’t kept completely up-to-date, or if you’re building a plugin or theme for public consumption, you have to be able to test on multiple versions of WP.

To do this, I like to install my WordPress code in its own folder inside of my VM shared folder, marked by version, and setup a vhost to access that particular version, like wp495.loc and wp496.loc. Then, I pull my theme or plugin from the central repo into an adjacent folder. After that, I simply create a symbolic link from the appropriate place in wp-content to the repository…

 

ln -s /var/www/repos/cool-theme-im-working-on /var/www/wp495/wp-content/themes/cool-theme-im-working-on

 

Now, you can symlink the code your working on into multiple WP installs (and versions) for testing without having to copy and paste or push and pull every time you want to run tests.

One caveat here: if you’re on Windows (like me) you’ll want to be running Git Bash as an administrator when you start the box to ensure this all works properly.

2. Use wp-config.php to Override Site URL

You can use the wp-config.php file to override the home and siteurl settings that are part of the wp-config database. These are the configuration options that cause WordPress to redirect you back to the production url when you first dump a db to your local. The override is simple:

define('WP_HOME', 'http://wp495.loc');
define('WP_SITEURL', 'http://wp495.loc');

These values make it easier to manage database updates. You could even use them to work directly with the production DB (if you don’t like your job all that much), or store your DB copy up on the actual database server. It’s significantly faster to copy the database on the server than dump and re-constitute it on local. If you’re going to do that, you just need to adjust the DB values in the same file.

3. Forget About the FTP Server

If you want to be able to use WordPress’ features like Media Upload and Update on the server, then you’re going to have to setup an ftp server. And most of your clients are going to need that. But, if you’re building, say, a personal wedding website, then you don’t need to bother.

Instead, install a good Amazon S3 plugin like WP Offload S3 Lite and setup your local instance to use it. Then, add your media on the local machine. The plugin will automatically move the media over to S3, and set the URL for the media to the S3 url.

If you’re keeping the rest of you WP content folder in CVS (not recommended for large, long-term projects) then updating themes or plugins is just as simple. Simply run it local while connected to the production database, commit, and pull on prod.