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

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.