Starting Conditions and Possible Strategies

[genr8r]

The migration project for the Joomla Academy is underway. We began conversations by doing a bit of a current state analysis. There are pre-existing projects and others running in parallel to the current project all trying to create this solution for the Joomla community. The below summary may be incomplete. So, feel free to flag any initiatives that I might have missed.

Other Wordpress to Joomla Initiatives

Google Summer of Code 2023

https://github.com/joomla-projects/soc23_joomla-converter

It requires both the Wordpress site and the target Joomla site to be on the same server at the moment. It is making a connection to the Wordpress database and bringing that data into the Joomla database with the appropriate schema changes.

Google Summer of Code 2025

There is a parallel project that was approved on a similar time frame as this Joomla Academy project. I will update this discussion with links to their information when I have it. We are in direct conversation as both mentors and students. We are running the two projects as separate but parallel and with a spirit of openness in the event that either project can benefit from the insights of the other.

Existing Joomla data transfer solutions

We acknowledged a couple of existing Joomla solutions that are not intended to necessarily import data from other specific sources but yet provide inspiration for some the data mapping and data transferring possibilities between websites.
Systems discussed included:

• J2XML - https://eshiol.it/it/joomla/j2xml/j2xml39.html
• RO CSVI - https://rolandd.com/products/ro-csvi/how-it-works

Potential Strategies

We discussed a variety of ways to approach the project in our initial conversations

Direct Database Conversion (from one local db to another)

This was discussed as a possibility to leverage the efforts of the 2023 GSOC project mentioned above. We set it aside for a number of reasons.

• Work for the 2023 project is still ongoing sporadically and we don't want to cloud those efforts.
• The challenges around connectng databases on remote servers even for a fully functional solution likely present additional difficulty for people trying to make use of the tooling.

Direct Database Connection (feed Joomla content from a WP database)

This takes the local database connection strategy one step further. Instead of converting the data to conform to Joomla standards, we could "teach" Joomla to read data directly from the WP database schema. This eliminates the need for any data conversion. This strategy would allow a Joomla and WP to share data from the same store and run in parallel. The challenges of setting up and maintaining such an arrangement seem non-trivial and likely have much more limited use cases than simply exporting the data from a WP site for migration into Joomla.

Proposed Strategy

Use of Joomla native extension architecture for a 3 Tiered approach

Different CMS's and platforms will have different ways of exporting data. The 3 tiered approach will allow migration tooling to be built that will leverage whatever data formats are exported from other platforms in future projects.

Tier 1 - Native Export Data from Source Platform

The native export data of whatever platform is being targeted. For the purposes of this project the target is Wordpress. Every Wordpress site allows for Export from the Tools menu. The goal is to take that exported data and configure it for import into Joomla following all database schema standards within Joomla.

Tier 2 - Joomla Plugin for Data Transformation

This is a Joomla plugin that is programmed to uniquely handle the data transformation of whatever the source platform is. The plugin essentially maps the source data to Joomla.

Tier 3 - Joomla Component to Manage the Migration

This is a Joomla component that can manage the whatever plugins are being used to import data into Joomla. The component will allow the site administrators to handle any special tasks like mapping custom fields, etc. The component will be setup to standardize and handle as much of the process that is not source platform specific as possible. Abstracting away as much functionality as possible from the plugin is intended to make it easier to create tools for migrating from other platforms in the future. So, the component handles the admin UI and as much of the "standardized" part of the process as it can. The plugin for the source platform will focus on only the data transformation that is specific to the source platform. This is similar to how RO CSVI exists as a component, but has separate plugins for managing data from Virtuemart, Hikashop, J2Store, RS Forms, etc.

Targeted Data for Conversion

• For the purposes of the Wordpress to Joomla Conversion we are looking to target
• com_users
  • username
  • passwords - WP will be using bcrypt starting with v6.8 matching Joomla's use of bcrypt since v3.2. We should discuss how or if we want to handle older versions using MD5
  • email addresses
  • permissions level
• com_content - all pages and posts become articles. WP actually keeps all "pages" in the same db table as "posts". So technically everything is a "post". We did have some discussion about how pages can be managed in a hierarchical taxonomy in WP. Joomla categories are also hierarchical, but have a lot more in addition to that taxonomy that might make simply creating a "pages" category and then mirroring the taxonomy as categories unwieldy. Now you get a single article within each category that was setup up just to handle the hierarchical relationship. We also discussed using com_tags to manage these relationships as they are much lighter weight than categories and still allow for hierarchical content relationships.
  • All the relevant metadata
  • All the relevant publishing data (author, dates, status, etc.)
• com_categories
  • captured as a way to keep content organized
• com_tags
• captured as a way to keep content organized
• com_fields - While Advanced Custom Field (ACF) are not technically "core" to WP they are used very aggressively within the WP community. It is also one of the plugins that Wordpress copied from WP Engine as part of their ongoing disagreements. This speaks to the plugins unique importance to the WP community. In addition, fields ARE part of Joomla core and are rightly perceived as and important part of the main content on the site.
• Media Files - We did discuss briefly the implications of how WP stores media in wp-content and what challenges that might present. Do we really need media stored in folders organized by date of upload?

Additional Considerations

Model Context Protocol's (MCP's)

https://modelcontextprotocol.io/introduction
We briefly discussed the recent of development of MCP's from Anthropic. While these are largely relevant integrating artificial intelligence tools, they have two features that are of interest.

1. MCP's are a way of standardizing an interface for data transfer and systems integration
2. The can serve as a kind of wrapper for API's making them easier to use - https://www.youtube.com/watch?v=7j1t3UZA1TY
   On the downside MCP's are usually incorporated as the part of the server broadcasting what tools and resources are available rather than on the client side. To use this strategy would entail developing an MCP for Wordpress so that it could advertise what is available for interconnection. This is contrast to focusing on how Joomla can ingest data.
3. (edit) OR... Automattic already built it - https://github.com/Automattic/wordpress-mcp. We will add this to our latest discussions.

Schema - Using Structured Data as a standard

We also discussed whether it is necessary or beneficial to "standardize" data that is brought into Joomla as part of the hand off between Tier 2 and 3 described above. There was a strong sense in our conversation that IF this is beneficial using the Structured Data definitions at schema.org would be an incredible helpful standard to deploy.

1. It would provide structured data for all content by literally by definition
2. It would provide a universal well-documented target for data conversion schemas
3. It is formatted as JSON which can be formatted as a file for import and/or it can be presented as a feed. This leaves open the possibility of pulling in content via JSON feeds formatted around a universally accepted standard.
   While there are tangential benefits to making use of Structured Data as part of the process, it is not clear that it is beneficial to the core effort of migrating WP to Joomla. Is it just presenting another data transforming intermediary step that is unnecessary?

Joomla 6 Implications

We are in conversation with Joomla 6 release leads in the event there is anything critical for the success of this project that is needed in Joomla 6. We are VERY aware of the roadmap and timelines for the next major release and commit to respecting the standard Joomla release cycle completely.

• Our initial discussion envisions this tool as part of the Official Joomla Extensions - https://extensions.joomla.org/category/official-extensions/