Joomla! How-To's: Development

Session storage is a very important aspect of web applications. In its simplest form, a PHP session allows data to be stored temporarily on the server and accessed throughout a user's time on the site. When that user leaves the site or is inactive for a certain amount of time, the data is destroyed. While anonymous sessions are common, sessions are usually associated with user logins. When a correct username/password combination is entered, a session is created around that user's access information and then read and checked every time that user loads a page. As a developer, you can access this session functionality to enhance your extensions.

Debugging PHP applications has always been a bit of a challenge, as the environment is so distributed. At the minimum, there is a web server, the PHP interpreter, and the web browser. While there are tools that add debugging environments to PHP (such as XDebug), you don’t always have access to install them on the server you’re working with.

Fortunately, you can gain some reasonable debugging capabilities through FirePHP. When you want to dump objects or variables back to your browser without having to do so in your HTML, FirePHP is ready for the task. It can also be used to handle code traces and PHP errors.

FirePHP is both a Firebug extension and a PHP library. When the PHP library is in place, special HTTP headers containing JSON objects are created. Firebug reads the HTTP headers, decodes the JSON, then shows the variables in the console. Since the output body is unaffected, it is extremely useful for debugging XML, JSON, PDFs, images, or other non-HTML output generated in PHP.

Something I have run into frequently during module development is the need to allow multiple instances of that module on a single page. Joomla!, of course, handles 99% of the work involved, but there are a few tricky aspects to making this work. One is the need to eliminate styling conflicts, especially in themed modules. If you only use generic classes and then load multiple theme/color stylesheets, the end result can be unpredictable to say the least.

Long-time users of Joomla are quite familiar with content plugins. When you want to take some user-entered text and reformat it into something else, there’s nothing quite as handy as having a content plugin ready to do your bidding.

However, Joomla 1.5 brought some subtle behavior changes. In Joomla 1.0, content plugins act on both articles entered through the Article Manager, as well as HTML entered in user created modules. When a Joomla 1.0 content plugin is recoded for 1.5, the original effect still takes place on content items, but module output is left unchanged.

What happened? Content plugins in Joomla 1.5 are designed to only act on articles managed through the Article Manager. This will seem inconvenient to people used to the old behavior, but there is a good reason for this change. While many content plugins reformat user-entered HTML, others add markup near the article title or just after an article is output. Also, some content plugins are designed to do additional tasks when articles are saved. These actions do not make sense within the context of a module, so content plugins no longer run on them.

While this good in that it enforces consistency, it also poses a problem. Now that content plugins only work on articles, how do you reformat markup coming from modules? Fortunately, there are a couple of workarounds in Joomla 1.5 achieving similar (if not better) results.

Because of it ubiquitous nature, automatic emailing is something that many clients expect. People want to be notified immediately of changes on their sites -- when a new article has been submitted, or a blog comment has been posted. Joomla! already provides some of this functionality out of the box by notifying administrators when a user has registered on their site. You, however, may find yourself needing to implement emailing in your own components. As you may have already guessed, Joomla! provides a very helpful class for this: JMail.