Plugin repo bookmarklet

Sometimes when I’m checking out plugins in the WordPress.org repository, I like to view the source before I download. So partly out of boredom and partly out of laziness, I decided to create a bookmarklet that jumps you from a WordPress.org-hosted plugin page to its subversion repository.

The bookmarklet: Plugin Repo

To use the bookmarklet:

  1. Drag the above ‘Plugin Repo’ link to your bookmarks bar
  2. Visit any plugin page (or plugin’s sub-page) in the WordPress.org plugin repository
  3. Click the bookmarklet and you will be sent to that plugin’s SVN repo trunk url
  4. Boom.

Force sub-categories to use the parent category template

A couple of times in the last several years, I’ve needed sub-categories to inherit their parent’s archive template, but it’s just not something the Template Hierarchy supports. I’ve seen several plugins that tried and failed to do it, so finally I wrote a little filter that in my testing, works any number of levels deep, from sub-sub-categories to sub-sub-sub-categories. Enjoy!


function new_subcategory_hierarchy() {	
	$category = get_queried_object();

	$parent_id = $category->category_parent;

	$templates = array();
	
	if ( $parent_id == 0 ) {
		// Use default values from get_category_template()
		$templates[] = "category-{$category->slug}.php";
		$templates[] = "category-{$category->term_id}.php";
		$templates[] = 'category.php';		
	} else {
		// Create replacement $templates array
		$parent = get_category( $parent_id );

		// Current first
		$templates[] = "category-{$category->slug}.php";
		$templates[] = "category-{$category->term_id}.php";

		// Parent second
		$templates[] = "category-{$parent->slug}.php";
		$templates[] = "category-{$parent->term_id}.php";
		$templates[] = 'category.php';	
	}
	return locate_template( $templates );
}

add_filter( 'category_template', 'new_subcategory_hierarchy' );

Easy way to check if jQuery is already enqueued

Had a plugin wreaking some havoc today because it was overloading jquery.js with a minified, older version. Plugin authors: There’s a really simple way to check if jQuery or a jQuery library is already registered and enqueued. This covers really obscure edge cases where a plugin may have de-registered WordPress’s default scripts.

The offending code:

wp_register_script('myjquery', 'https://ajax.googleapis.com/ajax/libs/jquery/1.6.4/jquery.min.js', true, '1.6.4', false);
wp_enqueue_script('myjquery');

The fix:

// If jQuery isn't already enqueued, register and enqueue it
if ( ! jQuery ) {
	wp_register_script('myjquery', 'https://ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min.js', true, '1.7.2', false);
	wp_enqueue_script('myjquery');
}

Don’t Let Support Get Lost in Translation

I was lurking in the #wordpress support channel on IRC last night and noticed somebody getting the shrug off for a support issue because he wasn’t a native English speaker.

Now, the advice I initially gave him was ridiculed by others in the channel as stupid, but without really knowing the guy’s issue I was doing the best I could with what I could decipher from his broken English. And its not like anybody else was giving it a go, so I invited him into a private chat to get a better feeling for his problem.

We went round and round, him explaining in broken English and me trying to be as clear and concise as possible. Finally, I offered to use Google Translate so he could explain in Portuguese. He was floored that I would do this, but we tried it anyway. Turns out, it made all the difference in the world.

We went back and forth like that, me doing hyperspeed copy pasta with Translate, him doling out the Portuguese and after a few minutes we managed to get his issue resolved.

The problem as I see it is this: WordPress is all about contribution, whether it’s code, knowledge or time. Turning new WordPress users off by turning them away doesn’t really garner much support for the community, especially with the non-English-speaking crowd (who by the way make up about 2/3 of the worldwide community!).

Many users who seek support in IRC support are novice-level and they’re just trying to figure things out. It really doesn’t take all that much extra effort to meet them half way.

HowTo: Disable Access to the WordPress Dashboard for Non-Admins

Update: I had a few requested to bundle this into a plugin so I did. You can download it here.

Currently, I’m working on a site where we didn’t want non-admins to even be able to access the wp-admin dashboard. I searched around quite a bit looking for a complete shutoff-solution but most of the results detail how to literally disable the “Dashboard” menu in wp-admin.

Finally, trolling the comments on a like-solution in a post by c. bavota, I stumbled across a simplified version of bavotasan’s function that does exactly what I want, plus it redirects unworthy users to the homepage!

The simplified function was authored by somebody going only by the moniker of Jake.

It’s a pretty simple solution. It adds an action calling a function called ‘redirect_dashboard’ which checks the user level, and if the currently-logged-in-user is unworthy, they get bounced to the homepage. Pretty neat. On line #4, the function checks the user level, with the default set as ‘level_10′ or administrator. I modified this to ‘level_7′ to exclude anyone below the Editor level, but you could choose whichever capability level suits your purpose. Vist the Roles and Capabilities Codex page to find out more about user levels.

Here’s the snippet (which should be added to your theme’s functions.php file)

add_action('admin_init', 'no_mo_dashboard');
function no_mo_dashboard() {
  if (!current_user_can('manage_options') && $_SERVER['DOING_AJAX'] != '/wp-admin/admin-ajax.php') {
  wp_redirect(home_url()); exit;
  }
}