Back to Drupal. The LAMP stack (Linux, Apache, MySql, and PHP/Perl) prefers Linux, and most developers have their development environment on some Linux GUI such as Ubuntu. I started there, but found I was missing some things I had become accustomed to in Windows.

Fortunately, I'm not alone; others before me have gotten their Apache/MySQL/PHP stack working on Windows. They call this "WAMP" and it works quite well. I've worked with two different WAMP stacks, XAMPP and WampServer. Both use the same core packages (Apache, MySQL and PHP), but have different control panels. I prefer WampServer simply because it's easy to switch between PHP versions 5.2 and 5.3.

As far as a development environment goes, Microsoft doesn't support PHP out of the box. There has been some talk over the years, and I've even seen some snippet libraries and at least one attempt at making PHP a .NET-compatible language.

I'm not so interested in using PHP as a .NET language because the most likely eventual target for my PHP code will be a Unix-compatible server. All I want is an integrated development environment (IDE) that lets me work quickly and debug, and provides a platform for documentation.

I've explored several different tools, all of which are available on the Windows platform:

The trick is to get all of these pieces to work together, on your preferred platform, with a development environment that allows you to debug and walk through the code.

In this appendix, I'll cover the prerequisites for getting Drupal running on your Windows development box. I've been using Windows 7, so the screen shots and tools will be for that platform. Adjust for your system.

There are four parts to the LAMP stack, and we will be twiddling with the first three. First, we will replace Linux with Windows and get a system up and running with Apache web server, MySQL database, and PHP. As I mentioned before, this configuration is called WAMP and it is the most stable.

After that, we'll install the same Drupal code, but we'll replace Apache with IIS and MySQL with SQL Server.

Many tools are needed to create the WAMP stack on Windows. Fortunately, someone has already put everything together. There are a number of WAMP server collections, all with the same open source pieces: Apache HTTP Server, PHP, MySQL, and phpMyAdmin, a MySQL database administration package. Some packages also have other tools we won't be using here.

The two most popular are XAMPP and the aptly named WampServer. Choosing one is a matter of taste. I like the WampServer collection because it seems to be the easiest to add in different versions of PHP, but you can use whichever feels comfortable to you.

First, you'll want to get the WAMP stack installed and running, a pretty straightforward task. You can get WampServer from http://wampserver.com. Download and install it; it's pretty easy.

Installing WampServer is pretty straightforward. I installed the server on the root of the C: drive, just to make things easier, as shown in Figure A-1.

Figure A.1. Default location for WampServer

I'll be using this directory for all the pieces. When you're done, you'll get the happy screen indicating success (see Figure A-2).

Figure A.2. WampServer set up complete

Start the server and make sure it starts. If everything is successful, the WampServer icon will show up in your task tray (Figure A-3).

Figure A.3. The WampServer icon

Make sure the WampServer meter is green. If it is some other color, something is wrong.

The most common cause of this problem is that Apache didn't start. The most common reason for Apache not starting is that you have something else controlling port 80. The most common application that controls port 80 is Microsoft Internet Information Server (IIS).

If you encounter this problem, you can check to see who is sitting on port 80 by asking WampServer. Click on the icon to display the WampServer control panel, as shown in Figure A-4.

Figure A.4. The WampServer control panel

On the Apache submenu, you'll find a selection to "Test Port 80." (See Figure A-5.)

Figure A.5. Testing the HTTP port

This brings up a command window so you can see what is using that port, as shown in Figure A-6.

Figure A.6. IIS is using port 80.

If you want to fix this, just to go Computer Management and turn off the default web site—that is, if you have a generic site. Your mileage may vary. To turn off IIS, go to Computer Management. I usually get there by typing "iis" in the "Search programs and files" area of the Start menu. This brings up the IIS control panel. On Windows 7 it looks like the screen shown in Figure A-7.

Figure A.7. IIS in Windows 7

Here we can see that, indeed, IIS is using port 80. Clicking "Stop" should release that port so Apache can use it. It is possible to run Apache on a different port, but I don't recommend it, especially while you are learning a new environment.

Having gone through all of that, you'll see that VS.Php has its own version of Apache built in and will use a random port, much like Visual Studio does when debugging ASP.NET. But I like to have Apache controlling port 80 as well, since I sometimes access my site when Visual Studio is not debugging.

Once you have your WAMP stack running, you'll want to load Visual Studio and the VS.Php add-on, if that's the development environment you have chosen.

I use Visual Studio 2010, but VS.Php supports older versions of Visual Studio as well. Plus, there is a distribution of VS.Php that includes the free Visual Studio Shell in case you don't have a full license for Visual Studio.

Once you've installed a compatible version of Visual Studio, get the VS.Php bits from http://www.jcxsoftware.com/VS.Php and run the installer. It's probably safe to stay with the defaults for now. You should end up with the happy screen shown in Figure A-8.

Figure A.8. VS.Php happy screen

Now you can start VS.Php. This will start Visual Studio and VS.Php will then add itself to the development environment. You'll probably get the nag screen (Figure A-9) prompting for a license. You can activate it now if you have it, or just continue.

Figure A.9. The VS.Php trial version nag screen

Since you have a new language, you'll want to tell Visual Studio how to handle the source code. The settings below are compatible with Drupal's code formatting conventions. In Visual Studio, go to Tools

Figure A.10. Make sure tabs are consistent with Drupal tab rules.

Drupal's code formatting conventions require two spaces for indents, and that spaces should be used instead of the tab character. Now let's tell Visual Studio that it should know about some additional file extensions for PHP code files, as shown in Figure A-11.

Figure A.11. Adding file name extensions

Add the .info and .module extensions and press OK.

MySQL comes packaged with WampServer, which also includes a tool that lets you manage your database server. You can create and delete databases, create and query tables, and manage users and permissions. This tool is called phpMyAdminand is available from the WampServer console (see Figure A-12). I cover phpMyAdmin in detail in Chapter 4.

Figure A.12. Accessing phpMyAdmin

Clicking phpMyAdminlaunches the default browser and presents your MySQL database, as shown in Figure A-13.

Figure A.13. The phpMyAdmin screen

If you'd rather use Visual Studio to manage your database server, you can install the MySQL Connector for .NET, which is available for free at http://dev.mysql.com/downloads/connector/net. The Connector will install itself into Visual Studio and give you the same kind of functionality you're accustomed to with the Visual Studio Server Explorer. See Figure A-14.

Figure A.14. MySQL Connector for Visual Studio

At this point, you are ready to download the Drupal code and start developing. See Chapter 4 to get started. However, if you'd rather install IIS and SQL Server to replace Apache and MySQL, we'll do that in the next section.

Version 7 is the first release of Drupal that abstracts the data layer to make it easier to plug in databases other than MySQL. The database layer is based on PHP Data Objects (PDO), which allows the decoupling of database engines from the PHP core. This decoupling means a database engine vendor can write a thin layer to translate generic database calls into its engine's protocol.

The leaders of the Drupal 7 development effort have been adamant that all core modules be written to work through this data abstraction layer. Because of this commitment, a project was commenced to write the drivers for Microsoft SQL Server, which takes the form of a PHP extension, php_pdo_sqlsrv.dll. We'll be enabling that, plus some other things written specifically to get SQL Server running.

To learn more about how to program against the database abstraction layer, see Chapter 9.

While PHP has been extended to be friendlier in a Microsoft environment, Microsoft's Internet Information Server (IIS) has been extended to be a little friendlier with the open source world. With the advent of FastCGI and Windows Cache Extension for PHP (WinCache), IIS now plays nicely with PHP. So let's put it all together and see if we can get Drupal running on a WISP (Windows/IIS/SQL Server/PHP) stack.

You can get the bits you need at http://www.microsoft.com/web/drupal. Click the tab on the left that says "Install Drupal 7 with SQL Server" to see the screen shown in Figure A-15.

Figure A.15. Get the bits from Microsoft

Click the "Install" button, shown in Figure A-16.

Figure A.16. Invoking the web installer

This presents a User Account Control (UAC) warning. Click "Yes" to continue. You'll see the Microsoft Web Platform Installer as shown in Figure A-17.

Figure A.17. The Web Platform installer

You'll want to click around this installer and make sure it is set to install the following pieces:

Click Install and then review the screen shown in Figure A-18.

Figure A.18. The Web Platform confirmation screen

Accept the license terms and watch everything load. You should get the happy screen shown in Figure A-19.

Figure A.19. Web Platform Installation happy screen

That's it for the prerequisites. Now let's load the Drupal core bits. Back on the Microsoft Drupal site, click the Download button as shown on Figure A-20 to get the Drupal code.

Figure A.20. Drupal package for SQL Server

Unzip the contents of the package to your desktop or somewhere convenient. There's no need to put it in the inetpub directory structure, as there is a script that will do that for you. In fact, it should be anywhere except the inetpub directory. In the directory you choose, as shown in Figure A-21, you'll see the executable, DeployDrupalOnSqlServer.exe. Click it to start the process.

Figure A.21. Drupal distribution for IIS and SQL Server

The script calls GenericSetup.cmd, which will create a database on your SQLEXPRESS installation, add some service account rights, and then copy the Drupal modules to the IIS folder hierarchy.

The next step is to load our code into VS.Php and get it running. From Visual Studio, select File

Figure A.22. VS.Php's new project wizard

The next screen, shown in Figure A-23, lets you indicate the location of the existing code.

Figure A.23. Project location screen

This is the directory that IIS uses as its default, and the one that the setup script copied all of the Drupal bits to. Give the project a name that feels good to you and press Next to go to the project type screen shown in Figure A-24.

Figure A.24. VS.Php's Project type screen

Select Web project so the appropriate tools are incorporated into the development environment.

The wizard will scan the directory and ask which subdirectories to include in the solution. Since you're in the process of learning Drupal, it is probably best just to include everything for now. (See Figure A-25.) This will allow you to step-debug the entire core so you can see how things work.

Figure A.25. Include the directories you want to be part of the project.

That's the last step. Press Next and then Finish.

The project will load and you'll see the familiar Visual Studio environment. (See Figure A-26.) You are only a couple steps away from starting a debugging session!

Figure A.26. The Visual Studio project screen with the Drupal PHP project loaded

By default, VS.Php is configured to use its own version of Apache web server to run the code. We need to change that so that IIS will be running it. Get to the project's property pages by selecting Project

Figure A.27. Project property pages

We'll change the debugging mode to use IIS. Select "Local IIS web server" from the drop-down menu. This will start a wizard to configure IIS 7, as shown in Figure A-28.

Figure A.28. The IIS configuration wizard

We will need to create a new virtual directory, so check the Advanced Settings box and click Next to see the screen in Figure A-29.

Figure A.29. Specify the virtual directory name

Enter the name of a new virtual directory. You might already have a virtual directory named drupal; if so, you can just create another one to distinguish it. Click Next to get to the screen shown in Figure A-30.

Figure A.30. Application pool selection

When the platform installer installed FastCGI, it set up an application pool. You can specify another application pool, but it's probably best to stick with the default for now.

Clicking Next displays the review screen, as shown in Figure A-31.

Figure A.31. IIS configuration review screen

This screen shows our choices, so we can fix any mistakes we might have made. Click Next to finish the IIS configuration and display the happy screen shown in Figure A-32.

Figure A.32. IIS configuration happy screen

Now click Finish to return to the project Property Pages, as shown in Figure A-33.

Figure A.33. Project property pages showing IIS configuration

Click OK on the property pages to get back to the development environment.

So far we've installed the Drupal core code, created the database drivers, and set up IIS to be our web server. Now we need to perform the Drupal core installation using these settings. From Visual Studio, press F5 to start debugging.

Visual Studio, working with VS.Php, will open Internet Explorer and start executing the code. You should see a browser open with the Drupal installation program, as shown in Figure A-34.

Figure A.34. Drupal installation screen

At this point, we know that IIS is running and the debugger is being invoked. Select an installation profile and press"Save and continue." This will take you to the screen shown in Figure A-35.

Figure A.35. Choose a language

Your copy of Drupal might have more languages than this, so select the appropriate language and press "Save and continue." The Drupal installation code will check to make sure all of the requirements are met. You might get a screen indicating a problem, as shown in Figure A-36.

Figure A.36. A requirements problem

This particular one is easy to rectify by creating the directory and retrying the installation. You might see other requirements problems based on your installation. These must all be resolved before you can get any farther.

Once the requirements are verified, you'll get the database configuration screen shown in Figure A-37.

Figure A.37. Database configuration screen

But we can see a problem here—there's no way to select Microsoft SQL Server. That's because we need to install the drivers where PHP can see them, and then tell PHP where they are.

First, go back into IIS and select the virtual directory you created earlier. (See Figure A-38.)

Figure A.38. Managing the PHP installation

Double-click on PHP Manager, which will open in the window as shown in Figure A-39.

Figure A.39. PHP Manager in IIS

Right away, we can see that some settings are not optimal. Clicking on "View recommendations" brings up a window showing the problems and the recommended solutions. (See Figure A-40.)

Figure A.40. Configuration recommendations for PHP

Take all of the recommendations, and click OK. Next, we want to change the PHP version to use the one that the web installer installed. Back on the screen shown in A-39, click "Change PHP version" to get the screen shown in Figure A-41.

Figure A.41. Changing the PHP version

Select the PHP version that's in the PHP directory under Program Files and click OK.

Now we need to add a couple of extensions so PHP knows about our database drivers for SQL Server. Under PHP Extensions, click "Add an extension." (See Figure A-42.)

Figure A.42. Managing PHP extensions

Now enter the location of the extension, as shown in Figure A-43.

Figure A.43. Adding the SQL Server PHP extension

The installer should have placed the driver files in C:Program FilesPHPext. If they aren't there, you'll need to find them and copy them to this directory. Now repeat the process to add php_sqlsrv.dll. This is the actual driver that talks to the database.

Now we can check the configuration all at once. From the PHP Manager, click on "Check phpinfo()" as shown in Figure A-44.

Figure A.44. PHP Manager

This loads a PHP page and executes the command phpinfo(), which will dump all kinds of configuration information to the window. First, though, it will ask where it should be executed, as shown in Figure A-45.

Figure A.45. Launching phpinfo()

The results of phpinfo() will display. Scroll down the page and look for the section titled "PDO," shown in Figure A-46.

Figure A.46. The PDO section of the phpinfo() report

As we can see, the SQL Server PDO driver is loaded and PHP recognizes it.

Now return to the browser where the installation is taking place and press refresh (F5). SQL Server now shows up as a choice (Figure A-47).

Figure A.47. SQL Server appears as a choice.

We're almost done. Just give the name of the database that the script created, and the name of a user who owns the database.

If the information is correct, the installer will create and populate all of the tables while showing the progress. (See Figure A-48.)

Figure A.48. The installer throbber

Once the tables are created, it's time to provide some information about the site, as shown in Figure A-49.

Figure A.49. Basic site information

The installer writes the site information to the database and displays the installation-complete happy screen, shown in Figure A-50.

Figure A.50. Site installation happy screen

Clicking "Visit your new site" takes you to the top screen where you can start administering the site and creating content.

Drushis short for "Drupal shell." It is a PHP script that takes care of a lot of the things you'll find yourself doing often. Drush is designed to handle many administrative tasks from the command line. You could live your life as a Drupal developer without using Drush, but you could also go out back, shoot a squirrel, and then dress it and cook it in a pie for dinner. But why would you do that, when you can just buy ready-made squirrel pies from the frozen foods section of your grocery store?

And that's what Drush is. A tasty treat that is packaged for your convenience. Drush makes otherwise repetitive tasks easy and scriptable.

Many hosting providers that offer Drupal have Drush installed already. Drush calls upon several standard *nix tools, like wget, tar, and gzip. And since most Drupal hosting providers run in a *nix environment, adding Drush is simple for them.

Installing Drush

Unfortunately, the standard Windows machine doesn't have all of those tools, so you'll need to install them on yours. This is sort of a hassle, but I guarantee you, if you spend a few minutes now getting this environment set up, you'll save far more time as you start developing your Drupal applications in a Windows environment.

Here is how to get those tools loaded and running.

First, download the Drush bits at http://drupal.org/project/drush. Grab the latest version as shown in Figure A-51.

Figure A.51. Download the Drush bits.

Use your favorite unzipper to put the files in the appropriate directory. I use c:drush. We'll add that to our environment path a little later.

Now, we need to get the Drush prerequisites. These are all open source tools, and they each have Windows binaries with an installer. The download page for the first one, libarchive, is shown in Figure A-52. It is located at http://gnuwin32.sourceforge.net/packages/libarchive.htm.

Figure A.52. Download page for the open source libarchive tool

Grab whatever flavor you want. I usually just download the setup program for the complete package. Run the setup program and use the defaults. (See Figure A-53.) This will install your program, but won't make changes to the path. We'll deal with that in a moment.

Figure A.53. Setup program for the libarchive tool

You'll need a total of four GNU packages to make Drush work:

1. http://gnuwin32.sourceforge.net/packages/libarchive.htm

2. http://gnuwin32.sourceforge.net/packages/gzip.htm

3. http://gnuwin32.sourceforge.net/packages/wget.htm

4. http://gnuwin32.sourceforge.net/packages/gtar.htm

Now we need to set the PATH environment variable to include Drush, PHP, and the binaries installed above. To do this, you need to get to the Environment Variables screen, which varies depending on your OS. Right-click Computer, select Properties. Click Advanced system settings, and then Environment Variables. You will see a screen like the one shown in Figure A-54.

Figure A.54. Environment variables dialog

Under User variables, click New... You will see the Edit User Variable window, shown in Figure A-55.

Figure A.55. User variable dialog

Enter path as the Variable name and the new directories in the Variable value field. Be sure to include the path to a compatible version of PHP, since Drush will be using that. I used c:Program FilesJcx.SoftwareVS.Php2010Php 5.3;C:drush;C:Program FilesGnuWin32in, but your system might be different.

The semicolon separates the paths, which indicate where the following files are located: php.exe, drush.bat, and the tar/gzip/wget binaries.

If you have a command prompt open already, you'll need to close it and open another one for it to read the new path.

Running Drush

Now let's test to see if we were successful in installing Drush and its prerequisites. At a command prompt, change to the directory just above the modules and themes directories. Mine is C:wampwwwdrupal7sitesall.

Type drush at the command prompt. You'll get a nice long list of the wonderful things you can do, as shown in Figure A-56.

Figure A.56. The Drush help screen

Note

I have gotten a message on some machines indicating that a particular DLL is missing.

I don't know exactly why this happens, but you can download the DLL at http://www.dll-files.com/dllindex/dll-files.shtml?msvcr71.

If this works for you, you have just made your Drupal experience a lot more productive. Drush helps you do a lot of things that would otherwise require a lot of mousing around.

Drush knows where the Drupal projects are out in the 'tubes. It also knows the database location and login information by reading the settings.php file created by the installer. Because of this, it can perform administrative tasks without requiring the GUI. That means, of course, that anyone who has access to Drush and your directory structure can do the same thing. Standard security precautions are applicable.

The first useful thing you'll probably do in Drush is to use the download command, dl. The download command grabs the most recent version of a project from the directory in the projects area of drupal.org where the project is maintained Dusing wget (one of the tools you installed a few minutes ago). It then unzips and unpacks the package (again, using the tools you installed) and puts the project folder in the appropriate spot. It knows whether a particular project is a module or a theme, for example.

Downloading the Omega theme, for example, requires just a single command:

drush dl omega

Figure A-57 shows what this looks like:

Figure A.57. Downloading the Omega theme with Drush

You can also download and enable modules using Drush. Let's add a module that creates a hierarchical administration menu. The project is admin_menu, and it takes just two Drush commands to get it installed (see Figure A-58):

drush dl admin_menu
drush en admin_menu

Figure A.58. Downloading and enabling a module

Loading the site, we can see that it works, as shown in Figure A-59.

Figure A.59. The Administration menu enabled

Drush can take care of a lot of the things you do on the administration pages of your site—enabling and disabling modules, for example, or clearing caches. You can also interrogate system properties, evaluate variables, and interrogate the database. Plus, Drush has its own API, so other module developers can attach their commands to the Drush core. Brilliant!

Appendix C has a list of built-in Drush commands.

Drupal was originally designed to run under the LAMP stack. Much progress has been made in the standardization of the code to make it possible to move beyond that particular technology stack. With Drupal 7, you can now use different web servers and databases. Here, we did just that, first replacing Linux with Windows, and then replacing Apache with IIS and MySQL with Microsoft SQL Server.

I expect there will be a lot of demand for Drupal running under Windows with the WISP stack, and that a Windows-focused community will appear and champion this platform to make Drupal more popular than ever.