The Joomla project has released Joomla 2.5.28 that has been tagged as the last release in the Joomla 2.5 series.
Officially, as of December 31, 2014, the Joomla 2.5 series will no longer be supported. This means that there are no new releases planned for Joomla 2.5, as the Joomla project is putting all its efforts in its Joomla 3.3 and upcoming 3.4 series
There are no security related fixes in the Joomla 2.5.28 release, so there is no real rush to upgrade. However as this is the last of the Joomla 2.5 series you should start planning to upgrade your Joomla 2.5 websites to the even more secure, feature rich and mobile ready Joomla 3.3.6 environment. From January 1st Joomla 3.X will be the only security maintained release.
Joomla have a mini-guide on the uprade process: https://docs.joomla.org/Planning_for_Mini-Migration_-_Joomla_2.5_to_3.x
Differences between Joomla 2.5 and Joomla 3.3
The main differences between Joomla 2.5 and Joomla 3.3 that will most likely influence your upgrade situation are:
- Joomla 3.3 uses Bootstrap, where Joomla 2.5 does not. The Bootstrap markup makes your Joomla website responsive, which means that your Joomla website should look great in all viewing devices (desktop, tablets and mobile phones)
- Joomla 3.3 uses jQuery, where Joomla 2.5 does not.
- Joomla 3.3 needs PHP 5.3.10+, but Joomla 2.5 will work on PHP 5.2.4+. (Please check with us if the server that runs your site now meets this requirement)
- Joomla 3.3 needs MYSQL 5.1+, but Joomla 2.5 will work on MYSQL 5.0.4+.
In addition to these high-level differences your upgrade process may run into snags due to one or more of the following issues:
- Extension compatibility (in case you have installed some third-party extensions on your Joomla 2.5 site that are not Joomla 3.3 compatible)
- Template compatibility (there are some differences in the Joomla templating system that will most likely make your Joomla 2.5 template not fully compatible with Joomla 3.3)
Planning your Upgrade
Before starting to upgrade, you should do your homework. You have a live website that you need to upgrade, so spend some time to carefully plan your upgrade project (yes, you should view it as a project).
Here are some planning steps that will help you:
- Verify that your hosting environment supports the Joomla 3.3 technical requirements (PHP 5.3.10+ and MYSQL 5.1+). If it does not ask your host helpdesk to upgrade your account appropriately.
- This is a great opportunity to remove any inactive extsnions you have on your Joomla 2.5 website. There is no need to keep old inactive extensions on your website and it does pose a security threat in the first place.
- Make a list of all your third-party extensions (modules, components and plugins) installed on your Joomla 2.5 website. Visit each extension provider website and make sure that you have the latest version and that this version is also Joomla 3.3 compatible. Some extensions might have a new – only for Joomla 3.3 – extension release. If this is the case, then download such releases and keep them handy for your post Joomla 3.3 upgrade steps. Some extensions (usually modules) might need post upgrade configuration changes due to the new CSS stylings (and Bootstrap) present in Joomla 3.3 – make a list of needed changes for each one.
- Contact your template provider and download the Joomla 3.3 template version or ask them for specific instruction on changes that need to be made to your Joomla 2.5 template once you have upgraded to Joomla 3.3.
Upgrade Steps
Once you have done your planning steps and have all your resources ready (e.g., new template, new extension, etc.). you can follow these steps:
- Make a backup of your Joomla 2.5 website before starting – even better to clone your Joomla 2.5 website and test the upgrade process on the clonned site before replicating it on your production site.
- Verify that your Joomla 2.5 site is on using Joomla 2.5.28. If it is not, you can easily upgrade to Joomla 2.5.28 from your Joomla 2.5 Component → Joomla Update page
- Verify that your third-party extensions are the latest Joomla 2.5 (and Joomla 3.3 if possible) compatible versions. You should have done this in step 2 of the planning process, but you can also do a sanity check by making sure that there are no reported upgrades in your Joomla 2.5 Control panel Updates icon or your Extension → Extension Manager → Update tab.
- Go back to your Joomla 2.5 Component → Joomla Update page and click on the Options button and then change the Update Server parameter in your Update Source tab from Long Term Support (recommended) to Short Term Support and click the Save button. Please note that these parameter settings are no longer accurate as Joomla 3.X will be supported for at least 2-4 years.
- Your Joomla 2.5 Component → Joomla Update page should now show you the option to one click install the latest Joomla 3.3.6 (or better) release. Click in the Install the update button.
Your Joomla 2.5 website has been upgraded to Joomla 3.3 and you are now ready for your post upgrade process steps.
Post Upgrade Steps
Now that your website has been upgraded to the latest Joomla 3.3 release, you can follow these post upgrade steps:
- Visit your Joomla 3.3 Extensions → Template Manager and select the isis – Default template as your Administrator template.
- Install any Joomla 3.3 extension upgrades you identified during step 2 of your planning phase and/or make any post upgrade changes recommended by your third-party developers.
- Install your new Joomla 3.3 compatible template from your template provide and/or make any changes to your existing template.
- Test and inspect everything – frontend and backend.
Default Joomla Template Upgrade Steps
As indicated in step one of the previous section your Joomla 3.3 administrator template should be set to Isis – Default.
If your Joomla 2.5 website was using one of the built-in Joomla site templates, e.g., Beez2-Default, you can choose to use one of the Joomla 3.3 site templates, e.g. Protostar – Default. If this is the case, you may also need to change the position of your main menu module from position-7 (which was the case on your Joomla 2.5 default template environment) to position-1 (for the Protostar template on Joomla 3.3). You should also set your Menu Class Suffix on your main menu module to nav-pills to get the default menu styling on Joomla 3.3.
Conclusion
Upgrading from Joomla 2.5 to Joomla 3.3 is not as complicated as you may think. Proper planning and doing your homework should get you to your Joomla 3.3 – very secure and totally responsive – website.
Credits
Article adapted from http://www.joomlapolis.com/support/tutorials/95-installation/18478-migrating-from-joomla-25-to-joomla-33?pk_campaign=newsletter&pk_kwd=news20141215, Joomlapolis is the creator of Community Builder.
Of particular interest to me, was the revelation that Joomla is so dependent on menus that if you create articles that aren’t linked in menus (I tend to link only the top level of a site to the main menu, and then link within articles to other articles), Joomla really doesn’t like this and you will see in the url that it’s created a baffling structure of sub-categories. If however every article belongs in a menu, then this does not happen and you can control your url structure. The menu does not need to be shown – it can be inactive.
http://www.bbc.com/news/technology-29846539
Mark Stockley, an analyst at security firm Sophos, said the warning was “shocking”. “Many site owners will never have received the announcement and many that did will have been asleep,” he said. “What Drupal badly needs but doesn’t have is an automatic updater that rolls out security updates by default.” There is strong feeling on both sides with many arguing against “dumbing down” Drupal.
Whilst we wait for an auto-update mechanism in Drupal (perhaps in Drupal 8?), we’ve always been able to update Drupal for our customers. It’s a free service but one done “on request”.
We do not apply updates automatically to any and all Drupal sites we host for a very good reason. The risk of breaking a customer’s site is too great. It’s worth noting the Drupalgeddon security problem was the first such in 9 years. So it’s arguable the risk of such a security problem happening again on such a scale is manageably small. Drupal updates typically replace the entire Drupal codebase, leaving just the /sites/ folder untouched. If a customer or their developer has made any changes to a core file, these changes will be wiped out.
Sometimes a bug will be fixed or a feature changed as a result of an update. The site may well have a work around in place already for the bug and the update will then cause the site to break. These are just a few of the reasons.
The problem for us is, we did not build the site in the first place, nor are we familiar with it’s inner workings. So for us to be sure the site is in a working state after an update is very hard to do. A working homepage does not signify the site is 100% working. If the customer is going to be involved, which in our view they have to be, to check the site after the update, they should be involved all the way through – from the point of getting a Drupal notification email of an update, or getting a notification from the Drupal security list through to the timing of the update, to checking the site afterwards in case a roll back is required.
What changes have we made? Actually very little. We have simply streamlined our internal processes to make the technical side of doing the update a lot quicker. A lot of our customers have several sites with us. So we are now using some simply scripting so we can update all a customers sites, once they give us the go ahead.
Inspiration for the scripting came from Dane Powell ‘s blog: http://danepowell.com/node/69
Our version of the script is:
Update Multiple Drupal Sites Script
#!/usr/bin/env bash
installpath[1]=/our/pathtosite1
installpath[2]=/our/pathtosite2
installpath[3]=/our/pathtosite3
for index in 1 2 3
do
filepath=${installpath[index]}
printf "Updating %s\n" "$filepath"
cd $filepath
drush pm-refresh
drush archive-dump --overwrite --destination=/pathforbackups/backup.tar
yes | cp .htaccess ../
drush vset --always-set maintenance_mode 1
drush cache-clear all
drush up drupal --yes
drush vset --always-set maintenance_mode 0
drush cache-clear all
yes | cp ../.htaccess ./
chown -R apache:apache ./
done
Notes on the script.
This script is for discrete Drupal sites, not Drupal multisite.
We copy .htaccess out of the way and put it back afterwards and we noticed Drupal updates sometimes overwrote the original.
The final steps resets the file ownership permissions on the site to whatever your webserver runs as. If using suphp this would need to be changed.
Output is written to the command line so you can see what is going on.
Use at your own risk. Comments and improvements are welcome.