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!

To overcome this problem, users usually rely on an (super) administrator user action, since it’s the only user level who can access the Global Chek-in tool in the backend panel.

The main concern in this ACL rule on Joomla is that most of the times users who manage the website contents have a manager access level, since this user level is much more restricted on technical configuration’s options.

To allow Global Check-in action for managers, just edit the core file located at /libraries/joomla/users/authorization.php adding below line 91 the following code:

$this->addACL( "com_checkin", "manage", "users", "manager" );

Important: Since this is a core hack, keep in mind that it could be overwritten on further upgrades!