Migrate TYPO3 or move to Drupal or WordPress or Joomla?

Today with such huge leap in the changes to TYPO3, people are really moving over to WordPress and Drupal. There is a haphazard move to migrate to Druapl and WordPress. People are cashing in, and we at SCWEBS as a solution expert are not really happy about this extra bill. Financially this is extremely good, for an agency like ours.

We can just cash out by suggesting alternate solution, and justfy extra costs, and keep our company runing happy at the cost of my client’s money!

Is this really justified?


There are more than 4 lac websites that are still running on TYPO3 version 4.5.x and TYPO3 version 4.6.x.

One of the major change was the move from PiBase to ExtBase. Developers were not ready to move, clients were not ready to move. And the real fact that whenver there is a change – no one really wants to be ready. But the one who makes the move will be the smart person.

Some of the large enterprises and NGOs are already migrating from TYPO3 4.x or TYPO3 6.x to the latest TYPO3 version. But the main debate was whether we should really stick to TYPO3?

Several companies have already moved from TYPO3 to other options like Drupal, Joomla and WordPress. Was it really a cost saving smart move? I don’t think so.

I have been working on Content Management Systems (CMS) since almost 18 years or more from now. That is as a student, I had been fond of Content Management Systems (CMS). When I saw Drupal, WordPress and Joomla I had even started writing my own CMS system during those times.

When I met TYPO3, I was totally surprised that this Content Management System (CMS) can take over everything. TYPO3 was not framed behind PiBase or ExtBase, but it came forward with a beautful idea from the king Kasper Skårhøj. His main ideas helped build this extremely flexible Enterprise class Content Management System (CMS) from day one!!!. TYPO3 surely needs time to learn, but one learnt there is no going back. You can make it work like a Blog like WordPress, as an E-Commerce system like Magento, WooCommerce, PrestaShop or anything out of those 100+ choices, TYPO3 can be a Comunity portal like Drupal’s strong features.

TYPO3 could become anything, and even today when I re-learnt Drupal and WordPress, I am not happy with the options. WordPress and Drupal surely do excel, but if you chose TYPO3 once, I do not see a point why one should move out.

But such a move will surely cost on a long run, because in-spite of learning Drupal, WordPress and other ssytems I am not happy with these systems. One can argue that this is my individual opinion, but trust me on a real long run – the cost of choosing other systems will be learnt.

Today at SCWEBS we still use TYPO3 as our main expert area, and when one needs a real blog, we still do prefer WordPress. But if it is very simple blog like feature, TYPO3 is all we prefer. For E-Commerce WooCommerce or Prestashop and we do prefer a TYPO3 based shop like tt_product on several occasions. Drupal or Joomla almost never come into picture untill and unless a customer really wants to get it done by us.

In many cases, we have built a totally custom solution using Symfony and Laravel but we are proud that till date have never moved a TYPO3 customer out. I feel that migrating to ExtBase and TYPO3 Version 9 is far easier than moving over to Drupal.

If you want to migrate your site to WordPress or Drupal, contact us, we will personally help you out. I will show why TYPO3 is still better than the rest. There are 100+ reasons and areas where TYPO3 excels.

If you are still running your website on one of the TYPO3 versions like TYPO3 version 3.8, TYPO3 version 4.5 or TYPO3 version 4.6, TYPO3 version 6.2 LTS then we suggest it is time to migrate to newer TYPO3 version.

TYPO3 is quite secure, and we can justify it. We still kept some of our site on versin 4.x to analyze how attacks happen, and to what level. Today, on one of our 4.5 site, the site goes down and comes back up within 10 minutes, all by itself. The hackers are trying twice every day to get in, and succeed to a level, but they can’t get much deeper. We are watching what all they can do. They could not do much harm as of now… but we can’t sayfor how long. We are not such big security experts like our friends in TYPO3 security team. So our advice – migrate before it is too late.

These older versions are slowly getting older, and they may soon be hacked by a smart thief. By now, agencies are all well prepared to handle TYPO3 migrations, and these days costs are quite lower too. If you are an agency with many TYPO3 sites that needs migration, we can help with several strategies to lower the costs much further.

If you have a TYPO3 migration query, do get in touch with us. We are curiously waiting.

Prevent Search Engines from flooding the Encode Cache – using an XCLASS

The RealURL encode cache could get flooded with the URLs that are used by search engines like Google, Solr etc… If we know the exact parameter they use, we can prevent the flooding using this simple function given below

1.) Add this code to the file “Realurl.php” in the “Sconfig\Xclass” folder. Here “Sconfig” – is the name of our extension. “Xclass – folder may need to be created if not present”



namespace Scwebs\Sconfig\Xclass;

class Realurl extends \tx_realurl {
public function encodeSpURL(&$params) {

protected function encodeSpURL_encodeCache($urlData, $internalExtras, $setEncodedURL = ”) {
// \TYPO3\CMS\Core\Utility\GeneralUtility::devLog(‘Inside the hook now!’, ‘realurl’, 1, array($urlData));
if( isset($_GET[‘gclid’]) ){
$this->devLog(‘gclid detected. Not doing anything!’);
return ”;
parent::encodeSpURL_encodeCache($urlData, $internalExtras, $setEncodedURL);


2. Our Xclass needs to be registered, this can be done in the “Sconfig/ext_localconf.php” using the code below:

$GLOBALS[‘TYPO3_CONF_VARS’][‘SYS’][‘Objects’][‘tx_realurl’] = array(
‘className’ => Scwebs\\Sconfig\\Xclass\\Realurl’

The default controller for extension not found.

Some time we get the error like
“The default controller for extension “extname” and plugin “Calendar” can not be determined.
Please check for TYPO3\CMS\Extbase\Utility\ExtensionUtility::configurePlugin() in your ext_localconf.php”.

Even we have all the correct configurations in ext_localconf.php and ext_tables.php

This is what we have in ext_localconf.php
‘Vendor.’ . $_EXTKEY,
‘Calendar’ => ‘list, show’,
‘Calendar’ => ”,


This is what we have in ext_tables.php
‘Calendar For Dates’,

All the configurations are perfect but still we get the error, why?

Yes there is the reason for it. Suppose we have more than one extension, or more that one plug in in the same extension.
Other extensions or plugins might have had flexforms, and we have added that plugin and configured the flexform.
Now for the same tt_content element we have selected the plugin “Calendar”, and when we select this plugin we dont see any flexform values of
previous plugins.
But in Databse the table tt_content still stores the flexform values of old plug in and this leades to error.

Solution :
1) Go to databse and delete the flexform values for the perticular tt_content element.
2) Delete the old content element and add the new tt_content element.

TYPO3 extBase get locallang labels in Controller

We can use the below code to get the locallang lables in our extension controllers.


Or we can use


TYPO3 fluid selectbox viewhelper.

In the below example, the selectbox options are coming from locallang.

‘hotelclass’ => array(
‘exclude’ => 1,
‘label’ => ‘LLL:EXT:myext/Resources/Private/Language/locallang_db.xlf:tx_myext_domain_model_hotels.hotelclass’,
‘config’ => array(
‘type’ => ‘select’,
‘items’ => array(
array(‘LLL:EXT:myext/Resources/Private/Language/locallang_db.xlf:tx_myext_domain_model_hotels.hotelclass.2star’, ‘2’),
array(‘LLL:EXT:myext/Resources/Private/Language/locallang_db.xlf:tx_myext_domain_model_hotels.hotelclass.3star’, ‘3’),
array(‘LLL:EXT:myext/Resources/Private/Language/locallang_db.xlf:tx_myext_domain_model_hotels.hotelclass.5star’, ‘5’),
array(‘LLL:EXT:myext/Resources/Private/Language/locallang_db.xlf:tx_myext_domain_model_hotels.hotelclass.7star’, ‘7’),
‘size’ => 1,
‘maxitems’ => 1,
‘eval’ => ”

To display this select box in FE from, we can use the custom view helper.

To use the viewhelpler follow the following steps.

1. Create the file


2. Add the below code

namespace TYPO3\Myext\ViewHelpers;

class TcaOptionsViewHelper extends \TYPO3\CMS\Fluid\Core\ViewHelper\AbstractViewHelper {

* local cache for dataMaps
* @var array
protected $dataMaps = array();

* @var \TYPO3\CMS\Extbase\Persistence\Generic\Mapper\DataMapper
* @inject
protected $dataMapper;

* objectManager
* @var \TYPO3\CMS\Extbase\Object\ObjectManager
* @inject
protected $objectManager;

* Is returning select values for a property or propertyPath of a given object or className
* @param mixed $subject The object or className the property belongs to
* @param string $property The property itself
* @return array The select options as array
public function render($subject = NULL, $property = ”) {
if (!is_object($subject) && is_string($subject) && class_exists($subject)) {
$subject= $this->objectManager->get($subject);
return self::getSelectOptions($property, $subject);

* Is resolving the select values for a property or propertyPath of a given object or className
* @param string $propertyPath The property itself
* @param object $subject The object or className the property belongs to
* @return array The select options as array
private function getSelectOptions($propertyPath, $subject) {
$selectOptions = array();

if (is_object($subject)) {
$propertyPathSegments = \TYPO3\CMS\Core\Utility\GeneralUtility::trimExplode(‘.’, $propertyPath);
$object = clone($subject);
$propertyName = $propertyPath;

// resolve a property path
if (count($propertyPathSegments) > 1) {
foreach($propertyPathSegments as $key => $propertyName) {
$propertyType = $this->dataMapper->getType(get_class($tempObject), $propertyName);
if (strpos($propertyType,’_’)) {
$object = $this->objectManager->create($propertyType);
} else {

$dataMap = self::getDataMap($object);

if ($dataMap == NULL || !$dataMap->isPersistableProperty($propertyName)) {
return $selectOptions;

$tableName = $this->dataMapper->convertClassNameToTableName(get_class($object));
$columnName = $dataMap->getColumnMap($propertyName)->getColumnName();

// only convert select items which do not have a DB relation
$columnConfig = $GLOBALS[‘TCA’][$tableName][‘columns’][$columnName][‘config’];
if ($columnConfig[‘type’] == ‘select’ && count($columnConfig[‘items’]) && !$columnConfig[‘foreign_table’]) {
foreach ($columnConfig[‘items’] as $option) {
$selectOptions[$option[1]] = \TYPO3\CMS\Extbase\Utility\LocalizationUtility::translate($option[0], $this->controllerContext->getRequest()->getControllerExtensionName());
return $selectOptions;

* Resolve the dataMap for the given object
* @param object $object The domain object to get the dataMap for
* @return Tx_Extbase_Persistence_Mapper_DataMap
private function getDataMap($object) {
$class = is_object($object) ? get_class($object) : $object;
if (!isset($this->dataMaps[$class])) {
$this->dataMaps[$class] = $this->dataMapper->getDataMap($class);
return $this->dataMaps[$class];

3. Add the below lines in fluid template, that is intended to show FE form

{namespace custom=TYPO3\Myext\ViewHelpers}

<f:form.select property=”hotelclass” options=”{custom:TcaOptions(property:’hotelclass’,subject:’TYPO3\\Myext\\Domain\\Model\\Hotels’)}” />

4. The output source will be like this.

<select name=”tx_myext_hotels[hotels][hotelclass]”>
<option value=”2″>2 Star</option>
<option value=”3″>3 Star</option>
<option value=”5″>5 Star</option>
<option value=”7″>7 Star</option>

Thanks to: https://gist.github.com/anonymous/888297