Updating our companies major portals from Typo3 CMS 4.7 LTS to 6.2 LTS was a good piece of work, so I was not really keen on updating any websites again. A good excuse for us was the fact that RealURL was not yet available for Typo3 CMS 7, but now it is – no more excuses. We need to do it anyway.
Before you even start, you should check the requirements of Typo3 CMS 7. It requires at least PHP 5.5 and MySQL 5.5, which might not be available on your server. So check the Typo3 CMS 7 System requirements before you continue.
I started with a relatively small project, which was ideal to get some experience. Only a few dozens of pages, a couple of TypoScript files, and most important, no legacy extensions but only good maintained Extbase 6.2 extension. I was pleasently surprised that the whole migration with fixing all issues (see below) only took roughly one hour, so my thanks to the Typo3 CMS team for that great job!
If you have one or more pre Extbase 6.2 extensions which don’t yet use namespaces (i.e. classes are named like Tx_MyExtension_Domain_Model_Whatever instead of just Whatever), there is an extension called “compatibility6” which comes bundled with Version 7.2. You can also use it if you already screwed your Typo3 installation and you can’t login into the backend anymore: you can install it manually by editing the typo3conf/PackageStates.php, search for compatibility6 and change the state from inactive to active. Please note that the usage of this extension has a negative impact on performance, although I can’t quantify the impact. It might just be ok for smaller websites.
The update process is explained here: http://wiki.typo3.org/TYPO3_CMS_7.2.0. In our case, the basic steps were:
- download the Typo3 sources
- uninstall RealURL
- delete typo3temp/Cache folder
- switch typo3_src to new version
- run all checks in the Install tool
- login into the backend, update RealURL to the recent version and
- install it again
Update problems
Of course the update did not go without any problems, so let’s discuss them in this section.
CSS missing!
After finishing the update work in the Install tool I went to the backend login page and was somewhat suprised – I didn’t expect that fresh oldschool style:
Ok wait, there’s something wrong. Obviously the t3skin.css was missing.
It turned out that somehow the PackageStates.php was mixed up, and although the t3skin system extension was marked as active, it obviously wasn’t. Doing some internet research revealed that this problem occurred for others as well. I ended up in simply deleting the PackageStates.php (after doing a backup) and reload the login page. This way, the PackageStates.php was regenerated from scratch. Once it was created again, I needed to re-activate almost all system extensions manually. All in all this was just a matter of minutes, so no big deal.
No leading backslashes please!
After fixing the CSS issues, I loaded the start page which includes one of our custom extensions, and ended up with another exception:
$className “\My\Nifty\Class” must not start with a backslash.
Some of our makeInstance() calls had a backslash before the FQCN, which whith Typo3 CMS 7 is not allowed anymore. Since the backslash is not needed, we simply removed it, e.g.
// works ok with Typo3 CMS 6.2, but not 7.2:
$myInstance = GeneralUtility::makeInstance('\\My\\Nifty\\Class');
// works ok with Typo3 CM 6.2 AND 7.2:
$myInstance = GeneralUtility::makeInstance('My\\Nifty\\Class');
This also applies for calls to the ObjectManagers get-function!
Stating the class name as a string leads to the ugly double backslashes, which nobody likes. With PHP 5.5+, we now can use the ::class constant:
$myInstance = GeneralUtility::makeInstance(My\Nifty\Class:class);
which I really prefer because it is more readable and you can now use your IDEs code completion.
When the views are gone
Next reload, the page loads … yay! No exceptions. Good. So on to the next issue (a real classic):
Sorry, the requested view was not found.
The technical reason is: No template was found. View could not be resolved for action "index" in class "My\Nifty\Controller\IndexController".
This time the problem was in the Configuration\Typoscript\setup.txt of one extension, where we still used the old name for the view folders:
# this works until Typo3 6.2
templateRootPath = {$plugin.tx_mynifty.view.templateRootPath}
partialRootPath = {$plugin.tx_mynifty.view.partialRootPath}
layoutRootPath = {$plugin.tx_mynifty.view.layoutRootPath}
# with Typo3 7.x, use
templateRootPaths.10 = {$plugin.tx_mynifty.view.templateRootPath}
partialRootPaths.10 = {$plugin.tx_mynifty.view.partialRootPath}
layoutRootPaths.10 = {$plugin.tx_mynifty.view.layoutRootPath}
Extbase supports fallback paths for templates, layouts and partials, which is quite cool – when you know it. Fluid uses the highest index (in our case only one, the 10) as directory for looking up the templates, and tries out the next lower one if it fails. Oh, and also it is called RootPaths instead of RootPath for a while already.
Say “hi” to number seven
Updating to Typo3 CMS 7.2 caused far less trouble than the previous “LTS-Jump”. I really like the fresh look of the backend, and the fact that the Typo3 core has been cleaned up even further.
Surely the website I migrated was only a small one with no legacy extensions, but I think I covered some issues which might be helpful to others!
