Disable Post Format UI

Currently is WordPress version 3.6 in Beta status. But new nice features are available and ready to test. One of this features is the new UI for the post formats. Post formats is a nice chance for more possibilities to declare a post to your readers. But sometimes we don’t need post formats. The default for hide the Post Format UI is user specific and is an option in the screen options, see the screenshot.
Continue reading …

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.