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 …

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.

Load Minimum of WordPress

A small contribution for all those using WordPress as a backend, framework or something similar. The applications, especially in the B2B sector, becoming more and more, as do the questions.

So far, I've always liked to recommended BackPress. But even a well-maintained standard is feasible, with all its advantages in the context of the philosophy of updates. WordPress reduces initializing to a minimum, if the constant SHORTINIT is set.
Continue reading …

Force Reload of Scripts and Stylesheets in your Plugin or Theme

If you're developing a WordPress theme or plugin you may have had the problem that scripts or stylesheets are not reloaded from the source when you refresh the page because they are cached somewhere on the way from the server to the browser. There are various methods to suppress this behaviour like disabling the browser cache in the options or by using a web development add-on. Sometimes this simply does not work because it's not always apparent where the content is cached since there are so many possibilities and you may have missed to disable all of them.

WordPress provides a simple method to ensure that all stylesheets and scripts are reloaded from the source when they have changed by providing a version parameter:

wp_enqueue_script( $handle, $src, $deps, $ver, $in_footer );
wp_enqueue_style( $handle, $src, $deps, $ver, $media);

You can increase the $ver parameter every time you've changed the files:

wp_enqueue_script( 'my_script', 'my_script.js', '', '0.11' );
wp_enqueue_style( 'my_style', 'my_style.css', '', '0.11' );

The URL of the stylesheet/script will be changed to '.../my_script.js?ver=0.11' so that every caching system detects the changed file and reloads it from its source and the user always gets the recent version.

But to change the version number manually every time in the development stage would be a bit tedious and you're a programmer, right? So let's automate this:

wp_enqueue_script( 'my_script', 'my_script.js', '', time() );
wp_enqueue_style( 'my_style', 'my_style.css', '', time() );

The value of time() changes every second so the version ID of the file changes constantly and it's reloaded from the source and not from some cache.

It's a bit disadvantageous that you have to substitute the time based version parameter by a "real" version number every time you deploy your code since the actual user still should have the benefits of cached scripts and stylesheets. Let's extend the idea:

define ('VERSION', '1.1');

function version_id() {
  if ( WP_DEBUG )
    return time();
  return VERSION;
}

wp_enqueue_script( 'my_script', 'my_script.js', '', version_id() );
wp_enqueue_style( 'my_style', 'my_style.css', '', version_id() );

This way you can make sure that in your development environment everything is reloaded from source all the time but a productive server takes advantage of caches.