MetaMod Position Display Management

When using Joomla! sometimes one requires to hide some information, like a specific menu, or an entire position.

MetaMod let’s you do this in a quite easy way. One can follow their documented technique of moving stuff from an non-existing position into the real position, or one can use a simpler strategy that does not imply having virtual positions and nor moving stuff between these virtual positions and the real position.

Imagine you wish to hide all position placeholders on a marketing landing page. It’s quite easy:

  • Download and install MetMod. Don’t forget to read the documentation to know how MetaMod works.
  • The first step is to define the MetaMod position in the last one to be interpreted by Joomla!, usually the footer or the debug.
  • This guarantees that our code will be executed only when all positions are already loaded.
  • The second step is to define the MetaMod execution rules, as stated in the documentation.
  • Next, in the PHP window, include the execution code that will hide or display the position through the injection of a Javascript conde snippet.

Here’s an example: let’s say that one wishes to hide the stuff on the left of the page (usually the menu, login, etc.) when the user is located in the Virtuemart Cart plugin.
Here’s what one has to do:

  1. Identify the location through the $option and $view parameter values.
  2. Inject a Javascript script that finds the left position element and hides it.
  3. If required, adjust the size of the remaining position in order to claim the extra space.
  4. Return the current position.
Here’s an example that hides the “column_left” position. Please note that this MetaMod example is located in the “debug” position, change it if necessary.
if ($option == 'com_virtuemart' and ($view == 'cart' or $view == 'pluginresponse'))
echo "
   elem = document.getElementById('column_left');['display']='none';
   elem = document.getElementById('content_wrap');['width']='960px';

return 'debug';

Obviously this must be adapted to the template in use and it may required some adjustments, like the new size of the position that should claim the extra space.

One can use Firebug to help finding the HTML div elements identifiers involved.

Drupal vs Joomla!

Hexónico has launched a free item exchange service for the Portuguese speaking community: Trocaqui.
It was implemented using Drupal, for the user front-end, and that raised a lot of questions. Many people asked me, “why Drupal and not Joomla!” and “you’re using a CMS, what’s the difference between Drupal and the others“.

So, I’ve decided to write a bit about the Trocaqui project and why Drupal.

When the project started, obviously some options have been evaluated: writing from scratch, using a framework, using a CMS, etc..
Writing from scratch was out of the question, since it would consume too much time to achieve the quality and functionality some systems already provided. The same applied to the usage of a framework that would left all the hard work to the developers. Mambo, Joomla! and Drupal are all CMS references.
From those, Mambo is an old friend, which has been dropped in favor of Joomla!, since it is like the natural evolution of Mambo.

After some analysis, it came to the point where it was either Joomla! or Drupal. Some tests were performed to see which would respond best to the main requirements:

  • Translatable (i18n for Portuguese)
  • Easy to use for the end user
  • Extensible
  • Expandable
  • Forum support
  • Image management support
  • Flexible and easy user access configuration setup
  • Easily costumizable

The tests started by setting up the systems which was an easy task for both of them.


Joomla! is ready to be used just out-of-the-box. It allows one to manage text and images, it comes with a WYSIWYG text editor and is quite easy to understand. Almost everything is where one expects it to be. So, finding an option and using it is straightforward.
On the other hand, Drupal is not so usable out-of-the-box. It just supports text and doesn’t came with an WYSIWYG editor.
So, some additional modules were necessary in order to expand Drupal to support my needs.

When it comes to module/plugin installation, in Drupal it is totally manual, so are the upgrades.
One has to uncompressed the file contents into a specific directory, the go to the modules section in the administration menu to activate it. Then one has to configure it.
Sometimes this is not as easy as it seems and some technical background is required in order to setup things correctly.

Core Modules

Drupal does not come with a WYSIWYG text editor.
Since I needed a rich text editor, I had to test editors before selecting one that worked as I needed. It was a bit painful because I had to test some and that took more time than I was initially expecting.

Drupal does not come with an image module.
A content management that cannot manage much beside text is not very useful.
Thus, the quest of an image module began. I’ve found Drupal has many modules that support images. And I’ve also found out that the reason for this proliferation of image modules is that because they all suck. There’s not one good image module for Drupal, so it seems that everyone that needs one, develops one.
After some digging and testing, I’ve finally found an image module that suited half my needs. After some more digging, I’ve found another module that was suited for the other half of my needs.
Everyone that needs images on their CMS should check if Drupal modules fit their needs before going for Drupal.

How They Work

Drupal working philosophy is not straightforward.
In Drupal, things are not were one expects it to be. It works with a organization and, to me, it complicates things, making it far more complicated that it should and needed to be.
Even today sometimes I take 10 or 15 seconds looking around for a specific option. It is not administrator friendly, specially if you don’t work with it often.

None came with a forum solution, so I had to install one on each of the systems.

Finally I’ve finished setting up the systems.
Drupal had been painful so far, and I was loosing some consideration about it. But people do refer to it as a great CMS, so I decide to continue according to my plan.

It was time to evaluate things regarding my functional needs.
An here’s the turning point favoring Drupal.

Joomla! does not come with flexible user parameters. But Drupal does.
In Drupal, the core user module allows one to defined specific parameters and corresponding value types in a very easy way. Probably Joomla! allows it to, but I didn’t invest much time searching for such a module/plugin.

Joomla! does not allow drag-and-drop.
In Drupal, it is easy to move things using the mouse, just drag that menu option and drop it where you want it, do this option as many times as needed and the push the save button. This seems a minor issue, even from me (I’m a less WIMP than the average), but the amount of work that I was performing with such easiness allowed me to be far more productive than doing the same similar task in Joomla!.


Everything was going fine until a show stopper bug was found. There was so many exchange categories that Drupal stop ignoring the specified exchange category order.
Not even the weights were working. Even banging directly on the database the items were not showing up in the correct order.
This forced to stop the project for some weeks while finding the solution.
There were other complaining about this bug, it is know for years but yet, Drupal seems to be ignoring it.
This problem has been posted this in Drupal forum but the lack of answer was starting to put this project on a failure risk because it seemed that there was no solution .
But suddenly, a specific module for this problem came from Ben. He was just fantastic in helping with this problem, he developed a small module, with a few lines of code, that solved the problem. Trocaqui was on the move again.

Next, it was necessary to create a template for the user to use when posting a new exchange item.
This revealed the true power of Drupal and why technical people love it. In Joomla! One needs to modify the forum module source code and use that modified module and, when a new version came out, do the same.
In Drupal I only needed to create a hook. A hook is like a handler that overrides the original code. One just say, when this event happens, that one wishes to do such and such. It was not easy to find out the correct data in the data structure that needed modification, specially when one is new to Drupal programming. But once the correct data was found, it revealed simple, easy and clean. The simplicity was dazzling and by then there were no doubts whatsoever that Drupal was the way to go.

Translating things to Portuguese also revealed much easier in Drupal. Both systems do have translation files for their modules, but Drupal allows one to translate things on the fly. Drupal has a translation interface that does not require the user to edit the translation file and upload it into the server.

Permission configuration also revealed a bit simpler in Drupal. I’ve just configured the read, write and administer accesses of each module for registered and non-registered users.

Finally it was necessary to create a specific home page to show to everyone that landed on the site.
Since by then Drupal was already selected, this was not even tried in Joomla!.
In Drupal there’s a specific front page module that is just fantastic. There were two pages created: a specific home page for non authenticated users and another to authenticated users. It was just simple.


After all this quest here’s the lessons learned:
Joomla! is recommended for non-technical people and for web sites that do not require awkward requirements. It’s a great out-of-the-box solution and much easier to work with. But when things get though, one needs a technical person and one wants Drupal supporting your site, even if it costs a lot of time to learn how to use it.