Lately i’ve tested some techniques to overcome the blocking nature of script tags to improve page load performance, and i ended up using LABjs which seems a really promising project.
The main drawback of this non blocking technique is that, since JavaScript parsing is not blocking the interface anymore users may encounter several flash of unstyled (or un-behaviored) content (FOUC – FUBC), which may break the interface (and make your marketing team screams at you).

The solution here is: struggle a bit more instead of leaving script tags in the head.

What i’ve came up by following some suggestions by the LABjs author and the web community is to separate my CSS styles in two separate levels: one for un-behaviored contents and one for JavaScript enabled browsers.
The trick is simple: since the only tag script you need is the one of LABjs, just open it and add this line at the very top of the file:

document.documentElement.className = 'hasJS';

This way you will add a hasJS class to the html tag that you may target in the CSS rules to overwrite and implement styles to get your interface ready for JavaScript interactions.

The drawback of this technique is that adding a class attibute to html tag won’t validate, but that’s the only CSS addressable node before DOM ready event.

This way your interface won’t flash anymore and your users won’t notice any change while JavaScript is getting loaded in a more efficient way.

<form role="search" method="get" id="searchform" action="">
[...]
</form>

As for the spec, role is an attribute introduced in XHTML draft for accessibility, but still not valid.

If you need valid documents, the fastest way to get rid of this attribute is to edit the get_search_form() function in general-template.php core file, but for better compatibility and safer future upgrades you can target the issue from your theme’s functions.php file by adding the following lines:

function valid_search_form ($form) {
    return str_replace('role="search" ', '', $form);
}
add_filter('get_search_form', 'valid_search_form');

The best solution for our coding needs is to adopt a JS framework as backbone for our scripts. One of the very first framework I’ve worked with is Mootools, since it’s very developer friendly and fulfils lots of JavaScript’s “holes”.

In the next few days i’m going to receive a copy of:  MooTools 1.2 Beginner’s Guide, which I’m going to review for the sake of some of my followers and friends which are in need of a good starting point to learn how to improve their interfaces.

If you are interested you can check the details of the guide at the publisher website.

Stay tuned!

The only problem is that, once you have coded an override for a module, it’ll be used for all module’s instances within the CMS. The issue here is that you might want to output one module in a column as just a simple list of links AND in the main body as a content-rich table.

This problem can be addressed with a module hack and the addition of a new backend parameter type (for 1.5 native modules only), both in a system wide or module specific way . Here is a step by step tutorial:

Adding a new parameter to the module

Joomla 1.5 features a native way to add backend parameter types beside the native ones. In our case i’ve realized a new element (parameter) file which will look if a template override folder exists for the spefic module and, if found, will list all PHP files whose name is prefixed with “custom_” . You can download the file here.

Now you’ll need to place this file inside a folder called element, then open the .xml configuration file of the module and search for the <params> opening tag. Replace it with the following code (YOURMODULENAME is the module name):

<params addpath="/modules/mod_YOURMODULENAME/element">

Now place the new parameter as the last child of the <params> tag:

<param name="template" type="customtemplates" modulename="mod_YOURMODULENAME" default="default" label="Custom template" description="Use this custom template file" />

Hacking the main PHP module file

To make the module fully aware of the new template you choose, you need to pass the customtemplates paramenter to the static method which retrieves the template. For instance let’s say your mod_mymodule.php file has a line like this:

require( JModuleHelper::getLayoutPath( 'mod_mymodule') );

Now provide the customtemplates parameter by changing the line to:

require( JModuleHelper::getLayoutPath( 'mod_mymodule',$params->get('template','default') ) );

Done!

Untill no custom template’s overrides are found, the default template (default for the module or the default override if present) will be used. Once you’ll create a custom_whatever.php template file it’ll show up in the select list.

Adding the new parameter system-wide

By adding the parameter as a native-like parameter, you’ll be able to use it on all module without calling it in the <params> tag.

To add the paramenter system-wide you just have to place the customtemplates.php element in the /libraries/joomla/html/parameter/element folder. Since this is a custom element you shouldn’t have any problem on CMS upgrades.

The drawback

There’s a major drawback for this solution: since you are going to modify some module’s file you’ll need to keep a copy of them to prevent future upgrades from removing your changes (and breaking your template).

Further readings

Joomla has a really flexible parameter system, underused by many developers. Here are a couple of further reading to understand how parameters can help your everyday Joomla coding:

• Joomla Docs: Component parameters
• Joomla PHP: extending config.xml with plugins

ezSQL

When dealing with MySQL databases, one of the most used PHP class is ezSQL, by Justin Vincent. If you’ve never listen about it, just think that a slightly modified version of this class is used as the core of Wordpress database library, and every time you query the database for a post, ezSQL comes in action.

Despite its effectiveness, ezSQL development seems to have stopped to version 2.04.

Since in my projects i often use this class to work with MySQL databases, i’ve written a small extension to the ezSQL_MySQL adapter to add shortcuts and more efficient functionalities to make further easier to manage databases’ data with PHP. Here you are CRUDités.

CRUDités: MySQL appetizer

Crudités are traditional French appetizers comprising sliced or whole raw vegetables. As of its name, CRUDités is just a set of handy methods to quickly manage many operations of writing, storing and deleting from and to MySQL databases.

Aside from the basic ezSQL methods, it adds some methods to build MySQL queries from strings and data arrays, new methods to retrieve datas from columns and rows, some utility methods and a whole new table binding system, to store table’s fields and quickly update and store new datas.
For example you’ll be able to query a database and get a resulting array of rows just with this code:

$rows = $db->get_data(array(
      'select' => 'id,name,surname',
      'from' => 'customer_names'
));

You can get more informations about the project by visiting its main page, or you can directly download the class file by clicking here: CRUDités (13.5 kB)

Day by day, i’ve understood why so many developers use libraries (or frameworks) such as Mootools or jQuery: It’s a matter of typing.

document.getElementById("test"); //native Javascript
$("#test"); // with jQuery

At the same time i’ve learnt that libraries aren’t always worth their weight. Small projects don’t need them, and just writing a shortcut like:

function id(string) {
   return document.getElementById(string);
}

can make your life better (and more lightweight).

Introducing Bicycle 1.2

That said, here is a new version of Bicycle, my little “JavaScript Collection”. As from the name, it’s a lightweight and load-cost-effective library (about 9Kb minified) with everything is needed to keep your code simple and cross-browser. Here is a sample code:

var el = $getEls("test");  // get the element with id "test"
var input = $TN("nametext");  // get the first element with name "nametext"

Chainability

Anyway, if you need something more, since this new version Bicycle features a convenient chainability wrapper, with even new methods such as mouse and DOM-ready events and AJAX handling.

The chainable structure is bound to the $b namespace, so that you can use it along with other libraries. Here is a sample code:

$b("#test").css("color","red").txt("New text!");

See the documentation for more methods.

Form Handling

Finally, as a bonus, i’ve added a smart piece of code called Telegraph, which is basically a form handling library to quickly get and manipulate form inputs:

$b.getForm("myForm").value("testinput"); // get an input value
$b.getForm("myForm").serialize(); // serialize form data in a JavaScript object

Grab a copy

At last, more code can’t mean same weight, but i suppose you won’t mind it, ’cause  Bicycle core + chainability + new methods + Telegraph is just 22Kb minified.

Head to the main project page to get more infos and documentation, or grab a copy of the source code and “take a ride” with your brand new Bicycle.

Changes in this new version are:

1. Updated MooTools Core to 1.2.2 1.2.3 and MooTools More to 1.2.2.2 1.2.3.1
   
2. Added .getValue() to the compatibility file
3. Added .getSelected() to the compatibility file to fix some issues under IE
4. Added Json support to the compatibility file
5. Added window.onDomReady shortcut for DOM ready event
6. Changed MY_Behavior::mootoolsFix(); to handle new MooTools files 
7. Changed MY_Behavior::mootoolsFix(); to correctly render old tooltips format title::text for items with hasTip class (anyway, remember that classes to style the tooltip have changed!)
8. Added a validate.js replacement to fix an issue with changed namespaces. ( this replacement is no more needed)
   

The source code is released in the form of patch: unzip it and upload files in your Joomla root, eventually overwriting files. MooTools library is uncompressed to allow for a quicker debug. Anyway you may minify it with your tool of choice.

Here is the code: Mootools 1.11 to 1.2.2 (71.68 kB)

Update (again): Sometimes i can’t get if MooTools team is too vital or library milestones are not well defined… anyway here is an update to use latest MooTools 1.2.3. No major changes have been made to the fix library, anyway keep reporting compatibility issues. Here is the zipped  file: Mootools 1.11 to 1.2.3 for Joomla 1.5 (72.06 kB)

Update (09/20/09): New version available. Corrected some bugs in the compatibility file and added a loop check to replace MooTools 1.11 when called from a component as custom script. Now the validation core script doesn’t need to be replaced. Get source here (carries the original validate.js as in Joomla 1.5.14:  MooTools 1.11 to 1.2.x (72.88 kB)

In Joomla 1.5.x everything works fine when viewing the page as HTML, but in PDF and print friendly format view these shortcodes aren’t converted nor removed. Moreover displaying these contents could be unnecessary or unwanted.

This problem arise because in pdf and print view files in Joomla com_content component not all content plugins (those addons called mambots) are loaded. In PDF view file components/com_content/views/article/view.pdf.php there’s just one plugin (called image) loaded before the content is outputted (lines 68 -69):

JPluginHelper::importPlugin('content', 'image');
$dispatcher->trigger('onPrepareContent', array (& $article, & $params, 0));

The (dirty) solution

From a quick glance in the plugins/content folder i’ve noticed that there’s no any image.php plugin  file in a clean Joomla 1.5.10 installation. So i’ve decided to use this hole and create a custom plugin to clean my content without messing up the core com_content code.

After installing the plugin and activating it you are given (at the moment) two options:

• a radio to clean loadposition code (defaults to Yes)
• a textarea for typing custom regular expressions (one per line).

In this last field remember to omit backslashes (/) instead write curly brackets, for example {code\s*[a-zA-Z]}

Here is the package for download: plg_image (clean plugins code) (1.79 kB)

As always feedbacks and suggestions are welcome.

I’ve recently digged the problem and found that this could be related (kinda randomly) to a bunch of problems and conflicts with other Joomla feature (such as system cache).

In my own projects im using right now SH404SEF as SEF component and i’ve found it’s a really good piece of software, so here is a recap of the fix/patch for the problem.

First of all upgrade SH404 to the latest release by downloading it from JoomlaCode.

Now open custom.sef.php in administrator/components/com_sh404sef/ and search for a line containing:

$shDefaultParams['sh404SEF_PROTECT_AGAINST_DOCUMENT_TYPE_ERROR'] = 0;

and set the paramenter to 1:

$shDefaultParams['sh404SEF_PROTECT_AGAINST_DOCUMENT_TYPE_ERROR'] = 1;

If this line is not present then add it at the end of the file.

Now go to the backend panel in Joomla and purge all SEF url by:
Components -> SH404SEF -> Purge SEF Urls
then clear the cache by:
Tools -> Clean Cache

This will clear all current URLs, so that SH404SEF has to recreate them, anyway your PDF button should work again and the PDF URLs should be as the HTML one with an ending parameter ?format=pdf.

Source: http://extensions.siliana.com/forums/index.php?topic=9509.0

Note: As a side effect you shouldn’t problably be able to use the pdf folder feature to store custom PDFs!

Despite all these advanced features Joomla 1.5 is still stuck at JS framework Mootools 1.11. The latest version of this framework, 1.2.x, introduced many new features and a complete re-engineered code. Due to these changes, Joomla developers plan to upgrade Mootools in the 1.6 release, to be able to spread code changes to all plugins, modules and components. Until that release we’ll be stuck at outdated, unsupported and often undocumented code.

This is an attempt to add Mootools 1.2 support to current Joomla 1.5.9 release. Let’s start:

Update: A new version of files presented in this post is available here!

Requirements:

1. Nearly full compatibility with Mootools 1.11 to avoid errors
2. Upgrade of Mootools plugins where possibile
3. None or minimal Joomla core hacks
4. Implementation of Mootools in legacy (1.0.x) components

1. Smooth Mootools upgrade.

First of all let’s download the latest version of Mootools Core and Mootools More (right now 1.2.1):Mootools 1.2.1 Full (28.51 kB)

Unzip the archive and place the two files in media/system/js/

Then download this compatibility file, which will make old 1.11 scripts work rather smoothly with the new framework, and place it in the same folder as above (update 05/22/09 added getValue, Json and window.onDomReady compatibility, thanx Toopixel):

2. Plugins Upgrade.

One of the more usefull plugin shipped with Mootools is Squeezebox, used for the modal windows, here is the 1.2 Compatible version, ready to be placed in the above mentioned folder media/system/js/:

3-4. Let’s try some PHP

Since i want to touch Joomla Core files as less as possible, im going to use some little tricks to be able to use Mootools 1.2 just in the Frontend and on-demand from the template’s main index.php file.

Joomla is based on several PHP libraries placed in the libraries/ folder; one of them is the Joomla API, but we can find ezSQL (a database lib), PHPMailer (a mailing system) and phpgacl (an access list system). To take advantage of Joomla’s built-in libraries loading system and, at the same time, prevent overwrites by future releases, i created a folder called my_libs in libraries/ containing a class file: my_behavior class for Joomla 1.5.9 (1.13 kB)

Basically the class provides a static function which recalls the head part of Joomla document object, looks for Mootools and replaces it with the 1.2 version we uploaded before.

If Mootools is not found, then it’s simply loaded, extending it’s presence in the head of legacy 1.0.x components.

You can call this newly added class in your Joomla theme index.php by placing these lines of code before the head template tag:

<?php
JLoader::import( 'my_libs.behavior' );
MY_Behavior::mootoolsFix();
?>
<jdoc:include type="head" />

If you need to switch back to v1.11 you can pass false as first argument to the function like this:

MY_Behavior::mootoolsFix(false);

Note this!

This is just a test, it should work on a basic Joomla installation, anyway feel free to report errors and issues to improve the code.

Untill now, I’ve experienced that Virtuemart uses it’s own logic to load libraries, so it’s excluded by default.

Optionally you can exclude specific components by passing an array with their option value as second argument:

MY_Behavior::mootoolsFix(true,array("com_sobi2","com_comprofiler"));

In SOBI2 an error will be issued on search form unless you set the registry option use_own_mootools to 0.