Planning is half the migration: What to consider when replacing Gridelements

You can work with the Gridelements extension in very different ways. Therefore, you first need an overview of the elements present in the project, as well as their configuration. But also a clear plan for the migration of existing data sets is helpful.

The following points helped us to get a realistic estimation of the upcoming work.

We first need to get an overview of the installation:

• Which grid elements are there and what is their purpose?
• How often are these really used?
• Are child elements of a grid element rendered differently by TypoScript?
• Are grid elements used in a nested way? For what purpose?
• What flexform settings are there?
• Away from grid elements: are there backend fields in content elements that can be merged with Flexform settings (e.g. background colors)?

An initial SQL query may look like the following. It lists the identifier of all grid elements as well as the number of times they are used:

SELECT tx_gridelements_backend_layout, count(tx_gridelements_backend_layout) 
FROM tt_content
WHERE hidden=0 AND deleted=0 AND CType='gridelements_pi1'
GROUP by tx_gridelements_backend_layout

You will need additional, project-specific queries to analyze nesting and child elements.

Discuss with your customer which elements they can forgo in the future. Much of what was implemented years ago may no longer be needed today. Take every opportunity to free the system from legacy elements.

After analyzing the project, you should have identified potential pitfalls. Next, you need a rough roadmap of how you will migrate the existing elements:

• Which grid elements (and their child elements) will be replaced with which CTypes?
• What new content elements will need to be created?
• How will the existing records be migrated? Via SQL script, TYPO3 Upgrade Wizard, manually?

For a first estimation of the effort and an offer to your customer, you don't have to plan every detail yet, but at least have a clear idea of the necessary work steps.

Depending on the status of your project, it may make sense to combine the Gridelements migration directly with a TYPO3 upgrade.

The customer has asked you to perform the necessary work, now it's time to get down to the nitty-gritty. You must now solve the following topics.

1. configuration of the new elements

• Which content element replaces the previous grid element (and its child elements, if applicable)?
• How must the Flexform settings (of the Gridelements) be migrated?
• Which additional fields have to be provided in the TYPO3 backend; which are superfluous?

2. Migration of existing data/records

• How will the migration be performed: automated via Script/Upgrade Wizard, or manually?
• In detail: the values of which database fields are still relevant in the future; into which field do they have to be migrated?
• Do the contents of the database fields also have to be adapted (e.g. class names in the RTE field)?
• What relations are there that also need to be migrated, such as image relations in a FAL (File Abstraction Layer) field?

Do the grid elements and content elements have many flexform settings, frame classes, and the like? Then it is recommended to create an overview. You may then find that, for example, background colors can currently be assigned in multiple ways.

The goal should be to reduce complexity and make the editor's daily work easier. To do this, it makes sense to take a step back and look at content maintenance as a whole. Discuss with the customer what his pain points are in his daily work.

We summarized which content element type is best for us in the first blog post.

In the third part, we show some code examples to extend container elements in a meaningful way.