Google Summer of Code

TYPO3 Transition Tool

Nicolas Forgerit

Abstract

TYPO3 is right in a big rebuilding phase and will make a huge technical step from version 4 to version 5. Basis of the new version will be the FLOW3 Framework which is just maturing into its beta phase. One of the new concepts is the implementation of a Content Repository (CR) which transparently persists data in form of Nodes in a hierarchical Node-Tree. For making the transition as smooth as possible, there is a need of functionalities to transform TYPO3v4 contents into CR-compatible data.

Additional Information

Foreword

 

Maybe i should begin with introducing myself to you. As you can see, my name is Nicolas Forgerit and living in Karlsruhe, Germany. I'm currently 23 years old and i'm studying computer science and physics at the Karlsruhe Institute of Technology (KIT).

 

I've worked at the probably well-known TYPO3 agency punkt.de for over a year and was allowed to participate at the T3CON10 in Frankfurt. That was about the time, i noticed that the TYPO3 community is cool and i decided i want to participate :)

 

Overview

As already mentioned above TYPO3 is currently in a big rebuilding phase and due to the huge technical step from TYPO3v4 to v5 the former's content ist not "out-of-the-box" v5 compatible. They both have a hierarchical XML-based content structure thus they are translatable into each other and it should be possible to provide a tool-chain that makes it easier to do the transition step from v4 to v5.

 

At first, auto-generated XML-based v4 content can easily be produced out of an existing v4 TYPO3 instance using SYSEXT:impexp. The idea is to divide the transition into 2 main parts:

 

  1. A Data Provider Extension for T3v4 which exports T3v4 data (using above mentioned impexp)
  2. A Data Acceptor Packet for FLOW3 which imports #1's data into the TYPO3CR

 

They each should be accessible through a RESTful interface which makes them both flexible and scalable. Additionally, plugin #2 would be able to make XML transformations on the imported data computing them with pre-configured XSLT snippets. Optionally, the Data Acceptor could provide an easy-to-use Javascript-based GUI for preparing the data without further knowledge of XML transformations.

 

 

 

Impact on TYPO3

 

On of the main problems of the transition from TYPO3v4 to v5 is the huge gap which, when it gets too big, i.e. it is too uncomfortable or expensive for current v4 customers to step to v5, those users may migrate to somewhere else. Thus, it's important to make the gap as small as possible and a substantial part of that would be an easy-to-use content transition tool that, since it would be mainly XSLT-based, can be used by non-PHP coders.

 

Issues

  • T3v4's Content Elements (CE) are linked together via their Page-IDs (PIDs). Since there can be a need to alter the linkings, they must be handled in a flexible way.
  • There may be T3v4 extensions that have no direct T3v5 successor so the solution has to be aware of that problem.
  • TYPO3 is well known for its strengths concerning i18n. A transition solution for transferring T3v4 to T3v5 content needs first class support for internationalization (i18n) and localization (l10n) (it is announced that v4.6 introduces XLIFF!)
  • TYPO3v5's Node-Tree structure is not yet stable so the whole solution needs to be highly configurable for still being useful if things change in future.
  • Allow the definition of rules for exclusion of CE's and pages 
  • Additionally to the exclusion rules, the solution should be able to handle certain content types in a special pre-configured way, e.g. move Nodes to another parent Node or reorder and reassign Page IDs (so that they are sparse) or simply delete all nodes above a certain id, etc.
  • Security, esp. Authentication is a problem since the channel of communication between plugin #1 and #2 is probably untrusted (OAuth? SSL? OpenID?)

 

Goals / Deliverables

  1. TYPO3v4 RESTful data-provider, which uses the TYPO3v4 export-function: sysext/impexp/app/index.php for generating the XML-based content export. It seems that there are already some RESTful exporting Extensions for T3v4 that need to be examined for their possible usage.
  2. FLOW3/TYPO3v5 RESTful data-importer, which receives #1's data and stores it in the TYPO3CR. There will be hooks for scripts that perform XSL transformations along with a bunch of pre-defined standard snippets for adopting the T3v4 data to T3v5's structure. 
  3. Plugin #2 provides a Preferences page which let's the admin control the following things:
    1. Source: URI to the TYPO3v4 installation whose contents need to be transformed and that installed and activated source plugin #1.
    2. Show and alter the linkings of the Sources pages and CE's
    3. Show alternatives to extensions that do not work in T3v5. Idea: Maybe we should use the TYPO3-Wiki for Extension Developers to provide information about successor plugins and extension-aware tips for the transition from T3v4 to T3v5. These tips can be fetched and shown on the Preferences page of plugin #2.
    4. Since XSLT is the fitting Domain-specific language for XML-based transformations plugin #2 provides simple hooks for a batch of XSLT-files. Thus the transformation can be highly configured by non-PHP programmers.
    5. Referring to exceptional rules for CE's, pages and content types, there is a need for a name-based (and maybe wildcard-/regex-enhanced) description language for those rules.

Maybe it could be handy to split-off the import-functionalities for the TYPO3CR such that they are controllable in a RESTful way; this would of course separate plugin #2 into 2 different plugins.

Details

The text above should contain enough details so far; simply contact me if it does not. 

Required Skills or Background

  • XML, XSL/XSLT, maybe XLIFF (since this will be supported by v4.6 and Phoenix)
  • FLOW3
  • v4-lib (esp. sysext/impexp)
  • maybe JSR-170 (and its subsequent standards) by which the TYPO3CR was highly influenced