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:
- XAMPP setup as my local server (any *AMP installer should be fine)
- a wildcard DNS entry that maps
127.0.0.1. This allows requests for any of my local sites, by name, to be directed back to localhost
- I have Apache’s
mod_vhost_aliasenabled , 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.conffile. I then use the following Virtualhost entry in
\apache\conf\extra\httpd-vhosts.confto map requests to the correct subdirectories:
VirtualhostApache1234567891011121314151617181920<VirtualHost *:80>ServerAdmin webmaster@localhostServerName localServerAlias *.localdev.highbrow.com.auVirtualDocumentRoot E:\Projects\websites\%1\site<Directory "E:\Projects\websites">Options FollowSymLinksAllowOverride AllOrder allow,denyRequire all grantedAllow 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
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.auwill resolve to
- 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
wpand 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
mysqlCLI 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.
REM user and pass, username = database name
set siteName="Highbrow Interactive"
REM these are the credentials you will login to Wordpress with
set adminUser="Hugh Campbell"
REM these get nuked straight after install
SET /P AREYOUSURE=This will nuke the current site %siteUrl% and the DB %dbName%. Are you sure (Y/[N])?
IF /I "%AREYOUSURE%" NEQ "Y" GOTO END
REM SQL setup
mysql -u root -p -e "DROP USER IF EXISTS %dbName%@localhost;DROP DATABASE IF EXISTS %dbName%;CREATE USER %dbName%@localhost IDENTIFIED BY '%dbPass%';CREATE DATABASE IF NOT EXISTS %dbName%; GRANT ALL PRIVILEGES ON %dbName% . * TO %dbName%@localhost;exit;"
REM setup core
call wp core download
call wp core config --dbname=%dbName% --dbuser=%dbName% --dbpass=%dbPass%
call wp core install --url=%siteUrl% --title=%siteName% --admin_user=%adminUserDummy% --admin_password=%adminPass% --admin_email=%adminUserDummyEmail%
REM add user 2, and remove user 1
call wp user create %adminUser% %adminEmail% --role=administrator --user_pass=%adminPass%
call wp user delete 1 --yes
REM setup some defaults
call wp option update timezone_string "Australia/Melbourne"
call wp option update blogdescription %siteDesc%
call wp option update permalink_structure "/%postname%"
call wp plugin install --activate wordpress-seo
call wp plugin install --activate google-analytics-for-wordpress
call wp plugin install --activate coming-soon-maintenance-mode-from-acurax
call wp plugin install --activate query-monitor
REM install some local premium plugins
call wp plugin install --activate "E:\Projects\websites\shared\plugins\backupbuddy-126.96.36.199.zip"
call wp plugin install --activate "E:\Projects\websites\shared\plugins\gravityforms_188.8.131.52.zip"
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.