Localhost WordPress sites under Windows 10

I develop on Windows 10, using XAMPP. It’s not the sexiest of platforms, but it works fine for me. I have the following local setup in place, with a few configuration rules, and a batch file that allows me to quickly spinup new sites, not as subdirectories under localhost but as unique subdomains. This includes

• creation of unique databases
• installation of a core set of plugins, whether from wordpress.org or a local directory
• creation of an admin user
• the dropping of the default user (ID 1) the purging of default content.

All of this is handled by a single Windows batch file. To make this happen, I have the following things in place:

1. XAMPP setup as my local server (any *AMP installer should be fine)
2. a wildcard DNS entry that maps *.localdev.highbrow.com.au to 127.0.0.1 . This allows requests for any of my local sites, by name, to be directed back to localhost
3. I have Apache’s  mod_vhost_alias enabled , and configured to route all requests for subdomains back to a single directory, and its subdirectories. Enable the module by uncommenting the relevant line in Apache’s apache\conf\httpd.conf file. I then use the following Virtualhost entry in \apache\conf\extra\httpd-vhosts.conf to map requests to the correct subdirectories:
   
   Virtualhost

   Apache

   <VirtualHost *:80> ServerAdmin webmaster@localhost ServerName local ServerAlias *.localdev.highbrow.com.au VirtualDocumentRoot E:\Projects\websites\%1\site <Directory "E:\Projects\websites"> Options FollowSymLinks AllowOverride All Order allow,deny Require all granted Allow from all </Directory> ErrorLog "logs/localdev.log" # Possible values include: debug, info, notice, warn, error, crit, # alert, emerg. LogLevel debug </VirtualHost>

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

   <VirtualHost *:80>         ServerAdmin webmaster@localhost         ServerName local         ServerAlias *.localdev.highbrow.com.au         VirtualDocumentRoot E:\Projects\websites\%1\site         <Directory "E:\Projects\websites">                 Options FollowSymLinks                 AllowOverride All                 Order allow,deny                 Require all granted                 Allow from all         </Directory>           ErrorLog "logs/localdev.log"           # Possible values include: debug, info, notice, warn, error, crit,         # alert, emerg.         LogLevel debug   </VirtualHost>

   
   The main lines to consider are ServerAlias *.localdev.highbrow.com.au and VirtualDocumentRoot E:\Projects\websites\%1\site – this means that the wildcard value is used to generate the path to the site’s document root. so dave.localdev.highbrow.com.au will resolve to E:\projects\websites\dave\site\
4. WP-CLI setup and available globally. After installing it,  test its availability by opening a command window somewhere (or better still a ConEmu window) type wp and hit enter. You should see a list of possible  commands. If you see an error about an unrecognized command, you need to configure your PATH variable. Repeat the test with the mysql CLI tool, which is installed with XAMPP, under \mysql\bin\mysql.exe . If you need to make changes to environment variables, I can recommend Rapid Environment Editor as a civilised alternative to editing the files by hand.

 

The script should be called from the location where you’d like the new WordPress install to live, so if I wanted a new site at test.localdev.highbrow.com.au I’d create a directory at E:\projects\websites\test\site and execute the script from there.

When run, the script creates a new DB (or drops an existing one to recreate it); it then downloads WordPress core, installs and configures it to connect to the new local database. It then creates user two and removes user one, and all of user one’s content, so the sample post, sample comment and sample page are all removed. Next, it downloads, installs and activates some plugins, and installs a few local plugins.

 

There’s some room for improvement here. The permalinks setting doesn’t seem to be respected (could just need a rewrite rules flush). You could easily strip out Hello Dolly and Akismet, if you have no interest in them.  Read the WP-CLI docs to see what is possbile; the main thing is to reduce the amount of time spent button-clicking in the WordPress admin. Some examples:

• if you use Gravity Forms, install the Gravity Forms CLI add on, and keep a standard contact form saved as a json file, and then import it with
  call wp gf form import "W:\shared\plugins\gravityforms\simple contact form.json"
  (note that you need to have Garvity forms configured first, from the admin UI, for this to work
• for standard brochureware sites, create a default menu and then create standard pages (home / our services / about us / contact us), adding each to the menu in turn.

Because these local URLs requires DNS resolution to function, sites created with this setup require an internet connection to resolve. If you need to work offline, you will need local hosts file entries.

The same script could easily enough be converted to become a bash script for use in a *nix environment.

I will acknowledge an alternative to this approach is a Vagrant setup such as VVV or chassis. Although, after some heartburn, I have managed to get both of these working under Windows, it’s not that much fun. Privileges, in particular, for setup tasks like creating local hosts entries, are not handled well, and answers like “just run it as administrator’ are not a solution, in my book. Appreciate that Windows is not a platform of interest, compared to Mac or Linux, and the user experience on other platforms in doubtless butter-smooth. Both tools also seemed to be light on for suggestions as to how to deploy the site you are creating. I don’t recall discussion of deployment of your container to a platform that supports it, for example.