Strange Symphonies The best way to predict the future is to invent it

Changing Default WordPress Media Link URL

When selecting a media from your WordPress Media Library, by default the Link URL selected, is the File URL. Now this may not be ideal if all the images you upload are not going to link to the file, and instead are just images to upload.

Link URL

Luckily we can change the functionality, but the ability to change the default Link URL is not exposed to the user.

The option specifying the default link type is stored in the WordPress options as "image_default_link_type". You can access the hidden WordPress options via visiting http://example.com/wp-admin/options.php (where example.com/ represents the url and path to your blog).

After accessing the page, search for "image_default_link_type" (its in alphabetical order). By default it should say "file".

This field has a few options:

• blank (Yes literally nothing, or I just use "none")
• file - Use the File URL, ie: http://example.com/wp-content/2010/04/example.png
• post - Use the Post URL, ie: http://example.com/?attachment=1

Change the value to "none". Do not touch the other options. Once you are done, save the changes by scrolling to the bottom, and hitting "Save Changes".

There you have it, your WordPress default media Link URL has been changed.

Links and Resources

• WordPress.org Option Reference - Lists down all the available WordPress options

Advice on Extending WordPress

There are a lot of tutorials on how to extend WordPress through developing WordPress plugins and themes. In fact because of the plethora and information available, and the low barrier of entry into extending WordPress, the platform has developed a huge software economy.

The WordPress software economy is fantastic. But as a software developer, delivering WordPress solutions, finding the right tool for the job is difficult. You may find a great plugin that can do the job for you, but the code is so convoluted, you have a difficult time understanding what it does.

When reading through the source code of other plugins, my first goal is to find out where does the plugin hook into the WordPress API. Secondly, what do these hooks do.

When extending WordPress, here are my recommendations.

• action and filter calls are at the top of the file.
• Encapsulate your action and filter callback functions in a class.
• Name your callback functions the same name as the hook.
• Split your plugin or plugin into different files.

Action and Filter Calls Are at the op of the Plugin File

Thus I propose people doing WordPress plugin development expose their actions and filters at the beginning of their plugin file.

Here is a portion of the sourcecode for the plugin Shortlinks. It is recommended you view the full source here.

Example:

<?php
/*
Plugin Name: Shortlinks
Plugin URI: http://blog.aizatto.com/shortlinks
Description: Add "Get Shortlinks" to the admin side for Pages, and Taxonomies (includes custom taxonomies, categeories, and post tags)
Author: Ezwan Aizat Bin Abdullah Faiz
Author URI: http://aizatto.com
Version: 0.1
License: LGPLv2
*/

add_filter('get_shortlink',     array('Shortlinks', 'get_shortlink_post_type'), 10, 4);
add_filter('get_shortlink',     array('Shortlinks', 'get_shortlink_taxonomy'), 10, 4);
add_filter('post_row_actions',  array('Shortlinks', 'post_row_actions'), 10, 2);
add_filter('media_row_actions', array('Shortlinks', 'post_row_actions'), 10, 2);
add_filter('page_row_actions',  array('Shortlinks', 'post_row_actions'), 10, 2);
add_filter('tag_row_actions',   array('Shortlinks', 'tag_row_actions'), 10, 2);

At the beginning of my plugin file, after the plugin headers describing the plugin, on lines 12-17, I define the filters the plugin uses. Notice how by placing the hooks at the top of the file, I can quickly see where does this plugin hook into.

Encapsulate Your Hooks Into A Class

I also created a class called Shortlinks based on the name of my plugin. This class encapsulates all the actions and filters callbacks, so I don't run into some naming issue.

Name your callback functions the same name as the hook

Likewise this allows me to name my functions after their action and filter names, so that I can quickly see which hook or filter they are referring to.

Its very easy to use the action and filter name for the function, and I try my best not to use any custom names unless its necessary. This easily allows me to standardize my function naming, and developers won't have to think much on when does this function get called. There is no real reason to name the callback function a different name.

The only exception to this, if you have a plugin that calls at most three action or filters. For example see my Shortlinks By Path code.

<?php
/*
Plugin Name: Shortlinks By Path
Plugin URI: http://blog.aizatto.com/shortlinks-by-path
Description: Strips off the domain name and leaves the path and query string when you click on "Get Shortlink"
Author: Ezwan Aizat Bin Abdullah Faiz
Author URI: http://aizatto.com
Version: 0.1
License: LGPLv2
*/

add_filter('get_shortlink', 'shortlinks_by_path', 20);

function shortlinks_by_path($shortlink) {
	return parse_url($shortlink, PHP_URL_PATH) . '?' . parse_url($shortlink, PHP_URL_QUERY);
}

Calling Hooks Inside a Callback

Its normal to sometime call a hook inside a callback, thats fine. As long as the top level hook is at the top of the file, and can be easily found.

Functions for use Inside A Template

Sometimes you may need to expose functions to the template. That's fine! Just place the code outside of the plugin class. In the Shortlinks example, it would be after the Shortlinks class.

Split Your Plugin Into Different Files

When your plugin or theme file starts getting big, it is time to refactor it, and separate it into different files.

Separate your plugin or theme into 3 files:

• functions.php or your plugin main file - All your hook calls are here.
• functions/template.php - All functions used by the template are stored here
• functions/hooks.php - Place your hook class here

Then inside your functions.php, you include them via:

require_once 'functions/template.php;
require_once 'functions/hooks.php;

If I see the need to split my plugin into different files, this is the most basic directory structure I use. With a quick glance of the directory I can see how the plugin is structured, and where to find the functions I need.

Sometimes I would need to create my own Walker class, and would place the class inside functions/walker.php.

Conclusion

Well there you have it, my advice on how to extend WordPress. At least in organizing you directory structure.