A very small but very good discovery I made at this year’s WordCamp Portsmouth was thanks to Robert O’Rourke. I never knew that if you folded down the Screen Options at the top of the Appearance > Menus admin screen in WordPress, you get a few extra fields for menu items. They’re hidden by default.

The big one for me is “Description”. I’ve often used a menu for managing the items (i.e. posts and pages) that are featured in a carousel on the home page of a site. I wrote my own code to populate the menu query with information from the posts the menu items refer to—specifically, a description or extract to use as teaser text. Well, this little discovery that I can allow clients to set (or override) the teaser text right there while they’re managing the carousel “menu” is small; but I think little things like this really help clients when they’re busy managing their site.

But if you have to explain to them to open Screen Options and check a box to do something that might be important, it’s two steps forward and one step back. A bit better, but not ideal.

What if you could force “Description” to be checked?

Read more »

Someone asked in a comment here recently whether a WordPress plugin I’d posted could be adapted to work as theme code. The reasoning was that a client might deactivate a plugin, breaking some of the site’s functionality.

Careless clients clicking around in the admin interface can be a concern for a responsible developer. Of course, the primary way of limiting this kind of risk is to assign clients to appropriate roles. If the pre-defined roles don’t quite fit, Justin Tadlock’s excellent Members plugin can help you get it right.

But say you have a client to whom you want to give plugin activation / deactivation capabilities (so they can add new plugins themselves), but the site you’ve built includes certain plugins that really shouldn’t be deactivated. What then?

Read more »

NOTE: Forget these workarounds! We’ve now got core functions to do the trick :) Check out Justin Tadlock’s tutorial on using them.

Also, to disable theme and plugin editing, don’t just remove the menu links. You can use a constant in wp-config.php to completely switch that functionality off.

I’ve recently been looking at de-cluttering the WordPress admin interface. There’s some good plugins for this, such as Adminimize, WP-CMS Post Control (for hiding boxes on the post screen, according to user role) and White Label CMS (for extensive customization of logos, menus, etc.).

As ever, I’m also interested in getting just a particular aspect working with a bit of theme code—if only one aspect is needed, it’s sometimes nice to drop it into the theme and have one less plugin loading. The aspect I’m thinking of here is removing a few menu items.

So, with the usual caveat that this is code for theme developers, to be dropped into the active theme’s functions.php file, and a nod to hungred.com for initial inspiration, here goes.

Read more »

Most WP developers know by now that the right way to add script libraries from a plugin or theme is to use the wp_enqueue_script function. It makes sure scripts aren’t loaded more than once, and so on.

However, I just had some problems getting some jQuery to run on the login / registration form. I used wp_enqueue_script like a good WP developer but… no go. Where’s my jQuery?

It seems the answer lies in the fact that after scripts are enqueued in a normal WP page, they get spit out by something inside the call to wp_head(). I guess you could add wp_head() to the login header, but who wants all those redundant plugin scripts and styles that (presumably) aren’t even meant to be there.

After a bit of digging around it seems that the solution is the wp_print_scripts() function. So, to get jQuery working on the login form, put these lines in the code you hook onto login_head:

wp_enqueue_script( 'jquery' );
wp_print_scripts();

Here’s a quickie that can help with WordPress sites that have a lot of pages. If some of the pages have longish titles, the “Parent Page” drop-down on the edit page screen can get unwieldy. The scroller for the drop-down can run off the right side of the screen.

OK, it’s fine (often easier) to use the keyboard to navigate drop-downs. But not everyone knows how to, and even so, with a large amount of pages, selecting the right parent can become a pain.

I think I adapted the following code from a plugin or someone else’s post. Thanks whoever you are, but frankly I’m so busy at the moment I’ve forgotten where it came from! Anyway, if you drop the following into your custom theme’s functions.php, you’ll get a new “Create child” link under every page listed in WP admin, when you hover over the title:

add_filter( 'page_row_actions', 'slt_child_page_action', 10, 2 );
function slt_child_page_action( $actions, $page ) {
	$actions["create-child"] = '<a href="' . add_query_arg( array( 'post_type' => 'page', 'parent_id' => $page->ID ), admin_url( 'post-new.php') ) . '" title="Create a new page with this page as its parent">Create child</a>';
	return $actions;	
}
add_action( 'edit_page_form', 'slt_set_child_page' );
function slt_set_child_page() {
	global $post;
	if ( $post->post_type == "page" &amp;&amp; $post->post_parent == 0 &amp;&amp; isset( $_GET["parent_id"] ) &amp;&amp; is_numeric( $_GET["parent_id"] ) )
		echo '<script type="text/javascript">jQuery( document ).ready( function($) { $("#parent_id").val("' . $_GET["parent_id"] . '"); } );</script>';
}

The first bit adds the page action link. The second bit adds some jQuery to the right edit screen to set the specified parent, if it’s been passed. I couldn’t find another way to set the drop-down… Well, it works!

UPDATE 23/10/10: Changed the URL for the creation of a new page from /wp-admin/page-new.php to /wp-admin/post-new.php?post_type=page.

UPDATE 21/9/11: Changed the URL for the creation of a new page again, to be properly dynamic with admin_url and add_query_arg. Thanks One Trick Pony!

PLEASE NOTE: This code has now evolved into my Developer’s Custom Fields plugin. Please use this plugin instead of the code below, which is kept here out of historical interest only!

I’m currently working on a client’s WordPress site where there’s quite a few bits of custom functionality in my custom theme that rely on them entering values for posts or pages using WP’s custom fields.

Custom fields are really flexible. However, they’re not perfectly user-friendly. For instance, if no post or page is currently using a custom field that you’ve built functionality on, the user has to enter the name as well as the value of the field the first time it’s used. The drop-down of field names is dynamically gathered from the fields currently in use. Also, sometimes you want to make things easier for clients by having inline tips, and inputs that suit the field (e.g. a checkbox or select drop-down instead of just a plain text entry).

So, I set about piecing together a way to take over the Custom Fields meta box…

Read more »

Being a die-hard hand-coder, WYSIWYG editors irk me. It’s partly an irrational “Get your mits off my code!” thing, but it’s often very practical.

Working with WordPress, many of the sites I deploy for clients need specific layout code within the editable content of WP-managed pages. The code is necessary, and the clients are savvy enough to work around my HTML when they edit their copy.

WP’s visual editor, however, isn’t. It switches any

$user->rich_editing = 'true';

$user->rich_editing = 'false';