Using Joomla! as an intranet

If you’re using Joomla! for an intranet, or any site that is closed down completely for all non-registered, there’s a simple trick: put your site in offline mode. Out of the box this will lock down everything for everyone who hasn’t got backend permissions, but there’s a way to change that.

Offline mode

Step one is to put the site offline. There’s an option for that in the Global Configuration. You’d normally use that when making significant changes to your site, to keep users out, but allow managers and administrators in. In our case, we want to allow all registered users. I suppose that with the new ACL in Joomla! 1.6, there will be a place where you can change this. For now, we’ll just make a small hack to /includes/application.php

// Find this line:
if ($this->getCfg('offline') && $user->get('gid') < '23' ) {

//Change it to: 
if ($this->getCfg('offline') && $user->get('gid') < '18' ) {

The template

You might also want to adapt the look of the login page to your site. Here we don’t need to hack a thing, as we can use template overrides. Copy the file /templates/system/offline.php to /templates/[YOUR_TEMPLATE]/offline.php. It’s plain HTML with some PHP tags, so you should have no problem editing it to your liking. Changing the graphics and some text will be sufficient for most people.

Read more

Easier debugging in Joomla!

If you’re a template designer or extension developer (or if you just like to hack existing extensions), you might want to take a look at J!Dump. I started the project more than a year and a half ago, in the dark ages when Joomla! 1.5 was still in beta. I didn’t have the time to maintain it, but luckily Jens-Christian Skibakk (aka jenscki) stepped up and took over development. This month, a brand new version 1.1 was released.

What is J!Dump?

J!Dump solves some often recurring problems during development. When you want to know what a variable contains, you can use var_dump() or print_r(), wrapped in <pre> tags for readability. With large complex objects, this quickly turns into a mess. Furthermore, the output is mixed in with regular Joomla! output, which makes it even messier. And if you’re var_dump() statement is followed at some point by a redirect, you never even get to see the output.

J!Dump does it differently. When you dump($foo);, the contents of $foo are stored in the session data. At runtime, J!Dump opens a popup window, and shows the dumped variables, using a nice javascript tree. This allows you to dig into the variable a much nicer way than reading hundreds of lines of print_r output.

The best way to get a feel of how J!Dump can make your life easier, is to try it. Simply install both the plugin and the component on your test system and put a dump($some_object); statement in your code somewhere. Check the readme for more info.

Of course there are better ways to debug your applications. The nice thing about J!Dump is that it’s very easy to setup and get started, especially if all you need is a quick insight in the code instead of full-blown debugging.

By developers, for developers

J!Dump is a free GPL extension, which not only means you can use it as you wish, you’re also encouranged to contribute to it. If you want to add some features, let me know, and I’ll add you to the project.

The book “Mastering Joomla! 1.5 Extension and Framework Development” by James Kennard mentions J!Dump, as well as J!Code, as being two prominent tools for the developer. Cool!

Read more

Roll your own migrator plugins

The migrator component makes moving data from your old Joomla! 1.0 site to a shiny new 1.5 site very easy. You can even make it migrate data from third party components, using the so called ETL plugins (for Extract, Transform, Load). But what if the components you’re using don’t supply ETL plugins? Roll your own! You don’t have to be an expert developer — just follow these easy steps.</p>

  1. Find out which database tables the component uses. You can usually find these by looking at phpMyAdmin, or by looking for files in the component’s /table folder.
  2. For each of these table, make a new file and give it the name of the table. Eg. if the table is called #__guestbook, make a file called guestbook.php. Keep in mind that come components might depend on tables from other components or the core, such as the user table. You’ll need to make sure you migrate those tables as well.
  3. Inside the file make a class with the name of the table, like this:
class Guestbook_ETL extends ETLPlugin
  1. First we tell the migrator what our plugin is called:
public function getName() {
return 'My Guestbook Migrator Plugin';
}
  1. Next, we need to tell the migrator what table we migrate from:
public function getAssociatedTable() {
return 'guestbook'; // no prefix needed
}
  1. Finally, we need the CREATE statement. You can get that by using SHOW CREATE TABLE jos_guestbook in your MySQL client, or by looking at the component’s XML file.
public function getSQLPrologue(){
return 'CREATE TABLE #__guestbook (`id` int(11) NOT NULL auto_increment, .....';
}
  1. Install the migrator component on your old site, and use it’s upload feature to add the plugins. Activate the migration and continue as usual.
  2. Enable Legacy mode and install the component. Make sure to check the XML file, some components have a DROP TABLE statement in there. It’s also good practice to use CREATE TABLE IF NOT EXISTS statements.

This approach should work for most of the components out there. Still, this is only the tip of the iceberg. Migrator plugins are a lot more powerful than that. They allow you to rewrite the tables and the data in them, eg. for when the 1.0 and the 1.5 version of the component have a different database schema. If you want to learn more about that, you should take a look at the actual ETLPlugin class, as well as the core plugins that come with the com_migrator package.

Resources

Read more

Debugging Joomla! applications in Eclipse

Past weekend, we went to Utrecht to attend Joomladay NL 2008. On the community day, I gave a presentation about the Eclipse project. The presentation included a short introduction to the project, an overview of the different ways of developing PHP applications in Eclipse. At the end I explained how PHP developers could debug their PHP applications using Xdebug.

Read more