Hallelujah! CodeIgniter has finally released version 2.0.0 after a very long and patient wait, as a stable, production ready framework. It was deemed more stable than the 1.7.2 version for quite a while before it was officially released, as all bugs that were fixed in the old version were applied to the dev version at the same time, while making further improvements. So the usual deal of waiting a few months while a new major release goes through it’s teething stage thankfully doesn’t apply here, it’s ready to roll right now.

What do you need to know?

There are a few new items in 2.0 which you can read in more detail about on their website, however the main points to note if you are planning an upgrade are:

• PHP4 support is gone, the lowest version of PHP supported is 5.1
• The validation class (which was deprecated) has been completely removed, the form_validation class has taken over
• Scaffolding has been removed (this was also deprecated)
• Plugins have been removed, Helpers are to be used instead

What do you need to do?

As always, take a full backup before you make any changes so you can rollback.

Download the latest version of CodeIgniter Reactor and extract it somewhere on your computer.

Hopefully you’ve only made changes to the files in the system/application folder. If you’ve made changes to anything else in the system folder, you’ll need to go back and move those changes to where they should be in the system/application folder before you can move forward.

The system/application folder in 2.0 has been moved to the top level, so first thing you need to do is move your system/application folder to sit in the root alongside the system folder.

Now delete the system folder.

Completely.

You’ve now removed the CodeIgniter base, simply swap in the system folder that you downloaded from the CodeIgniter site, add the following additional files from the download into your site, and we’re ready to move on to a few convention changes.

• index.php
• application/config/foreign_chars.php
• application/config/profiler.php

Convention changes

In each of your controllers and models, (unless you’ve created your own base controller to extend, in which case you only need to update your base controller) you are probably doing something like

class user_model extends Model

You’ll need to go through and change this to

class user_model extends CI_Model

The same goes for controllers, whereby instead of extending Controller, you need to now extend CI_Controller

Change your plugins to helpers

If you’ve written or downloaded any plugins to use on your site, you’re going to have to convert them into helpers. It’s a pretty simple change, just move the files in the plugins folder to the helpers folder, rename them from xxx_pi.php to xxx_helper.php. Then update your config.php file to make sure you are autoloading the same files as before but now as helpers. That’s it!

Move over to Form Validation

You can in theory get the old validation.php file from the 1.7.2 version of CodeIgniter and place it in your application/libraries folder and be done with it. However, if you can spare the time it’s more beneficial to use the new Form Validation class as you’ll be able to take advantage of the much neater code and also keep on top of any updates and improvements made over time. When working with user data, keeping on top of security releases can be a pretty important thing. The small amount of effort is worth it.

That’s it.

You’ve just upgraded to a version 2.0 base. Now you need to give everything on your site a thorough test to make sure that everything is in working order.

There are a few more left field items, but for 90% of sites out there using CodeIgniter 1.7.2 this will cover you for making the upgrade pretty painlessly.

If you do get stuck, remember there’s a very active userbase on the CodeIgniter forums only too happy to help out.

There comes a time when you need to bite the bullet and upgrade your site from the old to the new. Not only are you leaving yourself open to security vulnerabilities as older versions are no longer supported so new security holes found are left open, but future work will also be more complex as extensions are no longer being made for your sites outdated framework.

This can only spell disaster, maybe not in the immediate future (hopefully never), but you’re doing yourself and your sites users a disservice by leaving it outdated and vulnerable. It’s also a perfect time to give the site a facelift, but that’s fuel for another post.

Of course this is easier said than done, particularly if you’ve let your site age quite a bit. Fortunately for the most part, the upgrade process for Joomla is relatively straight forward, the downside though is any third party or custom extensions that your site has will not gracefully be moved over in the upgrade process.

So if you have a basic, content only site, you’re in luck. If not, some planning needs to happen to make the transition as smooth and painless as possible.

There’s no path at this stage (and nothing has been announced) to migrate directly from 1.0.x to 1.6.x, so this article will cover both migrating from 1.0.x to 1.5.x, then from 1.5.x to 1.6.x.

Migrating from 1.0.x to 1.5.x

This step is the easiest of the whole process, and is well documented on the Joomla wiki http://docs.joomla.org/Migrating_from_1.0.x_to_1.5_Stable

It basically involves installing a component on your existing 1.0.x site to create a file that will be used when installing a fresh Joomla 1.5.x site.

Note that we said ‘migrating’ instead of ‘upgrading’, this is because you actually need to download Joomla 1.5.x from the Joomla site and do a completely fresh install on your development machine, rather than edit any existing files.

Nearing the completion of the the installation process of the Joomla 1.5 site there will be a screen that will allow you to kick off a migration process, simply upload the file that was created earlier from your old site and it will import with a good amount of success the following:

• content
• core modules
• custom html modules
• menus
• data from core components

What it will not import though are (among others)

• 3rd party plugins / components / modules
• custom plugins / components / modules
• templates (as these are file based)

If you are making the move all the way to Joomla 1.6.x, then this is all you need to do with the Joomla 1.5.x migration, move on to ‘Migrating from 1.5.x to 1.6.x’

Why? Joomla 1.5.x allowed plugins, modules and components to run in what was called ‘legacy mode’, which meant that it allowed code that was built for Joomla 1.0.x to run in a Joomla 1.5.x site.

This backwards compatibility is non existent in Joomla 1.6.x as the core of the site has been modified too much to efficiently be able to allow for older code to be supported. While initially it may seem like a pain, looking forward this is a good move as it will force extensions to be well written and closely follow the Joomla conventions, making it much easier for developers to make their own extensions or work on existing code.

If you are planning to stay at Joomla 1.5.x for now, then you will now need to start the process of reinstalling all of the components, modules and plugins that you had on your 1.0.x site and switch on the Legace Mode plugin to allow them all to run smoothly.

You will also need to make a few modifications to your template file as the syntax for displaying Joomla elements has changed somewhat. Details on upgrading a template from Joomla 1.0.x to 1.5.x can be found here: http://docs.joomla.org/Tutorial:Upgrading_a_Joomla!_1.0.x_template

Migrating from 1.5.x to 1.6.x

Thankfully a component has been created to help out with this move, at the time of writing though there were a few issues we found which we’ll outline shortly, but first, how to use it.

The component is named jUpgrade and can be found here: http://extensions.joomla.org/extensions/migration-a-conversion/joomla-migration/11658

This step doesn’t require you to download and install a fresh Joomla 1.6.x site, this component when run will actually download the latest stable package for you, install the files in a new folder that is creates called jupgrade, and will create all the tables it needs to run in the main database but with j16 as the prefix instead of the default jos prefix. This allows you to run the two sites side by side until your migration is complete.

The installation process is pretty impressive to watch, however as noted earlier, there were a few issues that we found with this upgrade (at the time of writing the latest stable version of Joomla was 1.6.0 and the latest stable version of jUpgrade was 0.5.3, while our experience was with 0.5.1, some bugs are noted to be fixed and will be marked as such)

• Placeholder / separator menu items were not moved over (possibly fixed in v0.5.2)
• Many menu items were pointing to the wrong article (possibly fixed in 0.5.2)
• Multiple menu items were marked as the default (possible fixed in 0.5.2)
• Creating new menu items throws an error if an alias is not explicitly set, however the menu item is still created (this may be a Joomla bug, not the jupgrade)
• Content of custom HTML modules were lost in the move and needed to be manually re-entered
• At first attempt trying to view a category listing (from a newly created menu item) the site throws a 404. The quick manual fix was to move the category to be a child of another category, then move it back. It seemed to work fine after that, but obviously that’s a pretty poor workaround. Hopefully this has been fixed in a later release of jUpgrade.

A few extra notes for 1.6.x first timers:

A new feature for ‘discovery’ is available in the extenuation manager which allows you to simply add your files to the site and have Joomla discover them and present them to you in a list of items that are available for installation rather than have you need to package them and upload them as an installable package.

• There’s been a change in the required XML format for your extensions, which you can see here: http://www.finishjoomla.com/blog/22/joomla-16-vs-joomla-15-templatedetailsxml/
• When installing a module, while the installation will be successful, it won’t show up in your list of modules straight away as you are used to. You need to create a ‘new’ module, the module you installed will show up in the list of modules you can choose for the module you are creating.

The raw base

To start off with, we’re going to at least need some sort of menu structure to get us going. For this, the best way to structure the menu is using an unordered list (ul), nesting your submenus as you go. Below is the example we’re going to use in this demo it its raw unstyled format.

(The running demo is here – http://lazarus.salsainternet.com.au/demos/css_jquery_dropdown.html)

Menu item 1

Submenu item 1
Submenu item 1


Menu item 2
Menu item 3
Menu item 4

Submenu item 4.1
Submenu item 4.2


Menu item 5

Opening that in a browser is going to be pretty plain, something like this:

A little css

For the sake of this tutorial we’re only going to give the menu a basic look and not get too fancy. So we’ll just create a nice green and black menu.

The nav we are going to create is going to be a left to right manu, with the second level popping out below its parent, so we first need to order the items left to right and get the submenu it the right position. (To keep it simple, the style is going to be added to the same file and not extracted into a saperate stylesheet)

Hiding the submenu

Now that the menu is working and displaying as we want it to, now we need to hide the submenu by default and setup the style for the hover state.

Change the left value for the “#mainmenu ul li ul” class to be off the screen somewhere (we’re using -12000px here) and add a new hover class for the list item, which moves the ul back to where we just had it when the user hovers over the main menu item.

				#mainmenu ul li ul{
					width: 170px;
					position: absolute;
					left: -12000px;
					float: left;
					clear: left;
				}

					#mainmenu ul li.hover ul{
						left: 0px;
					}

Adding the jQuery event… the fun part

Up to this point, the file could run as a standalone HTML file, and with a little extra CSS could actually work in a lot of browsers, but there are many out there that don’t support using the “:hover” on list items, so we need to make use of some javascript to tell the browser to react when the user hovers over the main menu items. So first step here is to actually load the jQuery javascript:

(The no conflict line has been added in cases where people may already be calling a javascript file that makes use of $, it prevents us from running into any javascript code conflicts)

And now here is where the magic happens, using jQuery you can ‘chain’ function calls one after the other without having to do each function call on an element on its own line which cuts down the file size and keeps things neat and together.

Finally, just to top things off we need to add some hover colors to the menu items.

				#mainmenu ul li.hover a{
					background-color: #3c3;
				}
				#mainmenu ul li ul li.hover a{
					background-color: #333;
				}		

And that’s it, a fully functional CSS dropdown using jQuery. In a later article, I’ll cover adding a slight animation and also adding multiple levels of dropdowns.

Demo and full code

Here’s the running demo – http://lazarus.salsainternet.com.au/demos/css_jquery_dropdown.html

Happy coding!

Chris