Aliso the GeekPosts tagged ‘jQuery’ | Aliso the Geek

Extended WordPress Settings API Tutorial, Part 2

Alison Barrett — Sun, 02 Jan 2011 00:57:05 +0000

The purpose of the display_section() function is only to add descriptive text (or other HTML) to that specific settings section. Whatever is output by this function will be displayed below the section subheading. If you register the sections individually instead of in a loop, you can use a different callback function for each section and insert custom content here.

For now, just put an empty function inside the class:

/* Description for section */
public function display_section() {
	// code
}

5. Display the Form Fields

The reason we wrote a helper function to add our settings to the database is so we could pass certain arguments along to the callback function (which is responsible for outputting the HTML to display the field). This allows us to use the same callback function for every single field, and still get unique displays for each type. Let’s walk through the callback function, display_setting().

/* HTML output for individual settings */
public function display_setting( $args = array() ) {

	extract( $args );

	$options = get_option( 'mytheme_options' );

	if ( ! isset( $options[$id] ) && 'type' != 'checkbox' )
		$options[$id] = $std;
	elseif ( ! isset( $options[$id] ) )
		$options[$id] = 0;

	$field_class = '';
	if ( $class != '' )
		$field_class = ' class="' . $class . '"';

The arguments for this function, which are the same arguments as our create_setting() function, get passed in an array and then turned into variables by extract(). Then, we create an array of all the existing options in the database with get_option(). The argument for that, ‘mytheme_options’, is the name of our master options array.

If the current setting, $id, doesn’t exist in the database, then it assigns that setting its default value. You should also exclude checkboxes in this if statement, because checkboxes don’t have user-created values (they’re either on or off).

Then we check for a custom class to use for this field. If it’s equal to anything other than an empty string, it will output ‘class=”$class”‘ in the HTML form field.

There is a fairly massive swtich statement coming up next. I’ll just give you the text field code for now, and the rest after I explain it:

	switch ( $type ) {

		case 'text':
		default:
			echo '';

	 		if ( $desc != '' )
	 			echo '
' . $desc . '';

	 		break;
	}
}

This is pretty straightforward. It’s printing an HTML input field, with a custom class if the setting has one, and setting its name, id, and value. It prints the description, if it exists, on a line below the field in small text. It’s also setting a “placeholder” attribute. This is an HTML5 attribute, and we’ll be using it to find the default value for that field in some jQuery later on.

Note that I’m using the text field as the default in this switch statement. You can use whichever type you want as the default, just make sure it comes last in the switch statement and has “default:” under the “case” line.

Where are the form labels and the table structure?

The Settings API prints the HTML for these settings inside a table cell that’s already created. WordPress automatically creates the table, creates a row for each field with a table header containing the field label, and opens and closes the table cell around the form field.

This is both good and bad. It saves us a lot of code doing that manually, and it formats it like other settings pages in WordPress so it has the same look and feel. However, it is less flexible for those who want their options page to look a little different. This is where the jQuery comes in (back to that in a bit).

Below is the rest of the switch statement. This code should all go after switch ( $type ) { and before case 'text': for it to work properly.

case 'heading':
	echo '' . $desc . '';
	break;

case 'checkbox':

	echo ' ' . $desc . '';

	break;

case 'select':
	echo '';

	if ( $desc != '' )
		echo '
' . $desc . '';

	break;

case 'radio':
	$i = 0;
	foreach ( $choices as $value => $label ) {
		echo ' ' . $label . '';
		if ( $i < count( $options ) - 1 )
			echo '
';
		$i++;
	}

	if ( $desc != '' )
		echo '
' . $desc . '';

	break;

case 'textarea':
	echo '' . wp_htmledit_pre( $options[$id] ) . '';

	if ( $desc != '' )
		echo '
' . $desc . '';

	break;

case 'password':
	echo '';

	if ( $desc != '' )
		echo '
' . $desc . '';

	break;

Subheadings Within a Section

In the switch statement, I added a “heading” type as an option. This is useful for dividing up long sections. Since a setting is displayed within a table cell on the right-hand side, I had to cheat the system a bit here. I close the table cell and the table row, and then open a new row with a cell spanning two columns. Then I put an h4 inside to give it a consistent appearance and (somewhat) proper semantics. To avoid displaying a label on the left, the title is left blank, and the text for the heading is put in the description.

6. Custom Javascript and styling

At this point, the settings page is 100% functional and is visually consistent with the rest of the WordPress admin. You could stop right here and have a solid theme options page. If you want something with a little more pizzazz, then we have more coding to do.

jQuery Tabs

Go back to the add_pages() function and add this line of code under what’s already there:

add_action( 'admin_print_scripts-' . $admin_page, array( &$this, 'scripts' ) );

This calls a function in our class so we can insert our own Javascript, and it only applies it to our theme options page in the admin. Here’s that function:

/* jQuery Tabs */
public function scripts() {
	wp_print_scripts( 'jquery-ui-tabs' );
}

Now we need to add some jQuery code to our admin page. We will do that in the display_page() function. Replace everything inside that function with the following:

echo '

Theme Options
';

	settings_fields( 'mytheme_options' );
	echo '
		';

	foreach ( $this->sections as $section )
		echo '' . $section . '';

	echo '';
	do_settings_sections( $_GET['page'] );

	echo '
	



';

Before we get to the jQuery, I’ve added a couple of things. The entire settings output is now wrapped in a div with class=”ui-tabs”. Then there’s an unordered list with class=”ui-tabs-nav” that loops through our sections to output a link for each one.

Now the jQuery magic. First, we need to make some modification to the code structure. Each section needs to be wrapped in a div with class=”ui-tabs-panel”, but we can’t access any of the code between the sections with just PHP. So we’ll search for the

tags and use those as a marker for beginning a new section.

var wrapped = $(".wrap h3").wrap("");
wrapped.each(function() {
	$(this).parent().append($(this).parent().nextUntil("div.ui-tabs-panel"));
});

Thanks, Nathan, for the tip on using nextUntil() instead of next()!

This wraps the section headings inside of the div, and then takes what was directly after the headings—the table with all the form fields in it—and puts it inside that div. The next step is to add id attributes to the headings, and apply a class to all but the first panel to hide it from view:

$(".ui-tabs-panel").each(function(index) {
	var str = $(this).children("h3").text().replace(/\s/g, "_");
	$(this).attr("id", str.toLowerCase());
	if (index > 0)
		$(this).addClass("ui-tabs-hide");
});

The .each() function loops through the panels. By adding the “index” attribute to the function, it generates an arbitrary counter that we can use to determine whether we’re on the first panel.

Finally, apply the actual tabs functionality to our modified HTML:

$(".ui-tabs").tabs({ fx: { opacity: "toggle", duration: "fast" } });

The parameters inside the .tabs() function can be altered to change the animation and speed of the transition between tabs. Check out the jQuery UI documentation to see what’s possible.

Placeholder Text

The default values of our text and textarea fields are currently just showing up as values that the user has to manually erase to enter their own information. This isn’t a horrible thing, but we can make it more user-friendly by adding some jQuery and styling to the mix. Add this to the jQuery block in display_page():

$("input[type=text], textarea").each(function() {
	if ($(this).val() == $(this).attr("placeholder"))
		$(this).css("color", "#999");
});

$("input[type=text], textarea").focus(function() {
	if ($(this).val() == $(this).attr("placeholder")) {
		$(this).val("");
		$(this).css("color", "#000");
	}
}).blur(function() {
	if ($(this).val() == "" || $(this).val() == $(this).attr("placeholder")) {
		$(this).val($(this).attr("placeholder"));
		$(this).css("color", "#999");
	}
});

This takes any field with a default value in it and makes the text grey. The value then disappears when the user clicks on the field (only if the value was the default). When a user clicks out of a field, if the field is still empty, it re-inserts the value and makes it grey again.

Because we’re creating some HTML dynamically and it’s going to be styled after the fact, we use CSS to hide the elements on the page to avoid the “flash” of unstyled content when the page loads. We need to put in one line of jQuery to show that content again when the loading is complete.

$(".wrap h3, .wrap table").show();

There are some strange issues that show up in Firefox because of its autocomplete functionality. To fix that, add this to the jQuery block:

if ($.browser.mozilla)
         $("form").attr("autocomplete", "off");

Thank you, Billyben, for pointing this out to me!

Custom Styling

All the hard work is done! Everything from here on out is just gravy. To add custom CSS, we need to call our own stylesheet on our admin page.

First, create a new CSS file in your theme folder, and name it what you like (I’ll use mytheme-options.css). Add this to the add_pages() function:

add_action( 'admin_print_styles-' . $admin_page, array( &$this, 'styles' ) );

Now add the styles() function to the theme options class:

/* Insert custom CSS */
public function styles() {

	wp_register_style( 'mytheme-admin', get_bloginfo( 'stylesheet_directory' ) . '/mytheme-options.css' );
	wp_enqueue_style( 'mytheme-admin' );

}

Any CSS you put in that stylesheet will now be applied to your theme options page. To get the look seen in the screenshot below, put this in the stylesheet:

.ui-tabs-nav {
	border-bottom: 1px solid #ccc;
	height: 27px;
	margin: 20px 0;
	padding: 0;
}

.ui-tabs-nav li {
	display: block;
	float: left;
	margin: 0;
}

.ui-tabs-nav li a {
	padding: 4px 20px 6px;
	font-weight: bold;
}

.ui-tabs-nav li a {
	border-style: solid;
	border-color: #CCC #CCC #F9F9F9;
	border-width: 1px 1px 0;
	color: #C1C1C1;
	text-shadow: rgba(255, 255, 255, 1) 0 1px 0;
	display: inline-block;
	padding: 4px 14px 6px;
	text-decoration: none;
	margin: 0 6px -1px 0;
	-moz-border-radius: 5px 5px 0 0;
	-webkit-border-top-left-radius: 5px;
	-webkit-border-top-right-radius: 5px;
	-khtml-border-top-left-radius: 5px;
	-khtml-border-top-right-radius: 5px;
	border-top-left-radius: 5px;
	border-top-right-radius: 5px;
}

.ui-tabs-nav li.ui-tabs-selected a,
.ui-tabs-nav li.ui-state-active a {
	border-width: 1px;
	color: #464646;
}

.ui-tabs-panel {
	clear: both;
}

.ui-tabs-panel h3 {
	font: italic normal normal 24px/29px Georgia,"Times New Roman","Bitstream Charter",Times,serif;
	margin: 0;
	padding: 0 0 5px;
	line-height: 35px;
	text-shadow: 0 1px 0 #fff;
}

.ui-tabs-panel h4 {
	font-size: 15px;
	font-weight: bold;
	margin: 1em 0;
}

.wrap h3, .wrap table {
	display: none;
}

Voilà! ~~I used some CSS3 to achieve some nice visual effects, so there are no images required.~~This will make the page look consistent with the rest of the WordPress admin.

Now you have a functional, beautiful, kickass theme options page!

There are still a couple of small things to cover, so be sure to read the follow-up post to this tutorial.

Download the files (updated June 5, 2011)

Extended WordPress Settings API Tutorial, Part 1

Alison Barrett — Sat, 01 Jan 2011 18:19:05 +0000

Using the Settings API, WordPress creates an array of options and puts it into a single database entry. This is the cleanest, most efficient way to do it. Without the Settings API, it requires a decent chunk of code to accomplish that. You can create more than one options array if you wish, but in this tutorial we’re putting all the options in the same array.

1. Set Up the Theme Options Class

Almost everything we do is going to be contained in a custom PHP class so we can be more liberal with our function and variable names. First, create the PHP file. The naming standard for PHP class files is class.classname-here.php or class-classname-here.php. For the tutorial, I’m naming the class My_Theme_Options.

We’ll start with a couple of lines of code in functions.php:

if ( file_exists( STYLESHEETPATH . '/class.my-theme-options.php' ) ) {
	require_once( STYLESHEETPATH . '/class.my-theme-options.php' );
}

This will start up our theme options class. The rest of the PHP in this tutorial is written within that class, so you can close functions.php. Note: since we haven’t written the class yet, this will break your theme if you make it live before the next step.

Make a new file in the theme folder and make sure the filename matches the code above. In that file, create the My_Theme_Options class:

checkboxes = array();
		$this->settings = array();
		$this->get_settings();

		$this->sections['general']      = __( 'General Settings' );
		$this->sections['appearance']   = __( 'Appearance' );

		add_action( 'admin_menu', array( &$this, 'add_pages' ) );
		add_action( 'admin_init', array( &$this, 'register_settings' ) );

		if ( ! get_option( 'mytheme_options' ) )
			$this->initialize_settings();
	}

	/* Add page(s) to the admin menu */
	public function add_pages() {
		$admin_page = add_theme_page( 'Theme Options', 'Theme Options', 'manage_options', 'mytheme-options', array( &$this, 'display_page' ) );
	}

	/* HTML to display the theme options page */
	public function display_page() {
		// code
	}

	/* Define all settings and their defaults */
	public function get_settings() {
		// code
	}

	/* Initialize settings to their default values */
	public function initialize_settings() {
		// code
	}

	/* Register settings via the WP Settings API */
	public function register_settings() {
		// code
	}
 }
 ?>

What’s going on here? Well, the __construct() function is called automatically when the class is used to create a variable. (This only works in PHP5; for PHP4, you must use the class name as the function name.) We’re defining the sections in which we want our theme options organized, and then using two WordPress hooks to run a couple of functions. The add_pages() function is adding our theme options page to the menu in the WordPress admin, under “Appearance.” It’s just a blank page right now, but we’ll fill it in later.

2. Register the Settings

Registering settings with the WordPress Settings API is extremely simple if you only have a few settings, but once you get a dozen or more settings involved, it’s best to streamline your code.

In the WordPress Settings API, individual settings need a callback function to display the HTML. This does not need to be a unique function for each setting. If it shares a callback function with other settings, you need to pass arguments to that callback function to tell it which setting it needs to display.

To add all the settings to our database, we’re going to create our own helper function to register the setting with WordPress and then pass the proper arguments to the callback function. Put this inside the class:

/* Create settings field */
public function create_setting( $args = array() ) {

	$defaults = array(
		'id'      => 'default_field',
		'title'   => 'Default Field',
		'desc'    => 'This is a default description.',
		'std'     => '',
		'type'    => 'text',
		'section' => 'general',
		'choices' => array(),
		'class'   => ''
	);

	extract( wp_parse_args( $args, $defaults ) );

	$field_args = array(
		'type'      => $type,
		'id'        => $id,
		'desc'      => $desc,
		'std'       => $std,
		'choices'   => $choices,
		'label_for' => $id,
		'class'     => $class
	);

	if ( $type == 'checkbox' )
		$this->checkboxes[] = $id;

	add_settings_field( $id, $title, array( $this, 'display_setting' ), 'mytheme-options', $section, $field_args );

}

The only thing that needs to be changed here are the default arguments at the top. You can make these whatever you like. Here’s what each one does:

id: the ID of the setting in our options array, and the ID of the HTML form element
title: displayed as the label for the HTML form element
desc (optional): description displayed under the HTML form element
std: default value for this setting
type: which HTML form element to use
section: the section to put this setting into—must match the array ID of a section defined in __construct()
choices (optional): different choices in radio buttons or a drop-down menu
class (optional): add a custom class to the HTML form element

When you create the settings themselves, you’ll have to fill out these arguments for each one. If any of the arguments is left blank, then the default set in this function will be applied.

We’re also keeping track of which fields are checkboxes, because they need special treatment when the settings are saved.

The final line in this function is the WordPress Settings API in action. The “mytheme-options” argument is the slug for the admin page (it needs to match the slug used in the add_theme_page() function inside our add_pages() function.

In order for the settings to be initialized when the theme is activated, we specify our settings in a separate function, get_settings().

/* Define all settings and their defaults */
public function get_settings() {

	/* General Settings
	===========================================*/

	$this->settings['example_text'] = array(
		'title'   => __( 'Example Text Input' ),
		'desc'    => __( 'This is a description for the text input.' ),
		'std'     => 'Default value',
		'type'    => 'text',
		'section' => 'general'
	);

	$this->settings['example_textarea'] = array(
		'title'   => __( 'Example Textarea Input' ),
		'desc'    => __( 'This is a description for the textarea input.' ),
		'std'     => 'Default value',
		'type'    => 'textarea',
		'section' => 'general'
	);

	$this->settings['example_checkbox'] = array(
		'section' => 'general',
		'title'   => __( 'Example Checkbox' ),
		'desc'    => __( 'This is a description for the checkbox.' ),
		'type'    => 'checkbox',
		'std'     => 1 // Set to 1 to be checked by default, 0 to be unchecked by default.
	);

	$this->settings['example_heading'] = array(
		'section' => 'general',
		'title'   => '', // Not used for headings.
		'desc'    => 'Example Heading',
		'type'    => 'heading'
	);

	$this->settings['example_radio'] = array(
		'section' => 'general',
		'title'   => __( 'Example Radio' ),
		'desc'    => __( 'This is a description for the radio buttons.' ),
		'type'    => 'radio',
		'std'     => '',
		'choices' => array(
			'choice1' => 'Choice 1',
			'choice2' => 'Choice 2',
			'choice3' => 'Choice 3'
		)
	);

	$this->settings['example_select'] = array(
		'section' => 'general',
		'title'   => __( 'Example Select' ),
		'desc'    => __( 'This is a description for the drop-down.' ),
		'type'    => 'select',
		'std'     => '',
		'choices' => array(
			'choice1' => 'Other Choice 1',
			'choice2' => 'Other Choice 2',
			'choice3' => 'Other Choice 3'
		)
	);

	/* Appearance
	===========================================*/

	$this->settings['header_logo'] = array(
		'section' => 'appearance',
		'title'   => __( 'Header Logo' ),
		'desc'    => __( 'Enter the URL to your logo for the theme header.' ),
		'type'    => 'text',
		'std'     => ''
	);

	$this->settings['favicon'] = array(
		'section' => 'appearance',
		'title'   => __( 'Favicon' ),
		'desc'    => __( 'Enter the URL to your custom favicon. It should be 16x16 pixels in size.' ),
		'type'    => 'text',
		'std'     => ''
	);

	$this->settings['custom_css'] = array(
		'title'   => __( 'Custom Styles' ),
		'desc'    => __( 'Enter any custom CSS here to apply it to your theme.' ),
		'std'     => '',
		'type'    => 'textarea',
		'section' => 'appearance',
		'class'   => 'code'
	);

}

I included one of each possible type in this tutorial. You can just copy and paste these to add more settings to the page. Note: The ‘section’ argument must match the ID of a section defined in __construct().

Now that we have our helper function and the settings in place, let’s use them! Update the register_settings() function with this:

/* Register settings via the WP Settings API */
public function register_settings() {

	register_setting( 'mytheme_options', 'mytheme_options', array ( &$this, 'validate_settings' ) );

	foreach ( $this->sections as $slug => $title )
		add_settings_section( $slug, $title, array( &$this, 'display_section' ), 'mytheme-options' );

	$this->get_settings();

	foreach ( $this->settings as $id => $setting ) {
		$setting['id'] = $id;
		$this->create_setting( $setting );
	}

}

At the beginning of the function, register_setting() belongs to the Settings API. This is making our master settings array in the database, which is being named “mytheme_options.” The “validate_settings” argument is a function we will define later, to add custom validation to the user-entered data.

The add_settings_section() function is registering the different sections we defined in __construct().

3. Initialize Settings

When the theme is first activated, the settings need to be initialized and set to their default values (this is especially important if the options control title tags or other front-end output).

/* Initialize settings to their default values */
public function initialize_settings() {

	$default_settings = array();
	foreach ( $this->settings as $id => $setting ) {
		if ( $setting['type'] != 'heading' )
			$default_settings[$id] = $setting['std'];
	}

	update_option( 'mytheme_options', $default_settings );

}

What’s next?

At this point, the settings are all defined, and there are only two things left to do: tell WordPress how to display the settings, and create our custom validation function (which is entirely optional). That’s it!

Read Part 2 of the WordPress Extended Settings API Tutorial »

Meet the WordPress Settings API

Alison Barrett — Tue, 28 Dec 2010 05:07:04 +0000

I’ve been working on my own WordPress theme framework for the past several months, and it’s getting closer and closer to completion every week. A few months ago, after I had finished writing all the code for the framework’s theme options page, I learned of the WordPress Settings API. I initially ignored it because I had just finished writing all this beautiful code, which had taken far too many hours and given me far too many headaches to just abandon it all.

I decided to revisit the Settings API today, and I’m so glad I did! After about 9 hours at the computer, I rebuilt my theme options page using the Settings API, jQuery, and CSS3.

My theme options class went from 1258 lines of code to just 667. The API took care of a lot automatically. There are basically three things you have to do when using the Settings API:

Register the pages & sections for your options (if applicable)
Register the settings themselves
Tell WordPress how to display each field

Doing just those three things, you will have fully-functioning theme or plugin options. Anything on top of that is just extra PHP, Javascript, and CSS to make it look pretty.

Without extra styling or manipulation, here’s what an options page will look like when using the Settings API. (Click on the image for a full-size version with some annotations.)

Without using the Settings API, that entire page would have to be created and formatted manually. In addition, you’d have to write the code that processes the form, validates the fields, saves the options to the database, and sends the user back to this page (with error messages if necessary).

With the Settings API, all the form handling & processing is done for you, as is a good chunk of the actual page display. The form fields themselves are displayed using a callback function assigned to each specific setting, so unless you want to write a separate function to display each field, it’s helpful to make your own mini-API around this one and keep your code organized in the process.

There are a few great tutorials out there on the Settings API—the two I used were Settings API Explained from PressCoders and WordPress Settings API Tutorial from Otto on WordPress. Based on their tutorials, I developed a theme options class that you can reuse for your own projects (it will ultimately be released as part of my open-source theme framework).

I’ll go through the code piece by piece in my next post, the Extended WordPress Settings API Tutorial.

5 tips on writing WordPress plugins "the right way"

Alison Barrett — Thu, 21 Jan 2010 03:31:40 +0000

Just like many fellow programmers out there, when I first started publishing my own code for the world to see and use, it wasn’t the greatest. I didn’t fully understand the WordPress API and all the tools it had to offer. I have since learned a lot about how to write WordPress plugins “the right way”—the most efficient, clean, and safe way, that is. WordPress has functions, classes, and hooks that work right out of the box to make plugins easier to code and less risky to use. Here are a few of my favorite tips.

1. Use the $wpdb object for all database queries

If you only read and follow one of these tips, make it this one. Setting up database connections with mysql_connect over and over again is a waste of code. If you’re in anything other than a standalone processing script, $wpdb is ready to go with just one line of code:

global $wpdb;

(If you are using a standalone script for something, just include two files to make $wpdb work: wp-load.php and wp-includes/wp-db.php.)

There are different functions for the $wpdb class to make different kinds of database queries (see the WordPress codex page for details on them all).

On average, I find that using $wpdb saves two to three lines of code for each time I make any sort of database query. For example, this:

$name = mysql_real_escape_string($name);
$result = mysql_query("INSERT INTO $myplugin->categories_table (name) VALUES ('$name')");
if (!$result)
    die("Could not insert into database. ".mysql_error());

turns into this:

$wpdb->insert($myplugin->categories_table, array('name' => $name), array('%s'));

One of the most important reasons to use $wpdb instead of mysql_query is that it automatically protects the database from MySQL injection attacks. More details about that are on the codex page as well.

2. Call jQuery using wp_enqueue_script

One of the most frustrating things I’ve seen responsible for my WordPress plugins not working is that other plugins are calling jQuery the wrong way:

WordPress has its own way of handling calls to jQuery (and other common Javascript libraries). It’s called wp_enqueue_script. This is how WordPress would have you call jQuery in a plugin:

wp_enqueue_script('jquery');

So if WordPress itself needs to load jQuery, or an additional plugin calls it in this way, then it’s only loaded once, and it’s loaded in no-conflict mode. This means that there won’t be two jQuery scripts of different versions competing for attention. And if you prefer an external reference to jQuery (such as the one from Google Code), there is a method for doing that in a WordPress-friendly way, too (see step 2 on this linked page).

3. Use unique class & function names

If you have a function in your plugin called “load()”, then what happens if another plugin is activated on a user’s blog that uses a function called “load()”? Well, crap explosions happen. Plugins break. Solving this problem is easy: name all your functions something unique to your plugin. My personal method is to come up with a two- or three-letter representation of my plugin (like “sm” for SimpleMap) and use that as a prefix to all my function names. For example:

sm_display_map()

Easy as pie.

4. Prep all text for localization from the get-go

Even if you don’t include any translation files with your plugin, someone out there might want to write one for you (or for themselves). It’s pretty tedious to go back through your existing code and prep the text for translation, so make it a habit right away. First, you have to pick a key for your plugin’s translation files (this is usually just the plugin name or slug). Then you have to surround any text that gets displayed to the user with the following code:

__('This is the text to be translated.', 'PluginKeyHere');

Note: ‘PluginKeyHere’ would be the key you picked. For example, in SimpleMap this is ‘SimpleMap’.

The double underscore at the beginning will return the translated string to PHP. If you want to echo the string, instead of adding echo before the double underscore, you can use this shorthand:

_e('This is the text to be translated.', 'PluginKeyHere');

More details on localizing your plugin can be found in the WordPress codex.

5. Write a good README file

This is something I highly recommend. When I’m searching for a plugin to install, an inadequate or poorly written README file will often make me go back to my search results and keep looking. Writing a good README file shows that you care about the people using your plugin. If you treat it like it’s just a step WordPress forces you to take to submit a plugin to the repository, it’s going to make you look like an ass, and users won’t want to try your plugin at all.

To top it off, Mark Jaquith has recently released a plugin that makes good use of your README files on your own blog. It’s called I Make Plugins, and it automatically populates pages on your blog to promote the plugins you’ve created. You can see it in action here on Aliso the Geek.

Well, that’s all for now. More tips are sure to come in the future! If you have any suggestions, please leave a comment and share them!