By

*Updated Plugin* To Do List

After languishing in the WordPress.org Plugin repository for almost three years the To Do List Plugin has finally been updated! In fact it has been completely rewritten and is now fully compatible with the latest version of WordPress (3.4 at the time of writing).

This major update is pretty much what I had in mind for the original version of the Plugin. So, what’s new?
Read More

By

*New Plugin* Config Constants

Most people never need to edit the WordPress constants in wp-config.php but if you do then up until now there was no alternative but to edit the file manually.

However, the Config Constants Plugin changes this by allowing you to modify a select set of WordPress constants directly from the WordPress admin!

The Plugin options page looks like this:

You can only modify constants that are already defined in wp-cofig.php so you remain in full control of your configuration file at all times.
Read More

By

Deactivating a WordPress Plugin Automatically

With every release of WordPress there are so many cool new features to play with. This usually a good thing but one downside is that if you want to incorporate them straightaway into your Plugin it can break versions of WordPress that haven’t upgraded yet.

I had exactly this issue when adding some new code to my Plugin Options Starter Kit Plugin.

I added two new text areas to the Plugin options form that use the built-in WordPress editor. This is made possible by the fantastic wp_editor() function, which is only available in WordPress 3.3 (see my post on this function here). However, a lot of users who are already running this Plugin may not have upgraded to WordPress 3.3 (when it is released) by the time I post the Plugin update on WordPress.org.

So where does this leave you? How can you safeguard against Plugin incompatibility with a users version of WordPress. You could insert a simple die() function, but we can do better than that!

Check out the code below that generates the above message, safely deactivates the incompatible Plugin, and provides a convenient link back to the WordPress admin.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
function posk_requires_wordpress_version() {
	global $wp_version;
	$plugin = plugin_basename( __FILE__ );
	$plugin_data = get_plugin_data( __FILE__, false );
	$require_wp = "3.5";
 
	if ( version_compare( $wp_version, $require_wp, "<" ) ) {
		if( is_plugin_active($plugin) ) {
			deactivate_plugins( $plugin );
			wp_die( "<strong>".$plugin_data['Name']."</strong> requires <strong>WordPress ".$require_wp."</strong> or higher, and has been deactivated! Please upgrade WordPress and try again.<br /><br />Back to the WordPress <a href='".get_admin_url(null, 'plugins.php')."'>Plugins page</a>." );
		}
	}
}
add_action( 'admin_init', 'posk_requires_wordpress_version' );

So, what’s going on here?

First, we grab the current version of WordPress stored in the global $wp_version variable. Next, we have two lines of code to store the plugin folder/filename, and the name of the Plugin itself.

Now for the important bit. We use version_compare() to check we are running WordPress 3.3 or higher. If you want to check for a different version just change ‘3.3’ to a different value. If your installed version of WordPress is not compatible with the Plugin then we can go ahead and deactivate the Plugin, output a message, and halt the script.

Let’s check our Plugin is actually activated before we try to deactivate anything. We do this with the is_plugin_active() function. We need to pass in the Plugin folder and filename, which we stored in $plugin earlier. A value of true will be passed back if the Plugin is active.

Once we have confirmation that we can go ahead and deactivate our Plugin we just need to call the deactivate_plugins() function and pass it $plugin. This will actually deactivate the Plugin. The final step is to just call wp_die() with a suitable message. I have also added a link back to the WordPress admin for convenience.

You may be wondering why I am adding the code to a function and triggering it via the ‘admin_init’ action hook. Why not just add it outside of a function at the top of the Plugin file?

This is because of the is_plugin_active() function. If you try to call it outside of a function somewhere in your Plugin file, then it won’t have been defined by WordPress yet and a fatal ‘Call to undefined function’ error will be generated. This will also happen if you try to hook the function too early. Try replacing the ‘admin_init’ hook with ‘plugins_loaded’ instead to see what I mean. As long as you hook the function with ‘admin_init’ though everything should be fine.

The function is generic enough to be dropped into any existing Plugin and work right out of the box (neat huh?). The only thing you might need to adjust is the version of WordPress you want to test against.

I hope you find this code snippet useful. As usual let me know what you think in the comments.

By

How to Reuse the Post Editor in WordPress

If you have been following along with the development of WordPress 3.3 beta you may already be aware of the great new function wp_editor(). It really is a game changer. The WordPress core team deserve a real pat on the back for this one. So what’s all the fuss about?

The problem before WP 3.3 was that if you wanted to reuse the built-in editor, used on posts and pages, you had a real battle on your hands to get it to work. It was just too much hassle for the benefits gained.

In fact, the last time I looked into this I gave up and included the CKEditor JS library instead, as that was really easy to implement. This worked pretty well but not really ideal as the CKEditor library is quite weighty to include with your theme/Plugin.

What I REALLY wanted was be able to use the built-in editor that shipped with WordPress. And now I can! The new wp_editor() function has made the hideously difficult task of re-using the editor ridiculously easy. It’s just so easy now to throw editors at every text area in the WP admin you can shake a stick at, and it will work reliably and consistently every time. How cool is that?

In this post I’ll be creating a simple Plugin and show you how to add two separate instances of the WP editor on the Plugin options page. You will be able to grab the code for the whole Plugin at the end of the post.

But first, please bear with me whilst I go through the motions of setting up the Plugin structure. Don’t worry we’ll get to the good stuff soon enough. With this in mind I’m not going to go through every fine detail of the functions needed to set-up a Plugin. I just want to focus on the reusability of the WP editor.

First, let’s register our settings, as we will be using the WordPress Settings API to handle our Plugin options. The code for this is pretty straightforward.

1
2
3
4
5
// Init plugin options to white list our options
function wpet_init(){
	register_setting( 'wpet_plugin_options', 'wpet_options', 'wpet_validate_options' );
}
add_action('admin_init', 'wpet_init' );

Now we need an admin page for our Plugin. Again, this is standard stuff.

1
2
3
4
5
// Add menu page
function wpet_add_options_page() {
	add_options_page('WP Editor Test', 'WP Editor Test', 'manage_options', __FILE__, 'wpet_render_form');
}
add_action('admin_menu', 'wpet_add_options_page');

This will add a Plugin options page under the Settings top level menu with the title ‘WP Editor Test’. Now for the good part.
We need a function to render the form, but let’s break this down a bit. To start with, the Plugin options form uses the post method, with option.php used for the action attribute. Inside the form tags, and before any form fields are rendered let’s add two lines of code to handle all the Settings API details for us.

1
2
settings_fields('wpet_plugin_options');
$options = get_option('wpet_options');

Now we can render all our form fields safe in the knowledge that the Settings API is looking after us and giving us all the correct values and settings. We just need one Plugin option for now, a simple text area.

1
<textarea id="wpet_options[textarea_three]" name="wpet_options[textarea_three]" rows="7" cols="150" type='textarea'><?php echo $options['textarea_three']; ?></textarea>

All we need to do now is add a form submit button so all the loading/saving of the text area content will be handled for us! Sweet.

1
2
3
4
5
6
7
8
9
<p class="submit"><input type="submit" class="button-primary" value="<?php _e('Save Changes') ?>" /></p>
</p>
 
OK, so this is all fine and good for bog standard text areas but what about using the funky WP editor as a replacement? This is way easier than you might think. You’re gonna love this.
Simply replace the text area tag above with:
 
<pre lang="php" line="1">
$args = array("textarea_name" => "wpet_options[textarea_one]");
wp_editor( $options['textarea_one'], "wpet_options[textarea_one]", $args );

Basically, all you need to do is call the wp_editor() function and pass it an ID and some optional arguments. The first parameter is the actual content of the text area which we are pulling from the options db table, via the Settings API. Next we add in the ID of the text area as the second parameter. Finally, the third parameter accepts an array of settings you can use to customise the editor.

In this example we are just specifying one array parameter in $args which sets the name of the text area too. These are both the same in this case so we could have actually left this out altogether, as ‘textarea_name’ defaults to the ID name. I explicitly left it in as it’s a good idea to see what’s happening, on a first exposure.

Note: There is currently no WordPress Codex page for wp_editor() at the time of writing (November, 2011) so you will have to dig around the WordPress core to find out more about the parameters available.

Right, want more editors? You got it. We can easily add another instance of the WP editor. Check this out:

1
2
$args = array("textarea_name" => "wpet_options[textarea_two]");
wp_editor( $options['textarea_two'], "wpet_options[textarea_two]", $args );

Just make sure that you change the ID and name parameters to point to a new text area and bingo, we have two separate instances of our editor. That’s almost too easy!

You might have noticed that when we defined the register_setting() function the third parameter was specified as the ‘wpet_validate_options’ callback function. This is a validation function that you can pass your text area content through as it is saved. The callback is defined in the Plugin as:

1
2
3
4
5
6
function wpet_validate_options($input) {
	// Sanitize textarea input (strip html tags, and escape characters)
	//$input['textarea_one'] = wp_filter_nohtml_kses($input['textarea_one']);
	//$input['textarea_two'] = wp_filter_nohtml_kses($input['textarea_two']);
	return $input;
}

I have commented out the lines to validate and strip HTML tags as I want to keep the formatting. This validation function is really useful when you DO want to remove tags from text areas.

The full Plugin code is shown below. Copy it into a text file, save it as wp-editor-test.php, and add to your ‘/wp-content/plugins/’ folder. Just activate it, and visit the Plugin options page under the Settings menu.

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
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
<?php
/*
Plugin Name: WP Editor Test
Plugin URI: https://www.presscoders.com/
Description: Test Plugin to get the WP editor working on a Plugin admin page.
Version: 0.1
Author: David Gwyer
Author URI: https://www.presscoders.com
*/
 
// Init plugin options to white list our options
function wpet_init(){
	register_setting( 'wpet_plugin_options', 'wpet_options', 'wpet_validate_options' );
}
add_action('admin_init', 'wpet_init' );
 
// Add menu page
function wpet_add_options_page() {
	add_options_page('WP Editor Test', 'WP Editor Test', 'manage_options', __FILE__, 'wpet_render_form');
}
add_action('admin_menu', 'wpet_add_options_page');
 
// Render the Plugin options form
function wpet_render_form() {
	?>
	<div class="wrap">
		<div class="icon32" id="icon-options-general"><br></div>
		<h2>WP Editor Test</h2>
		<form method="post" action="options.php">
			<?php settings_fields('wpet_plugin_options'); ?>
			<?php $options = get_option('wpet_options'); ?>
 
			<table class="form-table">
				<tr>
					<td>
						<h3>TinyMCE - Editor 1</h3>
						<?php
							$args = array("textarea_name" => "wpet_options[textarea_one]");
							wp_editor( $options['textarea_one'], "wpet_options[textarea_one]", $args );
						?>
					</td>
				</tr>
				<tr>
					<td>
						<h3>TinyMCE - Editor 2</h3>
						<?php
							$args = array("textarea_name" => "wpet_options[textarea_two]");
							wp_editor( $options['textarea_two'], "wpet_options[textarea_two]", $args );
						?>
					</td>
				</tr>
				<tr>
					<td>
						<h3>Textarea - Editor 3</h3>
						<textarea id="wpet_options[textarea_three]" name="wpet_options[textarea_three]" rows="7" cols="150" type='textarea'><?php echo $options['textarea_three']; ?></textarea>
					</td>
				</tr>
			</table>
			<p class="submit">
			<input type="submit" class="button-primary" value="<?php _e('Save Changes') ?>" />
			</p>
		</form>
	</div>
	<?php	
}
 
// Sanitize and validate input. Accepts an array, return a sanitized array.
function wpet_validate_options($input) {
	// Sanitize textarea input (strip html tags, and escape characters)
	//$input['textarea_one'] = wp_filter_nohtml_kses($input['textarea_one']);
	//$input['textarea_two'] = wp_filter_nohtml_kses($input['textarea_two']);
	//$input['textarea_three'] = wp_filter_nohtml_kses($input['textarea_three']);
	return $input;
}

Note: The code in this post applies to WordPress 3.3 beta 2 which may see some tweaks to the way wp_editor() works before final release. So if you implement any code from this post in your own Plugins then make sure it still works in WP 3.3 final.

By

New Plugin – Format Media Titles

If you have ever uploaded many images/videos etc. via the WordPress media uploader you will now that it can be pretty tedious to have to manually edit the title for new media items.

‘Format Media Titles’ is a new Plugin to automatically format the media title for new uploads. It works by replacing characters such as hyphens, and underscores, with spaces. The title can then be capitalized by a method of your choice.

See the image below for a before and after view of the same image uploaded with and without the Plugin activated.

By

New Plugin: Display PHP Version

Just a quick post to let you know about a new Plugin we have just developed, called ‘Display PHP Version’. Read More

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

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

jQuery UI Widgets on Blog Pages

A little while ago I covered some important aspects of using the jQuery UI library inside of WordPress admin pages in the post entitled: jQuery UI in WordPress 3 Admin Pages.

This time, however, we will be focussing on how to add jQuery UI widgets into your WordPress posts/pages in a reusable way. All this will be wrapped up an a Plugin for portability. The Plugin will be uploaded to the WordPress.org Plugin repository and should be live soon, so you will be able to download it and use it on your own WordPress sites. Read More