So when you type something like you see in the title of this post, with all the funky characters, or even just something like a comma, apostrophe, or semi-colon, WordPress 3.3+ works the magic and automatically creates your post slug without the junk.

Details.

It may not seem like a big deal, but previous versions of WordPress would include those funky characters when auto-creating your permalink slugs. If you glance at URLs while surfing around WordPress-powered sites, keep an eye on the URL in the address bar. It’s common to see all sorts of non-alphanumeric stuff in there.

Does it matter? I think so, for numerous reasons:

• Readability, consistency – simple alphanumeric URLs work great everywhere, no need to clutter them up with redundant information. For example, funky characters can choke URL-shortening services. Also: fewer characters, facilitates better comprehension.
• Safer – certain characters such as `, ^, ", ~, #, %, |, \, <, >, ", ~, [, ], {, }, and the blank space are considered as unsafe and should not be included in the URI (ie., always need encoded). Including them may seem to work, but you’re introducing sort of unknown variable into the mix, a potential vulnerability*
• SEO — do funky characters like blank spaces and percentage signs in the URL hurt your site’s SEO? Maybe not, but why put anything in there that isn’t a keyword?

So smarter auto-slugs in WordPress 3.3, another one of the finer details that improves the overall WP post-editing experience, and something you may not have noticed.

Bonus tip

Another sort of related “smarter-slugs” feature noticed while looking into it, is the automatic removal of the “-2” that WordPress automatically appends to the post slug when a duplicate is detected. So for example, say you’re working on a new post:

1. Create a post with a slug such as “test-post”
2. Delete the post and send to the Trash
3. Create another post with the same “test-post” slug
4. WordPress detects the duplicate post in the database and appends a “-2”, like so: test-post-2 to the post slug
5. Create yet another post with the same slug and WordPress will append a “-3”, and so on..

Nobody likes the “dash-twos” but they are required for the auto-creation of non-duplicate post slugs. What I just noticed with version 3.3 is that, once you empty the Trash, WordPress automagically removes the “-2” from the post slug, improving workflow to save you time. This may have changed in a previous version and I just hadn’t noticed, or it’s another one of the administrative refinements of WordPress 3.3.

Update: it looks like the -2 removal only applies to drafts and pending posts, not to posts that have already been published.. (see comment from Otto)

* More info on forbidden characters and blocking them

© 2012 Digging into WordPress | Permalink | 14 comments | Add to del.icio.us | Post tags: permalink, tips, tricks

The WordPress 3.3 update focused heavily on streamlining and optimizing the Admin experience. The Admin Bar of WP 3.1 was intended as the “first step toward a front-end editor”. The original Admin Bar was debated for several good reasons:

• It’s enabled on the front-end by default
• Gobbles up too much vertical screen space
• It’s redundant, all links available elsewhere
• It’s not visually appealing in general

Using the many Admin Bar tricks that became available around the Web, WordPress users dealt with the thing in their own way and moved on with their lives. Some use plugins, some custom snippets & scripts, some just love it as-is. But now with the new 3.3 update, the big question is “what works and what doesn’t?” We’re glad you asked..

Admin Bar is dead, long live the Toolbar

If you’ve updated to WP 3.3, you’ve seen the smaller “Toolbar” tucked neat above the Admin area. The new Admin Bar Toolbar seems to address some of the main concerns about the old Admin Bar:

• No longer enabled on front-end by default
• Uses less vertical screen space
• Integrates the Admin header area, so no longer redundant
• It looks a little better (in my opinion)

For those who have not yet updated or have no idea what’s going on, here is a visual comparison of the old “Admin Bar” and the new “Toolbar”:

Admin Bar: bigger, clunkier, and redundant

Toolbar: smaller, simpler, and required

The new Toolbar certainly looks better, but concerns remain. From what I’ve gathered, the main gripe is that the Toolbar is mandatory, and possibly still redundant, depending on site setup and configuration (plugins, networks, etc.). Is it really mandatory? That sounds silly to me, but seems to be the case:

User Profile settings for the old Admin Bar: full control

User Profile settings for the Toolbar: bamboozled! No option to disable for back-end

So yeah, something changed, so the question for the Admin Toolbar is “what works and what doesn’t?” Let’s dig in and see what’s up..

Admin Bar changes, now WP Toolbar

As Ipstenu puts it: “You don’t have to like it, but it’s here to stay.” So it’s time to look at things practically and get on with it. First of all, if you have a plugin or functions script that hides, removes, or customizes the Admin Bar, definitely investigate to see if everything is still working according to plan.

What works..

After some testing, we’ve seen the following functions.php snippets continue to work in WordPress version 3.3:

// disable the admin bar (front end only) show_admin_bar(false); // disable the admin bar (front end only) add_filter('show_admin_bar', '__return_false');

In WP 3.1, these functions hid the Admin Bar on both sides of the fence — front end & back end. In WP 3.3+, these snippets will hide the Admin Toolbar only on the front-end of your site (the public side). Likewise, this snippet of CSS added to your theme’s style.css file hides the Toolbar on the front-end:

/* hide the admin bar (front end only) */ #wpadminbar { display:none; }

Keep in mind that, when using the CSS method, the Toolbar markup is still present in the source code, but will not be displayed in the browser.

Here is another useful snippet for disabling the Toolbar for lesser users:

// show admin bar only for admins if (!current_user_can('manage_options')) { add_filter('show_admin_bar', '__return_false'); } // show admin bar only for admins and editors if (!current_user_can('edit_posts')) { add_filter('show_admin_bar', '__return_false'); }

Note that this also only applies to Toolbar display on the front-end.

What doesn’t work..

Basically the show_admin_bar() function seems to work as it did before version 3.3, except that now the Toolbar is integral to the Admin area, so disabling it using the previous functions works only on the front-end of your site. So tricks like this stopped working:

If you’re running WP 3.1+ or 3.2+ (not 3.3+), then show_admin_bar() will continue to disable the Admin Bar on both front and back ends of WordPress.

Admin Bar plugins

In our book, we provide a list of plugins to help with customizing the 3.1 Admin Bar. Now working on the DiW 3.3 update, it’s time to check these plugins for compatibility with WordPress 3.3. Here are the results:

• Admin Bar Remover — disables Toolbar on front-end only
• Admin Bar Removal — doesn’t work in WP 3.3+
• Admin Bar Disabler — disables Toolbar on front-end only
• Admin Bar Minimiser — hides/minimizes Toolbar on both sides of WP 3.3, but looks weird because of the existing Admin design. Also, in the Admin the hover/toggle button is invisible.
• Global Hide/Remove Admin Bar Plugin — removes the User Profile Toolbar settings and removes Toolbar on front-end only
• Hide Admin Bar Search — there is no search bar in WP 3.3
• Stick Admin Bar To Bottom — works great on both sides of WP 3.3
• WP Custom Admin Bar — didn’t seem to work..
• Always show admin bar — works in 3.3 but applies only to front-end
• Update: Ultimate Admin Bar — puts it all in the Toolbar to further optimize your workflow

If you know of others, shout em out and I’ll update the post.

To be continued..

Without a doubt things will continue to change, and it’ll be fun watching as WordPress continues to evolve, Toolbar and all :)

© 2012 Digging into WordPress | Permalink | 16 comments | Add to del.icio.us | Post tags: Admin, admin-bar, tips, tricks

What are they?

I think what happened is that the restoration database that we ended up using had been opened in a file/text editor. It’s just a guess, and sort of irrelevant, but the text editor converted our UTF-8 characters into some other character set, like ISO-8859-1. So after restoration, we ended up with hundreds of these weird characters in the database – quotes, hyphens, dashes, and ellipses were all converted to Klingon:

“ = left quote = “
” = right quote = ”

‘ = left single quote = ‘
’ = right single quote = ’

— = en dash = –
– = em dash = —

• = hyphen = -
… = ellipsis = …

Identifying most of these characters was relatively painless, but the en-dash and em-dash characters may be reversed (i.e., – = em dash, and — = en dash). Testing the other character replacements in the database was easy, but discerning between instances of em & en dashes proved futile. So do your own testing and make good backups before making any mass changes. Hopefully someone can help us out with more of the specifics.

Clean ‘em up

Before making any changes to your database, make sure you have a good backup (or three). Then to clean up these weird characters from the WordPress database, use a program like phpMyAdmin to execute the following queries.

Clean up post_content

UPDATE wp_posts SET post_content = REPLACE(post_content, '“', '“');
UPDATE wp_posts SET post_content = REPLACE(post_content, '”', '”');
UPDATE wp_posts SET post_content = REPLACE(post_content, '’', '’');
UPDATE wp_posts SET post_content = REPLACE(post_content, '‘', '‘');
UPDATE wp_posts SET post_content = REPLACE(post_content, '—', '–');
UPDATE wp_posts SET post_content = REPLACE(post_content, '–', '—');
UPDATE wp_posts SET post_content = REPLACE(post_content, '•', '-');
UPDATE wp_posts SET post_content = REPLACE(post_content, '…', '…');

Clean up comment_content

UPDATE wp_comments SET comment_content = REPLACE(comment_content, '“', '“');
UPDATE wp_comments SET comment_content = REPLACE(comment_content, '”', '”');
UPDATE wp_comments SET comment_content = REPLACE(comment_content, '’', '’');
UPDATE wp_comments SET comment_content = REPLACE(comment_content, '‘', '‘');
UPDATE wp_comments SET comment_content = REPLACE(comment_content, '—', '–');
UPDATE wp_comments SET comment_content = REPLACE(comment_content, '–', '—');
UPDATE wp_comments SET comment_content = REPLACE(comment_content, '•', '-');
UPDATE wp_comments SET comment_content = REPLACE(comment_content, '…', '…');

Other tables

While cleaning up the DigWP database, several other weird characters also showed up in various places, but they were very few in number. I also noticed several instances of converted quotes, dashes, and hyphens scattered around in some other tables, mostly in the options table, buried deep within temporary rss_ data. So I didn’t bother with anything beyond the post_content and comment_content tables, but easily could have done so by modifying the previous queries like so:

UPDATE [table_name] SET [col_name] = REPLACE([col_name], '…', '…');

Just replace [table_name] with whatever table you want to clean up, col_name with the column name, and then replicate or edit the query with the proper character replacements.

Lesson learned

Take-home message: don’t open your database in a text editor. But if you do, execute these SQL queries for easy clean-up.

© 2011 Digging into WordPress | Permalink | 20 comments | Add to del.icio.us | Post tags: database, mysql, sql, tips

In previous versions of WordPress, if you enabled the Visual Editor via your User Profile page, that’s pretty much what you were forced to use. There was no way to leave it enabled and then just choose your preference locally from the Write/Edit post screen, so every time you updated your post, the editor would switch back to visual mode – even if you repeatedly click the HTML editing-mode button. Older versions of WordPress were like this for quite awhile, and during that time many WP peeps just decided to disable the Visual Editor to avoid the headache and constant switching.

Above is a screenshot of the User Profile page of version 2.3.3. At some point, it switched from “disabled” to “enabled”, as shown below for WordPress version 3.1.2:

Fast-forward to WordPress 3, and welcome the new streamlined Linking Tool that only works in visual-editing mode. It’s an awesome tool that makes internal linking almost fun, but unfortunately it is not available with the HTML editor. So all of those seasoned WP users who’ve been conditioned to disable the Visual Editor during setup are now completely missing out on the awesomeness of the new Link Tool.

I don’t know when it happened (which version), but somewhere along the way, WordPress started remembering your editing preferences right there in the Write/Edit post screen, so it’s no longer necessary to “Disable the Visual Editor” next time you’re setting up a site. Sure you can still disable it if you want to, but why? Leaving it enabled gives you the option to choose which editor to use while actually writing your post. This gives you access to WordPress’ new Link Tool without sacrificing your ability to compose in HTML mode.

Then again, I may be totally wrong and everyone already knows about this. I hope that’s the case, because the new Link tool is super useful and worth a quick jump into the Visual Editor.

© 2011 Digging into WordPress | Permalink | 16 comments | Add to del.icio.us | Post tags: Admin, editing, editor

Amazingly enough, there currently are over 1,000 plugins tagged as cache at the WordPress Plugin Directory. That’s a mind-boggling number, so for this poll we’re focusing only on caching plugins that improve overall site performance (as opposed to plugins specifically for caching images, feeds, stylesheets, and everything else). If you have a favorite that isn’t on the list, leave a comment and we’ll mention it when we post the results.

Check the sidebar for more WordPress polls! :)

© 2011 Digging into WordPress | Permalink | 43 comments | Add to del.icio.us | Post tags: polls

Here is our menu of Admin Bar Tricks for WordPress 3.1 and better:

• Disable the Admin Bar for individual users
• Disable the Admin Bar for all users of the current theme
• Disable the Admin Bar for non-Admins only
• Always show the Admin Bar
• Move the Admin Bar to the bottom
• Add or Remove links from the Admin Bar
• Clean up User Profile Page
• Disable and Customize the Admin Bar with Plugins
• Even More Admin Bar Resources

Disable the Admin Bar for individual users

By default, each registered user has the option of showing the Admin on the frontend and/or back-end of the site. Thus, to change your preferences, just visit Users > Your Profile and choose your options as seen here:

Unfortunately, this gets kind of tedious when customizing profiles for many users. Fortunately, we’re just getting started, so read ahead to see more efficient ways of disabling and modifying the WordPress Admin Bar.

Disable the Admin Bar for all users of the current theme

To cleanly disable the Admin Bar for all users of your theme (and thus your site), add this snippet to your theme’s functions.php file:

// disable the admin bar
show_admin_bar(false);

Alternately, you may use this method, which filters the show_admin_bar function:

// disable the admin bar
add_filter('show_admin_bar', '__return_false');

Another option is to hide the Admin Bar using CSS. To do so, paste this into your
theme’s style.css (or other stylesheet):

/* hide the admin bar */
#wpadminbar { display:none; }

Disable the Admin Bar for non-Admins only

Expanding on the previous example, here are two snippets that disable the Admin Bar for non-Admins and Editors. Place either of the following in functions.php:

// show admin bar only for admins
if (!current_user_can('manage_options')) {
	add_filter('show_admin_bar', '__return_false');
}
// show admin bar only for admins and editors
if (!current_user_can('edit_posts')) {
	add_filter('show_admin_bar', '__return_false');
}

As you might guess, any setting may be used for current_user_can(), so it’s easy to show/hide the Admin Bar for any particular group of users.

Clean up User Profile Page

After disabling the Admin Bar, you may want to hide its display settings in each user’s Profile Page. The easiest way to do this is with a simple function:

function hideAdminBar() { ?>
<style type="text/css">.show-admin-bar { display: none; }</style>
<?php }
add_action('admin_print_scripts-profile.php', 'hideAdminBar');

Just place that in your theme’s functions.php and you’re good to go. No more Admin Bar Settings displayed in the Admin area.

Always show the Admin Bar

Follow the white rabbit shows us how to show the Admin Bar even when logged out. As a bonus, a handy “Log in” button is added to the bar for easy maneuvering. Just add the following snippet to your theme’s functions.php file:

// always show admin bar
function pjw_login_adminbar( $wp_admin_bar) {
	if ( !is_user_logged_in() )
	$wp_admin_bar->add_menu( array( 'title' => __( 'Log In' ), 'href' => wp_login_url() ) );
}
add_action( 'admin_bar_menu', 'pjw_login_adminbar' );
add_filter( 'show_admin_bar', '__return_true' , 1000 );

You can see it in action at follow the white rabbit.

Move the Admin Bar to the bottom

Want to display the Admin Bar at the bottom of the page instead of the top? WPengineer shows us how with this bit of CSS via the functions.php file:

// move admin bar to bottom
function fb_move_admin_bar() { ?>
	<style type="text/css">
		body {
			margin-top: -28px;
			padding-bottom: 28px;
		}
		body.admin-bar #wphead {
			padding-top: 0;
		}
		body.admin-bar #footer {
			padding-bottom: 28px;
		}
		#wpadminbar {
			top: auto !important;
			bottom: 0;
		}
		#wpadminbar .quicklinks .menupop ul {
			bottom: 28px;
		}
	</style>
<?php }
// on backend area
add_action( 'admin_head', 'fb_move_admin_bar' );
// on frontend area
add_action( 'wp_head', 'fb_move_admin_bar' );

This code adds the required CSS to both the front-end (public pages) and back-end (admin pages). To disable for one or the other, just comment-out or remove the corresponding add_action() line near the end of the code. You could also just copy/paste the CSS into your theme’s style.css file if you only need to move it on the front-end of your site. An even easier way is provided by Coen Jacobs’ Stick Admin Bar To Bottom plugin that makes it happen automagically.

Add or Remove links from the Admin Bar

WPMU.org shows us how to add/remove links from the Admin Bar. This is especially useful for MultiSite networks, where all of the extra links may not be necessary. The following code may be used to remove links and/or menus (via functions.php:

// remove links/menus from the admin bar
function mytheme_admin_bar_render() {
	global $wp_admin_bar;
	$wp_admin_bar->remove_menu('comments');
}
add_action( 'wp_before_admin_bar_render', 'mytheme_admin_bar_render' );

For this example, we use remove_menu('comments') to remove the comments dropdown list. To remove a different link/menu, check /wp-includes/admin-bar.php for the corresponding ID. Here’s a list of some of them to get you started:

• my-account – link to your account (avatars disabled)
• my-account-with-avatar – link to your account (avatars enabled)
• my-blogs – the “My Sites” menu if the user has more than one site
• get-shortlink – provides a Shortlink to that page
• edit – link to the Edit/Write-Post page
• new-content – link to the “Add New” dropdown list
• comments – link to the “Comments” dropdown
• appearance – link to the “Appearance” dropdown
• updates – the “Updates” dropdown

To add links/menus to the Admin Bar, add the following code to your functions.php file:

// add links/menus to the admin bar
function mytheme_admin_bar_render() {
	global $wp_admin_bar;
	$wp_admin_bar->add_menu( array(
		'parent' => 'new-content', // use 'false' for a root menu, or pass the ID of the parent menu
		'id' => 'new_media', // link ID, defaults to a sanitized title value
		'title' => __('Media'), // link title
		'href' => admin_url( 'media-new.php') // name of file
		'meta' => false // array of any of the following options: array( 'html' => '', 'class' => '', 'onclick' => '', target => '', title => '' );
	));
}
add_action( 'wp_before_admin_bar_render', 'mytheme_admin_bar_render' );

You’ll want to adjust the parameters to fit your needs, and don’t forget to see the Codex for additional information. For even more insight into this technique, see WPengineer’s post on adding menus to the Admin Bar.

Disable and Customize the Admin Bar with Plugins

Almost immediately after the Admin Bar was added to the WordPress core, plugins started popping up to disable it, move it, minimize it, and more. Here’s a quick list of plugins and links for ultimate control over the Admin Bar.

• Admin Bar Disabler
• Admin Bar Minimiser
• Admin Bar Removal
• Global Hide/Remove Admin Bar Plugin
• Hide Admin Bar Search
• Stick Admin Bar To Bottom
• WP Custom Admin Bar

If you know of others, mention them in the comments and we’ll add them to the list!

More Admin-Bar Resources

Here are some excellent resources for more information on the WordPress Admin Bar.

• WP Codex: Administration Menus
• WP Codex: Function Reference/add menu
• How to disable the WordPress Admin Bar
• What Everybody Ought to Know about the WordPress Admin Bar

© 2011 Digging into WordPress | Permalink | 20 comments | Add to del.icio.us | Post tags: Admin, admin-bar, tips, tricks

What an auto-update failure looks like

After initiating the auto-update of the WordPress core (say, from 3.1.0 to 3.1.1), the “Update WordPress” screen will begin displaying the status of each step, beginning with these messages:

• Downloading update from http://wordpress.org/wordpress-3.1.1.zip…
• Unpacking the update…
• Verifying the unpacked files…
• Installing the latest version…

So far so good, but even if it gets that far, there’s still a chance of failure, as seen in this recent screenshot:

The status message that appears just before “Installation Failed” explains what WordPress thinks is the issue, but there are cases where things go wrong and no messages are displayed. In either case, the user can get locked out of the site. When this happens, trying to load any of your pages – admin, blog, login, etc. – gets you the nothing but the WordPress maintenance page:

Briefly unavailable for scheduled maintenance.
Check back in a minute.

Very frustrating, and very difficult to fix things when you can’t log in to Admin. Fortunately, you don’t need Admin to fix it and get back in. Just FTP your way to the root directory and delete the .maintenance file. The name begins with a dot, so if you don’t see it using your FTP program, try logging into your server’s control panel and using the file manager to find and delete. Here is a screenshot showing the .maintenance file in the root installation directory:

This file contains a variable that is used by the wp_maintenance function. It looks like this:

<?php $upgrading = 1302115706; ?>

If you get locked out of your site, deleting the .maintenance file will fix the issue and get you back into Admin and other areas of your site. Once there, WordPress may remind you of the recent update failure by displaying the following message:

An automated WordPress update has failed to complete – please attempt the update again now.

At this point, you have (at least) two choices: keep trying with auto-updates or download the latest version and upload manually. Even if you decide to upgrade manually, you may want to resolve the issue and get auto-updates working for future versions.

Check File Permissions

Proper file permissions are the key to smooth auto-anything. On the Codex Page for the Dashboard Updates SubPanel, the Troubleshooting section advises the following:

Make sure that your entire wordpress directory is owned by the username under which your Apache server runs. For example, if your server runs as https, and your files live in /var/wordpress do a “chown -R apache.apache /var/wordpress.”

In addition to this advice, you may also try changing the permissions of your /upgrade/ directory. As seen in the following screenshot, WordPress uses the /upgrade/ directory for a temporary file used during the installation process:

For the temporary WordPress file to be created, the /upgrade/ directory needs to be writable by the server. To see if this is the issue, try setting the directory permissions to 777 (or CHMOD equivalent) and trying the auto-update again. If it works, you’ve resolved the issue, but you should always use the most restrictive permissions possible. This may take some research, experimenting, and/or a Help ticket with your host, but once you get it, you’re all set for auto-updates. Here is an Online CHMOD Calculator to help with the conversion process.

Turn Off Safe Mode

If possible, disabling Safe Mode may help to get auto-updates working again. According to the PHP Manual, Safe Mode is deprecated as of PHP version 5.3.0:

This feature has been DEPRECATED as of PHP 5.3.0.
Relying on this feature is highly discouraged.

Disabling Safe Mode is done in a variety of ways. If disabling through your server’s control panel isn’t possible, you can use this snippet in your php.ini file:

safe_mode = Off

Or this snippet in your Apache configuration file:

<Directory /var/www/public>
 php_admin_flag safe_mode off
</Directory>

Just add that code to your httpd.conf file and restart Apache.

Define FTP Variables in wp-config.php

As discussed, another way to get auto-updates working is to define the requisite variables in your wp-config.php file. There are numerous variations on this technique, so you’ll need to do your own experimentation to get a set of definitions that work for your situation. Here is what works for me on Media Temple’s (dv) server:

define('FS_CHMOD_FILE', 0755);
define('FS_CHMOD_DIR', 0755);
define('FS_METHOD', 'ftpext');
define('FTP_BASE', '/httpdocs/');
define('FTP_CONTENT_DIR', '/httpdocs/wp-content/');
define('FTP_PLUGIN_DIR ', '/httpdocs/wp-content/plugins/');
define('FTP_USER', 'username');
define('FTP_PASS', 'password');
define('FTP_HOST', '123.456.789');
define('FTP_SSL', false);

Place that in your wp-config.php file, just above the line that says, “That’s all, stop editing! Happy blogging.” Don’t forget to edit the username, password, and any other variables with your own information.

If you’re asking yourself why bother with all of this information, it’s because WordPress auto-updates features is SO awesome that it’s worth resolving any issues to get it working. Together with automatic plugin and theme updates, auto-WordPress updates have saved us many hours of work. For some sites, auto-updates works perfectly, for others, not so much. Just remember what you’re playing for here – it looks like this and will make keeping up with WordPress updates a much more enjoyable experience.

© 2011 Digging into WordPress | Permalink | 13 comments | Add to del.icio.us | Post tags: tips, tricks, updates

© 2011 Digging into WordPress | Permalink | 53 comments | Add to del.icio.us | Post tags: polls

The flipside of regular updates is the maintenance of WordPress installs. Once you start maintaining more than a few installs for your clients, keeping both plugins and WordPress up to date can become a bit repetitive.

Setting up a WordPress Network, using the multisite feature, reduces maintenance time. Upgrading all your sites becomes almost as easy as upgrading it for one.

Setup hosting to allow wildcard sub-domains

I’ve found setting up a WordPress network in sub-domain mode – site1.example.com, site2.example.com – works slightly better than it does in sub-directory mode.

Sub-domain mode requires you set up wildcard aliases for your web and DNS servers. Setting up a wildcard alias in Apache requires a single line be added directly below the appropriate ServerName command:

SeverAlias *.example.com

On your DNS server, you need to add a wildcard sub-domain pointing to your ip address:

*.example.com   10.10.10.10

The WordPress Codex provides further information on setting up wildcard domains for various control panels.

Install WordPress and setup Network

You need to setup a WordPress network from a fresh install of WordPress. As a reader of Digging into WordPress, you can probably do this in your sleep.

Unlike a standard WordPress install, a WordPress Network must be installed in the root directory of a web server. I purchase domains for this purpose but you can use a sub-domain.

Once your wp-config.php file has been generated, you need to add this line to the file:

define('WP_ALLOW_MULTISITE', true);

You then need to visit WP Admin > Tools > Network where the instructions to create a network are easily followed. The Create a Network page in the codex is also helpful.

You’ll be ask to make changes to the .htaccess and wp-config.php files and create the directory blogs.dir in wp-content.

Decide on limitations

Before setting up clients on a WordPress site, you need to decide what you’ll permit them and their visitors to do. The settings you choose here affect everyone from site administrators down.

The settings to consider are (the settings I use are in brackets):

• Can site administrators create new users? (No)
• Which media upload buttons appear above the visual editor? (All)
• How much disk space does each site have for uploads? (Unlimited)
• What types of files can be uploaded? (Default listing)
• Maximum upload size of an individual file? (20000 kb)
• Is the plugins menu enabled for sites? (No)

I strongly advise you to keep the plugins menu disabled too. Your client is paying you to maintain WordPress because they lack the technical expertise; you don’t want them to enable WordPress Reset and delete everyone’s database.

Registration settings for the network need to be configured to. As this is for hosting your client’s sites, you’ll want to disable registration of new sites. You can choose to disable registrations entirely or allow user accounts to be registered.

To keep track of who is using the system, I disable registrations entirely. Site owners contact me when they need to add another user. Disabling registrations also prohibits requiring visitors to register before they can comment.

Once you’ve considered the limitations you want to apply to your clients, set them up at WP Admin > Super Admin > Options.

Adding clients to a WordPress Network

You can add users to the network at WP Admin > Super Admin > Users. I use a standard format for usernames to make searching easier.

With users added, you can now add their sites through WP Admin > Super Admin > Sites. Once their site is added you need to:

1. Edit the site (hover over the site in the list and click edit)
2. Enable the theme/s for the site
3. Add users with appropriate permissions to the site

Install Domain Mapping Plugin

Your client’s sites will use their own domain, rather than a sub-domain of the WordPress Network. This requires Donncha O Caoimh’s WordPress MU Domain Mapping plugin.

Unzip the plugin on your local machine, upload domain_mapping.php to the directory /wp-content/mu-plugins (create it if it doesn’t exist) and upload sunrise.php to /wp-content/. In your wp-config.php file add the line:

define( 'SUNRISE', 'on' );

Go to WP Admin > Super Admin > Domain Mapping and set your server’s IP address or its domain name in the CNAME entry. I always enable permanent redirect and usually enable user domain mapping page. If using a caching plugin (see below), I disable redirect administration pages.

You can then add domains to your client’s sites by visiting WP (Client Site) Admin > Tools > Domain mapping.

Otto has written up a great guide to using the domain mapping plugin.

Selecting plugins

A poorly coded or insecure plugin can cause enough problems on a standalone WordPress install. Because  a WordPress Network uses the same files and database across multiple sites, the problems are compounded.

Choosing plugins for a WordPress Network requires a glass half empty approach. The feature list of a plugin will tell you what it adds to your site, the code and support forums tell you what it takes away.

A good approach to take is to stick to plugins and plugin authors that are well-respected within the WordPress community. Plugins used on WordPress.com are a good starting point, as are plugins by Yoast, Donncha, and Automattic.

Big name or not, review the plugin’s code before installing it on your WordPress Network. Look for forms using nonces, wide use of the WordPress APIs, escaped database queries, among other things.

Other considerations

Hosting more sites on your server uses more resources so you should find ways to lighten the load.

The first plugin I install, (this goes for standalone sites too) is Jason Penny’s Use Google Libraries, which uses Google’s servers for hosting available JavaScript libraries. You must load JavaScript the WordPress way for this to have an affect.

If you’re creating bespoke themes for your clients, you probably have a standard starting point. If you’re not already doing so, you should use parent & child themes so you can fix bugs in your starting point and the changes instantly propagate to all the sites you host.

A parent theme will also allow you to share resources across multiple sites. If you use a base JavaScript or CSS file, reference it from the same URL at all times.

If you want to lower resource use further, install a caching plugin. I use W3 Total Cache on my server. It’s not easy to configure but when I did so, I saw an immediate drop in resource use and, more importantly, Pingdom reported a five-fold drop in response times.

Total Cache makes significant changes to the .htaccess file so exactly the same settings need to be used for all sites on your network.

Security, security, security

As I said earlier, a WordPress network shares files and the database across multiple sites. Any security issues a plugin, or theme, introduces are compounded as a result.

I can’t emphasise enough the importance of putting security first.

About the Author

Peter Wilson is a WordPress developer based in Melbourne, Australia, and started coding for the web in 1994.

Peter co-founded web production studio Soupgiant in 2009 and forms opinions on all things web at Big Red Tin.

© 2011 Digging into WordPress | Permalink | 43 comments | Add to del.icio.us | Post tags: clients

An automated WordPress update has failed to complete – please attempt the update again now.

For the past two years, this particular client had been great about ignoring the “Upgrade Now” nag and just waiting until the next scheduled maintenance (I usually check & update things every six weeks or so). But for some reason, one of the site’s Admins felt the need to click the Update button and give it a shot. And the auto-update failed.

I think one of the reasons why they acted instead of waiting is that the WP-upgrade message to the current version (3.0.4) included a message that emphasized that it was an urgent/important upgrade (because of the security issues with 3.0.3). I don’t have proof of this, or a copy of this most recent update message, but I’m thinking that the client saw that message and just sort of panicked.

Needless to say, my clients are now advised that I am only a tweet away from helping out in such emergencies, and that they should not attempt to upgrade anything themselves, regardless of how utterly easy the upgrade process seems to be.

Should clients update their own sites?

So that’s all pretty anecdotal, but after receiving numerous emails on the topic, I thought it would be helpful to put the idea out there and hear what other WordPress designers think about letting clients upgrade their own sites.

Surely, the answer depends on many factors, including the client’s experience with WordPress, web design, and so on, but my guess is that most clients choose WordPress because it so easy to use, not because they are the world’s most tech-savvy Admins. I guess my point here is that a majority of WordPress users aren’t adequately prepared to deal with an emergency if the “easy update” doesn’t go as planned.

What do you think?

Should clients be instructed to update their own sites? Just press the button and hope for the best? Updates usually go smooth, but you can’t assume that they always will. Case in point is the Admin who tried upgrading before I could log in and do it myself. They probably saw the update-now message and thought something like this:

• Well, that certainly sounds important
• Well, that certainly looks easy enough

And so then they click the button and give it a try. If it works, then great, everything works out and nobody skips a beat. If the upgrade fails on the other hand, the site could crash and data could be lost. In my opinion, WP & plugin updates should only be handled by someone who understands what they are doing, takes the time to check for issues, and knows how to fix things if/when necessary. But that’s just one opinion – what’s yours?

© 2011 Digging into WordPress | Permalink | 66 comments | Add to del.icio.us | Post tags: clients, updates