As Mårten explained in an earlier post we decided to redo our installation profile into a more diversified model with a common core set of modules and with a differentiated set of modules for every site that will use the common core.
Splitting the previous Yle – profile that we used as a base for our installation from the beginning was easy enough. Just create two new installation profiles – Syndprofile and Fyndprofile that used most parts of the earlier Yleprofile and the parts that were specific for the two installations into their own sets of repositories, ie synd_modules and fynd_modules and so on. Starting development on the fynd-platform was also very successful and has since launced two successful projects: Kuningaskuluttaja and MOT.
However, on the svenska.yle.fi – platform, the change posed a lot of challenges to overcome, since we had to change installation profiles on a running site. And since a lot of the path settings to modules and themes are set in the database at installation time a lot of file paths would have to be changed. So when we first tried the easiest approach, just replacing the profiles/yleprofile installation folder with a profile/syndprofile we were left with a severely broken site, that couldn’t find any modules or themes, no matter how many times you tried to clear the cache. So it became clear that we had to do the changes directly into the production database.
So what we did was to dump the database into an sql file and doing a search and replace on every occurence of yleprofile to the new synprofile. We opted to slightly change the name to synprofile since there are a lot of serialized data that contains the path in the database as well.
We have around 500 000 nodes in our database at the moment, and a pretty large index, but using sed to do the search and replace the operation only took a few minutes to do, even though the sql file itself is getting close to 5 Gigabytes in size.
$ sed ‘s/yleprofile/synprofile/g’ < svenskaylefi.sql > svenskaylefi_synprofile.sql
This, however, was not enough in our case. We also had a couple of modules and our own theme settings and features that was not going to be used in the other distributions so we had to manually change the location of these. Fortunately most of the file path settings are stored in just a few tables.
The paths are also stored in the cache tables so it is advisable to truncate them at the same time, especially
It took a few tries to get every step in this workflow to work out without problems, but when we finally figured out how to do it the migration process went pretty smoothly. Just one final hurdle gave us a bit of cold sweat when the site didn’t even bootstrap even though the migration process had otherwise gone smoothly. But, a manual flush of the memcache server solved that too.