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

get_theme_data()

The function that makes it possible is called get_theme_data(), and it simply returns an array of information about any of your theme files. Here is how it’s used in your theme template:

<?php get_theme_data( $theme_filename ); ?>

So $theme_filename is required and should be the path and filename of your theme’s style.css file. There is no default value for this, so you need to ensure a proper value.

So what information can you display with get_theme_data()? The function returns an array of values that basically comprises the different meta items in your stylesheet. Here is a list of possible return values (all strings):

• Name – theme name
• Title – either theme name or linked theme name
• URI – theme URI
• Description – wptexturized version of the theme name
• AuthorURI – theme author URI
• Template – theme parent template, if exists
• Version – theme version number
• Status – theme status (default: publish)
• Tags – theme tags
• Author – author name or linked author name

Note that these return values are case-sensitive and will not work if the first letter is not capitalized.

Examples

The Codex provides this example for getting and displaying the theme Name and Author:

<?php

    /*
     * Assign theme folder name that you want to get information.
     * make sure theme exist in wp-content/themes/ folder.
     */

    $theme_name = 'twentyeleven'; 

   /*
    * Do not use get_stylesheet_uri() as $theme_filename,
    * it will result in PHP fopen error if allow_url_fopen is set to Off in php.ini,
    * which is what most shared hosting does. You can use get_stylesheet_directory()
    * or get_template_directory() though, because they return local paths.
    */

    $theme_data = get_theme_data( get_theme_root() . '/' . $theme_name . '/style.css' );
    echo $theme_data['Title'];
    echo $theme_data['Author'];

?>

This should get you going.. just copy/paste into your theme template and indicate the theme name in that first line of code. Displaying other bits of theme data is matter of editing/replicating those last two lines.

Once you see how it works, you can do cool stuff with it, like display your theme’s version number sort of globally throughout your site. I’m using this technique to append version parameters to my stylesheet URLs, like so:

<link rel="stylesheet" href="<?php bloginfo('stylesheet_directory'); ?>/style.css<?php if(function_exists('theme_version')) theme_version(); ?>">

..and the output markup looks like this (notice the appended version parameter, ?v=1.3):

<link rel="stylesheet" href="http://example.com/wp-content/themes/xycss/style.css?v=1.3">

Because I am using multiple stylesheets, this method really saves a LOT of time trying to keep track of everything. Here is the theme_version() function that goes in your theme’s functions.php file:

// display version number
function theme_version() {
    $theme_name = 'xycss'; // customize with your theme name
    $theme_data = get_theme_data( get_theme_root() . '/' . $theme_name . '/style.css' );
    echo '?v=' . $theme_data['Version'];
}

And with a few modifications, you can also display your theme’s information in your posts and pages via shortcode:

// version number shortcode
function theme_version_shortcode() {
    $theme_name = 'xycss'; // customize with your theme name
    $theme_data = get_theme_data( get_theme_root() . '/' . $theme_name . '/style.css' );
    return $theme_data['Version'];
}
add_shortcode('theme_version', 'theme_version_shortcode');

With that second snippet in your functions.php file, displaying your theme info directly in pages is as easy as writing this:

[theme_version]

..and the output:

1.3

It’s pretty cool stuff, and I’m sure there’s tons more you can do with it too. If you know any tricks or tips, please share in the comments, Thanks :)

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

Know thy comments

In WordPress, there are three types of responses: comments, pingbacks, and trackbacks. The status of any given response is either:

• approved – appearing on your site
• spammed – flagged as spam
• moderated – on hold for review
• in the trash – marked for deletion

Theoretically, you’re going to know about approved comments that appear on your site. Likewise, you’ll have a chance to review any moderated comments, and nothing makes it to the trash by accident, so you know about those as well. What you don’t always know about are spam comments flagged as such by a plugin. Some of these are going to be ham, and they can be tricky to spot, especially as the number of spam comments begins to climb.

Out of the box

Out of the box, WordPress doesn’t flag any response as spam, unless you add some phrases to the built-in comment blacklist. Then, any comments matching any phrases in your blacklist are sent to the spam pile. So the key to preventing blacklist ham (mmmm..) is being absolutely sure that you want nothing to do with any comments mentioning “baby uggs” or who knows what.

Akismet & ham stats

It’s easy to stop spam without plugins, but activate Akismet and suddenly you’ve got greater accuracy, better automation, and some incredible-looking statistics. Here are Akismet stats for false positives during the last few months here at DigWP.com:

That’s good news, but don’t be fooled – the number of false positives also depends on you, the user. Seeing few false positives is good news if you’re actively looking for them, otherwise who knows how many ham comments have slipped through. We check for false positives fairly regularly, so the low numbers are great, as is the decreasing number of spam comments:

This is also a good sign, but it’s still smart to keep an eye on things and rescue as much ham as possible. Back in the day, I really got into analyzing teh spam – digging through the spam bin, looking for patterns, checking sources, and rescuing ham comments from the abyss. It’s fun if you have the time, but these days it’s better to just get it done..

Ham-rescue tips

Now that we’ve seen how it works, here are some clues for cleaving through large slabs of spam quickly and effectively..

• Comment text – legit comments tend to look real and stand out among the junk
• Gravatars – usually a good signal of quality, but spammers can haz gravatars too
• Link text – stupid link text is a huge giveaway, like “Baby Ugg Boots” or whatever
• Site URL – anything more than a domain or first-level subdirectory is probably spam
• Excessive links – legitimate comments rarely contain more than one or two links

Here’s a screenshot illustrating some of these aspects of spam. Of course, there are plenty more examples waiting for you in Ye Olde Spam Bin!

Gravatars really stand out, but aren’t always the ham you’re looking for

Those are the big giveaways, but it’s generally easier/quicker to scan for ham than spam. That is, rather than looking for evidence of spam, scan for signs of legitimacy and quality. So a good example would be scanning for gravatars – you’re not trying to find the grey mystery man icon, you’re looking for something original, like the flag icon in the previous screenshot. With some repetition, the visual clues sort of gel together and the ham just sort of jumps out at you as sift through the pile.

Wrapping it up..

So what did we learn? Spam is the bad stuff, ham is the good stuff. WordPress doesn’t flag anything as spam by itself unless you add phrases to the comment blacklist. Add a great anti-spam plugin such as Akismet to the mix, and you’ve made your life easier by automating the process. But if you care about your readers and their feedback, you should periodically scan through your spam comments and rescue any false positives. With some repetition, checking your spam and saving ham comments takes only a few minutes, improves the quality of your site, and keeps commentators happy and ready for more.

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

• wp_reset_postdata()
• wp_reset_query()
• rewind_posts()
• Quick Summary

wp_reset_postdata()

First up we have wp_reset_postdata, which restores the global $post variable to the current post in the main query. This is useful when using WP_Query to customize loops or create multiple loops on the same page. It looks like this:

<?php wp_reset_postdata(); ?>

This tag is nice and simple – it accepts no parameters and returns no values. It simply resets the post data after a custom query. So for example, let’s say we have a custom WP_Query loop in our theme’s header.php file, something like this:

$random_post = new WP_query(); 
$random_post->query('cat=3&showposts=1&orderby=rand'); 
while ($random_post->have_posts()) : $random_post->the_post(); 
<a href="<?php the_permalink() ?>" title="<?php the_title(); ?>">
	<img src="<?php echo get_post_meta($random_post->ID, 'featured', true); ?>">
</a>
endwhile;

This would display a random post in the header, but it will also change the main query object for any other loops on the page. Without the original query data available, the main posts loop contained in, say, index.php may produce unexpected results. Fortunately, we can use wp_reset_postdata to restore the query object to its original state.

To use wp_reset_postdata, just place after your custom loop(s). Here is our previous example with wp_reset_postdata to reset the loop:

$random_post = new WP_query(); 
$random_post->query('cat=3&showposts=1&orderby=rand'); 
while ($random_post->have_posts()) : $random_post->the_post(); 
<a href="<?php the_permalink() ?>" title="<?php the_title(); ?>">
	<img src="<?php echo get_post_meta($random_post->ID, 'featured', true); ?>">
</a>
endwhile;
wp_reset_postdata();

When to use: best used after custom or multiple loops created with WP_Query.

wp_reset_query()

Next up we have the wp_reset_query function, which resets the query used with custom loops. It’s a simple function that accepts no parameters and returns no values. It looks like this:

<?php wp_reset_query(); ?>

Specifically, this function was created to prevent issues with query_posts, as indicated for the function in the wp-includes/query.php file:

/**
 * Destroy the previous query and set up a new query.
 *
 * This should be used after {@link query_posts()} and before another {@link
 * query_posts()}. This will remove obscure bugs that occur when the previous
 * wp_query object is not destroyed properly before another is set up.
 *
 * @since 2.3.0
 * @uses $wp_query
 */

Looking at the wp_reset_query function in query.php, we see that it uses the adjacent wp_reset_postdata function to restore the global $post variable to the current post in the main query:

// destroy and reset the query
function wp_reset_query() {
	unset($GLOBALS['wp_query']);
	$GLOBALS['wp_query'] =& $GLOBALS['wp_the_query'];
	wp_reset_postdata(); // <-- RESET QUERY
}

// restore the query
function wp_reset_postdata() {
	global $wp_query;
	if ( !empty($wp_query->post) ) {
		$GLOBALS['post'] = $wp_query->post;
		setup_postdata($wp_query->post);
	}
}

So both wp_reset_query() and wp_reset_postdata() reset the query object by restoring the global $post variable, but wp_reset_query takes it a step further and actually destroys the previous query before doing so. This is important when using query_posts(), as seen in the following example:

<?php query_posts('posts_per_page=3');
if (have_posts()) : while (have_posts()) : the_post(); ?>

<h1><a href="<?php the_permalink(); ?>"><?php the_title(); ?></a></h1>

<?php endwhile; endif; ?>
<?php wp_reset_query(); ?>

When to use: best used after a query_posts loop to reset things after a custom query.

rewind_posts()

Last but not least, we have the rewind_posts function, which basically does what it says: rewinds the loop so you can re-use the same query. The function accepts no parameters, returns no values, and looks like this when used in your theme files:

<?php rewind_posts(); ?>

So to understand when to use rewind_posts(), let’s say we want to use the same query in two different locations on the page. We want to display post titles in the first loop and post content in the second loop. To re-use the same posts, we include rewind_posts after the first loop, like so:

if (have_posts()) : while (have_posts()) : the_post(); ?>
<h1><a href="<?php the_permalink(); ?>"><?php the_title(); ?></a></h1>
<?php endwhile; endif; ?>

<?php rewind_posts(); ?>

<?php while (have_posts()) : the_post(); ?>
<?php the_content(); ?>
<?php endwhile; ?>

So, while wp_reset_query and wp_reset_postdata reset the entire query object, rewind_posts simply resets the post count, as seen for the function in the wp-includes/query.php file:

// rewind the posts and reset post index
function rewind_posts() {
	$this->current_post = -1;
	if ( $this->post_count > 0 ) {
		$this->post = $this->posts[0];
	}
}

When to use: best for re-using the same query on the same page.

5-second summary

Quick summary for future reference:

• wp_reset_postdata() -> best used after custom or multiple loops created with WP_Query
• wp_reset_query() -> best used after a query_posts loop to reset a custom query
• rewind_posts() -> best for re-using the same query on the same page

I hope this is a useful round-up of when & how to reset/rewind the WordPress loop. Note that the WP Codex information on these functions is kinda thin, so feel free to share any tips or examples in the comments.

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

They key here is that only you and the server need access to the folder that you want to protect, so for example, stuff like:

• uploads
• upgrade
• backups
• cache-123
• temp-123
• etc..

Anything that regular users aren’t going to need to access. Then, you’ll also need the IP address of your server and your own machine. Once you have that information, use it to edit the following code:

Order Deny,Allow
Deny from all
Allow from 123.456.789.0
Allow from 0.123.456.789

You can emulate the “Allow from” lines to allow more IP addresses. Like maybe you’ve got a remote office or something. Once the code is ready, just copy and paste into an htaccess file located in the directory you would like to protect. Fix it and forget it, as they say..

I use this code on several sites and it works great. Only takes a minute to setup, and greatly improves the security of otherwise potentially vulnerable directories.

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

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

<?php $numlinks = $wpdb->get_var("SELECT COUNT(*) FROM $wpdb->links WHERE link_visible = 'Y'");
if (0 < $numlinks) $numlinks = number_format($numlinks); ?>

Place that in your theme file and then customize the output by placing <?php echo $numlinks; ?> wherever you would like to display the results.

A perfect example of this code in use can be seen at this random bookmark site.

© 2010 Digging into WordPress | Permalink | 3 comments | Add to del.icio.us | Post tags: blogroll, bookmarks, tips, tricks

function shortURL() {
	return 'http://your-site.com/';
}
add_shortcode('myurl', 'shortURL');

Now whenever you write a post in “HTML-mode”, you can include your blog’s URL at breakneck speed by simply typing “[myurl]”. Works great in WordPress 2.5 or better.

Shortcodes for your favorite links
To create a shortcode for your favorite links, we need to include the href attribute information as well as the anchor text for the link itself. We can do this by placing this function in your theme’s functions.php file:

function shortLink($atts, $content = null) {
	extract(shortcode_atts(array(
		"href" => 'http://default-website.com' // default URL
	), $atts));
	return '<a href="'.$href.'">'.$content.'</a>';
}
add_shortcode('link', 'shortLink');

Then, when creating a post, emulate the following format to include any links you wish:

[link href="http://your-site.com/"]Your Website![/link]

..which will output the following code:

<a href="http://your-site.com/">Your Website!</a>

When the href attribute is removed from the shortcode, the default URL will be used. You may specify the default URL in the third line of the function (see comment). This makes it easy to add a complete link to your site on the fly by simply typing:

[link]Your Website![/link]

One of the nice things about using shortcodes instead of hard-coded links is that you can easily change the default URL without breaking anything.

© 2010 Digging into WordPress | Permalink | 6 comments | Add to del.icio.us | Post tags: shortcodes, tips, tricks