I have recently been expanding my knowledge. PHP has been popular choice for webpages for many years now. Probably it’s one of the oldest and most mature programming tools I’ve had to use in a while. PHP webpages are well known for the LAMP stack (Linux, Apache, MySQL, and PHP). For my project, however, I am interested in setting up a WIMP stack (Windows, IIS, MySQL, and PHP… Yes it’s an unfortunate accronym…)

Sure enough, when LAMP is the status quo, then going against the grain with WIMP can sometimes feel like exploring undocumented territory. In particular I was creating a WordPress Multi-Site setup and found a small number of pitfalls and gotchas that I’d love to share with you now. We’ll see the steps for setting up a WordPress in WIMP (on a local dev environment) and we’ll pay special attention to the pot holes and speed bumps. Buckle up!

I am setting up this environment on Windows 10 therefore you might have better (or worse) success with a different Windows environment. Please let me know in the comments.

First step is to setup IIS. Now I assume you would already have IIS setup on your machine, but if not then checkout this MSDN documentation. What we need to add is the ability to create PHP App Pools in IIS. Download the Web Platform Installer and run it.

Click on the Products tab and click the Add button for the following: - PHP 7.1.1 (x64) - MySQL Windows 5.1

Pitfall #1: I specifically recommend MySQL 5.1 over 5.5. I was receiving error messages that 5.5 would not install successfully.

After you select those two products, press the Install button. The installer will prompt you for a password for the root DB user. Use whatever you’re comfortable with, but don’t use a weak password if this environment will be accessible from other machines.

Pitfall #2: Accept the resulting dialogs and you will see an “Installation Complete” message, however it’s very likely there will be an error message like so:

> We're sorry. The following products have failed to install.
> PHP Manager for IIS

The good news is, I haven’t found it to matter the least bit. So just ignore that error and let’s move on…

Now you will have your MySQL daemon running. You need to manually create your WordPress database before you can do anything with the application so let’s take an aside to set that up now. Open your PowerShell (or Command Prompt if you are not cool yet…) The proper way to run the mysql cli tool is with the following parameters:

> mysql -u root -p

This will prompt you for your password and then you can begin executing the commands. We only need to use one command here (Note the semi-colon is required):

mysql> create database wordpress;

This obviously will initialize a new database. The command to exit MySQL CLI is \q. If you are so inclined, now would be a good time to create a new user. This is how:

mysql> GRANT ALL PRIVILEGES ON wordpress.* To 'user'@'hostname' IDENTIFIED BY
 'password';

Now you are ready to download the WordPress source code. Click here to get the latest download link. Extract the archive to a folder you want as the root for your website.

Now we are ready to create the new site in IIS. Open IIS and first thing is to add a new Application Pool. Right Click Application Pools and click Add Application Pool. Give it a cool name like “WordPress” and select “No Managed Code” for the .NET CLR version. A PHP is not going to user any managed .NET code. Press OK to close the dialog.

Next, we can create the new site. Right click on Sites and click Add Website.... I like to call my “Site name” the same as the “Application Pool”. Click the elipsis beside the “Physical path” field and choose the directory you extracted the WordPress source to. I recommend in a shared dev environment to use a “Specific User” that is shared between devs, under Connect as... dialog, but if this is for your eyes only, then don’t bother.

Pitfall #3: If you are planning on doing a WordPress Multi-Site setup like I was, then you actually are required to use port 80. You can use an Application of an existing site, but then WordPress will only allow you to do sub-directory domains. If you plan on giving each of your children sites a different domain, then you need to create the new site, with port 80, just like I have described.

There is one last thing to do in IIS here. With the “WordPress” site selected, double-click the Default Document configurator. Some installations of IIS will only have one or two files here, such as “default.aspx” or the like. What we want is index.php so add it if it doesn’t already exist. Pitfall #4: If it does exist, you’ll see an alert:

“The file ‘index.php’ exists in the current directory. It is recommended that you move this file to the top of the list to imporove performance.”

Here’s a better idea! Remove all the default documents other than index.php. You won’t need them!

When your new IIS site is running, you can go to the fun part! Browse to http://localhost/ in your browser and begin the “Famous five-minute installation”.

When it asks for your database connection details, you should know the drill. The first MySQL command above made a new database called “wordpress” so that is the Database Name you use now. The Username you supply is “root”. To be fair, the Web Platform Installer never actually asked you to choose that, so it’s ok if you forgot. The Password was whatever you used to login to the MySQL daemon earlier. The Database Host should be localhost in this case. Only change this if the DB is on a different machine from the webserver. Note, if you were actually setting up a non-localhost environment, you still use “localhost” in this field. It’s the host that WordPress will use to find the DB, so it’s relative to the server, not the client, capiche? Last but not least it is recommended to change the Table Prefix for security reasons. Even though this is your localhost environment, you might want to update this part now so that it’s one less step if you might have to migrate the DB in the future. Sensible values would be the acronym of your product name or company. Or the top secret codename for your project. It’s ok, I won’t tell.

Submit the form and hopefully you see a page that has a Run the install button. If you see something else, follow the directions and go back and fix anything that may be amiss.

Now you should find yourself to the welcome page. This form is self-explanatory. Just create a title, username, password, and put your email. The Search Engine Visibility field won’t have an effect on a non-production environment, but feel free to set it now with the confident that you can change the value through the CMS at anytime later. Submit the form and you will see the “Success!” page.

Pitfall #5: I probably should have mentioned this earlier, but if you were planning on using an alias other than localhost you should do it before the installation process. WordPress will take the domain name and consider that as the only valid domain that can login afterwords. Changing it after the fact can be a bit of a pain. WordPress also doesn’t give any kind of error message when you are attempting to login with the wrong alias as the domain. Yes, even if they are resolving to the same IP it won’t work. It just redirects you back to the Login screen.

Hopefully you are logged in now. This is the CMS, if you haven’t seen it before. However, it is not yet the Multi-site CMS. We still have a few more configurations to take care of, but we’re almost done.

Go to the web root folder of your WordPress installation and open the file called wp-config.php. Scroll down enough and you will see a block comment like so:

/* That's all, stop editing! Happy blogging. */

Immediately above this line, put the following line of code and save the file:

define( 'WP_ALLOW_MULTISITE', true );

With that in place, you can refresh the CMS page and there will be a new feature… Can you find it? Just kidding it’s hiding pretty good so I’ll tell you. Click on Tools > Network Setup to see the new config page we just enabled. If you like the Network Title then go ahead and press the Install button. The page will reload and you will see a couple of code snippets. This is were it gets interesting…

First, do the first step that it tells you. Copy the PHP lines of code and paste it again into the wp-config.php below the last edit you made.

Pitfall #6: The weird part is that the second step is inadequate for general cases. What you should see in step 2 is the contents of a web.config file. There unfortunately is a bug in the rewrite rules preventing users from logging in properly, on all environments including localhost, under the WordPress and IIS configuration that I’ve told you. Never fear, because I have the preferred web.config right here for you to use:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <rewrite>
            <rules>
                <rule name="WordPress Rule 1" stopProcessing="true">
                    <match url="^index\.php$" ignoreCase="false" />
                    <action type="None" />
                </rule>
                <rule name="WordPress Rule 2" stopProcessing="true">
                    <match url="^([_0-9a-zA-Z-]+/)?files/(.+)" ignoreCase="false" />
                    <action type="Rewrite" url="wp-includes/ms-files.php?file={R:2}" appendQueryString="false" />
                </rule>
                <rule name="WordPress Rule 3" stopProcessing="true">
                    <match url="^([_0-9a-zA-Z-]+/)?wp-admin$" ignoreCase="false" />
                    <action type="Redirect" url="{R:1}wp-admin/" redirectType="Permanent" />
                </rule>
                <rule name="WordPress Rule 4" stopProcessing="true">
                    <match url="^" ignoreCase="false" />
                    <conditions logicalGrouping="MatchAny">
                        <add input="{REQUEST_FILENAME}" matchType="IsFile" ignoreCase="false" />
                        <add input="{REQUEST_FILENAME}" matchType="IsDirectory" ignoreCase="false" />
                    </conditions>
                    <action type="None" />
                </rule>
                <rule name="WordPress Rule 5" stopProcessing="true">
                    <match url="^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*)" ignoreCase="false" />
                    <action type="Rewrite" url="{R:2}" />
                </rule>
                <rule name="WordPress Rule 6" stopProcessing="true">
                    <match url="^([_0-9a-zA-Z-]+/)?(.*\.php)$" ignoreCase="false" />
                    <action type="Rewrite" url="{R:2}" />
                </rule>
                <rule name="WordPress Rule 7" stopProcessing="true">
                    <match url="." ignoreCase="false" />
                    <action type="Rewrite" url="index.php" />
                </rule>
            </rules>
        </rewrite>
    </system.webServer>
</configuration>

Go ahead and put the web.config in your root directory, beside the wp-config.php file. Note, I recommend to use this improved web.config file for all IIS installations of WordPress. The original config tries to make a best guess at what kind of environment and setup you are running and to be fair it works most of the time. However the one I linked to above is superior. Shout out to user misaxi for posting this web.config on his GitHub Gist.

Finally, the only remaining thing to do is log out of the CMS and then log back in. Enjoy your WordPress Multi-site and “Happy Blogging!” If you have any questions, feel free to leave a message in the comments below.

The Paper I Love

I recently presented a talk at the Papers We Love - Winnipeg Chapter meetup. The paper which was the subject of my presentation (and the subject of my affections) was Why Functional Programming Matters, by John Hughes. If that name sounds familiar, hopefully you are not thinking about the prolific film writer and director from the 80’s and 90’s. The former is well known for such cult classics as “Ferris Bueller’s Day Off” and “The Breakfast Club”. The latter is well known for his functional programming street cred.

Professor John Hughes, whose writing I love, is the progenitor and developer of such well known hits as Haskell and QuickCheck. His paper, also written in the 80’s, emphasizes that modularity is the major source of power that puts functional programming ahead of its procedural counterparts, most notably Object Oriented Programming languages. The modularity is exmplarized through use of two new “Functional Glues” that Hughes defines as Higher-order functions and Lazy-evaluation.

Excellent Programming Languages

One of the slides I presented, gave a terse sampling of the functional programming languages I consider worth your while as a modern day developer. I listed four languages, requiring to limit my selection for brevity:

1. Haskell
2. Clojure
3. Elixir
4. F#

All four of these languages share certain qualities and features and this correlation is not a coincidence. Afterall, John Hughes tells us at least two of the features we want are Higher-order Functions and Lazy-Evaluation, which unsurprisingly each of these languages support wholeheartedly. It’s also true that there are other excellent functional language features supported by all four of these choices. For example, pattern matching, partial evaluation, immutability, and referential transparency all stand out in my mind. There are also notable differences between these four languages. Haskell and F# will be the languages you choose if you want to get your hands dirty with category theory constructs such as functors and monoids. Conversely, Clojure and Elixir’s type systems are dynamic. Elixir is an excellent choice for concurrency due to Erlang’s amazing OTP which it integrates with seamlessly. Clojure’s emphasis on “code-as-data” I find well suited for the functional paradigm.

After letting this slide sink in, I noticed a correlation that you may find interesting. The order of languages on the slide represents the priority I would recommend as being best to learn. The surprising bit is the reverse order would be my recommended priority when deciding what languages to use in production.

Am I contradicting myself? Would I waste your time by telling you to learn one language but then turnaround and devalue it as non-practical? Actually, everything is alright and this will all make perfect sense (bear with me!) I believe both points of view are valuable and complementary; not contradictory. Allow me to explain…

The Explanation

What it boils down to is the following argument.

The value of learning a language is not simply being able to use that language in production code.

Namely, the student learning a particular language can enjoy the following benefits:

1. understanding the core principles of the paradigm
2. knowing where the core ideas come from

In this list, Haskell is the de facto grandfather of the other languages. Therefore, if you want to learn the origins of functional programming, that is the place to start. Likewise, learning Haskell is learning the fundamentals of the paradigm because the gap between language and principles is reduced. Finally, Haskell is a pure functional language, implying there aren’t any non-functional features. Therefore, you won’t lose focus by being distracted away from the functional oriented constructs.

The languages going down the list add incremental amounts of non-pure abstractions. We generally refer to these as “pragmatic” features. F# is at the opposite end of the spectrum. It supports the full weight of OOP and FP, and runs on the .NET CLR. It bears noting that, in my books, Elixir and Clojure are nearly tied in this respect. I really could have listed them the other way around and made the same arguments here.

A Different Point Of View

Next up, let’s look at the languages in the reverse order. I am now recommending the languages in decreasing order of. Here are the criteria I’m using to evaluate the relative ordering:

1. Community adoption
2. Recent growth

To be fair, F#, Clojure, and Elixir all are actively being expanded within their resepective communities. Haskell is a bit older and was established a long time ago but there just aren’t that many jobs available locally in the Haskell space. However, when it comes to community adoption, at least in the prairies, F# is the most common choice for functional language. Many local businesses are seeing more and more adoption of F#. This is evidenced by the fact that our user groups and developer conferences have had more F# talks in the last year than any functional language talks combined.

Conclusion

I love functional languages and the four I’ve listed are all excellent. Haskell, Clojure, Elixir, and F# are all excellent languages that are ready for you to learn and use in production (albeit with different considerations for each). If you want to go far, learn Haskell first. If you want to go fast, learn F# first. My favorite language is Clojure! Really, you can’t go wrong if you choose one and stick with it.

I am loving React and I want you to give it a try too.

There was an initial hurdle I had to overcome before I could proficiently work with – and not against – React. There was the not-so-small detail of setting up Vim, my code editor of choice. I explored many paths and followed advice from a few different sources, but unfortunately there were a few duds. It’s understandable considering the JavaScript landscape can change so frequently these days.

I have good news for you! I’ll tell you the successful path I’ve found for getting React setup in Vim. We will setup two main features:

- Linting via the Syntastic plugin, leveraging ESLint
- JSX syntax highlighting via the vim-jsx plugin.

Let’s begin.

Step 1 - Install Syntastic

There is actually a pretty good chance if you’re reading this then you already have Syntastic installed. Go ahead and skip to Step 2 then. Otherwise, read on. Syntastic is a syntax checker for Vim. Any code you have open in Vim can be checked for errors when you save your source file. Better yet, many languages are not just supported for syntax, they are also supported for checking compile time errors and static analysis. Essentially, if you’re used to seeing red squigglies in your commercial, name-brand IDEs, then this is the plugin that enables the same behavior. Installing it is easy if you have Pathogen or Vundle already setup. For your reference, the complete instructions to install with Pathogen are here, but the steps are really quite simple to follow along below.

If you don’t have Pathogen or Vundle, I’ll recommend you to use Pathogen. Please note that Pathogen and Vundle are very different tools and it’s completely normal and useful to have both. For installing plugins however, either one is capable of assisting you throughout this guide.

First, cd into your bundle path, like so.

$ cd ~/.vim/bundle

And initiate a git clone to pull down the syntastic repository and files.

$ git clone --depth=1 https://github.com/vim-syntastic/syntastic.git

Don’t forget to generate the help tags by typing this command in Vim:

:Helptags

This Vim command effectively installs the features you’ve recently downloaded via Pathogen. When that is complete, you can then move onto Step 2 to install the ESLint and React plugins for Syntastic to use.

Step 2 - Install ESLint

Note: The following projects are deprecated so you DO NOT want to use them. I kept finding articles and repos referencing these which were a major source of confusion in this step.

1. -- DO NOT INSTALL -- JSXHint - https://github.com/strml/jsxhint
2. -- DO NOT INSTALL -- syntastic-react - https://github.com/jaxbot/syntastic-react

The linter is what let’s Syntastic identify compiler issues and highlights additional potential concerns the compiler might not identify. Syntastic doesn’t know the latest EcmaScript features by default, let alone React’s JSX syntax that enables the inline XML syntactic sugar. That’s why we have to install two libraries that will be leveraged by Syntastic. Note, these are now NodeJS packages, not Vim plugins, so you will use the npm command instead of Vim’s Pathogen or Vundle to install the software throughout this step.

The key here is that you want Vim to have linting enabled for any and all of your React projects. Therefore, you want to globally install these packages. If you also want your build scripts for a specific project to be able to lint your source, say during a CI build, that’s fine. You will then want to locally install the packages for that too. If you’re googling and reading online and are not sure whether you want global or local installation methods, then that is the difference here. Globally is what Vim needs, locally is what your build agent needs. You can have both.

All that being said, let’s first install eslint.

$ sudo npm -g install eslint

That should install just fine. At the time of this writing, it will be version 3.16.0. (Note: version 1.x.x has different options for the configurations, so always check the version you are installing here).

Now, globally install eslint-plugin-react.

$ sudo npm -g install eslint-plugin-react

Note: on macOS this gives me a Peer Dependency Unmet error message. In my experiences, this is a fatal error that shouldn’t be ignored. However, apparently it’s a “false” warning this time and the recommendation is to ignore it. I don’t like it either.

Next, you have to configure the linter manually, by setting up a .eslintrc file. Don’t worry, I have one all ready for you to use. These rules were used by jaxbot at his blog here so send praise his way.

Put the following JSON into ~/.eslintrc (Note, this is in your home directory because we are configuring the global install).

{
    "parser": "eslint",
    "env": {
        "browser": true,
        "node": true
    },
    "settings": {
        "ecmascript": 6,
        "jsx": true
    },
    "plugins": [
        "react"
    ],
    "rules": {
        "strict": 0,
        "quotes": 0,
        "no-unused-vars": 0,
        "camelcase": 0,
        "no-underscore-dangle": 0
    }
}

Optionally, you can also globally install babel-eslint if you are using edge features of Babel. At the time of this writing, those would specifically be class properties, decorators, and types. ESLint supports ES6 through 8 and JSX by default. If you do use babel-eslint, you will have to replace the line "parser": "eslint" to "parser": "babel-eslint". Check the official github repo here for more info.

There is one more step that you need to do. Vim, or specifically Syntastic, won’t know to use the npm ESLint package yet. In order to set that up, it’s one easy line that goes anywhere into your ~/.vimrc file.

let g:syntastic_javascript_checkers = ['eslint']

Now you can exit and re-open Vim to “re-source” the .vimrc file. Better yet, here is a trick. You can re-source .vimrc by the following command in Vim, without having to leave the editor.

:so ~/.vimrc

That is it for Step 2. You will now have ESLint properly complaining when your .js or .jsx files are hopelessly inadequate. Remember, you can configure the rules at anytime in the ~/.eslintrc file. The documentation for that is here.

Step 3 - Install vim-jsx

We have linting executing on filesave now. This is great, but everybody I know loves their editor’s colour theme. Black and white is just not going to cut it and heaven help you if you use a high-contrast theme these days, but I digress. This step should seem comparatively easy now that you are an expert at installing Vim plugins. I’ll show you the commands for installation using Pathogen again, but feel free to use Vundle if your muse compels you.

What we want from this step ultimately is vim-jsx. However there is a dependency on vim-javascript, so let’s get that to begin with.

First you need to cd into your bundle path.

$ cd ~/.vim/bundle

Then simply git clone the repository into your bundles like so.

$ git clone https://github.com/pangloss/vim-javascript.git

You could do the :Helptags now, but let’s just sneak in one more package - the much anticipated vim-jsx.

$ git clone https://github.com/mxw/vim-jsx.git

Now, I give you permission to go to town on the helptags. In Vim, type the following command.

:Helptags

That should configure any .jsx files to show up with pretty colours. That is wonderful, but there is a catch! Many React applications use .js as the de facto file extension now, even if it is JSX syntax. This is ok, because I have the solution.

Please insert the following line anywhere into your ~/.vimrc file.

let g:jsx_ext_required = 0

Don’t forget to use that neat trick I showed you.

:so ~/.vimrc

That should cover all your bases. You will now have syntax highlighting and linting enabled in Vim for React projects. Please ask me any questions. I’m always happy to help.