Categories
Development Guides Windows

The Complete Guide to Running WordPress on Windows/IIS

So you’ve discovered to your absolute horror that the WordPress site your company has inherited is running on Windows… on IIS?

Before you stand up, throw your computer chair out the Window, maliciously eat your co-workers salad and enjoy it, or drop all the production databases, relax. We’ve got you covered.

🤷 What’s the problem?

Good point. IIS (Information Internet Services) is the home-grown proprietary (for now) web server provided by Microsoft for Windows customers. IIS is fantastic at what it does, and can serve as an efficient web host as well as an absolutely golden reverse proxy server.

So what’s the problem?

🙅🏾 Support

Zilch. Nada. No dice. WordPress is absolutely not designed to be run on IIS and probably never will be. This doesn’t mean your server is going to burst into flames when you run the site, but means that when support is needed you can be damn well sure your first bit of advice will be “don’t use Windows”.

So don’t use IIS? Simple?

Except that currently NGINX is crippled on Windows (source), and Apache, which is thankfully available on Windows via unofficial channels… But you still have very little support since it operates differently being on Windows.

However, WordPress requirements state:

We recommend Apache or Nginx as the most robust and featureful server for running WordPress, but any server that supports PHP and MySQL will do.

– so don’t lose hope just yet.

⚙️ Setting up WordPress

First you will need a database. It is recommended you have the database on a different server for performance and security reasons, but you can also have MySQL running on the same server as IIS.

MySQL runs well on Windows, and is very well supported. You shouldn’t expect much push-back in the way of configuring MySQL. However, if you wish to use Microsoft SQL Server, you may wish to check out Project Nami.

Once completed, setup a database and access user like you would a Linux-based setup installation.

Also, while it’s best to always be running the latest version of Windows Server, please consider using a version no later than IIS 10 (Windows Server 2016). This is because older versions of IIS do not have support for HTTP/2. Technically speaking the minimum requirement is IIS 7 (Windows Server 2008).

🐘 PHP on Windows/IIS

Prerequisites

You will need to configure IIS to use CGI processing for IIS (which isn’t enabled on default IIS installations).

You also need the URL Rewriting module for IIS, unless you are planning on using those super ugly index.php URLs.

PHP is fully supported on Windows. To download PHP, visit their website at windows.php.net. You will also need the C++ Redist 2019 which is found on the sidebar on their website downloads.

This guide will use FastCGI, which will require a Non-thread safe version (NTS) of PHP. Typically the first download listed in each PHP version on their site will be the ideal version for IIS.

Download the correct zip file and extract it to a place of your choice on your server (Program Files is acceptable). My choice is normally C:\PHP\X.X.X (version number).

If you’re planning on running any PHP tools such as WP-CLI, it would also be a good idea to add the above path to your system Path environmental variable.

To do so, open Run (Win key + R), and run rundll32 sysdm.cpl,EditEnvironmentVariables. Append the path to Path found under System variables.

Installing WP-CLI (optional)

Now is a good time to install WordPress CLI if you’re planning on using it. They provide a fantastic guide to setting up WP-CLI on Windows.

PHP Manager IIS Plugin (recommended)

There is a plugin for IIS called PHP Manager, which is able to do most of the heavy-lifting for you in configuring PHP. This will enable you to register new PHP versions, adjust plugins, edit configurations and even split containers to different IIS versions as simply as possible via GUI.

Simply download their extension and install it on your server. When you next run IIS you will find a new PHP module on the snap-in.

You can register a parent PHP version and it will affect all children sites. If you register an alternative version on a child site, it will over-ride the parent and so on, in a hierarchical manner. Multi-version PHP, hooray a benefit!

PHP Manually (experienced)

If you opt not to go for IIS manager (not a fan of community IIS modules), then you can still go ahead configuring PHP manually to the IIS container.

  • Find your container in IIS (e.g. Default Web Site) and click it.
  • Open Handler Mappings.
  • On the right-hand side, choose ‘Add Module Mapping‘.
  • Add the following entry:
    • *.php for Request Path.
    • FastCgiModule for Module.
    • Path to your PHP CGI for Executable.
    • Whatever you want for Name.
  • Head back, and go into Default document.
  • Add index.php to the list (your choice).
  • Test in your browser if PHP loads up.
    • Try index.php file with <?php phpinfo();

If you do the above for the topmost entry (normally your machine name), it will copy to all new containers, so you don’t need to do this process for each site.

Setting up WordPress

Now for an easy part – the WordPress installation! Thankfully this is as easy to do, if not easier than the Linux server counterpart.

Create your desired site in IIS. If you’re binding this a domain or subdomain, create a new site. Otherwise, you can create a subfolder (or virtual subfolder) in IIS to setup a subfolder WordPress installation.

In the folder you bound to the container, extract the WordPress installation zip (or use WP-CLI if installed earlier). If done correctly when you visit the URL in the browser you will see the good ol’ 5 minute installation screen.

Run through the installation as per a normal site, and congratulations – you have a WordPress site running on IIS!

ℹ️ FAQ

I received an error: 500 The FastCGI Processed exited unexpectedly.

Each version of PHP for Windows depends on a Visual C++ Redist package, which is mentioned in the download title. Normally recieving this error means your system does not have the one it needs, causing the CGI process to error.

In each download segment on the downloads website, check for VCXX (X being numerical). The left-hand sidebar will tell you which redistributable package you need and how to obtain it. Once installed, this error will stop.

If – for whatever reason – you are installing the Legacy 5.6 releases, download the 32-bit redistributable, regardless of your server architecture type.

Pretty Permalinks, and .htaccess

WordPress is smart enough to know it’s on IIS, so when you go to adjust permalinks instead of creating .htaccess, they will create a web.config file, which is the IIS equivalent. If you need additional rules the IIS rewrite module can attempt to parse your htaccess file in the IIS module.

If you create a .htaccess file, it will be ignored – IIS rewrite can attempt to convert these files, but not use them.

How do I set permissions?

The container will default to using the account IUSR, which won’t have access rights by default. For starting out, you could simply give IUSR full permissions to the folder, and your website will work. Updates will occur, cache will write, all gold.

This sometimes does not work, in which an alternative you can do is change Anonymous authentication in Authentication on the container to Application Pool identity, and give IUSRS group full access.

Both of these are not recommended for production use, as in the event of a compromise the hacker will have full write access. You can check out the guide on permissions from WordPress, as the permission fundamentals are similar.

How do I enable HTTP/2?

HTTP/2 is only supported in IIS 10 or above, which requires Windows Server 2016 or higher.

Should I choose Windows over Linux for WordPress?

No. Absolutely not.

Can I hook WordPress into Microsoft SQL Server?

Project Nami is a fork of WordPress that is designed to work with Microsoft SQL Server in place of MySQL. This team has replaced all MySQL functionality and added some beneficial functionality from SQL Server. This is well worth checking out!

Categories
Development

Use Visual Studio Code in your browser, thanks to Azure

Yes, the Electron-based Visual Studio Code – an app built in HTML and JavaScript – is not usable in a web browser. What a weird world we live in.

You may sitting there in your coffee shop, staring with contempt at your weakling tablet and thinking “boy, I wish I could run Visual Studio Code on this powerful lemon”. Well Microsoft apparently listened to you and your gaping wallet. You can now use Visual Studio Code, online!

The aptly named Visual Studio Online – designed to confuse the real Visual Studio developers up and down the land – runs the full Visual Studio Code experience within your web browser. But how, you probably didn’t ask?

Visual Studio Online hooks up to a Azure cloud instance that will run a full copy of Visual Studio Code. Basically, the web version (basically a pseudo-copy) will stream all the changes back to this real copy. Woohoo, programming – Netflix style!

💸But I’m too poor to afford Azure…

Don’t worry, my financially-challenged friend. No regular human can afford Azure.

You can install Visual Studio Online plugin on a computer of choice, and use that as your streamable programming buddy. This means you can use your home PC, a virtual machine, Raspberry Pi, just about anything that can run the latest version of Visual Studio Code.

To do this, you still need a Microsoft Azure account on a minimum subscription of pay-as-you-go. You don’t have to rent out any of their expensive packages, you just need the account to link your remote VSCode setup to.

👀 First Impressions

Microsoft are keen to point out this is insider quality, and is not yet ready for production usage. This is also made obvious by the fact it is not compatible with Firefox. Likely this stems from the regular editor being built upon Electron.

I tried this out by setting up an Ubuntu Hyper-V container, installing Visual Studio Code with Online, and hooking it up to my Azure account.

As far as what I tried, it works just as I would expect the desktop version to work. Extensions all appear to be the same, project and installation settings work (I assume client settings are per-browser, as it lost mine frequently), and the terminal works really well on the existing machine.

This works really well combined with Docker and ngrok, or with a forwarded port open via the home broadband router. All my extensions were compatible, and even Intellisense kept up well despite both a struggling VM and broadband.

This currently isn’t mobile friendly, so don’t expect to do any on-the-fly miracles with your phone. However, this works a treat on tablets for those remote working moments without a primary machine.

I’m really impressed with Visual Studio Online so far, and I can categorically say this will replace my AWS Cloud9 via SSH editor that I used to use.

Any thoughts, or want me to try anything out? Please, let me know via the comments below!

Categories
Development

Chromeboard, an Experiment Killed by Security

You wouldn’t be wrong if you’ve come to the assumption that I’ve stopped supporting Chromeboard. You can see from the commit log that I haven’t made a significant change since March of last year. This was largely unintentional, but there was a main reason as to why I chose to unofficially abandon the extension – I call it ‘Issue 9 of Death‘.

This is the reason why a rough 5% of the internet websites actually work with this extension. I’ve stopped working on the plugin because simply, in the current approach it will soon become completely unsustainable.

In this general interest post, I’ll explain what SAMEORIGIN is, how it relates to browser security, why it killed my plugin and what the future for Chromeboard is.

What is SAMEORIGIN?

Let’s quickly cast back to the internet 1995-2005. Put your mental image of a phone away, because WAP was a horrific mess that nobody used. I particularly remember around ’02-04 being a hot spot for friends and family being frequently affected by online scams and such. Back then though, we weren’t aware of these as much as we are now.

A popular attack at the time was the ol’ classic, ‘YOU’VE WON A PRIZE!’ hoax. You’ve clicked it, realised it’s a hoax and left. However, the browser has used this to make a request to your banks’ website that you have an authentication cookie for, and make a payment. As far as your banks’ website cares, you made that request. This is just one example of many Cross-Site Scripting (XSS) attacks.

One approach is this SAMEORIGIN header. This lets the source server (the website you visited) specify how the content it provides is controlled. If the policy is specified to the current website, it means that attacker sites cannot use an IFrame to attack unsuspecting customers.

And that last sentence is the exact reason why the Chrome extension does not work on a majority of websites.

You’re Harvesting Our Data?!

Not at all. In fact, Chromeboard doesn’t really care what you’ve specified. However, in order to be able to switch tabs without taking full control of the web browser, it loads up all your specified cyclical tabs into one page. And the only way this can be feasibly achieved is through the use of IFrames.

If a website has a defined SAMEORIGIN policy, it will disallow Chromeboard to render it. The most common reason will be because the IFrame location is not the same URL as where the page is coming from. Ergo, the website deems the extension is trying to spoof attack you and thus blocks it.

So Chromeboard is effectively made redundant, but for a completely legitimate reason.

Chromeboard Future

For now I can confirm that the Chromeboard extension is abandoned, but the project is still ongoing. The progress has disappeared because an API is being developed to manage the websites.

My plans for Chromeboard going forward are:

  1. Chromeboard settings are definable via a stateless REST API.
  2. Chromeboard primarily becomes an Electron app (ARM focus).
  3. Chromeboard browser plugin pivots the approach.
  4. ???
  5. (Not-for) profit!

Electron being a full application instead of being just a browser allows me some flexibility in approach. I can keep the app as a Kiosk terminal, however it is able to run web instances which allows Chromeboard to be seen as a web browser instead of a spoofing client. Since wallboards mostly reside on the IoT, I will be ensuring that this works on the Raspberry Pi.

I will keep posted as things develop, but hopefully this will clear up as to why progress for the Chromeboard plugin has completely stopped.

Nutab? Oh my, that’s a completely different story.

Note: Since this article was published, Chromeboard was issued a takedown due to copyright infringement (Chrome in the name, and in the logo). It has since been rebranded as Wallboard Lite.

Categories
Development

Using PHP 7 on Ubuntu 14.04 with Codeanywhere

I am a big fan of online IDEs. For me this enables me to do web development pretty much anywhere, on any device. My particular favourites are Codeanywhere and Codenvy. While both have their pros and cons, I pretty much use Codeanywhere free for my day-to-day development. It gives you a temporary VPS for your code, easily accessible, great no-nonsense IDE and easy to use SSH access. Perfect, I simply fire up the container and get to work.

I do have a problem with it however, and it isn’t something you can fault them for – Ubuntu 14.04. I love every release of Ubuntu, but nobody should be running PHP 5.4, which has been EOL for a long while now. PHP has made some massive strides since then with PHP 7, with 7.2 being the currently latest iteration. So the first thing I do is get the container as up to date as I possibly can get it.

They do have a PHP 7 container available if you go down the CentOS route, but I personally encountered dependency issues running their version. However your milage may vary, so if you are a fan of CentOS, you don’t need to continue.

Container Creation and Update

Once you’ve logged in to Codeanywhere, it will ask you what container you want to setup (otherwise, File > New Connection > Container).  In this instance, we will select the Ubuntu 14.04 version of the PHP containers.

Screenshot of Codeanywhere container screen showing PHP options

Once finished, you’ll have your own personal VPS for your project(s). Before we do anything, we need to make sure your Ubuntu box is up-to-date. For this we need to run the commands that every Ubuntu sysadmin is familiar with:

sudo apt update && sudo apt upgrade -y

‘update’ will tell your VPS what new updates are available, and upgrade will upgrade said packages (-y stops it asking if you want to proceed, if you do want to check it before installation then remove this).

In my scenario, it asks if you want to replace some pre-existing system configuration files. You can simply press Enter and skip through these.

Once finished, you’ll have an up-to-date container. We can now move up to PHP 7.

Updating PHP 5.4 to PHP 7

The current repositories for 14.04 do not use PHP 7, supporting 5.4 as the maximum. So we need to add a new repository to do this. Now, for some reason certain system functionality from base Linux have been removed, so we need to re-add these features. Use the following command:

sudo apt install -y software-properties-common

We now need to add a repository that supports PHP 7 in 14.04. In comes Ondrej, a PPA repository that does just that!

sudo apt install -y language-pack-en-base
sudo LC_ALL=en_US.UTF-8 add-apt-repository ppa:ondrej/php
sudo apt update
sudo apt upgrade -y

Normally the LC_ALL line is not needed. However, in this repository some characters are used in the description which breaks with non-UTF8 languages. The extra command parts will make sure it uses UTF8 to process it, and go through fine.

Once all commands are run, your system will be running the latest available PHP version. However, Apache will still be using PHP 5.4. Command line PHP works great for tools such as Composer and PHPUnit, but our application will not use it until Apache knows it exists.

We need to install some additional PHP modules for Apache to recognise it, which can be done by this command:

sudo apt install php7.2 php7.2-mbstring

Add php7.2-mysql if you use MySQL, or add others for the extensions you need. Use sudo apt search php7.2 to find out what’s available)

Now we need to command Apache to ditch PHP 5 and use PHP 7.2, so run the following commands.

sudo a2dismod php5 && sudo a2enmod php7.2

Now restart Apache to make sure the changes are fully committed.

sudo service apache2 restart

Now you should be ready to develop using the latest version of PHP. With this repository, you should also receive the latest updates to PHP whenever you run the update command, so you should be good going forward!

Checking PHP Version

If you want to check which version of PHP you’re running, then you need to do it twice. PHP can often be used in command line as well as on a back-end server techonology like Apache or NGINX. It is possible for your Linux installation to use one version of PHP, and your web server application to use another.

To check your command line PHP version, simply run the following command:

php -v

To check the Apache version of PHP, create a new PHP file in the root of your workspace (say, info.php). Paste the following into the file.

<?php phpinfo();

Now browse to it in your browser (right click the container, and click run. Then, add /info.php at the end of the URL). It should give you a full dump of the server technology, with the version right at the top.

Bonus – Quick WordPress Installation

This will install WordPress to /wordpress directory of your cabox. Run this command first which will set up the brilliant WP-CLI on your container.

sudo wget https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar -O /usr/local/bin/wp && sudo chmod +x /usr/local/bin/wp

And this can be used to create our WordPress installation. Run in the workspace folder (Run cd ~/workspace if you’re unsure). Change theurlhere.com to the domain of your container, plus the /wordpress.

mysql -u root -e "CREATE DATABASE wordpress01;" && mkdir wordpress && cd wordpress && wp core download && wp config create --dbname=wordpress01 --dbuser=root && wp core install --url=theurlhere.com/wordpress --title="WordPress Development" --admin_user=admin --admin_password=password [email protected] && sudo chown www-data:www-data *

This cuts down the famous 5 minute installation to about 15 seconds. Since this is development, I’ve kept things basic with the admin password simply being password.