the-customizer-wordpress-themes-gestalten-640x406

WordPress Theme Customizer Custom Controls

The Customizer is a relatively new way of WordPress Themes to provide you with options. Here is the visuality important, arrange the options directly in frontend for the Theme, play and save the settings.

We show you how to create your own classes to extend the controls, since not all fields and requests are in the core already. You can access existing solutions of the community or create your own classes. The first step is therefore a brief introduction for new classes and following an overview of some classes. Please extend this list via the comment form.
Continue reading …

Filename cache busting for WordPress styles and scripts

To embed custom CSS styles and scripts in WordPress you should use the wp_enqueue_script(), wp_enqueue_style(), wp_register_script() and/or wp_register_style() functions. Each of these functions allows you to define a version. By default it's the version of WordPress. The version identifier will be in the URL to the script as a query string.

The version identifier is used to expire the URL. Since the browser detects the new URL as a new resource, it will use the new instead of the cached resource.

Sadly not all endpoints respect the query string. From Google Developers:

Most proxies, most notably Squid up through version 3.0, do not cache resources with a "?" in their URL even if a Cache-control: public header is present in the response. To enable proxy caching for these resources, remove query strings from references to static resources, and instead encode the parameters into the file names themselves.

So the goal is to encode the version identifier into the filename without renaming the resource on the filesystem. This is where the following plugin comes in.
Continue reading …

How recent is “recently”?

If you deactivate plugins you can access them some time under the "Recently active" link in the plugin list table.

recentlyactive

"Recently" is not a very specific statement. So how long are deactivated plugins assumed to be "recent"? To find this out we have to take a look at the source code. In wp-admin/plugins.php line 166 the option "recently_activated" gets updated if a plugin is deactivated:

if ( ! is_network_admin() )
  update_option( 'recently_activated', array( $plugin => time() ) + 
  (array) get_option( 'recently_activated' ) );

The option contains an associative array containing the path to the main file of the plugin as the key and the time the plugins have been deactivated (as a unix timestamp) stored as a serialized value:

183 recently_activated a:1:{s:21:"hello-dolly/hello.php";i:1357900255;}

Before the plugin table is created the time stamp is used to determine the "recently active" plugins (wp-admin/includes/class-wp-plugins-list-table.php line 76):

$recently_activated = get_option( 'recently_activated', array() );

foreach ( $recently_activated as $key => $time )
  if ( $time + WEEK_IN_SECONDS < time() )
    unset( $recently_activated[$key] );
update_option( 'recently_activated', $recently_activated );

The code is walking through all plugin names stored in "recently_activated" and removes those which are older than one week and saves the others back in the options table.

So the answer to the question is: WordPress defines "recently" as one week.

WordPress Dropins

Plugins are pretty popular, since it is easy to adjust your blog or website to your liking with Plugins. Less popular are Dropins.

WordPress alows to replace some functions with Dropins. The list of possibilities isn't big and not well documented. But I like to use Dropins to enhance the possibilties of caching, especially APC and Memcache. But also to adjust uploads, permalinks and similar things are a typical scenario for Dropins.

Most of the Plugins are in the WP Content Folder, normally wp-content or via constant WP_CONTENT_DIR or the URL in WP_CONTENT_URL is defined.
Example:

// Custom content directory
define( 'WP_CONTENT_DIR',  dirname( __FILE__ ) . '/wp-content' );
define( 'WP_CONTENT_URL',  'http://' . $_SERVER['HTTP_HOST'] . '/wp-content' );

I use this in my dev environment or at my clients project for example, since I can access Plugins via FTP in different ways. See my WordPress Starter Repo on Github for more solutions and hints about this topic.

Only Dropins, which get loaded with a language key, aren't in this folder, instead they are in /wp-content/languages. Alternatively you can define the folder via the constant WP_LANG_DIR.
The Dropin for the German key de_DE takes that path. See the repo for read the source or find more information.

In Backend are Dropins listed since version 3.0, but only the following in the table and not the Dropin to the language key. Also you can not just deactivate or activate it via backend, that's why Plugins are preferred for some solutions.

Below is a table with all Dropins I know or I have found. The possible Dropins are echoing via the function _get_dropins() .

File Type of Dropin Active since Context
advanced-cache.php Advanced or Alternative Cache Constant WP_CACHE is TRUE Single Installation
db.php Own database class Always Single installation
db-error.php Own database error alert At DB Error Single installation
install.php Own installation routine At installation Single installation
maintenance.php Own maintenance message At updates, maintenance Single installation
object-cache.php External Object Cache Always Single installation
sunrise.php Before the WP Multisite Installation gets loaded If constant SUNRISE set Multisite installation
blog-deleted.php Own message, when a blog gets deleted If a blog gets deleted Multisite installation
blog-inactive.php Own message, if a blog is set inactive If a blog becomes inactive Multisite installation
blog-suspended.php Own message, if a blog got suspended When a blog gets marked as archive or spam Multisite installation
$locale.php functions at active language key When language key set in constant WP_LANG Single & multisite installation

Update: see the current solution for a custom maintenance mode on the post from Christopher.

How to disable auto-embeds (oEmbed) in WordPress 3.5

WordPress 3.5 will remove some options from the UI. One of these options is the Embeds section.

autoembed_urls, the on-off checkbox, goes way, and oEmbed is always assumed to be on. The only reason to have a UI on/off for oEmbed is if it was easy to accidentally embed items. But it doesn't parse every link in the post, just those on their own line or inside an [embed] code.

(Andrew Nacin, Ticket #21719)

oEmbed settings in WordPress 3.4

With that there is no visible setting anymore, which let's you disable the auto-embed function. But, WordPress is not WordPress if it doesn't provide another way to disable it. Here we go.

The embeds are handled by the WP_Embed class. The constructor of the class registers some actions and filters. Also a filter for the_content:

add_filter( 'the_content', array( $this, 'autoembed' ), 8 );

Now we just need to remove the specific filter again. Since we can't use $this in the remove_filter call we need to use the global variable $wp_embed which includes the reference to the object.

// Disable auto-embeds for WordPress >= v3.5
remove_filter( 'the_content', array( $GLOBALS['wp_embed'], 'autoembed' ), 8 );

You can add this code to an existing plugin or you can use the small plugin "Auto-embeds Disabler".

Site note: If you want you can "like" our new Facebook page to get some more WordPress related resources.

How to enqueue the bundled jQuery in footer – The Right Way

Why scripts should be placed into the footer of a site:

With scripts, progressive rendering is blocked for all content below the script. Moving scripts as low in the page as possible means there's more content above the script that is rendered sooner.

The second problem caused by scripts is blocking parallel downloads.

Steve Souders in „High Performance Web Sites: Rule 6 – Move Scripts to the Bottom

WordPress comes with many bundles JavaScript libraries like jQuery or jQuery UI.
So plugins and themes doesn't need to bundle these libraries again, instead, they can use the WP_Scripts API.

The registration is controlled by the function wp_default_scripts() in /wp-includes/script-loader.php.

/**
 * Register all WordPress scripts.
 *
 * @since 2.6.0
 *
 * @param object $scripts WP_Scripts object.
 */
function wp_default_scripts( &$scripts ) {
// […]
	$scripts->add( 'colorpicker', "/wp-includes/js/colorpicker$suffix.js", array('prototype'), '3517m' );

	$scripts->add( 'editor', "/wp-admin/js/editor$suffix.js", array('utils','jquery'), false, 1 );
// […]
	// not used in core, replaced by Jcrop.js
	$scripts->add( 'cropper', '/wp-includes/js/crop/cropper.js', array('scriptaculous-dragdrop') );

	// jQuery
	$scripts->add( 'jquery', '/wp-includes/js/jquery/jquery.js', array(), '1.7.2' );

	// full jQuery UI
	$scripts->add( 'jquery-ui-core', '/wp-includes/js/jquery/ui/jquery.ui.core.min.js', array('jquery'), '1.8.20', 1 );
	$scripts->add( 'jquery-effects-core', '/wp-includes/js/jquery/ui/jquery.effects.core.min.js', array('jquery'), '1.8.20', 1 );
// […]
}

As you can see, WP_Dependencies->add() expects the following arguments: The name, the path, the dependencies, the version and last but not least the argument to enqueue the script either in header or footer. Same as for wp_register_script() or wp_enqueue_script().

Now you should have noticed that the jQuery registration doesn't have the last argument, which means the script will be enqueued in header. With the help of a filter inside the wp_default_scripts() function we can change this.
In practice:

<?php
/**
 * Plugin Name: Enqueue jQuery in Footer
 * Version:     0.0.1
 * Plugin URI:  http://wpgrafie.de/836/
 * Description: Prints jQuery in footer on front-end.
 * Author:      Dominik Schilling
 * Author URI:  http://wpgrafie.de/
 */
function ds_enqueue_jquery_in_footer( &$scripts ) {
	 
	if ( ! is_admin() )
		$scripts->add_data( 'jquery', 'group', 1 );
}
add_action( 'wp_default_scripts', 'ds_enqueue_jquery_in_footer' );

This a really clean and nice way. No need of deregister and register functions.

Of course, you should test if this breaks any functionality, especially when you are using plugins/scripts which hasn’t set dependencies correctly.