Posts tagged with php

Today, 08/08/2008, is not only a popular day for getting married, it’s also a great day for the PHP world. PHP4 is no more, it’s expired, it’s pushing up the daisies! PHP4 is an ex-language. From now on, only PHP 5 is supported, the version that turned PHP from an advanced scipting utility into a an enterprise grade, full blown programming language.

A bit of Joomla history

When Joomla! 1.5 (called 1.1 at the time) was planned, it was decided to go for PHP4 compatibility, as PHP5 was not being adopted by ISP’s a lot. In retrospect, it would have been better to go for PHP5 right away, but of course, no-one at the time knew it would take two years before Joomla! was ready for release.

Luckily, in a flash of brilliance it was decided to make Joomla! forward compatible with PHP5. By coming up with some clever tricks here and there, adding the proper docblock comments, and having a clean naming convention, J!1.5 turned into an interim release that could bridge the gap between PHP4 and PHP5. The idea was that it then would be easy to refactor to PHP5-only in the next major Joomla! release.

Funnily though, when the time came to plan J!1.6, there was a general reluctance in the development working group to make the move to PHP 5.2, or even to discuss it. It took a couple of nudges from our end, to get the community to speak up and express the dire need to switch. It was great to see how the community really came together to push what it felt was important! In the end it was announced that 1.6 would be for PHP 5.2 only.

A bit of Joomlatools future

At Joomlatools, we knew early on we couldn’t realize all of our plans for Nooku using PHP4. As some people have begun to notice, Nooku is about more than just translations. A big chunk of the code is written in a way that will make it reusable for other extensions. Some of the API concepts and patterns we implemented (mixins, chain of command, inflection, …) wouldn’t have been possible with PHP4. So for us, PHP5 is the only way forward.

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!

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.

  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
  4. First we tell the migrator what our plugin is called:
    public function getName() {
      return 'My Guestbook Migrator Plugin';
    }
  5. Next, we need to tell the migrator what table we migrate from:
    public function getAssociatedTable() {
      return 'guestbook'; // no prefix needed
    } 
  6. 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, .....';
    }
  7. 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.
  8. 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