WordPress under OpenLiteSpeed & WSL

Once upon a time…

There was no easy way to get a dev environment set up under Windows that mirrored the way that your site would be served on share hosting like cPanel or SiteGround. Both use LiteSpeed, but on Windows you would be forced to use xampp or an equivalent to run a collection of Windows binaries and shared libs that gave you an Apache webserver and MySQL database environment. For the most part it worked OK, but it wasn’t a 1:1 equivalent of where your site would be ultimately served from.

In the WSL era

Now that we have a native Linux environment available under Windows, we have access to linux-native tools, libraries and practices. I’m using Docker, as it gives you any easy path to a clean preconfigured environment. Looking to set up multiple WordPress local dev instances, I started with a one-container-per-site approach, with each one a unique WordPress install with its own bind mount for customisations, all connected to a shared database container. This was OK, but not particularly flexible.

A better approach came in the form of OpenLiteSpeed. There is a very simple (perhaps a bit bare-bones) installation guide that lays out the steps needed to spin up an instance of the webserver and as many WordPress installs as you want. Similar to the mod_vhost_alias on Apache, it is one domain per subdirectory, as well as scripts to automate vhost and database creation. Also allows you to set up other non-WordPress apps / domains, under a single server. It includes various shell scripts to automate tasks like vhost and database creation, WordPress installation, and certificate issuance.

I’m using the self-signed certificate approach, which I’ve imported into Window’s root store so that my local sites can be served over https without security warnings, as the productions sites will be.

The main tweaks to the default compose file that I made were:

• added a bind mount to expose the php.ini that LiteSpeed is using, to allow changes to execution time, MAX_UPLOAD_SIZE etc. The provided instructions for this did not work for me – despite verifying the directory was mapped correctly, the ini did not load. Instead, I had to bind to the ini file itself, in order for it to be read. Unsure why.
  
      volumes:
  …
  ./php.ini:/usr/local/lsws/{lsphp85}/etc/php/{8.5}/litespeed/php.ini

  The exact target path will depend on the version of the OpenLiteSpeed in your compose file.
• Changed the restart behaviour of the container. I have found that the default behaviour of starting automatically was causing problems with the ssl certs, resulting in security errors after a restart. Re-running docker compose up -d works every time. Have not paused to debug this yet.

One thing that’s problematic with this setup is running wp-cli inside the respective sites. You can’t just execute it in a shell inside the local bind mount for the vhosts, as you will execute in the context of the local php install, and won’t be able to access the sites’ databases. Instead, you have to use docker exec to execute commands inside the LiteSpeed container context. I have simplified this with a bit of shell code.

Save it somewhere on your $PATH as wp-remote.sh, make it executable. My original version of this was a bash alias. Qwen helped me rewrite it as a script, that it could then use. You may have to tweak the user and container names to suit your local docker compose configuration.

It can be called with wp-remote {vhost-dir} {wp cli args} .

eg wp-remote highbrow.dev plugin list

This gives you a syntax very similar to the original wp .