Month: November 2013

Integrate LESS in JBST WordPress Theme

The WP LESS plugin offers a good opportunity to integrate LESS in your WordPress theme. How does this fit JBST? First i try to set the requirements.

JBST is based on Twitter’s Bootstrap, so we will have the option to update Twitter’s Bootstrap without changing any custom setting or extensions. JBST WordPress Theme can be use in two ways. In the first place someone can use JBST direct. In this case the website will be styled by using the build in customizer.
In the second option a child theme will be create. Customizing and styling will be done with the use of filters and hooks.
Updating of Twitter’s Bootstrap should be possible in both cases.
To find a suitable strategy i read Twitter Bootstrap Customization Best Practices. The solution of @sam seems to fit on the first sight. From How can I customize Twitter Bootstrap’s CSS using LESSCSS variables? i could construct a file structure.

Basically theme should compile customization.less which include Bootstrap. By default it always includes the bundled Bootstrap version. Compromise here will be the hard code path to Bootstrap’s LESS files:

@import ../../jamedobootstrapstarttheme/less/bootstrap.less
//custom Less code here

After this other CSS of JBST should also have to migrate to LESS. I will define a master and an custom file for this task too. So the final directory structure will look like:

/assets/bootstrap/less/*
/assets/jbst/less/*
/assets/less/boostrapcustomization.less
/assets/less/jbstcustomization.less

The plugin mentioned above should enqueue boostrapcustomization.less and jbstcustomization.less from the child theme folder if exists in the case of child theming or from the JBST parent theme in all other cases. Core files will always be imported from the parent theme. Updating Bootstrap won’t effect customizations.

So far the theoretical part. What did we find in practical? The first issue we found. The plugin didn’t support Twitter’s Bootstrap > 3.0.0. I fixed this by create a fork of the plugin which replies on less.php instead of LESSPHP. If your are interested you can download this code here.

Second issue was JBST doesn’t use the original Bootstrap files. Different versions of navbar.less are compiled and include based of the grid and navbar breakpoint (grid-float-breakpoint) settings in the customizer. To fix this we should save the customizer setting direct in some .less file (overriding bootstrap/variables.less).

Third JBST provides a custom CSS editor, this editor should be replace by a LESS editor.

The information in this blog will be used to migrate JBST to LESS. First steps are made already.

WordPress Development: Properly load your Javascript and set dependency

Theme and Plugin developers should wp_enqueue_script() to load the Javascript sources used in their code. Why should you enqueue? In the first place you should prevent conflict between your scripts. Secondly you should only load the resources you need per page. Load the right scripts only will reduce your load time.

WordPress offers a list of bundled resources like jQuery. So you don’t have to load jQuery every time, but you will have to set the dependency of jQuery of the sources you add.

Enqueueing you scripts proper will also help other theme and plugin developers. When two plugin need the same Javascript library you will load it only once. You will have to realize this in not guaranteed and documented well. If two plugins for example need some plugins of Twitter’s Bootstrap there will be no rules to describe the source already loaded. A solution can be both plugins depends on a third plugin which loads the resources. This kind of dependency is outside the scope of this blog post.

Although the reasons for proper loading seems clear many plugins and themes haven’t enqueued all their code.

Why do developers skip wp_enqueue_script()?

The main reason i found was the use of dynamic variables. Enqueued scripts load before the theme or plugin functions have been parsed in many situations. For example you will set the width of an element by javascript where the width will be user defined. The easiest but wrong solution will be to write it direct to source. Write javascript to source and for example make use of jQuery’s document ready will create a dependency of jQuery.

Solutions to use dynamic variables with wp_enqueue_script:

The first solution will be to write your code in native javascript not dependent of any library.
The second, and preferred solution in my opinion, is to (mis)use the wp_localize_script() function. wp_localize_script() localizes a script, but only if script has already been added. Can also be used to include arbitrary Javascript data in a page. The latest can be used to set your dynamic variables. Also read: Use wp_localize_script, It Is Awesome
Some example:

/** set parameters for display **/

$options = array();
$options[‘color’] = get_option( ‘color’, ‘blue’ );

wp_register_script( ‘color_display’, plugin_dir_url( __FILE__).’display_color.js’, array( ‘jquery’ ), ‘20131108’ );
wp_enqueue_script( ‘color_display’ );
wp_localize_script(‘color_display’, ‘color_display_options’,$options)

With display_color.js:

jQuery(document).ready(function($) {
$('colored').css('background-color',color_display_options.color);
};

Defer loading plugin

Recent i wrote a plugin for Defer loading. This plugin requires scripts are enqueued proper. Testing this i found many issues with different

plugins: