WordPress specific code in the component

[HermanPeeren]

In the models of the current component there is code that is specific for handling a WordPress source. The Project Brief however states:

This tool supports a flexible, extensible plugin system. Each migration source (e.g., WordPress) is handled by a dedicated plugin triggered by Joomla events.
You can easily create custom plugins to support other CMS platforms or proprietary data formats.

Having WordPress specific code in the component's models means that those models have to be updated when another source CMS is added. That is against the open-closed principle. A (typically Joomla) solution would be to put all WordPress specific code in a plugin. That can be in the same WordPress plugin you have now or (when it is handling a different aspect of the migration) by making another plugin for these adjustments.

Of course it is OK to have the current WordPress specific code temporarily in the component, as a proof of concept. But in the long run architectural considerations have to be guarded too.

[genr8r]

This is an especially good note around line 300 in the downloadAndProcessImage method...
https://github.com/joomla-projects/JA-Advanced-Migration-Tool/blob/main/src/component/admin/src/Model/MediaModel.php

Our media import seems especially skewed toward WP only in the component. Is there an issue with abstracting this back into the WP import plugin @Rahulsingh1939

I also noted the some to the language constants in the ProcessorModel
https://github.com/joomla-projects/JA-Advanced-Migration-Tool/blob/main/src/component/admin/src/Model/ProcessorModel.php

...are referencing taxonomies. That language for understanding content structure is used more within WP rather than Joomla. If the component is to be more "universal" we are probably better using Joomla specific constants (categories versus taxonomies).

[HermanPeeren]

Discussed today with Rahul some topics related to this Joomla specific code:

1. In the ProcessorModel 2 different schemas are being processed now:

   • The standardised ('universal') JSON that is produced by the WP-plugin (processed by the processSource() method).
   • The JSON output that is produced by the Joomla WP Migration plugin, based on the WXR export file (processed by the processJson() method).

   The second JSON format, that is created from the WXR file, was developed, because the WXR file doesn't contain all information about hierarchy, categories, users etc. So it only contains a subset of the information that should be in the standerdised JSON file. Still I think we can put that information in the 'universal' format, so we have only one, not CMS-specific JSON file format as input for the component. Maybe some information in that JSON file has to be marked as 'missing' or 'unknown' then, when produced from the WXR format. The WP-plugin in Joomla should produce such a standard JSON file and the component should only have to process one format.

2. There are 2 things that have to be done when migrating media files (like images):

   • migrating the file itself (to the images or files folder, from for instance the /uploads folder in WP)
   • adjusting the URLs referring to those files; both for "attached" media and for media which are embedded in the text of an article.

   About the first thing, migrating the file itself: at the moment the whole /uploads folder in WP is only imported as a whole, when having the images from the source CMS in a zip-file. I'd say: when using FTP (or variants of that), you can also download the whole /uploads folder in one go. Rahul said there was a problem with that, which is why now with FTP the files are only loaded one at a time. I don't think that is necessary, but I'm curious what the problem is downloading the whole remote folder. If you can find a solution for that, then it simplifies the whole media migration: you don't have to extract those files to upload for every article, and you don't have to check if the file is already uploaded in Joomla.

   If we have uploaded the whole /uploads folder (or other remote media directory), we don't have to care about uploading the files anymore when adjusting the URLs for all references to media files. Then you don't have to split between 'zip' and 'ftp' in the migrateMediaInContent() method. But also see point 3 here under.

   BTW, at the moment in extractImageUrls() you check if the uploads folder used by WP is in /wp-content/uploads or just /uploads for every article. But that will be the same for all articles. Probably some checks can be made earlier (for instance when uploading all media files in one go), just one time, instead of doing the same checks for every article. But also see point 3 here under.

3. Adjusting the URL is now CMS-specific. In the imported standard JSON the URL should already be adjusted to some mediaFolder-placeholder. In the JSON it should then also indicate what the original media folder for that CMS was. When producing a standard JSON schema in the Joomla WP Migration plugin, that can all be processed there. You should do the same in the WP-plugin (OK, that's a bit double work, but you can even extract some functions that you just use in both plugins, the WP and the Joomla one). In this way, you don't need to do WP-specific things with that uploads-folder in the component.

   N.B.: in current Joomla we put images in the /images folder and other media in the /files folder. Both folders can be adjusted in the com_media options. You should upload images and other files to those folders. That's why it is better to have a placeholder in the standard JSON import file than directly use Joomla's /images folder there (as I incorrectly suggested today as another option).

   N.B.2: I only see URL-adjustments now for articles, not for attachments (post_type='attachment')... You can have an image that belongs to a post, but is not part of the text. In Joomla that would be migrated to an intro-image.