I’m back in the game baby!

Following the great news that we(my family) will be able to keep the broadband service i decided it’s about time i turn some of my personal plugins into plugins the community can benefit from.

Today i submitted two requests to host plugins on the WordPress.org repository. Two no frills plugins that allow some additional filtering on the administration page that lists your posts, pages or custom types.

PFF(Post Format Filter) will allow you to filter the post list based on post format and will operate with any post type that supports post formats.

PTF(Page Template Filter) will allow you to filter the page list based on page template, and again will operate with any post type that supports page templates.

Less sitting around, more production.. (ie. releasing code that’s useful to the community – after all, the community helped get me where i am today)..

As an aside, i pushed out a new update to the PUT plugin today…  again needing to wrap my head around SVN(amazing how quick you can forget things), which took me longer than writing the code updates(though in honesty i had already written most of the new code in advance).


Mark “happy to still be here” Duncan … aka t31os

Bye, have fun without me!

UPDATE: Fortunately we’ve been able to agree on a slower Broadband package with our provider whilst keeping within the budget. I won’t be going anywhere just yet!

YAY!!!! 🙂 🙂


My first plugin on WordPress Extend

Recently i came across a question on WPSE about hacking a plugin called WordPress Post Tabs to allow disabled tabs when a tab had no content. After having a quick look over the plugin i was quite displeased at the way it was coded and gave up after making a quick hack attempt to enable disabled tab functionality, “It’s just not good enough” i said to myself, something this simple shouldn’t be so hard to implement, i’ll have to write a plugin to do it..

And i did.. (after some woes understanding how to use the repo and svn).

My first ever plugin hosted on the WordPress repository, Post UI Tabs or PUT for short.


Create stylish jQuery UI Tabs inside posts, page or custom post types using simple shortcodes. Choose from 1 of the 25 different jQuery UI styles or go Jedi and define your own CSS.


  • Smart CSS and Script loading
    Only loads CSS and JS when there’s a post in the loop with the shortcode
  • Skin selection
    Choose from a list of jQuery UI styles
  • Disable skin loading
    Optionally turn off stylesheet loading, and just define your own
  • Disabled tabs
    Disable clicking on tabs that do not have any content yet
  • jQuery cookie
    Enable the jQuery cookie script to track selected tabs
  • Tab navigation
    Display clickable links to navigate between tabs
  • Loading on archive pages
    Choose whether to display the tabs on non-singluar pages
  • Translation ready
    Supports other languages (though i need translations if anyone is up for it?)
  • Live style preview
    See a live preview of tab styles in the plugin settings page
  • Action & Filter hooks for code hackers
    Utilises WordPress actions and filters to allow custom hacks
  • Uses the WordPress Settings API
    If plugins you use aren’t using it, you ought to be asking why!


Here’s a temporary screenshot from my local dev environment.


You can download the plugin from WordPress Extend or alternatively just search for Post UI Tabs from the Add New plugin page in your WordPress administration area.

Feedback & Feature Requests

If you have any feedback or features you’d like to see added into PUT feel free to drop a comment on the end of this blog.

Bugs / Support?

Found something wrong with the plugin or need help getting it working right?

Please start a support topic on the WordPress.org forums.

Tweaking WPSE CSS

Wanted to post an image of what i’m currently running on WPSE in terms of custom CSS.

Ave at ya!..

Image is around 1.2mb, so might take some time for people on slower connections(a smaller, lower quality image wouldn’t do the designs any justice).

Conditional tags on init?

I was recently answering a question on WordPress StackExchange and the question of appropriate hooks came up when suggesting where to hook on your styles or scripts when you’re needing to check conditional tags, those such is_page(), is_category, and so on..


It was my impression, that both wp_print_scripts and wp_print_styles were front facing page actions that occur at a time equivalent to their admin counterparts and a query was raised by Rarst whether this is an appropriate place for enqueues..

The codex also suggests init as appropriate for enqueues.

Warning: You can only use conditional query tags on or after the init action hook in WordPress. For themes, this means the conditional tag will never work properly if you are using it in the body of functions.php, i.e. outside of a function.

I decided to write a PHP class as an example to get the results of hooking onto different actions because i was sure init was too early.

	class conditional_tags_check {
		private $results = array();
		public function __construct() { 
			add_action( 'wp_head',            array( $this, 'conditional_check' ) );
			add_action( 'template_redirect',  array( $this, 'conditional_check' ) );
			add_action( 'wp_enqueue_scripts', array( $this, 'conditional_check' ) );
			add_action( 'wp_print_styles',    array( $this, 'conditional_check' ) );
			add_action( 'wp',                 array( $this, 'conditional_check' ) );
			add_action( 'init',               array( $this, 'conditional_check' ) );
			add_action( 'wp_print_scripts',   array( $this, 'conditional_check' ) );
			add_action( 'wp_footer',          array( $this, 'output' ) );
		public function conditional_check() {
			$action = debug_backtrace();
			$action = $action[2]['args'][0];
			$this->results[] = "$action :" . ( is_page() ? 'yes' : 'no' );
		public function output() {
			echo implode( "\n<br />", $this->results );
	$conditional_tags_check = new conditional_tags_check;

I’ve purposely put the add action calls into a random order so you can see the natural order of the actions appear in the results(naturally the action occuring first will be the first result, and so on..).

The results for me came out as.

init :no
wp :yes
template_redirect :yes
wp_enqueue_scripts :yes
wp_print_styles :yes
wp_print_scripts :yes
wp_head :yes 

Init is the only action that fails the test, and shows “no”, where as all others appear to run late enough to determine the request is for a page(i was of course viewing a page). The above conditional tag could be replaced by any other and replicated to show that under each condition init fires too early to determine the kind of request(page, category, tag, single, etc..).

For reference the actions shown above fire in this order.

  1. init
  2. wp
  3. template_redirect
  4. wp_print_styles
  5. wp_print_scripts
  6. wp_enqueue_scripts
  7. wp_head

Can anybody see any problems with the test code or disagree? Drop me a comment..

Firefox 4.0, UX done wrong

After many years of being an avid and loving user of Firefox i’ve unfortunately been confronted with what i’d deem some of poorest UX decisions i’ve seen in Firefox ever, and can only hope the developers see sense before 4.0 is released in early 2011(so rumor has it).

This is what you can expect to see in Firefox 4.0 when you’re wondering where the hell link information is displayed..

Firefox 4.0 Beta 7 - New link url location
Seriously? The location bar? Meh..

Never in my time using Firefox have i come across a change that has caused me so much displeasure..

This problem seems to stem from a decision to replace the current “Status Bar” with an “Addon” bar, which apparently makes all the difference in terms of performance (or something like that).

The solution apparently is to install an extesion to put things back how they were, WHAT!… you want me to install an additional addon (on top of the ones i have), so the browser is back to “NORMAL!” …

To add insult to injury, not only is the URL you’d expect to find in the staus bar now in the location bar, but you no longer have the loading bar indicator, instead a Windows Vista style swirling circle is shown in the active tab..

My main issue with both of these features is that when i browse/use the web i tend to look to the bottom area of the browser for statistical information about the current page, whether it’s loading, which URL it’s fetching (or hanging on, whatever).. I’m now expected to look to the opposite side of my screen for that information (and that’s not an easy or comfortable change at all). I’m not yet able to see any benefits these items have from being in the upper area of the browser (there’s less room, and they are harder to see/spot/read/notice).

Fortunately, i keep 3.6.8 installed for when i need it, so if the changes drive me insane i’ll just load that up…. i just really hope i won’t feel forced to choose another browser in 2011, as there’s simply no way i’m going to continue to use Firefox if the team is going to continue making poor UX decisions like these two.

Comparison images of the two areas in question.

I pray this is changed by the time 4.0 is out..

What do you guys think? Is this a poor UX decision? Am i just picky, or do you agree?

Google Ole Style

I’m not sure about anyone else, because i imagine most of you are on super duper dual core processors or better, but personally i’m on a celeron laptop.

When it comes to using google images, it’s awful, the page just jumps about and switching back and forth between results is, well….. rubbish..

So i went looking for a way to use the original search (non-ajaxed), and stumbled onto a link.


Original search, bit with a strange twist, if anything it’s at least funny to use..


t31os' blog