Drupal with Composer on Apache on Bash on Windows 10!
James Williams
I've recently been playing around on Windows 10's new Bash on Ubuntu feature, which provides a native bash linux shell for Windows. I thought I'd try and get a Drupal 8 site running, via composer, served from Apache, without any need for a virtual machine in Windows. Kristian Polso wrote a great tutorial that got me most of the way there, but I wanted to share some extra discoveries and thoughts about the experience.
Skip straight down to the 'Lessons learned' section below for some conclusions I've made from going through this process, if you're not interested in the fine details about how I got it working.
There is probably a better way!
Before I go any further - yes, I realise there are various fully documented, better supported ways of running Drupal on Windows, but I just wanted to go through this to see if it could be done - and if I could do it. While it all turned out to be achievable, it is not necessarily the best way, but it offers potential, especially for those of us used to working with linux or apache. So this write-up is for the benefit of others that are exploring the idea too, as it is worthwhile, but is not necessarily a recommendation! After all, Microsoft themselves have not built bash on windows to replace SQL Server, Azure, IIS, or anything like that. Those things are built (and supported) for good reason, they are not being replaced.
I didn't try running PHP-FPM in the web server stack, which I know has many advantages.
The installation
As Kristian says:
Roughly speaking, the necessary steps for this are:
- Enable Linux functionality
- Install LAMP
- Install Mysql database for Drupal
- Install Composer
- Install Drupal 8
My installation didn't go quite as smoothly as that. I had to restart after enabling Windows 10's developer mode before I could even find the 'Windows Subsystem for Linux' feature to enable. I also accidentally found myself using the linux root user, which composer (rightly) warns is best to avoid for security reasons. So when setting your linux username, it's best to avoid using 'root' and actually pick a regular username.
Windows 10's built-in web server (IIS, or 'Internet Information Services') was listening on port 80, which is the normal port for a web server, but I wanted apache to do that instead, so I disabled the 'world wide web publishing' service.
I decided to try using PHP7, which meant adding a 'PPA' (i.e. a 3rd-party repository) for it, which the internet helped me with - so run sudo add-apt-repository ppa:ondrej/php
.Update: As of Ubuntu 16.04, PHP7 is available without needing the PPA! At this point, I was in linux-land so there was no need to go searching for how to do it with windows, I could just learn from the linux community. That's a big bonus of this feature!
sudo apt-get install apache2 php7.0 libapache2-mod-php7.0 mariadb-server php7.0-mysql php7.0-cli php7.0-gd git zip
That includes a few PHP extensions, plus apache, git and zip. I needed to enable apache's mod_rewrite too, as follows (lifted directly from the documentation on drupal.org) :
For Ubuntu Server 10.04, one needs to edit the file: /etc/apache2/sites-enabled/default
If there is no such file, try this one: /etc/apache2/sites-enabled/000-defaultsudo a2enmod rewrite sudo nano /etc/apache2/sites-enabled/default
Change (line 7 and line 11), "AllowOverride None" to "AllowOverride All".
Save and exit.
Restart Apache
sudo /etc/init.d/apache2 restart
I decided to use the 'Composer template for Drupal projects' to install Drupal, which uses the Drupal Scaffold composer tool. On running it, it told me that yet more PHP extensions would be needed, which I hadn't anticipated. That may have just been the version required with drupal-scaffold, I'm not sure, but they seemed sensible to me, so install them like this -- adding whichever ones it needs (which may be different for you now compared to when I wrote this):
sudo apt-get install php-xml php7.0-mbstring
Once I'd set up my LAMP stack according to Kristian's guide, and installed composer, I was ready to actually create the composer project, which was the point at which I diverged from his guide to install Drupal differently. I ran this within a new subdirectory in apache's /var/www
directory:
composer create-project drupal-composer/drupal-project:8.x-dev . --stability dev --no-interaction --prefer-dist -vvv
This actually timed out whenever trying to download Drupal core (which the extra verbosity -vvv
parameter helped me identify), but I discovered that composer could simply resume installation by running:
composer install
Composer is smart!
I then used drush to actually install Drupal:
drush site-install --db-url='mysql://root:root@localhost/my_database_name' --site-name=Example
Once all that was done, I decided to set up vhosts in the regular way I would for apache on linux. Then I could access my site in the browser, at a development domain. It works, and just as if I was on any unix-based machine!
Lessons learned
Whilst it does work, I learnt a good few things along the way.
Performance should theoretically be better than using a VM, but I haven't done any benchmarking of any sort, so I don't actually know.
Using composer and drupal scaffold works really well, as long as you don't mind resuming a timed-out download.
Setting up apache is always a little tricky, regardless of the host system. That is a drawback of doing things this way rather than using a purpose-built tool, such as Acquia Dev Desktop.
The biggest problem for me was when I started trying to edit files in the linux file system from Windows applications (e.g. notepad). I thought that would be easier for editing settings.php
, /etc/hosts
and the vhost configuration files, than doing so from a terminal-based editor like vim
. But doing that clobbers the linux file attributes/permissions. Files edited that way can end up no longer visible in bash, and the web server doesn't recognise changes. I had to delete them from Windows and recreate them within bash.
If those files can't be edited from outside bash, that would make using an IDE or xdebug, which, in my opinion, are absolutely necessary for modern Drupal 8 development, rather trickier. (I'll accept many people disagree with the need for those!) I expect solutions can be found, like using a shared file server (e.g. Samba?), but this is a big enough step to me to feel like other ways of running Drupal on Windows are more appealing.
If I was to continue looking to get a Drupal development environment working well on Windows, I think I'd pursue trying Parrot (since that's what I use normally on my work Mac anyway), Acquia Dev Desktop, or a different vagrant/VM-based solution. I've not tried a 'normal' Windows server stack (e.g. IIS) yet either, as I'm aware there are many differences that I want to avoid having to work around. I expect each potential solution will have its own set of benefits and trade-offs.
What are your experiences of running Drupal on Windows recently? What has it been like, what would you recommend?