Typo3 and Drupal. Developer notes.

Hi all,

I hope these notes will be interesting for those who like me are in a situation of choosing which platform to use for a new project. I got experience of creating couple of web sites on Typo3 platform before looking at Drupal alternative. So, here is result of my comparison.

TYPO3 and DRUPLA comparison

1. ACCESS RIGHTS SYSTEM

Both systems use a similar approach to control user access but TYPO3 offers more options:

• Access rights can be assigned to individual user ( not included in any group)

• User can belong to several groups at one time

• Group settings can be inherited when a new group is created

2. CONTROLLING A LAYOUT

2.1 Default layouts

Typo3 has several (decades) preinstalled templates which (above all) control page layout and can be customized to suit your needs.

Drupal has six preinstalled themes.

Typo3 allows developer to create custom layouts from scratch.

Drupal allows developer to create custom layouts from scratch

2.2 Creating custom layout from scratch in Typo3 and Drupal

TYPO3 allows the following:

• Option 1: using of special markers in HTML prototypes of pages. When page is rendered and markers are met, typo3 rendering machine substitutes them with dynamically generated content.

• Option 2: information about embedded elements of a page’s layout is saved in xml file with a reference to the prototype html file. When the page is rendered that information is used to incorporate content of embedded elements on a page

Drupal offers several options. All available options rely on overriding Drupal's built-in theme functions (theme hooks). The following options are available:

• Plain PHP themes (php functions are inserted on a page by developer to call Drupal's built-in theme functions)

• Using available template engines which fulfill a job of calling Drupal's built-in theme functions when meet appropriate markers in html file provided by developer. It simplifies developer’s life little bit because she doesn’t need to know Drupal's built-in theme functions. But a lot of work is still left. The following template engines are available:

1. PHPTemplate , that is default one since 4.7 version.

2. XTemplate ( not supported in last 5.x versions)

3. Smarty Template – the most powerful one but requiring knowledge of Smarty Template Engine Syntax.

2.3 Automation of creating custom layouts

TYPO3 comes with in-built tools (more precisely – they are provided by an extension (TemplaVoila) which allows developer to create custom layouts of any complexity with option 2 in user friendly visual interface. No other special knowledge except of pure html is required for this job.

Drupal contains no any tools for automation of creating arbitrary layouts.

Post notes:

1) Drupal stays easy to implement as long as developer uses default themes. It stops when it became necessary to create arbitrary layout for a complex page since this is not trivial job and no automation is foreseen to simplify it.

2) Drupal’s layouting system is not stable and goes through changes. It still carries load of limitations set on Drupal’s layouts by Drupal’s initial three column layout. For example, Drupal’s ‘block’ elements were initially intended to be used in sidebars (left and right columns). Only 4.7 version introduced ‘regions’ in themes which offer more flexibility in theme layout. But content is still assigned to regions through the block system interface initially intended for three column layout.

3) In Drupal, flexibility of custom layouts is limited by set of hooks provided by Drupal’s core. Compare with Typo3 where rendering machine just outputs content provided by some element . This is why Typo3 has no any limitations here. Typo3’s layouts are as flexible as html can be.

2.4 Final note:

creating custom layout in TYPO3 is much easier than in Drupal

3. CONTROLLING RENDERING MACHINE

Typo3 site can have set of low level TS templates (at least one template must exist) which can be considered as sets of instructions to be implemented when the page is rendered. These templates have nothing with html templates used in both typo3 and drupal for layouting pages. TS templates are written in TypoScript – internal typo3 configuration language. In theory, almost any thing you can do with TYPO3 can be achieved by just using TS templates. The essential thing about TS templates is that they support inheritance. It means, for example, if some content is inserted in the root TS template it’ll be shown in all other site pages too. From the other hand, inheritance is controlled by developer, so it is possible to define what must be inherited and what is not.

Drupal has no analog for what is described above.

Note:

TS templates are very flexible and powerful. In Typo3 it is possible to achieve great results by inserting just several lines in TS template. Drupal looses here.

4. EXTENDING THE SYSTEM

Functionality of both systems can be extended. In Typo3 it is done by extensions and in Drupal – by modules.

4.1 How is it organized in both systems?

In Typo3 content generated by extension is just inserted on a page at a place where that extension resides.

It can be imagined in the following way: TYPO3 rendering machine looks over page layout and seeing extension, executes it and then, when execution has finished, inserts a result created by extension on a page.

Extension doesn’t depend on Typo3 core in a sense of ability to create content. There is functions division. Extension creates content and typo3 core inserts it on a page.

In Drupal inserting a content generated by a module on a page is based on hooks – places in Drupal core. In these places Drupal’s engine looks in series in a directory where modules reside and calls functions from the predefined set of hooks for every module that defined those functions.

Thus, functionality added by a module is limited by set of hooks provided by Drupal’s core or, in other words, functionality of a module is bound and limited by Drupal’s core.

4.2 Must module developer know the system’s core?

In Typo3, in theory (there can be other considerations), any extension can be created without knowing of the typo3 core because extension doesn’t depend on TYPO3 core.

In Drupal module developer must have an imagination about Drupal functioning and know full set of hooks provided by Drupal’s core (that changes from version to version).

4.3 Is it possible to use the system core in a module?

Both systems offer this possibility.

.
4.4 Module architecture.

In Typo3 all the extensions have the same structure (see the following section, why). It helps in hacking of extension when necessary.

Drupal’s modules have no any obligatory structure.

4.5 Automation of the creating a new module (extension).

Typo3 contains a system functionality intended to help developer to create a new extension. It creates a skeleton of a new extension and set of necessary supporting files. Developer answers several questions in dedicated admin interface and gets ready to go (it produces a sample content) extension in return. The only thing developer must do is filling automatically created extension with a specific code. So, she can concentrate on extension related tasks not worrying about interaction with the Typo3 core.

Another good thing of automation is that all extensions created for Typo3 have a similar structure what helps much when necessity to hack an extension arises.

In Drupal no automation is foreseen.

4.6 Extensions (modules) managing

Typo3 contains a system functionality intended to manage processes of creating, spreading, searching, downloading and installing extensions.

All admin actions in the context of this functionality are done with a help of a dedicated user interface.

This functionality provides:

• search of extension in central extensions repository

• downloading of extension in the developer’s system

• automatic check of ability of using that extension in developer’s system

• automatic installation and registration of extension in the Developer’s system ( including database modification if it is foreseen by the extension)

In Drupal no automation is foreseen. All must be done ‘by hands’.

4.7 Post notes:

• TYPO3 has pronounced module structure while Drupal can be called as a module structure system only at a stretch ( in comparison with Typo3)

• TYPO3 has advanced tools of creating and spreading extensions while Drupal has none of them.

• TYPO3 extensions have complex structure combining class files, auxiliary files and resource files. But that structure is unified and created automatically.

Drupal’s modules are relatively simple but have no unified structure and must be created manually. As a result getting into (hacking) Typo3 extension is easier than into Drupal’s module what is especially important when you have a deal with an open source system.

4.8 Final note:

Working with Typo3 extensions is easier than with Drupal’s modules.

5. LOCALIZATION

Typo3 allows both admin interface localization and site content localization. Localization can be done to content element. Thus, any page can be localized as entirely as partly, up to content element depending on needs.

The system forces developer to support alternative languages - when a new extension is generated by a system, the language files are inserted in a generated set of extension files.

Drupal offers only admin localization. The only way of supporting alternative languages is creating a new version of the site for every new language.

6. CACHING

Both systems use caching to increase performance.

In Typo3 by default all the pages are cached on the server after being constructed for the first time.

Plus to this TYPO3 offers several methods to control caching. Typo3 allows developer to control caching setting it differently for different pages or even content elements. Moreover, in Typo3 it is possible to insert not cached content in a cached page.

Drupal has three caching modes:

• Disabled (default)

• Normal

• aggressive

Caching mode (one of the listed above) is defined for the whole site and can’t be different for some part of it.

Post note:

TYPO3 caching system is much more flexible. And this is not in vain. I have no idea what could I do if I had no option to insert not cached content into a cached page when worked with my last project.

7. TAXONOMY

Typo3 has many classification systems for content but they are separated and not combined in one on the site level.

In Drupal taxonomy is a categories system defined on a site level (can be hierarchical).

It can be used (it is not obligatory) for classification of content by belonging to one or several categories defined in taxonomy.

Benefits of using taxonomy are defined by set of Drupal’s core functions (more precisely, by hooks provided by Drupal’s taxonomy module and contributed Categories module) which can be implemented to elements of taxonomy. In general, it provides with possibility of grouping content elements by belonging to one or set of categories.

Post notes:

Presence of common content classification system in Drupal (and lack of it in Typo3) is explained, probably, by the following reasons.

1) historical reason: Drupal looks to has grown from a specific blog application for which this kind of system is a necessity while Typo3 was initially intending to be a framework dedicated for a wide set of tasks. This is why classification system is introduced in Typo3 only there where it is really necessary.

2) Possible benefits of using taxonomy in Drupal ,if it is used, are achieved in Typo3, thanks to its flexibility, by other methods. So it can’t be said that Typo3 looses here.

3) However, the idea of using united classification system for content is a very productive one. This is why several extensions were written for Typo3 and they allow developer to establish relation between similar content elements (for example, news items and events) in context of united classification system what is an analog of taxonomy in Drupal on a limited set of content elements.

4) In case of necessity, high level taxonomy can be added to Typo3 as its extension. Both Typo3 architecture and database structure do not prevent it (for example, for a database, the only thing we need is just extend tt_content table of the Typo3 database with a reference to taxonomy tables – analog of Drupal’s tables with a ‘term’ prefix.).

8. OBJECT-ORIENTED PROGRAMMING NOTES

One strange thing about Drupal is that it doesn’t use objects. Just have a look at any Drupal’s php file to see it. It concerns both - Drupal’s core and contributed modules.

Of course, OOP approach available in PHP is far from OOP implemented by high-level programming languages. But classes and inheritance existed in PHP of all 4.x versions. Even this helps in creating systematical and reusable code.

In code of the Typo classes are used everywhere. As a rule, base class of any Typo3 extension extends one of the core Typo3 classes.

I have installed latest (5.1) Drupal version that is dedicated to work under php5 but even it doesn’t use classes too. Meanwhile php5 essentially extends OOP of php by adding abstract classes, interfaces and overloading. It is already a real thing and, of course, Drupal loses on it.

9. FINAL NOTES

1. Typo3 is a very logical system. It was designed with all its base features at once. It is reflected in typo3 architecture, Typo3 flexibility, Typo3 power and, of course, in admin interface.

Drupal looks to grow from especial highly tailored web application. And this still prevents
it from being as flexible and as powerful as Typo3 is.

2. For the first glance Drupal looks not as complex as Typo3 is. But this is a true only if you are inside of Drupal core installation and need no essential customization. But if this is necessary you are bound to deep into not systematical, not friendly and not much logical Drupal core.

3. However, it looks that any task can be realized on both platforms. But in Drupal case it will require more developer’s efforts because Drupal is not as powerful and as flexible as Typo3 is. So, looking from developer perspective, time spent in learning Typo3 returns with more effective results in comparison with time spent in learning Drupal .

4. The same time, for some highly tailored web applications in a condition when task allows developer to stay within one of delivered Drupal’s themes, it can be not bad choice.