A lot of people wrote about how to migrate a site on Joomla - first to version 3, then it was up to 4, and now to 5. And in fact, if you follow the instructions, usually everything goes well and smoothly. But this is if you do not have a bunch of different components, modules, plugins installed, that can cause problems after the migration.

Each project on Joomla is unique and everyone will find subtle differences in the way their site works.

I want to describe here my process of migrating the site from Joomla 3.10.12. to version 4. And - if everything works OK on version 4, then migration to version 5 will be an easy walk, I will not even have time to finish my coffee, as everything will be over. Just don't forget to change the server PHP version to 8.1 for J5.

I should add that this site, the news site of the catholic church diocese for 17 years of work, including the database, collected almost 11,500 articles.

Migrate to version 4

So, here we go. I will not describe the entire process of migrating a site, because we all read the instructions. I start by making a copy of the entire-running site and database and then working only on that. I have some minor problems during the migration process, which I solved by simply disabling components and plugins that were incompatible with the new version. Then I select the Joomla Next update channel, and the system does a compatibility check, and then offers to update by clicking on the button. A little waiting time - and we see that everything is ready - now it is on Joomla 4. 

Debugging new version

This means I've ignored something again - the plugins/radicalmultifield/slideshowvertical/ plugin was used to build mini galleries within articles. It too needs to be disabled for now. Later I will slightly change the way galleries are displayed using the new version of this plugin.

But this is in the admin panel, on the frontend we have errors too - JROOT/templates/yoo_master/warp/systems/joomla/src/Warp/Joomla/Helper/SystemHelper.php:122. And it's because we don't have a compatible template. To start, I install YoothemePro and try to build the pages the same as on the old site. I had ready-made layouts for YoothemePro so it didn't take long - upload the layout and check it out.

When I was trying to display article cards on the blog category blog page, in a grid view with the article photo, and title, I ran into a problem, as it turns out, on a larger scale. I don't have intro images in any article, so I can't use the article photo and headline separately. At one time, when I asked to select a photo in the image field, the editors said it took an extra minute, which was too long.  

How did it work before, you ask?  There used to be a template from old YOOtheme with Warp framework, which had a custom script in the layout of the blog category that searched the text for a picture and used it in the layout. To do this I had to create an override of the standard blog layout by adding my own, and in the menu you have to remember to change that too. That is, when loading a page with 12 articles, for each of them the script looked for the first photo in intro or full text. 

Making a console plugin

At first I was very frustrated - for 11,5 thousand materials I don't want to insert it manually. The search for a solution ended quickly - there is no ready-made one. I started to look towards console plugins, yes, the ones that work directly from the hosting console, executing only those commands that you need. But there are no such ready-made ones. Well, I'll have to write it myself, although I must add that I'm not a top notch programmer. But we have one great tool at hand, which will at least give us a start, and then we'll fix it as we go along, and that's AI. 

Since Сhatgpt won't write everything properly anyway, let's go the other way - take a ready-made plugin for executing SQL commands, install it and check in the console that there is at least some response from it:

/opt/php81/bin/php /var/www/namesite/newsite.domain.test/cli/joomla.php sql:execute-file 

I asked chat to read articles about writing a plugin just in case. And now give him the plugin file, which is responsible for the execution of the command itself, and write a prompt on what we want to get. After a few tries and clarifications, I changed the code at RunSqlfileCommand.php, save it on the server, and typed autoimage:add in the console. Since I asked for logging, I saw that it was already done. After hesitating, I added more log output to the console and to the file. However, when I went into the database content table, I saw that everything was already in place. Let's start checking our articles.

And I noticed that somewhere at the end of pages  -  articles contain only titles, without photos - but there are images in the text - why did the script not use them? Again debug, and we find that the photos disappear from september.2016. This can be seen in the database, and all because then there was an older migration to version 3, because before there was no such field, and the fields in the article remained empty, without this entry {‘image_intro’: ‘‘’, ‘float_intro’:‘’‘, “image_intro_alt”:’‘, “image_intro_caption”:’‘, “image_fulltext”:’‘, “float_fulltext”:’‘, “image_fulltext_alt”:’‘, “image_fulltext_caption”:’"}, and since the field is empty, the script didn't process it. 

You can write a check in the script for this case, so that it fills in the empty fields and only then inserts the photo. But you can do it easier by executing in PhpMyadmin the command UPDATE mynewdb. j17_content SET images = ‘{’image_intro‘:’‘’, ‘float_intro’:‘’, ‘image_intro_intro’:‘’, ‘image_intro_caption’:‘’, ‘image_fulltext’:‘’, ‘float_fulltext’:‘’, ‘image_fulltext_alt’:‘’, ‘image_fulltext_caption’:‘’}' WHERE j17_content.images = ‘’’; 

Again we turn on our script to execute, and it fills the remaining fields with images in a blink of an eye. 

After a series of further checks, I find that there are still empty fields - and that's video. There's a small category where the page only has iframes from YouTube. But to display YouTube script in the preview, which weighs down the page load - it's a bad tone. That's why we need to make the script work extra hard to take preview frames directly from each video. 

By focusing on the details and addressing them promptly, the migration of a large site can prove to be far less daunting than it seems. 

With a portion of the work already completed, the next steps involve creating layouts for the remaining pages, setting up the parish catalog on Zoo, and preparing to go live..

P.S. In the next article I will write about another site migration. That one is more difficult, because it's on Joomla 1.5, multi language, and structure with collecting some articles to one "issues", with a very old JoomlaMagazine component, adding to Joomla categories. And many articles, too - 7000. It archives catholic diocese  newspapers for more than 16 years.