The process required to add the new uploader is a bit different, but not too much more difficult. I was able to adapt the old tutorial a little, so it shouldn’t be too hard to replace some code in an existing project and get the new uploader instead of the old.

For the sake of simplicity, let’s start with the same HTML snippet as in the old tutorial. This goes along with the rest of the HTML for your admin page, or wherever in the admin you’re trying to add an upload field.

<label for="upload_image">
	<input id="upload_image" type="text" size="36" name="ad_image" value="http://" /> 
	<input id="upload_image_button" class="button" type="button" value="Upload Image" />
	<br />Enter a URL or upload an image
</label>

Now we need to load up the necessary JavaScript files.

add_action('admin_enqueue_scripts', 'my_admin_scripts');

function my_admin_scripts() {
	if (isset($_GET['page']) && $_GET['page'] == 'my_plugin_page') {
		wp_enqueue_media();
		wp_register_script('my-admin-js', WP_PLUGIN_URL.'/my-plugin/my-admin.js', array('jquery'));
		wp_enqueue_script('my-admin-js');
	}
}

We bind the my_admin_scripts() function to the admin_enqueue_scripts hook, and enqueue both the media scripts and our own JavaScript file. Also, the scripts will only be loaded if the current page is equal to “my_plugin_page,” which you would of course replace with the slug your admin menu has.

Now for the complicated part: the script that hooks into the uploader. Continuing with the above example, it would be named my-admin.js.

jQuery(document).ready(function($){


	var custom_uploader;


	$('#upload_image_button').click(function(e) {

		e.preventDefault();

		//If the uploader object has already been created, reopen the dialog
		if (custom_uploader) {
			custom_uploader.open();
			return;
		}

		//Extend the wp.media object
		custom_uploader = wp.media.frames.file_frame = wp.media({
			title: 'Choose Image',
			button: {
				text: 'Choose Image'
			},
			multiple: false
		});

		//When a file is selected, grab the URL and set it as the text field's value
		custom_uploader.on('select', function() {
			attachment = custom_uploader.state().get('selection').first().toJSON();
			$('#upload_image').val(attachment.url);
		});

		//Open the uploader dialog
		custom_uploader.open();

	});


});

When the button is clicked, it creates a new instance of the wp.media object and configures it to only accept a single file, since the text field can only hold one file URL. Then it binds a function to the selection action, which gets the file attributes when an image is chosen and sets the #upload_image text field value to the file’s URL.

Providing everything went as expected, you should have a form field that will accept an arbitrary URL, or allow the user to upload one.

Core Control is a plugin that lets you monitor and adjust several parts of WordPress for diagnostic and development purposes. It makes it easy to view registered WP-Cron events, and trigger them with a click. It can also force WordPress to check for ore, plugin or theme updates, log any HTTP requests WordPress makes to external servers and determine which filesystem access method WordPress is using.

I decided to try it out again now that it hit the big two-point-oh, and was surprised now only by the amount of functionality it offers, but by how many other plugins it can conceivably replace. The Publicize module, for instance, will automatically post links to new posts on Twitter, Facebook and other popular social networks, so you don’t need another plugin for that if you run Jetpack. I also found the Mobile Push Notifications and JSON API modules to be intriguing. The former sends push notifications to your iPhone/iPad when new comments are posted, and lets you jump right over to the WordPress iOS app to manage them, and the latter is primarily of interest to developers looking to integrate a WordPress blog into another web site or application. (Previously I used this plugin, but Jetpack looks roughly equivalent.)

The big new feature in this version is a free service called Photon, an “image acceleration and editing service” which acts as a CDN for your images. It mirrors images it finds in your posts (or ones a theme or plugin developer specifies via an API) on WordPress.com’s servers, which enables them to be served faster and takes load off your server. This would be excellent for blogs hosted on cheap shared hosting, especially if coupled with a static caching plugin like WP Super Cache or W3 Total Cache.

The Star Wars wiki (starwars.wikia.com) is every bit as bad as TV Tropes. Send help!

— Matt Harzewski (@redwall_hp) December 19, 2011

The latest version of my Tweetable plugin, version 1.2.4, includes support for Twitter’s new embedding API, which enables you to do that with minimal effort. If you have the plugin installed (and “Auto-embeds” is turned on in the Media page of your Settings), you can just paste a properly-formatted URL from Twitter onto a new line in your post. After you hit Publish, it will appear in your post, thanks to the magic of oEmbed.

The best part? This is going to be built-in to WordPress 3.4, so you have ensured forward-compatibility. Otto, one of the major contributors to the WordPress core, has already worked up a patch and it is currently slated to be included in version 3.4. Beat me to it.

With the theme you can have a look at all of the globals, see any errors generated, and keep tabs on the MySQL queries (including their execution times) behind the page generation. It even includes a profiler.

You can choose which of the services are displayed, as well as hide the chart if you wish to have the widget be a bit more compact.

StatDash is my first item to be released on Code Canyon. It’s priced at $8, and is GPL compliant of course.

It didn’t take long for plugin developers to start finding ways to extend it.

Weblog Tools Collection has a small roundup of admin bar plugins, which add additional functionality to the admin bar. One lets you manage what appears on the bar, and several add entirely new items such as debugging tools.

Admin Bar Plugin Roundup [Weblog Tools Collection]

Core plugins shouldn’t be about “let’s have an official plugin for x.” They should instead be frameworks of additional classes and hooks that can be extended by plugins and themes. Instead of having, say, a canonical plugin to integrate Facebook into WordPress, you could have a “Microblogging” core plugin that doesn’t do much aside from add a bunch of new microblogging-related hooks (along with classes for interacting with the Twitter, Facebook, Tumblr, etc. APIs.). Plugins and themes could then hook into the microblogging core plugin, using it’s generic methods to update one social network or many simultaneously.

Does that make sense?

…even a theme or plugin that entirely dependens on WordPress to run at all, or simply improves WordPress in some way, would not be a derivative work and the GPL would not apply. For the vast majority of themes I’ve seen, the GPL would not apply because the theme is not, in my opinion, a derivative work. (In fact, if any one thing “incorporates” another, it’s most likely WordPress incorporating the theme, by use of the PHP include() call, rather than the other way around.)

According to the article, the copy of the GPL included in every download of WordPress even states that a derivative work is “a work containing the Program or a portion of it, either verbatim or with modifications.” I’ve been making a similar argument for awhile now. I have yet to see a theme or plugin that actually incorporates WordPress into the plugin code itself, rather than being included by WordPress. It sounds to me like WordPress, if anyone, is the one doing the deriving…

Most WordPress themes and plugins are unique code for the most part, with a few hooks or function calls. I must have missed the memo that utilizing a third-party API makes your application a subset of the other software. (That would mean any desktop application would be a derivative of the operating system.)

A follow-up article from the same author makes the additional case that, whether the GPL applies or not, the Fair Use Doctrine can protect developers from the licensing terms of the original creator. The same laws that ensure you can quote part of an article without having to pay whatever licensing fee the publisher can cook up apply to software. As little, if any, WordPress code is used in a theme, it would likely be considered fair use.

I like some of the ideology behind the GPL, and quite a few software packages licensed under it. However, it seems that in this case one party is misusing (or misinterpreting) it to prevent small developers from earning a living while further enriching the WordPress community. For what reason, good intentioned or no, I cannot guess.

It’s fairly simple to implement, providing you already have a bit of experience with the WordPress API.

The first step is to prepare your HTML. Put it wherever the code for your admin page is. You want to have a text input for the image URL, and a button that will launch the uploader dialog.

<tr valign="top">
<th scope="row">Upload Image</th>
<td><label for="upload_image">
<input id="upload_image" type="text" size="36" name="upload_image" value="" />
<input id="upload_image_button" type="button" value="Upload Image" />
<br />Enter an URL or upload an image for the banner.
</label></td>
</tr>

Now that the easy part is out of the way, it’s time to start making it do something. You need to enqueue some scripts and styles. Here’s an example function to show how it’s done:

function my_admin_scripts() {
wp_enqueue_script('media-upload');
wp_enqueue_script('thickbox');
wp_register_script('my-upload', WP_PLUGIN_URL.'/my-script.js', array('jquery','media-upload','thickbox'));
wp_enqueue_script('my-upload');
}

function my_admin_styles() {
wp_enqueue_style('thickbox');
}

if (isset($_GET['page']) && $_GET['page'] == 'my_plugin_page') {
add_action('admin_print_scripts', 'my_admin_scripts');
add_action('admin_print_styles', 'my_admin_styles');
}

We need the media-upload and thickbox scripts for starters, as well as jQuery, which is already included. Then we have to register and enqueue our own JavaScript file, my-script.js, which will handle the media uploader functionality. We also need to load the thickbox stylesheet in the next function.

The if (…) block ensures that the scripts and styles will only be included if the user is on a specific admin page. If you look at your plugin’s (or theme’s) admin page, the URL should have a ?page=some_string at the end. Substitute my_plugin_page for that string.

Now for the part the actually invokes the uploader: the JavaScript. This will go in the my-script.js file we included earlier.

jQuery(document).ready(function() {

jQuery('#upload_image_button').click(function() {
 formfield = jQuery('#upload_image').attr('name');
 tb_show('', 'media-upload.php?type=image&TB_iframe=true');
 return false;
});

window.send_to_editor = function(html) {
 imgurl = jQuery('img',html).attr('src');
 jQuery('#upload_image').val(imgurl);
 tb_remove();
}

});

The first click() event listener opens a ThickBox dialog when the “Upload Image” button is clicked, and loads the uploader page inside it. It also stores the name of the URL input field in a variable, for later use.

The second function overrides the send_to_editor() function in the media-upload script. This is probably the most important part. When the “Insert into Post” button is clicked in the uploader dialog, this function fires. It collects the URL of the image that was uploaded, dumps it into the awaiting form field, and closes the ThickBox dialog.

That’s it. Providing everything went according to planned, you should have a form field that will either accept an arbitrary image URL, or allow a user to upload one on the spot.

Update: If you want to use the fancy new media uploader introduced in WordPress 3.5, be sure to check out the revised and updated post that covers it.