By

Better Theme Activation Handling

Here at Press Coders we are never happy with making do with the same old functionality. We constantly re-evaluate the way we do things and always look to improve on user experience. So, what have we been up to?

Well, one thing that bugs us is that when activating a theme for the first time your site can typically look less than amazing. That is until you create some content and complete some initial configuration including:

  • Posts
  • Pages (About Us, Contact Us, Sitemap etc.)
  • Navigation Menu (and setting the Theme Location)
  • Widgets and adding them to widget areas

Wouldn’t it be cool to be able to (optionally) install this content automatically when activating a theme on a new site?

Yes, we thought so too, and that’s why we added it to our theme framework! ;)

The actual code of creating the default content will be left to another post. In this post we want to focus on what happens on the theme activation side, and demonstrate how our framework makes it a snap to change this behavior when activating the theme.

Let’s see what a bog standard theme activation looks like.

OK, so here we have added an extra admin notice to show we have activated a theme, and even thrown in a link to the theme options page for good measure. But it still isn’t great.

For one thing, the default activation message feels a little outdated. I mean, what theme doesn’t support widgets these days? So let’s start by removing this default activation message. We are safe to do this because we know that all our current and future themes will ALWAYS support widgets.

How do we do this exactly? Well, we need to make sure our code runs when a theme is activated. There is no built-in WordPress hook for this (seriously) but we can use the following to achieve the same thing.

1
2
3
4
5
global $pagenow;
if ( is_admin() && isset($_GET['activated']) && $pagenow == "themes.php" ) {
	 /* Show theme activation message, and setup them option defaults. */
	add_action( 'admin_notices', array( &$this, 'theme_activated' ) );
}

We can add code to the ‘theme_activated’ callback function that will be executed every time a theme is activated. You may have noticed that this callback is referenced via class method syntax. This is because we are using classes rather than standard functions, thus the callback references need to be modified slightly.

Inside our callback function we have a line of jQuery code to remove the standard WordPress theme activation notice.

1
2
3
4
5
6
7
?>
<script type="text/javascript">
	jQuery(document).ready(function($) {
		$('#message2').css('display', 'none');
	});
</script>
<?php

Now that is gone we can add our own message when the theme is activated.

This is getting a little better now. We have a more relevant message with some buttons to go to the site home page, or theme options page.

But what about the default content mentioned earlier? Well, in the functions.php file we have two constants (INSTALL_DEFAULT_CONTENT, and INSTALL_CONTENT_PROMPT) that we can alter to change the activation message/behavior.

When INSTALL_DEFAULT_CONTENT is set to FALSE (the default setting) the above theme activation message is shown. But when it is set to TRUE we see a new activation message.

You can decide whether to install the default content or just go straight to the theme options page (or any other page you want to). To prevent accidental installation of default content the is an alert box that pops up to make sure you want to go ahead.

And if you do choose to install the default content, you get a confirmation message after completion.

The second constant, INSTALL_CONTENT_PROMPT, is only relevant if INSTALL_DEFAULT_CONTENT is set to TRUE. It is used to decide whether the default content to be installed should be installed automatically or prompt the user first.

We have already seen the effect of having INSTALL_CONTENT_PROMPT set to TRUE above where the default content is ONLY installed if the user specifies. If set to FALSE then the default content is installed silently in the background.

In this case the activation message is the same as before (see screenshot below) when INSTALL_DEFAULT_CONTENT was initially set to FALSE.

Why bother to install default content in the background without giving the user a choice? Well this option is pretty useful in situations where you ALWAYS want to make sure default content is installed every time a theme is activated. We already have one clear use in mind for this feature, for a proposed theme test area. Users will be able to sign up for an account and get full admin access to a blog where they can try out any of our themes.

In this scenario, it suddenly becomes clear that being able auto-install default content upon theme activation is pretty useful. This is a great way to show off a theme to its full potential right from the start, without the user having to do any initial configuration.

The theme activation feature discussed in this post is really still a work in progress, and the final implementation will almost certainly change before we use this in a production theme. But, we were pretty excited by this new addition to our theme framework, and wanted to share our development progress!

So let us know what you think in the comments. Would you find this feature useful?

By

Testimonials WordPress Custom Post Type

Coming soon to a Press Coders theme near you… A Testimonial custom post type!

We created a testimonials WordPress custom post type to give us a ‘real world’ example to work with whilst we were experimenting with how these work inside of WordPress. It is our first attempt at using this awesome feature of WordPress, and it definitely won’t be our last. We have learned an awful lot the last few days tinkering around with custom post types, and custom taxonomies etc. It has been a real eye opener. It’s official, we have the custom post type bug now!

In fact, we already have another custom post type well under development that will make using content sliders in our themes an absolute dream! But more on that another time. Shhh… ;)

Click on the video below to see the testimonial custom post in action, and how all the features fit together, plus how the testimonial custom post types you create are actually used rendered on the front end of your site.

We have no firm plans to add the testimonial custom post type in our next theme, but with a little more polish it is going to find its way into one of themes sooner or later.

Let us know what you think, what custom post types you would love to see. The possibilities are endless. Inspire us, and we might just create a custom post type from your ideas!

By

Enqueue Scripts and Styles on CPT Editor Page

I’ve finally(!) got around to using custom post types, and I’m having a blast. I really wish I had looked into them sooner, they are so cool. The possibilities really are endless, and boost the capabilities of WordPress significantly.

Anyway, this post is about an interesting problem I ran into whilst creating my first CPT (custom post type). The editor for the CPT in question is only ever going to be used to enter a couple of sentences, so it really only needs to have a small height. The default height is way to big and so the other meta boxes on this CPT are pushed down the page.

The solution? Well, it is fairly easy to add custom CSS that will target just the post.php or post-new.php pages in the WordPress admin. However this has the side effect of altering the post editor for ALL post types. Not great.

So, I spent some time looking for a reasonable way that I could enqueue styles that would work for specific CPT’s. After a bit of experimentation I came up with a solution that I could probably reuse. So I created a wrapper function for wp_enqueue_style() that you can use to pass your CPT name along with the usual enqueue parameters, and it will magically enqueue your style ONLY on the CPT editor page that you specify! Cool huh?

Right, let’s take a look at some code..

First off, let’s target the general admin editor pages to run a callback function when either the post.php or post-new.php are loaded. This is pretty standard stuff.

1
2
add_action("load-post.php", array( &$this, 'custom_post_type_editor' ) );
add_action("load-post-new.php", array( &$this, 'custom_post_type_editor' ) );

The custom_post_type_editor() callback function is where we add the call to our enqueue function.

1
2
3
4
5
6
7
function custom_post_type_editor() {
	$cpt = 'my_custom_post_type'; /* Custom post type. */
	$handle = 'my_style';
	$src = get_template_directory_uri().'/css/my_style.css';
 
	wp_enqueue_admin_cpt_style( $cpt, $handle, $src );
}

Aha! This isn’t the usual wp_enqueue_style() function. Like I said earlier, it is a wrapper function. We call the new enqueue function as you do the normal wp_enqueue_style() function, except you also pass in the CPT name as the first parameter. The CPT name is the same one that you specified in register_post_type(). The new enqueue function supports all the usual parameters plus the additional one for the CPT name you want to target.

OK, now for the good stuff. The all important new enqueue function.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
public function wp_enqueue_admin_cpt_style( $cpt, $handle, $src = false, $deps = array(), $ver = false, $media = 'all' ) {
 
	/* Check the admin page we are on. */
	global $pagenow;
 
	/* Default to null to prevent enqueuing. */
	$enqueue = null;
 
	/* Enqueue style only if we are on the correct CPT editor page. */
	if ( isset($_GET['post_type']) && $_GET['post_type'] == $cpt && $pagenow == "post-new.php" ) {
		$enqueue = true;
	}
 
	/* Enqueue style only if we are on the correct CPT editor page. */
	if ( isset($_GET['post']) && $pagenow == "post.php" ) {
		$post_id = $_GET['post'];
		$post_obj = get_post( $post_id );
		if( $post_obj->post_type == $cpt )
			$enqueue = true;
	}
 
	/* Only enqueue if editor page is the correct CPT. */
	if( $enqueue )
		wp_enqueue_style( $handle, $src, $deps, $ver, $media );
}

Let’s step through what this function does.

  • Firstly, you will notice that you’ve got access to all the parameters available in the normal wp_enqueue_style() function. This is important for general use even though I am not using all the parameters in my particular CPT.
  • Next we reference the global $pagenow variable to grab the current admin page we are on, and initialize an enqueue flag variable to null.
  • This is followed by two tests for the admin page being viewed. The first test checks for new posts being created that are of a specific post type. If it finds a match with the one you passed in it sets the enqueue flag to true.
  • The second test is slightly more tricky as we need to test the post ID of the post being edited on post.php and check it matches our CPT.
  • If either test is successful the enqueue flag is set and our style sheet is enqueued ONLY on the post editor associated with our specified CPT!
  •  

    Whilst I was at it I couldn’t do a wrapper function for wp_enqueue_style() and not do one for wp_enqueue_script()! So here is the equivalent function for enqueueing scripts on a specific CPT admin editor page.

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    
    public function wp_enqueue_admin_cpt_script( $cpt, $handle, $src = false, $deps = array(), $ver = false, $in_footer = false ) {
     
    	/* Check the admin page we are on. */
    	global $pagenow;
     
    	/* Default to null to prevent enqueuing. */
    	$enqueue = null;
     
    	/* Enqueue script only if we are on the correct CPT editor page. */
    	if ( isset($_GET['post_type']) && $_GET['post_type'] == $cpt && $pagenow == "post-new.php" ) {
    		$enqueue = true;
    	}
     
    	/* Enqueue script only if we are on the correct CPT editor page. */
    	if ( isset($_GET['post']) && $pagenow == "post.php" ) {
    		$post_id = $_GET['post'];
    		$post_obj = get_post( $post_id );
    		if( $post_obj->post_type == $cpt )
    			$enqueue = true;
    	}
     
    	/* Only enqueue if editor page is the correct CPT. */
    	if( $enqueue )
    		wp_enqueue_script( $handle, $src, $deps, $ver, $in_footer);
    }

    Call this function in the same place as we did for wp_enqueue_admin_cpt_style() with:

    1
    
    wp_enqueue_admin_cpt_script( $cpt, $handle, $src );

    That’s it! I found these functions really useful and I know I will be re-using them again in the future. I hope you find a use for them too. Let me know in the comments if you do, I will be interested to hear.

By

FitPro 2.1 Released!

A new version of FitPro is now available that has some bug fixes, new features, and is fully compatible with WordPress 3.2.1. To download the latest version simply login to your Press Coders control panel and download the zip file from there.

To help you upgrade with the minimum of fuss you can also find an upgrade document (pdf) in the FitPro forum, at the top as a sticky thread.

Some of the new features include:

  • A ‘Reset Options’ button so you can revert your theme options to the defaults at any time.
  • A custom styles text box where you can enter your CSS commands directly, to have fine grained control over your site.
  • Info box widget now has an optional search field too.
  • The Sidebar Commander feature has moved from theme options to the Appearance->Widgets page.

If you are new to FitPro and haven’t tried it out yet, why not take the live demo for a spin and see what you think of it? Click the image above to go directly to the live demo where you can see try out all the great features of FitPro first hand.

Alternatively, you can find out why we think FitPro is such a great theme so click here to see all the juicy details!

By

WordPress Integration with Ext JS 4

The EXT JS 4 library from Sencha is a powerful Javascript framework for building rich and interactive UI’s for web applications.

Here at Press Coders we have been experimenting with the new version of Ext JS and are now starting to integrate our efforts into WordPress 3.1 as well. Read More

By

Still No jQuery Accordion in WordPress 3.1?

Update: Just posted a ticket to core trac. Response was that new JavaScript libraries tend to only get included if they are used in WordPress core, which explains why it isn’t added (yet). I think that it should be considered though because of its usefulness, and tiny file size!

There seems to be a bit of a shake up in the jQuery UI files included with WordPress 3.1. Firstly there is a new UI version (1.8.7), rather than 1.7.3 which was included in WordPress 3.0.4.

Also, the jQuery core files have been broken out of the single ui.core.js file into four separate files: ui.core.js, ui.mouse.js, ui.position.js, ui.widget.js. This makes it a little clearer what core UI components are included with WordPress. You can see this more clearly in the screen shot below. The core files are outlined in red.

There are two new UI widgets available in jQuery, and one of these, the button widget, has made it into WordPress 3.1. The autocomplete didn’t make it in. This is not a surprise as this might not be required that much at the moment, but users may need this as more autocomplete examples pop-up around the web.

I am a little disappointed though at the lack of inclusion of the accordion widget which has been around for a while now, and is a very useful addition to your web pages. There may be a good reason for this, that I am not aware of, but at just 9 KB it is very small and could be included without anyone hardly even noticing!

I use a lot of jQuery accordions for theme/Plugin options pages and find it a hassle to have to add in the accordion widget manually. It is not really a big issue, but it’s conspicuous by its absence. Anyone else know why it is not shipped along with the other WordPress jQuery files? Let me know in the comments if you do.

Oh, and the datepicker widget would be nice too. However this is around 35 KB so might be seriously considered for now. Anyway, just imagine being able to pick the date from the nice jQuery datepicker rather than have to manually enter the date/time as you do now. ;)

By

Find the Admin URL in WordPress 3.0

The other day I was looking for a way to get the URL to the installed WordPress admin folder. I was almost certain that I would have to ‘construct’ this URL manually. This wasn’t a problem I had done similar tasks many times before.

But to my pleasant surprise I found a nifty little function called get_admin_url(), which I didn’t know existed. This is probably as it is a new addition to WordPress 3.0. The function can be found in the /wp-includes/link-template.php file at line number 1950. You can see the full source code here.

Looking at the core code it is obvious that this function was written with a more general purpose in mind. In fact it returns the WordPress admin URL of multi-site blog with a specific ID. If you don’t specify a particular ID then it returns the current blog admin URL.

Interestingly, there is another closely related function called admin_url() which returns the admin URL of the current blog only. The difference between the two is that you can’t specify a blog ID with this function.

If you only need to get the admin URL of the current blog (as I did) then you can use either function with no parameters, and they will both return exactly the same result. It’s just a matter of preference.

Looking through the /wp-includes/link-template.php file I noticed that there were a few other new functions added to WorPress 3.0 for returning WordPress links.

Here is a quick summary (including links to the source code) of all the new link related functions in link-template.php:

By

Minimise Admin Bar Plugin

Now available to download from the repository.

OK, it’s been a while since our last Plugin release, so we are pleased to announce a brand new one hot off the press! What does this one do? Well, if you have used a beta version of WordPress 3.1 you will know that on the front end of your blog pages you now have displayed, by default, an admin bar. A screen shot of this is shown below.

The admin bar gives you a menu full of quick links to your WordPress admin panel. A lot of users don’t seem to like the admin panel displayed at the top of every page, and so seek ways to disable it or remove it. You can easily disable it on a per user basis via a users profile page, as shown below.

However this is not that useful if you want to remove it site-wide. The Admin Bar Minimiser Plugin was written to help users keep the admin bar active but be able to minimise it at any time to make it less obtrusive. You can see a demo of the Plugin in action in the following video:

As you can see, the Plugin works by allowing you to minimise the admin bar from view via a single click. You can bring it back just as easily. This also works for the admin bar displayed on the WordPress back end too.

Don’t forget though, to be able to minimise the admin bar on the WordPress back end too, you will need to enable it for the currently logged in user. This is because the admin bar is not enabled by default for WordPress admin pages. However it is for front end pages.

The Plugin will be live in the WordPress repository soon, we are just waiting for the Admin Bar Minimiser SVN repository to go live.

Since the demo video above was recorded I have added an options page for the Plugin. This allows you to set whether the front end, and back end shows the admin bar maximised by default. I would love to hear what you think about the Plugin, and how useful you think it is going to be to you once WordPress 3.1 is here.

By

Installing WordPress 3.0 Multisite/Network!

This post covers the brand new multisite/network feature in WordPress 3.0, which was previously called WordPressMU (and was a separate project, the two have now been merged in WordPress 3.0). To follow along you will need to be running WordPress 3.0 or higher.
Read More

By

Our Recent Activity

Just an update on our recent activity. As someone pointed out to me just yesterday the blogs have been fairly quiet since May. Well true, but this certainly does not mean that we have been idle, far from it!
Read More