The Joomla! project has been into the Google Summer of code editions 2005, 2006 and 2007. Past week Google Geek herder extraordinaire, Leslie Hawthorn announced this years edition of the Summer Of Code. We will certainly apply to be part of this great program. Like past year we will start the (internal) preparations for this program, and we start with getting together the mentor team.

Mentors who are interested can contact me by sending a personal message in the forum, or post a message in the forum area that has been created for the 2008 edition of the Summer Of Code. What we expect from mentors is that they are able to guide students during the week (2-4 hours per week), have knowledge of the Joomla! 1.5 application and content management framework. Preferable you have some experience with guiding or training students, but this is certainly not a must. If you are interested , but have doubts also do not hesitate to use the Summer Of Code 2008 forum area to post your questions.

More information on this program will be posted as soon as possible. Google has posted a Frequently Asked Questions for everyone who is interested on reading more about this program. If you are interested in past years summer of code you can check out the Summer Of Code team blogs or read the end-term report that holds some specific information about how the program was run past year.

Source: willebil

So if you’ve used the migrator or checked out 1.5 you might have seen this strange “backlink” concept floating around the place. I was asked the question today what it was and if it is important to migrating your site. The quick answer is that its not critical though its probably something that you’re going to want to have, because its cool and it attempts to keep your old menu URL’s around so that you can still get to stuff with the old links. Did I mention it was also cool?

So the basic idea of backlink migration is that in 1.5 somebody went and rewrote SEF so it actually looks nice. We also have a completely new way of routing a whole heap of core components as well just to throw a lot of things off. We’ll add to the fun that a lot of people out there have deployed third party SEF as well because 1.0 SEF didn’t quite get the friendly part as good as what it is now in 1.5, which also adds to pain.

So if 1.5 is so different how do we handle this? There are a few options available to a stock Joomla! site: Legacy routing from the Legacy plugin and Legacy SEF from the Backlink Migration plugin. This will enable a lot of backwards compatibility for most links, especially if you’re using the Core SEF (about 90% of links appear to get things right). Also to use Legacy SEF you will need to have regular SEF enabled as well and used the .htaccess file as well. However not everyone is using Core SEF, so enter the other parts of the backlink migration plugin.

So what the backlink migrator does is export your old Itemid, a name, the original URL, an SEF url (generated by the 1.0 sef system from the original URL) and a new URL so that you can pipe things manually if need be. It pulls this information from your menu table, so it will attempt to find any item in your menu and migrate it using the 1.0 SEF to try and generate an SEF url. When the backlink migration plugin is active it uses all of this information to then try to match up the old information with the new information from the database. We’re basically trying to do our best to provide the ability to maintain backlinks where possible, but we can’t do it for everything.

So if you were wondering about backlink migration, then that is basically it. Its pretty simple but I’m hoping it will allow more people to migrate without the pain. The basic aim is to make sure links still go somewhere, not into a 404 black hole, and that search engines will gradually update with the new links (since that is what will be handed out). Eventually your old links will go away and you can switch of all of these plugins and be happy with nice shiny SEF urls

Source: pasamio

No doubt if you’ve already got a Joomla! 1.0.x site you’re wondering what it’ll take to get your site to 1.5, you might also be wondering if you can get their third party extensions migrated as well and you may even wonder if its safe to sit on 1.0 for a little while longer until things pan out a bit for this funny 1.5 thing and people start writing new extensions and updating old extensions. So I thought I’d write up some thoughts about migrating to 1.5 and spread some news to help people out.

Migrator Updates
To get started in the land of Migration there has been an update: the migrator tool is now at RC6. Some tutorials on the net have been mistakenly saying you need the same version of Migrator as you do Joomla! release, which is just plain wrong. Earlier migrators will work with later Joomla! releases and vice versa, though really you’re going to want the latest and greatest to get things to behave properly. So the migrator should also work fine regardless of your Joomla! release, but it has been heavily tested from versions 1.0.10 to 1.0.14RC1, so being on at least those releases is the most advisable. Additionally I’ve tested the migrator on Mambo 4.5.2, 4.5.5 and 4.6.3 and have had the import run successfully again the sample data for those sites (note: Mambo isn’t officially supported or fully tested and not all data may be transferred properly). Whilst not all data will be transferred, the core of Mambo hasn’t changed that much so we’re able to use the exact same mgirator with those Mambo releases as Joomla! 1.0, cool!

So whats new with RC6? Well now there is the ability to select which plugins you wish to run (so you can selective export tables) and for the developers there was an addition to the API to make it even easier to alter the SQL automatically generated by the ETLPlugin framework and add SQL before and after a plugin runs. The core_log_* tables have also been removed which for older sites could be quite large tables so this should speed up the creation of dump files.

And the stable migrator? Well if RC6 is holding up pretty well and no issues come up in the next week or so, RC6 is probably going to turn into the Migrator’s stable release. This means from the Migrator side of things I feel I’ve gotten most of the bugs out and its easy to use. The stable will probably have a few more updates with regards to documentation shipped but this should be the only change.

Update PHP version
Where possible upgrade to PHP4.4.x or higher to get the best compatibility. There are known issues with PHP 4.3.x releases (especially with 4.3.9) so upgrading to the latest release will give you less troubles both in migration and with 1.5 in general.

iconv errors
I’ve seen a few iconv errors floating around the place about invalid characters. For the most part things seem to be fine by ignoring them, however they may cause other issues. For the most part if iconv is flagging an issue with something then it would appear that the data has information in it that isn’t quite right. Check your data for any strange characters or use a slightly different encoding and see if you have any issues still.

I’ve also seen some issues with migration that can be solved by going through David Gal’s old guide for UTF-8 in 1.0 on the forum:
http://forum.joomla.org/index.php?topic=55065.0 so checking that you’ve applied all of the tips, namely the “SET NAMES ‘UTF8′” tip.

Don’t forget the prefix!
The migrator changes the prefix to jos_ regardless of the original site prefix. This was done to normalise the prefix. This doesn’t mean you can’t use a different prefix in your 1.5 database but when it comes to migration the “old prefix” is “jos_”. Additionally it doesn’t mean that you can’t export a site if you don’t have a ‘jos_’ prefix, it just means that the migrator dump file will always use the ‘jos_’ prefix.

Memory and time
If you have the ability to, give your PHP process more memory and execution time during migration. This will allow the system to create and load dumps faster if you can increases these limtis and will reduce the number of page reloads to avoid exceeding time or memory limits. Whilst the migration systems attempt to do their best, giving it some breathing room also helps. This is especially relevant for larger Joomla! instances!

Misbehaving 1.0 extensions
Before migrating, create a small 1.5 test installation and install your 1.0 extensions on to it and test with using legacy mode or not. Some extensions that do not work properly with 1.5 at the moment are mod_pda and Joombackup, both of which from reports on the forum cause Joomla! not to load properly. Not all extensions will be supported in 1.5, so its handy to test it on a vanilla (non migrated) 1.5 site to see how they behave before attempting to migrate your 1.0 site.

The tortoise or the hare?
Joomla! 1.0 support isn’t going to disappear the moment 1.5 is released, which means you don’t have to race to get to 1.5 and get everything updated. You can wait a while on 1.0 until updates to your extensions are 1.5 compatible. What you might gain from waiting is better third party support for your extensions and an easier migration pathway. If you are just using the Core of Joomla! then it is easy to upgrade to 1.5, but if you heavily rely on third party extensions then you might want to get in touch with their developers about writing migration plugins and 1.5 versions of their extensions.

SEF
In Joomla! 1.5 we’ve updated the SEF to behave a lot better, but that makes it different to 1.0’s style. For those who haven’t installed a third party SEF solution in 1.0, then you can merely enable the Legacy Plugin (with legacy routing) and the Backlink Migration plugin in 1.5 to have approximately 90% of 1.0 SEF URL’s routed appropriately. If you have a third party SEF extension, the backlink migration system will build a list of SEF links from your menus. This means that any link that is in your menu should be transferred properly, even if you have third party SEF, but not all links will be transferred.

File permissions
If you’re doing a migration make sure you give Apache write access to installation/sql/migration/ and ensure you’ve got a temporary directory set up and writeable (e.g. /tmp) for the migrator to use. The migrator alters the dump file before it imports it into 1.5 to handle things such as different prefixes and transliteration. It is important that you make these directories writeable.

Manual insertion
Whilst this is certainly the hardest way of doing things, you can also manually insert most tables from the dump file into Joomla!. You will have to take care of manually renaming any key values to ensure that there aren’t any clashes. I’m not quite sure what the best and easiest way to do this is, but it would be possible if you have an existing 1.5 site and want to insert content from your old site into it. The only table that this won’t work for is the menu table, this has to be handled specifically via the 1.5 migration process.

Core hacks and modifications
The migrator doesn’t support core hacks or modifications to the core database tables. If you have installed anything like a bridge to the system that modifies the core tables then these will not migrate properly. The migrator is designed to handle the core tables as they are, not in their modified form. Contact the creator of the bridge to acquire migrator plugins approriate to your tables (you can override the core plugins by putting your own over the top) if you want to migrate a modified site.

Migration Errors
If you encounter an error half way through migration, the system won’t let you attempt to migrate again because your database might be in an inconsistent state (hey, it had an error!). This means that if you get an error during migration you will need to start the entire 1.5 install again to get a clean database and the system will then allow you to try to migrate again.

Source: pasamio