Perishable Press

Set Up WordPress MultiSite on MAMP

Jeff Starr — Sun, 10 Mar 2013 03:00:58 +0000

In this tutorial, you’ll learn how to install and run WordPress MultiSite on a MAMP webserver. Running multiple sites from a single installation simplifies and streamlines administration, and serving it all from a locally installed version of MAMP gives you everything you need to develop your network of sites for the Web.

WordPress enables you to create multiple websites from a single installation, requiring only one database and one set of files for thousands or even millions of sites. But it does require some tweaking and experimenting to really get the hang of WordPress MultiSite, so doing it on a live server may not be for everyone. Fortunately MAMP enables you to set up your very own local server environment in a matter of seconds on your Mac OS X machine. This is perfect for setting up WP MultiSite and developing your sites safely and securely behind the scenes.

Requirements

Knowledge needed: WordPress, familiarity with Apache, MySQL, PHP
Requires: WordPress, MAMP, Mac OS X (version 10.4.0 or later)
Project time: 1 – 2 hours

If you’re not a Mac, check out these _AMP alternatives for setting up WordPress locally.

Getting Started

To set up your own local server environment with MAMP, visit their website and download the free version to follow along with this tutorial, or grab the Pro version for greater functionality and flexibility. Then of course you’ll also need the latest version of WordPress, which is currently at 3.5.1. You can grab the latest from WordPress.org/download. Note that MAMP requires that your Mac is running Mac OS X 10.4.x or better.

Once you’ve downloaded MAMP and WordPress, you’re all set for the tutorial, which guides you step-by-step through the process of installing and configuring MAMP and WordPress for local testing and development. Upon completion, you’ll have a robust, flexible, and secure platform for developing your own network of sites.

Overview – What, How, and Why

Before diving in, it’s important to have a solid understanding of how everything works, sort of like seeing the “big picture” of what’s happening. The first thing we’re doing is installing and configuring MAMP, which stands for Mac, Apache, MySQL, and PHP, and basically provides you with a fully functional server environment on your Mac computer. So instead of trying to do it “gorilla-style” and develop multiple WordPress sites on a live server, MAMP enables you to build and test everything from the safety and comfort of your local machine.

Then after setting up MAMP, you’re ready to roll tough with WP MultiSite, which gives you the power and flexibility to build and operate multiple sites from a single installation of WordPress. Setting up WP MultiSite requires a little more configuring than regular, single-site WordPress, and so getting everything working on a local server environment like MAMP is a smart way to maintain control over the entire process.

That said, let’s start by installing and configuring MAMP, and then move on to setting up WordPress MultiSite. Along the way, we’ll provide some additional tips and tricks to help you get the most out of the experience.

Setting up MAMP

In the first part of the tutorial, we’ll install and configure MAMP on your local Mac machine. Once MAMP is set up and working properly, you’ll have a robust, flexible platform on which to develop and test anything that requires Apache, MySQL, and PHP. This alone is a powerful tool to have in your belt, and in the second part of the tutorial, you’ll learn how to set up WordPress MultiSite for virtually endless site-building possibilities.

Step 1: Installing MAMP

Once you’ve downloaded the latest version of MAMP, double-click the disk image and drag “MAMP” (not “MAMP PRO”) to your Applications folder. Note that you’ll need administrator permissions to install the MAMP software.

After installation, all of your MAMP files will be available in the Applications/MAMP directory. To facilitate expediency, you may want to create a shortcut to the MAMP directory and/or the MAMP.app application file.

MAMP also provides a handy Dashboard widget for direct control over your MAMP servers. To install the MAMP widget, copy the file Mamp Control.wdgt from the MAMP directory to the Widgets directory located at ~/Library/Widgets. The widget should work immediately when viewing your dashboard (see screenshot), but if it doesn’t you may need to reboot and/or double-click the widget file directly from the Widgets directory.

Step 2: Configuring MAMP

Once MAMP is installed, run the program by clicking the “MAMP.app” icon from the ~/Library/Widgets directory. As MAMP opens, you’ll be asked “Do you want the application mysqld to accept incoming network connections?” Yes, you do want that, so click the “Allow” button to proceed.

Next, MAMP will open a browser window and go to the default Start page, located at http://localhost:8888/MAMP/. As seen in the screenshot, the MAMP Start page contains a variety of resources, including a link to phpMyAdmin and your database connection parameters. Along the top of the page, you’ll find tabs for phpMyAdmin, XCache, and other major components. To create a local server environment, MAMP includes over 20 different programs, including eAccelerator, Zend Optimizer, Freetype, and many more. To see a complete list, visit the “FAQ” tab from the Start page.

In addition to the Start page, the application panel should also be visible after starting MAMP. As seen in the screenshot, the MAMP control panel enables you to Start/Stop the servers, Open the Start page, and set your Preferences. Clicking on the “Preferences” button brings up an options panel that provides some basic server settings. Let’s go through each of these settings and optimize our MAMP configuration for WordPress.

First, click on the “Start/Stop” button and check all of the options, as seen in the screenshot. Also notice that we can set an alternate URL for the MAMP Start page if desired.

Next we want to change the server ports from MAMP defaults (8888 and 8889) to Apache and MySQL defaults. To do this, click the button that says “Set to default Apache and MySQL ports”. This will set the Apache port to 80 and the MySQL port to 3306, which are both standard web-server port numbers.

Lastly, click on the “PHP” button and review the default settings, and then do the same for the Apache settings. For WordPress, the default settings for both of these options panels are going to work fine, so there is no need to change anything for this tutorial. Just know that they’re there, so if later on you decide to change something, you know where to do so.

Step 3: See it working

So MAMP is installed, and you can check functionality by creating a simple index.html file and adding something like

`Hello World`

. Then put the file in MAMP’s /htdocs/ directory. Then open a browser tab to http://localhost/ to get a basic idea of how MAMP is working. The /htdocs/ folder is like the root directory of your local site, and its URL is http://localhost/. We now have all we need to set up WordPress MultiSite.

Setting up WordPress MultiSite

With MAMP installed, configured, and ready to go, it’s time to install WordPress and set up MultiSite. WordPress provides a powerful, flexible framework for building websites, and with its MultiSite functionality, a single installation of the software enables you to create an unlimited number of websites using a single database and one set of files. It’s really powerful stuff, so learn more and get it for free at WordPress.org.

Step 1: Installing WordPress on MAMP

After downloading the latest version of WordPress, unzip the contents and move them to MAMP’s /htdocs/ folder. After the files have been moved, locate the wp-config-sample.php file in the root directory (htdocs), and rename it to wp-config.php. Then open the file and enter the following database connection settings:

/** The name of the database */
define('DB_NAME', 'wordpress');

/** MySQL database username */
define('DB_USER', 'root');

/** MySQL database password */
define('DB_PASSWORD', 'root');

/** MySQL hostname */
define('DB_HOST', 'localhost');

Once you get the database credentials dialed in, save the file and navigate to the MAMP Home Page in your browser. Click on the “phpMyAdmin” tab (near top of page) to open phpMyAdmin, which is basically an user-interface for the MySQL database. On the first page that appears in phpMyAdmin, there’s a field for creating a new database (see screenshot). Using the default settings, simply type “wordpress” in the “Create new database” field and click the “Create” button to create the database.

After the database is created, open a new browser tab to the WordPress installation page at http://localhost/wp-admin/install.php. Here you will specify a Site Title, Username, Password, and Email address. After filling them in, click the “Install WordPress” button to install WordPress.

At this point, WordPress is installed and you should see the “Success!” message appear on the page. You’re now ready to set up MultiSite and begin your local website development on MAMP. Click on the “Log In” button to log into WordPress to get started with MultiSite.

Step 2: Setting up MultiSite

With MAMP and WordPress installed, it’s time to set up MultiSite, which enables you to create an entire network of sites. As we go, keep in mind that MultiSite is powerful stuff, and there are a LOT of settings and functionality involved. A complete guide to WP MultiSite is beyond the scope of this tutorial, but you can find all the gory details at the official Create a Network page in the Codex. In this part of the tutorial, we cover the basic requirements for setting up and running WordPress MultiSite locally on MAMP.

Begin the set up process by opening your site’s wp-config.php file from the /htdocs/ directory. Here we will define the MultiSite parameters near the bottom of the file. Just above where it says, “That’s all, stop editing! Happy blogging”, add the following line:

define('WP_ALLOW_MULTISITE', true);

With that code in place, visit the WordPress Admin and click on the newly added “Tools > Network” item. On the “Create a Network of WordPress Sites” page, check that everything is filled in correctly and then click the “Install” button to create your network of sites.

Note: In this tutorial, sub-directories are required for sites added to the network. To use subdomains instead, refer to this guide: WordPress MultiSite Subdomains on MAMP.

After clicking the “Install” button, the Network page will display the remaining steps required to complete MultiSite installation. For the sake of completeness, we’ll go through each of these steps and explain a little further about the purpose of each.

First create a directory named blogs.dir in your /wp-content/ folder, such that its path looks like /htdocs/wp-content/blogs.dir/. The blogs.dir folder is where WordPress stores uploaded media for your network of sites. This directory must be writeable by the web server.

Next open your wp-config.php file from the root directory, locate the line that says define('WP_ALLOW_MULTISITE',true);, and place the following code beneath it:

define('MULTISITE', true);
define('SUBDOMAIN_INSTALL', false);
$base = '/';
define('DOMAIN_CURRENT_SITE', 'localhost');
define('PATH_CURRENT_SITE', '/');
define('SITE_ID_CURRENT_SITE', 1);
define('BLOG_ID_CURRENT_SITE', 1);

These definitions are automatically generated and required for MultiSite to work. Note that a certain amount of customization is possible by tweaking these definitions, should you decide to experiment later on.

Lastly, create a blank file named .htaccess in your /htdocs/ directory and add the following code:

RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]

# uploaded files
RewriteRule ^([_0-9a-zA-Z-]+/)?files/(.+) wp-includes/ms-files.php?file=$2 [L]

# add a trailing slash to /wp-admin
RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L]

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule  ^[_0-9a-zA-Z-]+/(wp-(content|admin|includes).*) $1 [L]
RewriteRule  ^[_0-9a-zA-Z-]+/(.*\.php)$ $1 [L]
RewriteRule . index.php [L]

If somehow you find any existing WordPress rules in your root .htaccess file, replace them with this code (see this post for more details).

Upon completion of these three steps, WordPress MultiSite is enabled and configured. Returning to the Admin Area in the browser, WordPress will require you to log in again. After doing so, click on the new “Network Admin” link in the upper-right corner of the screen to create, configure, and manage your Network of sites.

Next Steps..

WordPress MultiSite opens the door to endless possibilities, and there’s a LOT of cool features and functionality that you should explore by simply navigating through the Network Admin area. To create and add a new site to your Network, click on “Sites > Add New” menu item and fill in the blanks. To view and manage individual sites, click on the “Sites > Sites” menu and hover over any site on the list. As you hover, a variety of options will appear, enabling you to Edit, Deactivate, Archive, Spam, Delete, Visit the site, or go to its Dashboard.

As you develop locally, don’t forget to keep backups of your work. Using a Mac, you’re probably covered using Time Machine or similar, but if you ever just want to grab a complete backup of your entire local server, it’s easily done with a quick copy of your /Applications/MAMP directory.

Conclusion

In this tutorial, we’ve seen how to set up WordPress MultiSite locally on MAMP. Following the steps in this guide, you can create a powerful, flexible developing platform and host all of your sites with a single installation of WordPress.

Note: This article appears originally in .net Magazine #220. Minor edits have been made concerning software versions and other details.

WP-Mix – A fresh mix of code snippets and tutorials

Jeff Starr — Mon, 21 Jan 2013 22:17:42 +0000

Wrapping up 2012, I finally launched xyCSS.com, which is all about responsive, grid-based design. To showcase xy.css, I used it to design WP-Mix.com, which also serves to house a growing collection of choice code snippets. Currently WP-Mix features over 100 snippets, tutorials, and other useful bits to help with WordPress development and web design in general. The topics are similar to those at Perishable Press (e.g., WordPress, PHP, JavaScript, CSS, etc.), but the posts are less-involved and aimed at intermediate to advanced developers.

About the site

As mentioned, WP-Mix.com is focused on two things: showcasing responsive, grid-based design, and sharing as many juicy code snippets and design techniques as possible. While visiting the site, you can see the liquid grid in action by clicking the “show matrix” button at the top of the page.

Default UX view — click the “show matrix” button to view the liquid grid.

xy-grid view — click the “hide matrix” button to return to default UX view.

Details

Here are some interesting tidbits about the site:

WP-Mix.com is built with WordPress and xy.css. Everything is kept as clean and minimal as possible, with only a handful of required plugins:

Crayon Syntax Highlighter — syntax highlighting*
Simple Feed Stats — easy feed stats (without Feedburner)
Simple Basic Contact Form — clean, simple contact form
Simple Local Avatars — custom local avatars
WordPress Database Backup — quick and easy database backups

Here are a few more notable moves to further streamline WP-Mix for better SEO, usability, and maintainability:

Comments are disabled — this greatly simplifies everything
Tag and author archives are disabled — focuses activity on content pages
Clean search URLs — replaced query-string with permalink style URLs
Clear navigation — hyperlinks are underlined, perpetual post navigation, etc.
Distraction-free — everything is focused on the content
Built with xy.css — for responsive, liquid-grid design

* Note about the Crayon plugin: it produces some great looking code, but requires way too many HTTP requests to do the job. The plugin makes 15 HTTP requests for syntax highlighting (even on the home page where it’s not needed).

Screenshots

Here are some representative screenshots for WP-Mix:

Squeaky clean, content-focused design

Syntax-highlighting for all code snippets

Streamlined toolbar contains only the essentials

Plans

Going forward, I’ll be posting as many useful/interesting code snippets as possible. I think it’s much better to share snippets than to let them whither in the archives. Plus, posting and organizing the content online makes them available from any location, which is nice when I’m working out of the office.

Other plans for the site include possibly opening it up to registration and user-submitted posts, so that other enthusiasts can share their snippets as well.

So that’s it for now, I hope you enjoy the new site, responsive grid design, and all the code snippets. If you enjoy the site, you can grab the feed for free updates delivered fresh. Tweets also appreciated :)

New Site: xyCSS.com – Responsive Grid Design

Jeff Starr — Thu, 17 Jan 2013 01:41:34 +0000

For the past year or so, I’ve been heavy into responsive, grid-based design. In December, I “soft-launched” my new site, xyCSS.com with a simple tweet:

Bringing it all together: http://xycss.com/

As implied (and explained), xy.css is a lightweight CSS template for creating semantic HTML5 designs on a responsive liquid matrix.

At its core, xy.css neutralizes rogue browser styles, combines horizontal and vertical grids, and provides a flexible template for responsive design. From there, xy.css facilitates clean, device-neutral designs with a complete set of preset classes for easy layouts via grid-based columns and rows.

My new baby has eight circular and symmetrically positioned heads

Features

xy.css brings together the best CSS techniques from around the Web and integrates them into a single, powerful stylesheet template. As showcased on the home page:

These key techniques coalesce in xy.css, providing the control, flexibility, and consistency required for responsive, grid-based design. To see some examples, check out the Demos.

So that’s it in a nutshell: xy.css is a CSS template for responsive grid-based design. It’s all open source and very much a work in progress. The plan is to bring a few like-minded individuals on board and take it to the next level. Drop a line to learn more.

Custom fonts displayed on the vertical grid

About the site

The site itself — xyCSS.com — is built with WordPress, HTML5, CSS3 and of course xy.css. To help visualize the responsive, grid-based design, the site includes numerous on-page tools:

Upper-left corner – displays the current browser width
Upper-right corner – buttons for showing/hiding the grid
Lower-left corner – displays the current @media rules
Upper-right corner – “Top” button

To view the vertical grid, click the “show matrix” button. To see the horizontal grid, resize the browser width to 984px and click the “layout grid” button. Visit Tools to implement any of these diagnostic techniques on your own web pages.

Visualize the xy matrix for any page on the site by clicking the “show/hide matrix” button

Responsiveness

Here are some additional screenshots demonstrating the responsiveness of xyCSS.com.

For large screens, the main menu is positioned on the right side of the content

As screen width decreases, the menu items rotate 90 degrees to optimize space

For smaller screens, the menu slides to the top of the page to further optimize space

For increasingly smaller screen sizes, the menu items begin to “squish” together, which is fun to watch

And of course all of this responsiveness is perfectly aligned with the liquid matrix (horizontal and vertical grid). Here’s one more for the road..

The eight circles on the xyCSS homepage collapse into menu items for smaller screens

Visit the site to learn about and see more responsive, grid-based action!

Learn more..

Check out these links to learn more about xy.css:

I’ve also designed my new site with xy.css — check out WP-Mix.com for a fresh mix of code snippets and tutorials, delivered via responsive liquid grid. Learn more about WP-Mix!

Thanks for reading! :)

5G Blacklist 2013

Jeff Starr — Thu, 10 Jan 2013 07:55:00 +0000

Following up on much feedback (and this post), here is an update for the 5G Blacklist for 2013. As explained in the 2012 article (and elsewhere), the 5G Blacklist helps reduce the number of malicious URL requests that hit your website. It’s one of many ways to improve the security of your site and protect against evil exploits, bad requests, and other nefarious garbage. If your site runs on Apache and you’re familiar with .htaccess, the 5G is an effective way to secure your site against malicious HTTP activity.

About the 5G Blacklist

The 5G Blacklist is a simple, flexible blacklist that checks all URI requests against a series of carefully constructed HTAccess directives. This happens quietly behind the scenes at the server level, saving resources for stuff like PHP and MySQL for all blocked requests.

How it works

Blacklists can block just about any part of a request: IP, user agent, request string, query string, referrer, and everything in between. But IP addresses change constantly, and user agents and referrers are easily spoofed. As discussed, request strings yield the best results: greater protection with fewer false positives.

The 5G works beautifully with WordPress, and should help any site conserve bandwidth and server resources while protecting against malicious activity.

5G Blacklist 2013

Here is the third version of the 5th generation blacklist:

# 5G BLACKLIST/FIREWALL (2013)
# @ http://perishablepress.com/5g-blacklist-2013/

# 5G:[QUERY STRINGS]

	RewriteEngine On
	RewriteBase /
	RewriteCond %{QUERY_STRING} (\"|%22).*(<|>|%3) [NC,OR]
	RewriteCond %{QUERY_STRING} (javascript:).*(\;) [NC,OR]
	RewriteCond %{QUERY_STRING} (<|%3C).*script.*(>|%3) [NC,OR]
	RewriteCond %{QUERY_STRING} (\\|\.\./|`|=\'$|=%27$) [NC,OR]
	RewriteCond %{QUERY_STRING} (\;|\'|\"|%22).*(union|select|insert|drop|update|md5|benchmark|or|and|if) [NC,OR]
	RewriteCond %{QUERY_STRING} (base64_encode|localhost|mosconfig) [NC,OR]
	RewriteCond %{QUERY_STRING} (boot\.ini|echo.*kae|etc/passwd) [NC,OR]
	RewriteCond %{QUERY_STRING} (GLOBALS|REQUEST)(=|\[|%) [NC]
	RewriteRule .* - [F]


# 5G:[USER AGENTS]

	# SetEnvIfNoCase User-Agent ^$ keep_out
	SetEnvIfNoCase User-Agent (binlar|casper|cmsworldmap|comodo|diavol|dotbot|feedfinder|flicky|ia_archiver|jakarta|kmccrew|nutch|planetwork|purebot|pycurl|skygrid|sucker|turnit|vikspider|zmeu) keep_out
	
		Order Allow,Deny
		Allow from all
		Deny from env=keep_out
	


# 5G:[REQUEST STRINGS]

	RedirectMatch 403 (https?|ftp|php)\://
	RedirectMatch 403 /(https?|ima|ucp)/
	RedirectMatch 403 /(Permanent|Better)$
	RedirectMatch 403 (\=\\\'|\=\\%27|/\\\'/?|\)\.css\()$
	RedirectMatch 403 (\,|\)\+|/\,/|\{0\}|\(/\(|\.\.\.|\+\+\+|\||\\\"\\\")
	RedirectMatch 403 \.(cgi|asp|aspx|cfg|dll|exe|jsp|mdb|sql|ini|rar)$
	RedirectMatch 403 /(contac|fpw|install|pingserver|register)\.php$
	RedirectMatch 403 (base64|crossdomain|localhost|wwwroot|e107\_)
	RedirectMatch 403 (eval\(|\_vti\_|\(null\)|echo.*kae|config\.xml)
	RedirectMatch 403 \.well\-known/host\-meta
	RedirectMatch 403 /function\.array\-rand
	RedirectMatch 403 \)\;\$\(this\)\.html\(
	RedirectMatch 403 proc/self/environ
	RedirectMatch 403 msnbot\.htm\)\.\_
	RedirectMatch 403 /ref\.outcontrol
	RedirectMatch 403 com\_cropimage
	RedirectMatch 403 indonesia\.htm
	RedirectMatch 403 \{\$itemURL\}
	RedirectMatch 403 function\(\)
	RedirectMatch 403 labels\.rdf
	RedirectMatch 403 /playing.php
	RedirectMatch 403 muieblackcat


# 5G:[REQUEST METHOD]

	RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
	RewriteRule .* - [F]


# 5G:[BAD IPS]

	Order Allow,Deny
	Allow from all
	# uncomment/edit/repeat next line to block IPs
	# Deny from 123.456.789

To use: include the entire 5G Blacklist in the root .htaccess file of your site. Remember to backup your original .htaccess file before making any changes. Test thoroughly while enjoying your favorite beverage. If you encounter any issues, please read the troubleshooting tips and/or leave a comment to report a bug.

Note: in some cases it may be necessary to place the QUERY STRING rules before WP-permalink rules.

Pre-changelog notes

The changes made for 5G 2013 are aimed at maximizing compatibility. Unfortunately, a number of required changes are due to improper coding and ignoring HTTP specifications. As mentioned previously, using unsafe characters in URLs obsoletes security measures that are based on pattern-matching, which is integral to the process of blocking malicious activity.

To illustrate, it is possible to protect against a wide range of malicious requests by blocking unsafe characters such as unencoded question marks “?” included within the query string. Firewalls, blacklists, security plugins and scripts are able to safely block such bad requests UNTIL some widely used service such as Google Adwords decides to start including multiple unencoded question marks in their query strings. Suddenly blocking potentially dangerous “?” requests is useless because nobody wants to block legitimate (Google) traffic.

Moral of the story: if you develop for the Web, contribute to its security by encoding your URLs according to spec. If you use security plugins, firewalls/blackists, and scripts that rely on pattern-matching to protect your site, please encourage and educate others about the importance of adhering to HTTP specifications.

Changelog

Removed from QUERY STRINGS

Square brackets “[” and “]” (details)
Colon “:” (details)
Unencoded question mark “\?” (WP’s preview feature, Piwik, Adwords, et al)
Removed “(menu|mod|path|tag)\=\.?/?” (WP menus, WP Super Cache, Joomla, Googlebot, et al)
Removed “environ” (common string)
Removed “scanner” (various WP plugins)
Removed “%3E” (common string)
Escaped backslash, from “\” to “\\”

Removed from USER AGENTS

Commented out match for blank/empty user-agent “^$” (PayPal, WP-Piwik, et al)
Removed match for “libwww” (used by Lynx browser)

Removed from REQUEST STRINGS

Double forward slash “//” (Pingdom, gtmetrix, et al)
Removed match for “/cgi/” (Fancy indexes, Authentication)

Added to QUERY STRINGS (5G 2013)

“TRACE” and “TRACK”
“base64_encode.*\(”
“\|%3E”
“GLOBALS(=|\[|\%)”
“REQUEST(=|\[|\%)”
“`”
“(\"|%22).*(<|>|%3)”
“(<|%3C).*script.*(>|%3)”
“(javascript:).*(\;)”
“(\;|\'|\"|%22).*(union|select|insert|drop|update|md5|benchmark|or|and|if)”

Other changes

Optimized syntax, improved formatting.

Troubleshooting

If there is an error, remove the code and make a backup of your original .htaccess file (if you haven’t already done so). Investigate the URL for whichever page is blocked or not working, making note of any non-alphanumeric characters or anything else that looks unusual. With a good idea of what to look for, examine the 5G directives to see if anything looks similar. If so, try removing (or commenting out) the offending line (or characters) and see if that resolves the issue.

If that doesn’t work, further investigation is required, and there are numerous ways of going about it. Here is a good walkthrough of my halving method of isolating problematic code, which I recommend unless you have your own favorite way of troubleshooting ;)

Show support

If you benefit from my work with the 5G and would like to show support, consider buying a copy of my book, .htaccess made easy. You’ll get a complete guide to .htaccess, exclusive forum access, and a ton of awesome techniques for configuring, optimizing, and securing your site. Your generous support allows me to continue developing 5G/6G and other awesome resources for the community. Thank you!

Disclaimer

The 5G Firewall is provided “as-is”, with the intention of helping site administrators protect their sites against bad requests and other malicious activity. The code is open and free to use and modify as long as the first two credit lines remain intact. By using this code you assume all risk & responsibility for anything that happens, whether good or bad. In short, use wisely, test thoroughly, don’t sue me.

Learn more..

To learn more about the theory and development of the 5G Firewall, check out my articles on building the 3G, 4G and 5G Blacklist. The 6G beta article also contains some good information. And if all that’s not enough, a quick search for “blacklist” in the sidebar should also yield many results.

Introspection WordPress Theme

Jeff Starr — Wed, 09 Jan 2013 03:23:47 +0000

Free WordPress theme! The dark/minimalist design of the Introspection theme was originally created for a Pink Floyd fan site. After taking the site down to clear room (and time) for new stuff, I felt the design was too sweet to just let rot away in the archives. So after a few days of generalizing Introspection for public use, I’ve made it freely available for download so it can shine on..

Introspection (click image for full-size view)

Introspection is a clean, simple theme designed to streamline workflow, optimize content, and inspire productivity.

Features

Minimalistic, lightweight, optimized design
Supports custom menus, widgets, and featured images
HTML5/CSS3 design with browser-safe colors and fonts
Traditional two-column, fixed-width design
Tabbed sidebar menu showing recent, popular, and random posts
All-standard, plug-n-play WP theme functionality

The thing I like about Introspection is that it’s simple, clean and focused on content. It’s designed with greyscale color palette, consistent typography, and a well-balanced layout. When using this theme, I literally feel like creating content just to see how it will look “on the page.” Plus the theme’s source code is lightweight and flexible — perfect for intermediate users who want to customize their own introspective theme.

Demo

Introspection Demo

Download

WP Theme - Introspection - version 20130108 - 254KB ZIP

Note: Introspection is also available from my WordPress themes page.

Protection for WordPress Pingback Vulnerability

Jeff Starr — Thu, 03 Jan 2013 07:52:37 +0000

It was recently reported about a WordPress Pingback Vulnerability, whereby an attacker has four potential ways to cause harm via xmlrpc.php, which is the file included in WordPress for XML-RPC Support (e.g., “pingbacks”). In this post, I offer a simple .htaccess technique to lock things down and protect against any meddling via the xmlrpc.php file. Note: this technique is only recommended if you aren’t using XML-RPC for anything (e.g., pingbacks, Blogger, MovableType, etc.). Update: Check out the alternate method to whitelist specific IPs while protecting against threats.

About the Pingback Vulnerability

According to this article, there are four ways that WP‘s XML-RPC API (specifically, the pingback.ping method) could be abused by an attacker:

Intel gathering — attacker may probe for specific ports in the target’s internal network
Port scanning — attacker may port-scan hosts in the internal network
DoS attacks — attacker may pingback via large number of sites for DoS attack
Router hacking — attacker may reconfigure an internal router on the network

Again, this is just a summary for reference, see the original article for more details on these various vulnerabilities as well as the pingback.ping method. No need to rehash everything here :)

Protect against WordPress Pingback Vulnerability

If you know you aren’t using the XML-RPC functionality for anything, and would like to protect against any vulnerabilities, you can lock things down with a simple slice of .htaccess:

# protect xmlrpc

	RedirectMatch 403 /xmlrpc.php

Include that after any other rules in your site’s root .htaccess file and you should be good to go. To test that it’s working, try accessing the xmlrpc.php file in your browser. If it’s working, you’ll get a “403 – Forbidden message”. Tip: to redirect requests for xmlrpc.php to a custom page, modify the RedirectMatch like so:

# protect xmlrpc

	Redirect 301 /xmlrpc.php http://example.com/custom-page.php

Alternate .htaccess method

Here is an alternate .htaccess technique for denying all access to xmlrpc.php:

# protect xmlrpc

	Order Deny,Allow
	Deny from all

Using this method, it’s possible to allow access to xmlrpc.php for specific IP addresses. For example, if you know your Blogger and/or MovableType IP(s), you can whitelist them by adding an “Allow” line for each, like so:

# protect xmlrpc

	Order Deny,Allow
	Deny from all
	Allow from 123.456.789
	Allow from 321.654.987

Note: if you use one of these .htaccess methods, keep in mind that it may be removed once the reported vulnerability is secured in a future version of WordPress.

Thanks to Yael K. Miller for bringing this to my attention.

(Please) Stop Using Unsafe Characters in URLs

Jeff Starr — Tue, 01 Jan 2013 01:08:10 +0000

Just as there are specifications for designing with CSS, HTML, and JavaScript, there are specifications for working with URIs/URLs. The Internet Engineering Task Force (IETF) clearly defines these specifications in numerous documents, including the following:

The specifications for Uniform Resource Identifiers (URIs) and more specifically Uniform Resource Locators (URLs) provide a safe, consistent way to request, identify, and resolve resources on the Internet. As clearly stated in RFC3986:

A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier.

Thanks to the brilliant work of experts such as Tim Berners-Lee, Roy Fielding, Larry Masinter, and Mark McCahill, developers have a safe, consistent protocol for working with URIs/URLs on the Web. It is important that we adhere to these specifications when developing software, plugins, apps, and the like. Failing to do so introduces potential security vulnerabilities which may be exploited by nefarious individuals and malicious scripts.

Character Encoding Chart

To help promote the cause of Web Standards and adhering to specifications, here is a quick reference chart explaining which characters are “safe” and which characters should be encoded in URLs.

Classification	Included characters	Encoding required?
Safe characters	Alphanumerics `[0-9a-zA-Z]`, special characters `$-_.+!*'()`, and reserved characters used for their reserved purposes (e.g., question mark used to denote a query string)	NO
ASCII Control characters	Includes the ISO-8859-1 (ISO-Latin) character ranges 00-1F hex (0-31 decimal) and 7F (127 decimal.)	YES
Non-ASCII characters	Includes the entire “top half” of the ISO-Latin set 80-FF hex (128-255 decimal.)	YES
Reserved characters	`$ & + , / : ; = ? @` (not including blank space)	YES*
Unsafe characters	Includes the blank/empty space and " < > # % { } \| \ ^ ~ [ ] `	YES

* Note: Reserved characters only need encoding when not used for their defined, reserved purposes.

Usafe Characters

More about “unsafe” characters from RFC1738:

Characters can be unsafe for a number of reasons. The space character is unsafe because significant spaces may disappear and insignificant spaces may be introduced when URLs are transcribed or typeset or subjected to the treatment of word-processing programs. The characters “<” and “>” are unsafe because they are used as the delimiters around URLs in free text; the quote mark (“"”) is used to delimit URLs in some systems. The character “#” is unsafe and should always be encoded because it is used in World Wide Web and in other systems to delimit a URL from a fragment/anchor identifier that might follow it. The character “%” is unsafe because it is used for encodings of other characters. Other characters are unsafe because gateways and other transport agents are known to sometimes modify such characters. These characters are “{”, “}”, “|”, “\”, “^”, “~”, “[”, “]”, and “`”.

All unsafe characters must always be encoded within a URL. For example, the character “#” must be encoded within URLs even in systems that do not normally deal with fragment or anchor identifiers, so that if the URL is copied into another system that does use them, it will not be necessary to change the URL encoding.

Reserved Characters

More about “reserved” characters from RFC1738:

Many URL schemes reserve certain characters for a special meaning: their appearance in the scheme-specific part of the URL has a designated semantics. If the character corresponding to an octet is reserved in a scheme, the octet must be encoded. The characters “;”, “/”, “?”, “:”, “@”, “=” and “&” are the characters which may be reserved for special meaning within a scheme. No other characters may be reserved within a scheme.

Usually a URL has the same interpretation when an octet is represented by a character and when it encoded. However, this is not true for reserved characters: encoding a character reserved for a particular scheme may change the semantics of a URL.

Thus, only alphanumerics, the special characters “$-_.+!*'(),”, and reserved characters used for their reserved purposes may be used unencoded within a URL.

On the other hand, characters that are not required to be encoded (including alphanumerics) may be encoded within the scheme-specific part of a URL, as long as they are not being used for a reserved purpose.

URLs in HTML and JavaScript

In earlier versions of HTML, the entire range of the ISO-8859-1 (ISO-Latin) character set may be used in documents. Since HTML4, the entire Unicode character set may also be used. In HTTP, however, the range of allowed characters is expressly limited to only a subset of the US-ASCII character set (see the Character Encoding Chart for details).

So, when writing HTML, ISO and Unicode characters may be used everywhere in the document except where URLs are referenced*. This includes the following elements:

, , , , , ,
, , , , , , ,
,