Installing WordPress MU on Mac OS X Leopard

I’ve run through this process a few times now, so I thought I’d document my steps for anyone who’s interested in setting up the multi-user version of WordPress on their local box for testing purposes.  The power of the multi-user version of WordPress is impressive, especially when combined with BBPress for forums, and the teetering-on-official-release BuddyPress for social aspects.  Ready to dig in?  Lets go.

The first thing you need to ensure prior to installing WordPress MU locally is that you have the underlying technologies installed.  WordPress and WordPress MU run on LAMP, or in this case MAMP.  There are all-in-one packages out there that install all three for you, and OS X does come with versions of Apache and PHP, but we want to learn how to get our hands dirty and be able to fix anything ourselves in times of crisis, right? So we need to make sure you’ve got Apache running, MySQL installed with a dedicated database setup, and PHP installed.

Turning on the Apache Web Server

First, we’ll tackle Apache.  This sentence will probably take longer to write than it will for you to turn on Apache on your Mac.  Go to System Preferences > Sharing > Web Sharing.  Checking of the “Web Sharing” checkbox here toggles the Apache server.  If you ever need to restart Apache, its as easy as coming in here, unchecking the “Web Sharing” checkbox, and checking it again.  Cake.

Installing MySQL

On to MySQL.  You’ll need to download the most recent version of MySQL, which can be found at the MySQL downloads page. Click “downloads” under the MySQL Community Server section.  Scroll down to the “Mac OS X (package format)” link and click.  Here is where you’ll have to ensure you download the proper package based on your Mac.  I chose the 10.5 (x86) since I’m running an Intel MacBook Pro, which ias the x86 processor. After you determine which package suits your Mac, click the “pick a mirror” link, and if you’ve never downloaded anything from the MySQL site before, you’ll have to register quickly.  Once you’ve registered and downloaded the dmg (named mysql-5.1.31-osx10.5-x86.dmg in my case), you’re ready to run the installer.

Once you’ve opened the dmg, you’ll see two .pkg files we’ll be interested in.  First, run the installer pkg file, which will walk you through a simple install.  After the initial install you’ll want to launch MySQLStartupItem.pkg, which will ensure that MySQL starts each time you restart your Mac. You’ve now got MySQL installed on your Mac!  Note the install location, as we’ll need that later on to create the database for WordPress MU.  Mine installed at /usr/local/mysql/bin/mysql.

Another item worth mentioning is that working with MySQL, PHP and Apache requires you to have access to a lot of OS X’s hidden files.  I recommend a great OS X app called FileXaminer, which I read about in MacWorld a while back.  FileXaminer lets you browse all the hidden files in Finder, and chmod the permissions on files and folders directly from Finder, rather than the command line.  Definitely a great solution for 10 bucks.

Installing PHP

The final piece of our MAMP stack is PHP.  PHP installation is fairly straightforward, and the best package online is located at Entropy’s PHP download page. There’s a box on this page titled “PHP 5 on Mac OS X 10.4, PPC and Intel”, and you can select the “PHP 5.2.4 for Apache 2” package.  Its definitely worth reading through this page first, but most users will have the default setup of Apache, and won’t need to make any changes prior to running the install.

After running the entropy installer, you can run a test to make sure everything went well.  Create a file titled test.php, and stick the following code in it: <?php phpinfo() ?>. Put test.php in your /Sites folder (/Users/yourusername/Sites), and then open up http://10.0.1.2/~yourusername/test.php.  The IP used in this example is found in System Preferences > Sharing > Web Sharing.

The phpinfo function is a great way to quickly check all the settings of your PHP install, so save this test file for reference in the future.

There’s one final tweak to PHP that’s really a best practice.  You’ll want to navigate to your php.ini file, and open it in your favorite text editor.  My php.ini is located at /private/etc/php.ini.  Make a duplicate of this file (sometimes the original will be called php.ini.default, so make a dup called php.ini).  Once you’ve opened the php.ini file, search for “register_globals = On”, and switch it to register_globals = Off”.  Also, search for “magic_quotes_gpc = Off” and switch it to “magic_quotes_gpc = On”.  In the php.ini file, all lines that start with a ; are commented out, so you’ll want to search for these two lines that are not commented out and then make the changes.

Save the changes in php.ini, then restart Apache in System Preferences.  Then open your test.php file again, and look for the changes to make sure they were made.

Installing WordPress MU

Finally, its time for the money melon.  Download the latest version of WordPress MU from the download page.  Unzip the package and stick it in your /Sites directory, and rename (I chose “wpmu”).  The first thing you’ll want to do before attempting to install WordPress MU is to open the README.txt file that is in the root directory of the unzipped WPMU package.  You’ll want to read this carefully and cater the specific files you your specific install case, but they basically touch upon the php.ini file that we’ve already edited, and the httpd.conf file, which is Apache’s root config file.  I found mine located at /private/etc/httpd.conf.  You can find a better understanding of the Apache httpd.conf file, the directives contained within, and an explanation of the .htaccess files you can use to override the httpd.conf file in your local sites at the Apache web site.  I found that after reading a few short pages here, that the Apache config file cascade is very similar to the cascade of CSS files and rules.  Cool stuff.

Creating a MySQL database

Once you’ve read through the README.txt and made appropriate changes to your php.ini and httpd.conf files (and taken decent notes, hopefully), you’re ready for the install.  Since you’ve already got the files unzipped in your /Sites directory, the next step of the install is creating the database. Open the Terminal application (Applications > Utilities > Terminal), and type the following command:

/usr/local/mysql/bin/mysql -u root -p

where the path matches the MySQL path I mentioned to remember earlier.  The -u root tells MySQL that you want to login as “username root”, and the -p tells MySQL to prompt you for a password. If you’ve never logged into MySQL in terminal before, the username for root will either be root or blank.  After you’ve successfully logged into MySQL, you’ll know as the command prompt will have changed to:

mysql>

To create a database, type the following command:

CREATE DATABASE wpmu;

where wpmu is the name of the database.  You can name the database whatever you’d like, but make sure to follow it with the semi-colon, and remember the name of your database.

While we’re in here, its probably a good idea to change your root username.  Type the following command:

UPDATE mysql.user SET Password=PASSWORD(“new password”) WHERE User=”root”;

Replace the new password with your desired password.  Once we’ve created the database, and updated the root MySQL user’s password (and noted both), we can exit MySQL by typing:

exit

Running the WPMU Installer

You can now open the index.php from your wpmu folder in your web browser.  It may tell you that you have to change the permissions on a few folders prior to running the install.  If this occurs, it is extremely easy to modify the permissions using FileXaminer.  The two folders you’ll have to mod are the root /wpmu folder and the /wp-content folder, changing the permissions on both from 755 to 777.  After you’ve made these changes, refresh the index.php file, and enter the proper information.

Since WPMU doesn’t allow you to install at “localhost”, and you have to use “localhost.localdomain”, I had to make a change in my hosts file as well.  The file is located in /private/etc/hosts, and I changed:

127.0.0.1 localhost

to

127.0.0.1 localhost.localdomain

and resaved the file.  Also note that I set the database location to “localhost.localdomain”.  The other information on the install screen should be pretty simple; the database name and password we just created in MySQL.  Once you’ve filled out the form, submit and you should be looking at a nice, fresh, local install of WPMU.

If you do get stuck, the WPMU Forums are a big help, as most likely users have run into your same problem. The steps above worked for me, but there may be variables with your certain configuration that you’ll need answered in the Forums.

Good luck, and happy WPMU’ing!

UPDATE 3/4/09: If you’d like to configure OS X Leopard to host multiple local WordPress instances, follow this great tutorial at O’Reilly.  I’ve spent hours piecing together solutions from various articles, but this O’Reilly article sums it up great.  Basically, I’ve now got WPMU running locally at test.wpmu.local, and WordPress running locally at test.wp.local.  Apache’s Virtual Hosts are really powerful, and essential if you’re going to be working on multiple client websites that run on WordPress.

Advertisement

Review: Web Standards Solutions by Dan Cederholm

Book review of Dan Cederholm’s Web Standards Solutions

Web Standards Solutions by Dan CederholmWeb Standards Solutions: The Markup and Style Handbook is just that: an essential guide and reference that builds upon the theory presented in Jeffrey Zeldman’s Designing with Web Standards with real-world practices.  Dan Cederholm is a designer working full-time in the field, and he presents practical and easily understood examples in a light tone.  This book is nothing less than essential for today’s working web designer.  Oh, and did I mention the 2nd edition is just around the corner, slated for release in May 2009?

Part One: Get Down with Markup

The book is split into two sections: the first reviews markup and creative methods of implementation, the second delves into CSS and solves many of the issues facing the modern CSS designer.  I’ve got over ten years of experience in the web design field, and I was simply amazed at some of the practical solutions to problems that I had faced.  Covering the essentials, from lists, headings, tables and forms, to expanding their usage through markup minimization and the application of Microformats, Web Standards Solutions contains inventive methods that are not only web standards compliant, but will save you time in your day to day projects.

One of my favorite chapters was the one covering anchors.  Countless times I’ve used semantically meaningless empty anchors to have the user jump lower in an HTML page.  This solution seems almost rudimentary, but gives meaning to my markup.  Its really almost comical how many decisions you make while coding without stopping to consider the implications when working a full-time job.  Another favorite that I put into immediate practice over at NESN.com was the chapter on tables, and the relations we can establish between data.  Taking the knowledge I took from Dan’s review of table markup, I combined it with the hCalendar chapter from my Microformats book and built the team calendars on NESN.com.  Check out the Red Sox schedule as an example.

Part Two: SimpleBits of Style

The second section of the book covers practical usage of CSS.  The one chapter I have referred to frequently is the section on building CSS layouts.  Cederholm breaks down CSS layout into four distinct methods, communicated in their most simplistic format, to ease the learning curve and also simplify the transition of using them as skeletons for your site designs.

Another technique I’ve pulled from this book is the “faux columns” created by repeating a background image vertically.  I’ve used this on just about all my sites I’ve designed since reading the book, and would recommend the investment so you can do the same.

The fact that Web Standards Solutions: The Markup and Style Handbook is an essential piece of the web designer’s arsenal is undeniable.  I have a personal connection to the book, as Dan makes reference to and uses in some of the book’s examples the Boston Red Sox, and their path to the title in 2004, when the 1st edition was originally published.  Being from the Boston area and working for NESN I definitely found the examples delightful.  Also going to Endicott college in Beverly, MA, I spent a good amount of time in Salem, where Dan’s SimpleBits studio is located.

The second edition of Web Standards Solutions is set for release in May, 2009. You can purchase Web Standards Solutions over at Amazon.com.

Rating

  • Overall: 8 out of 10

Keeping The Creative Spark

Sometimes it’s just as easy as getting out of your chair and hopping around like a weirdo.

How can we keep creativity around? Is it possible to call up at any point?

Between being a web designer at work and a musician at home. How do I balance the need to stay creative?

I believe that it is possible to be creative at any point in time, even when you feel all is lost and you cannot make one more brush stroke or hum one more tune. Here I’ll offer up a few tips on staying creative.

Score it

Add some music to change your mood. If you’re already listening to music, change the tune or listen to a different genre. One good way to go about changing your mood with music is listening to the ol’ iPod on shuffle.

Reset

The idea here is to get your mind off of whatever is distracting it. Lets get back to that quote about hopping around like a weirdo. My favorite way to get out of any negative feelings that are holding me back from my work is to get out of my chair and go for a lap around my building. I usually skip at some point on this walk. Yes, I may look like an idiot, but who really cares? It makes me laugh at myself uncontrollably. Laughing enough that by the time I get back to my desk, I’m ready to go with a clear head and clear mind.

Prime it

Figure out what gets your mind going creatively when you are at your peak and surround yourself with it. Is it a certain painting? A lucky penny? Calling a good friend for a laugh? Whatever it is, keep it around when you are working.

Don’t forget about this great article over at A List Apart titled “Staying Motivated“, which I have pinned to the wall right next to my desk at work.

Good luck!

When not to split your CSS files

I’ve read a lot of articles and a few books that detail various methods for web designers to split up their CSS files. Authors have recommended splitting your CSS files to include individual CSS files for fonts, another for colors, another for structure, and the list goes on and on. The WordPress default theme comes with a CSS file that has tons of duplicate declarations.

Reduce page load time

One issue that quickly arises if you start forking your CSS like this is the number of HTTP requests that your pages are making. Since your average browser can only make 2 HTTP requests at any given moment, the splitting of CSS files into separate files therefore can slow down load time on your pages. The same rule applies for your JavaScript files, as well as CSS background images. If you can combine all your CSS background images into one larger image map, and then position them correctly via the background property, you again reduce the number of HTTP requests per page. This and many other rules are detailed at the Yahoo Developer Network in their page on Best Practices for Speeding Up Your Web Site. This page also happens to be the basis for the YSlow Firefox plugin, so if you don’t feel like reading all the rules, just download the plugin and run an analysis on your homepage. It will tell you if you have too many HTTP requests right off the bat.

Don’t keep ’em separated

The other problem that just gets under my skin is having duplicate CSS declarations. I hate going through a CSS file to find that I have 3 different declarations for my h3 tags; one that sets the font-size, another that defines the margins and a third that sets it as an inline element. Again, I know this can’t be avioded and is even beneficial in some cases, but the majority of the time I find myself combining as many declarations as possible simply for clarity’s sake. The entire theory behind splitting your CSS files based on fonts, colors, etc. is based upon this duplication of CSS declarations, and I for one think its rubbish. The smaller our files are the better, right?

Necessary decisions

I personally like to split my CSS files out of necessity, not practicallity. Rather than loading up one main site CSS file with a bunch of Internet Explorer X-specific hacks, I would much prefer to stick them in an IE6 or IE7-only CSS file. This serves a few purposes. If you place your IE6 or IE7 style sheet references in conditional comments, like this we do on this page (check your source!), they don’t get read by smart browsers. So you’re not feeding excessive and unnecessary code to new, standards-compliant browsers. Second, it makes it really, really easy to drop support for an older browser once its no longer needed. For example, what happens when IE8 is released (we’re waiting) and we can safely remove support for IE6? First, we’re throwing a party. And not just because we don’t have to test in IE6 any more, but more because to drop support all we had to do was change one line of code rather than digging through all our CSS to find the old hacks. We may even start the party first, and then drop support for IE6 for all our sites in a total time span of 5 minutes, after having a few cocktails, just to prove once and for all how easy it is, and why this is the only reason you should ever split your CSS.

Molly Holzschlag wrote an article a while back that details the different ways you can setup your CSS files to cater to different browsers via @import and the like. Check it out at the Peachpit site.

If you’re going to split your CSS into separate files, make sure its for the right reason.