Two template tags have been added:

If you have posts in multiple categories, you can use get_referrer_category() to retrieve the category object, based on the referrer url.

get_referrer_url() returns the full URL of the referrer.

Also, there are two extra arguments for previous_post_smart() and next_post_smart(): $in_same_cat and $excluded_categories.

This is how the function prototype looks like:

previous_post_smart(
	$format = '« %link',
	$title = '%title',
	$fallback = true,
	$in_same_cat = false,
	$excluded_categories = ''
);

No wp_footer() call

Lots of plugins, including this one, rely on the wp_footer() call to include their JavaScript files. Open your theme’s footer.php file and make sure you have this line somewhere:

<?php wp_footer(); ?>

Using the_title() in the wrong places

A mistake I see in a lot of themes is code like this:

<a href="<?php the_permalink() ?>" title="Permanent Link to <?php the_title(); ?>"><?php the_title(); ?></a>

This causes all sorts of problems. You should use the_title_attribute() instead:

<a href="<?php the_permalink() ?>" title="Permanent Link to <?php the_title_attribute(); ?>"><?php the_title(); ?></a>

No id & class attributes for dynamic sidebars

If you want to have editable text widgets, you’ll have to change code like this:

register_sidebar(array('name' => 'My Sidebar',
	'before_widget' => '',
	'after_widget' => '',
	'before_title' => '<h4>',
	'after_title' => '</h4>',
));

to this:

register_sidebar(array('name' => 'My Sidebar',
	'before_widget' => '<div id="%1$s" class="widget %2$s">',
	'after_widget' => '</div>',
	'before_title' => '<h4>',
	'after_title' => '</h4>',
));

You can use <li>s instead of <div>s. The important part is id="%1$s" class="widget %2$s".

Post thumbnail switching

If your theme supports native thumbnails (introduced in WordPress 2.9), you will be able to change them by double-clicking on them.

Editable options

Similarly to editable_images(), you can now have editable bits of text anywhere in your theme. For example:

<?php editable_option('blurb'); ?>
 
[...]
 
Today's mood: <?php editable_option('mood'); ?>

It’s like text widgets, without the widgets.

No more autogrow

If you’ve been using the basic text editor, you’ve probably had your share of frustration with the autogrow script. After switching from Autogrow to Growfield without much improvement, I’ve decided to stick to a normal textarea with a scrollbar.

The rich editor is not affected by this.

Configurable nicEdit

I’ve added two buttons to the rich editor panel: font-family and font-color. More importantly, you can now select which buttons you want to use. Just paste this code in your theme’s functions.php:

function configure_fee_nicedit($config) {
	$config['buttonList'] = array(
		'bold', 'italic', 'strikethrough',
		'left','center', 'right',
	);
	return $config;
}
add_filter('front_end_editor_nicedit', 'configure_fee_nicedit');

See the available configuration options.

Upgrade instructions

If you have custom code written for the plugin, read on:

Renamed hooks:

front_ed_fields -> front_end_editor_fields
front_ed_allow -> front_end_editor_allow
front_ed_disable -> front_end_editor_disable

Renamed CSS classes:

.front-ed -> .fee-field
.front-ed-{filter} -> .fee-filter-{filter}
.front-ed-container -> .fee-form

Since I use WP-UserOnline on all of my sites, I adopted it (along with WP-PageNavi) and will continue to support it.

Version 2.60 has a few noticeable enhancements:

When viewing the list of online users, admin pages will also have pretty titles, instead of URLs.

Clicking on a user’s IP addresses now takes you to a much more helpful page on domaintools.com instead of arin.net. As such, I decide to removed the country flag icons, since they slowed down page loads and were a hassle to set up.

Finally, to completely uninstall the plugin, it’s enough to delete it through the WordPress admin.

In this tutorial, I’m going to show you the best way to do that.

Let’s say you have a plugin that adds a custom shortcode. The shortcode needs some JavaScript code which requires jQuery.

If you’re just starting out with WordPress development, you might be tempted to write something like this:

How a WordPress Youngling does it

add_action('wp_head', 'add_my_script');
 
function add_my_script() { ?>
<script type="text/javascript" src="<?php bloginfo('wpurl'); ?>/wp-content/plugins/my-plugin/jquery.js"></script>
<script type="text/javascript" src="<?php bloginfo('wpurl'); ?>/wp-content/plugins/my-plugin/my-script.js"></script>
<?php }

Let’s see what’s wrong with that approach:

Firstly, since WordPress 2.6, the user can move the wp-content directory wherever he wants. What does that mean? That’s right: instant plugin breakage.

Secondly, if the user installs another plugin that also uses jQuery, the page will end up with jQuery being loaded twice.

Fortunately, WordPress lends us a hand with these two problems:

How a young Padawan does it

add_action('template_redirect', 'add_my_script');
 
function add_my_script() {
	wp_enqueue_script('my-script', plugins_url('my-script.js', __FILE__), array('jquery'), '1.0', true);
}

The above script ultimately does what the first one does, except:

• it gets the correct path for the file
• it checks if jQuery has already been included or not
• the script tag is written in the footer, so the page loads faster

That’s an obvious improvement. But what if the shortcode appears on a single page?

You’re needlessly including a file 99% of the time, causing slower page loads.

Notice that in the last two examples, we’ve been using the template_redirect action.

The trouble with wp_enqueue_script() is that you have to call it before wp_head() fires. So, before the page is rendered, you have to decide if you should add your script or not. Not an easy call to make, is it?

Well, there’s a secret method that will let you enqueue scripts after the entire page has been displayed.

The Jedi Knight way

add_action('wp_footer', 'print_my_script');
 
function print_my_script() {
	global $add_my_script;
 
	if ( ! $add_my_script )
		return;
 
	wp_register_script('my-script', plugins_url('my-script.js', __FILE__), array('jquery'), '1.0', true);
 
	wp_print_scripts('my-script');
}

In this case, the script will be enqueued only if the $add_my_script global was set at some point during the rendering of the page.

The key here is that you’re calling wp_print_scripts() directly, instead of relying on WordPress to do it for you.

It will still check if jQuery was already enqueued or not.

You can set the $add_my_script flag from any function or method, including from a shortcode handler:

add_shortcode('myshortcode', 'my_shortcode_handler');
 
function my_shortcode_handler($atts) {
	global $add_my_script;
 
	$add_my_script = true;
 
	// actual shortcode handling here
}

So, the script will be added if [myshortcode ...] was found in any of the posts on the current page.

Nothing more to do here, except wrap it up in a nice class:

The Jedi Master way

class My_Shortcode {
	static $add_script;
 
	function init() {
		add_shortcode('myshortcode', array(__CLASS__, 'handle_shortcode'));
		add_action('wp_footer', array(__CLASS__, 'add_script'));
	}
 
	function handle_shortcode($atts) {
		self::$add_script = true;
 
		// actual shortcode handling here
	}
 
	function add_script() {
		if ( ! self::$add_script )
			return;
 
		wp_register_script('my-script', plugins_url('my-script.js', __FILE__), array('jquery'), '1.0', true);
 
		wp_print_scripts('my-script');
	}
}
 
My_Shortcode::init();

I hope this tutorial has helped you on your way to mastering WordPress script loading.

Further reading:

• wp_enqueue_script() reference
• Using plugins_url()
• Shortcode API
• Jedi Ranks

PS: This post was prompted by this question from Artem.

The Menu Format

First off, there’s a new format called “menu”. It’s basically the year and month menu from the fancy format, but without the post list. It’s meant to be displayed on year and month based archives, to aid navigation.

Usually, those archives are handled by the archive.php template in your theme, so that’s where you should use it:

<?php smart_archives('format=menu'); ?>

New arguments

There are also two new arguments:

month_format – can be one of ‘numeric’, ’short’ and ‘long’

posts_per_month – set the number of posts displayed per month; by default, all posts are displayed.

<?php smart_archives('posts_per_month=25'); ?>

Finally, you can now customize the look and feel more easily. See Advanced Tweaking.

Custom styling

If you want to customize the appearance of the archives using your own CSS, here’s how you do it:

1. Add this code to your theme’s functions.php file:

add_filter('smart_archives_load_default_styles', create_function('', 'return false;'));

2. Copy everything from smart-archives-reloaded/inc/styles.dev.css into your theme’s style.css file.
3. Change the CSS in your theme’s style.css file, as needed.

Custom markup

If you want to go one step further and change the generated HTML markup, you can do that too (understanding of object inheritance is required).

First, take a look at the SAR_Generator class (in smart-archives-reloaded/generator.php).

In your theme’s functions.php file, you can extend that class, like so:

smart_archives_load_default_generator();
 
class SAR_Custom_Generator extends SAR_Generator {
	protected static function generate_fancy() {
		// your custom code here
	}
 
	protected static function generate_block() {
		// more of your custom code here
	}
 
	...
}

Then, all you have to do is add the ‘generator’ argument to the template tag:

<?php smart_archives('generator=SAR_Custom_Generator'); ?>

Besides tags and terms, you can now edit categories as well, using the same interface. They all have autosuggest enabled, to make it easier to work with.

Custom fields with multiple values can also be edited now. Here’s a code example:

<ul>
<?php
$values = get_editable_post_meta(get_the_ID(), 'my_key');
foreach ( $values as $value )
	echo '<li>' . $value . '</li>';
?>
</ul>

Finally, you can now edit all widget titles, not just titles of text widgets.

Other enhancements:

• optimized script loading
• fixed issue with Internet Explorer
• fixed issue with comment paragraphs
• fixed issues with the $post global

So instead of working to prevent this spread, why not encourage it? Why not get the ideas, capabilities, and functionality of any given piece of software out to as many people as possible and kindle the flame? There are many ways to make money, so why choose a method that requires investing just as much time and effort into making software that lots of people want to use as trying to prevent the usage of said software? It sounds counterintuitive and/or just plain stupid on paper, but is generally seen as the traditional and conservative way to do it. Physical products must be treated differently than knowledge.

In the WordPress world, people are constantly trying to find new business models that make sense in the context of GPL software. An interesting approach is the recently launched WP Questions site. Here’s how it works:

You ask a support question related to WordPress and put a price tag on it. Whoever answers your question gets that amount of money from you. Note that anyone can see the questions and the answers to them.*

What you’re paying for is not the knowledge itself – you could get that free of charge, by asking in the WordPress.org support forums. But by asking on WP Questions, you have a higher chance of getting a timely answer from one or more knowledgeable people, whereas in the WP.org forums your question could simply be overlooked or be given a half-baked answer.

I really think this could work. With the ever-growing user base of WordPress, a need for reliable, high-quality support is starting to appear. See WP Help Center for instance.

So what do you think? Will WP Questions still be here next year?

____

* …at least until an answer is approved. There’s a search field, but it would be nice if the site had a public archive of questions answered in the past.

This post contains technical information for developers who want to add their own editable fields.

We’re going to enable any option to be editable from the front-end.

The filter

The essential element of each editable field is a WordPress filter. You can use either an existing filter, or a custom one.

We’re going to use a new one:

function editable_option($key) {
	echo apply_filters('editable_option', get_option($key), $key);
}

As you can see, editable_option() simply wraps the value returned by get_option() in a filter.

In your theme, you can now write:

<p><?php editable_option('my_option'); ?></p>
 
<p><?php editable_option('my_other_option'); ?></p>

The class

Each editable field needs a class to handle retrieving and saving the edited content.

class My_Editable_Option extends FEE_Field_Base {
	/**
	 * The type of object we're editing
	 * @return string
	 */
	static function get_object_type() {
		return 'option';
	}
 
	/**
	 * Called when generating the HTML on the front-end
	 * Wraps the $content in special markup, if the user has the right permissions
	 * @return string
	 */
	function wrap($content, $key = 0) {
		if ( ! $this->check($key) )
			return $content;
 
		if ( empty($content) )
			$content = $this->placeholder();
 
		return parent::wrap($content, $key);
	}
 
	/**
	 * Called when a user double-clicks on an editable field
	 * Fetches the content to be edited
	 * @return string
	 */
	function get($key) {
		return get_option($key);
	}
 
	/**
	 * Called when a user clicks the "Save" button
	 * Saves the modified content and then returns it
	 * @return string
	 */
	function save($key, $content) {
		update_option($key, $content);
 
		if ( empty($content) )
			$content = $this->placeholder();
 
		return $content;
	}
 
	/**
	 * Called at each step
	 * Confirms that the current user has the right permissions to edit the field
	 */
	function check($key = 0) {
		return current_user_can('manage_options');
	}
}

As you can see, it’s pretty easy. There are a few other aspects that you can learn by looking at the built-in classes as reference. They can be found in the fields folder.

Connecting the dots

Now all we need to do is to connect the class to the filter. Here’s how you do this:

function register_my_field() {
	register_fronted_field('editable_option', array(
		'class' => 'My_Editable_Option',
		'title' => 'My Option',
		'type' => 'input',
		'argc' => 2
	));
}
add_action('front_end_editor_fields', 'register_my_field');

Here are the arguments you can set for register_fronted_field():

• class – the class which will handle the editing (mandatory)
• title – the field title (mandatory)
• type – input | textarea | rich (default: input)
• priority – the filter priority (default: 11)
• argc – number of args the filter accepts (default: 1)

Putting it all together

Here’s all the code put together. Add it to your theme’s functions.php and ‘My Option’ should appear in the list of fields on the plugin settings page:

function editable_option($key) {
	echo apply_filters('editable_option', get_option($key), $key);
}
 
 
class My_Editable_Option extends FEE_Field_Base {
	/**
	 * The type of object we're editing
	 * @return string
	 */
	static function get_object_type() {
		return 'option';
	}
 
	/**
	 * Called when generating the HTML on the front-end
	 * Wraps the $content in special markup, if the user has the right permissions
	 * @return string
	 */
	function wrap($content, $key = 0) {
		if ( ! $this->check($key) )
			return $content;
 
		if ( empty($content) )
			$content = $this->placeholder();
 
		return parent::wrap($content, $key);
	}
 
	/**
	 * Called when a user double-clicks on an editable field
	 * Fetches the content to be edited
	 * @return string
	 */
	function get($key) {
		return get_option($key);
	}
 
	/**
	 * Called when a user clicks the "Save" button
	 * Saves the modified content and then returns it
	 * @return string
	 */
	function save($key, $content) {
		update_option($key, $content);
 
		if ( empty($content) )
			$content = $this->placeholder();
 
		return $content;
	}
 
	/**
	 * Called at each step
	 * Confirms that the current user has the right permissions to edit the field
	 */
	function check($key = 0) {
		return current_user_can('manage_options');
	}
}
 
 
function register_my_field() {
	register_fronted_field('editable_option', array(
		'class' => 'My_Editable_Option',
		'title' => 'My Option',
		'type' => 'input',
		'argc' => 2
	));
}
add_action('front_ed_fields', 'register_my_field');

Giving back

If you write a new editable field that you think will be useful for other users, post it in the support forum. I might include it in a future release of the plugin, giving you credit for it, of course.