So that’s what you might see in your TypoScript Object Browser:

 Switching from there to the Template Analyzer:

At the bottom of the Template Analyzer, you’ll find a “Complete TS” section and a link ~which looks like normal text.

Clicking on that link will give you the entire concatenated TypoScript and here you’ll also find that the line numbers finally match to the error message.

A well hidden gem which works most likely in all TYPO3 4.x versions

DISCLAIMER: Don’t take the following too serious – when reading this post please keep in mind that the TYPO3 community itself consists of much more than just the Core team activity – many things take place outside of code repositories and can’t be measured anyhow. Every contribution is important and every single action has value.

Using Gerrit sometimes feels quite lonesome – you don’t really see who’s active and you don’t really get a feeling on how much is done in the TYPO3 Core at a certain point. To visualize on how active the contributors are and to show the most active members I applied a little scoring and summed up the results for the time since 2006.

Early 2006 impact chart with few early contributers - click the image to see the full chart

The scoring is quite easy – every author of a patch gets 10 points, testers get 3 and reviewers 1 point*. Looking at the stats it seems that even the statistics pulled from the old Subversion days seem to meet up with today’s numbers – of course we’ve to keep in mind that everything which was pulled from Subversion doesn’t really point to the author but to the actual committer (except if there was a “Thanks to XXXXX” reference in the commit).

To visualize the numbers I choose a Github like impact chart**. Each contributor has it’s own color and line in it and whenever he got active the width of the line scales up. To maintain the overview the scale of the width isn’t linear and every contributor who’s not within the “Top 20″ had to be scaled down to “1″. The line stops if the contributor didn’t get active anymore. The scores are grouped and compared by month.

Taken the last 3months - see the entire stats on the referenced page.

In addition to the chart I also created a table based overview for the “Top 20″ contributors with their score***.

Few things I got from the numbers. There have been 290 contributors already – simply amazing. Comparing the (huge) scores of the release managers with their fellow contributors shows once more that they can be really proud about the job they did or do. It’s also quite cool to see that many people keep sticking around. And finally it was quite surprising to see that our community manager Ben van’t Ende can also be found in the stats. Besides that it’s up to everyone else to find their conclusions from these numbers. I hope it’s motivating everyone to see that the community is active as always.

The script I created to generate the charts isn’t too nice at the moment, but I promise to publish it once I cleaned it up a bit. If you can’t wait to get your hands on it, feel free to send me a mail or tweet. – but I published it anyways: github.com/tolleiv/Repo-Activity-Monitor

Links in short: Impact chart, Monthly “Top 20″ tables.

* The scoring includes the commits to the Core master and all related submodule commits. Unfortunately the submodule commits don’t hold the reviewer and tester information. Also some of the latest changes made in the submodules may not show up at the moment because the submodule pointers haven’t been updated yet.
** Inspired by the incredible RaphaëlJS vector graphics library which is distributed with an MIT license and can be found on raphaeljs.com
*** Again – don’t take it too serious – the scoring doesn’t take into account that some patches can be written in 15 minutes where others take days. It also only uses the final testers and reviewers mentioned in the commit message, other contributions are not counted atm

First of all TemplaVoila 1.6 was released parallel to TYPO3 4.6. It shipped with 22 bug and compatibility fixes. In general the 1.6.x branch is supposed to be compatible with TYPO3 4.4+ which also made it possible to clean up the extension quite a bit. In addition to that TemplaVoila 1.6.1 will show up in the TER in the next few hours. It fixes 10 additional issues.

Besides that, the main repository for TemplaVoila was moved to git.typo3.org and the old Subversion repository and my Github repository have been removed. The new repository location also enables and enforces a new way to contribute code changes for the project. Comparable to the TYPO3v4 Core every change request can be sent to Gerrit, where I can review the changes before they get merged into the repository. That workflow turns out to be very efficient for me. A detailed summary on how to contribute code to any repository hosted on git.typo3.org can be found on wiki.typo3.org. To sum up some of the steps – here’s how you submit a patch*:

git clone git://git.typo3.org/TYPO3v4/Extensions/templavoila.git
cd templavoila
scp -p -P 29418 <username>@review.typo3.org:hooks/commit-msg .git/hooks/
git checkout -b workingBranch
# ... work on the files ...
git add <changedFile>
git commit
git push origin HEAD:refs/for/master/<topic>

A further general change to the team happend more or less silently. During 2011 nobody from the old team or any new developer showed interest in the project and only few contributors helped with bugfixes or reviews. Due to that I also changed my attitude regarding future releases.
I’m currently planning to release one version parallel with every main TYPO3 4.x release, to make sure that TemplaVoila works in new versions and to make sure people can enjoy TYPO3 with TemplaVoila in the future as well. I’ll also try to keep it compatible with all “stable” releases and aim to keep the issue count within the bugtracker as low as possible.
But I’m not planning to integrate new major features such as the field content sliding (use EXT:kb_tv_cont_slide please) or a context sensitive content wizard (a.k.a “content firewall”). Also major refactorings won’t happen because they’d consume far too much of my time – therefore also the desperately needed update of the mapping module or a new new page module will not be implemented in the near future.

Nevertheless I’m open for any type of contribution and I’d be happy to review and test any patch showing up in Mantis or Gerrit – I’m just not able to spent a major part of my freetime for it.

• The Pragmatic Programmer: From Journeyman to Master – a must read for every programmer and once in a while worth to take a look at. It also opens up tons of other topics which you should be pragmatic at.
• Why Functional Programming Matters – introducing the concepts of lazy evaluation and high-order functions for a couple of mathematical examples. With Steam.js as implementation of lazy evaluation in JavaScript.
• MapReduce: Simplified Data Processing on Large Clusters – every now and then I’m trying to get my hands dirty with CouchDB and re-reading this paper and the related works is always a good start.
• Some texts worth looking at when it comes to user stories Imperative vs Declarative Scenarios in User Stories, The Easy Way to Writing Good User Stories, A User Story Primer, How do you estimate the Business Value of User Stories? You don’t., Story Smells: The Valueless Story
• The training wheels came off – shows how valuable BDD scenarios should look like and why the cucumber-rails (ruby gem) stopped shipping predefined step definitions to enforce better scenarios among newcomers.
• What Your Dog Can Teach You About Building Teams - a blog post which has a good point, it misses some background information though. In depth insights might come from Management 3.0: Leading Agile Developers, Developing Agile Leaders and Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers which I won’t have time to look into
• Coding Conway’s Game of Life in Ruby the TDD Way with RSpec #1 – a great screencast showing TDD in action with Ruby and RSpec. This 50min screencast shows how things evolve during TDD coding sessions and how models can grow within test suits.

What’s on your list?

TCEMAIN.clearCacheCmd=all|<pid>

But of course it isn’t very smart to clear all caches once you have filled them up for hundred or even thousand records. To work around these limits it’s quite handy to use an API which lives in TYPO3 since 2008. It allows to add tags to the page cache and removes the caches by tag.

Adding tags to the current page can be done with this block:

$GLOBALS['TSFE']->addCacheTags(array('tx_example_model:' . $id));

Removing the caches for that specific page could look like this:

$GLOBALS['typo3CacheManager']->getCache('cache_pages')->flushByTag('tx_example_model:' . $id);

Correctly integrating this with your extension is quite easy. To set the tags, add the first block into your controller and make sure you provide the proper uid for the rendered domain objects. To remove the caches once a record is saved in the backend just register a t3lib_tcemain hook and flush the tagged caches.

Credits: Fabrizio Branca @fbrnc – thx for pointing me to it

class Tx_Example_Hooks_Tcemain {
	public function processDatamap_afterDatabaseOperations($status, $table, $id, $fieldArray, &$reference) {
		if ($table == 'tx_example_model') {
			$GLOBALS['typo3CacheManager']->getCache('cache_pages')->flushByTag('tx_example_model:' . $id);
		}
	}
}

EXT:example/ext_localconf.php

$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['t3lib/class.t3lib_tcemain.php']['processDatamapClass']['example'] = 'EXT:example/Classes/Hooks/Tcemain.php:Tx_Example_Hooks_Tcemain';

First of all you should understand the concept. This nice little “definition” (from flow3.typo3.org) sums it up pretty well:

A signal, which contains event information as it makes sense in the case at hand, can be emitted (sent) by any part of the code and is received by one or more slots, which can be any function in FLOW3 in extbase.

To get this running in extbase, you’ve to get hold of the Tx_Extbase_SignalSlot_Dispatcher, which is the central instance to manage all of it. Within Extbase that’s done easily with this snippet within your classes:

   ...
	/**
	 * @var Tx_Extbase_SignalSlot_Dispatcher
	 */
	protected $signalSlotDispatcher;

	/**
	 * @param Tx_Extbase_SignalSlot_Dispatcher $signalSlotDispatcher
	 */
	public function injectSignalSlotDispatcher(Tx_Extbase_SignalSlot_Dispatcher $signalSlotDispatcher) {
		$this->signalSlotDispatcher = $signalSlotDispatcher;
	}
   ...

Next thing is to make use of it. The Slot (listener) part could look like one of following blocks. In all cases you define the Signal by it’s class (not necessarily a PHP Class) and it’s name. Next to that the Slot can either be defined by a Closure, an object with a method name or a PHP-Class and a method name.

   ...
// Using a closure
$this->signalSlotDispatcher->connect(
      'Crunching', 'emitDataReady', function($data) { crunch($data) }, NULL, FALSE
);
   ...
// Using a method of the current object
$this->signalSlotDispatcher->connect(
     'Crunching', 'emitDataReady', $this, 'crunch', FALSE
);
   ...
// Using a method of the specified class
$this->signalSlotDispatcher->connect(
     'Crunching', 'emitDataReady', 'Cruncher', 'crunch', FALSE
);
   ...

To trigger the Signal which invokes the Slots registered above, you’ve to run the following code.

$this->signalSlotDispatcher->dispatch('Crunching', 'emitDataReady', array($data));

One thing I found was that by default the Tx_Extbase_SignalSlot_Dispatcher it not a Singleton in older extbase versions. Bastian fixed that already in the master and 1-4 branches and lucky enough this change was part within the TYPO3 4.6.1 release. But I think it’s still important to mention that this wasn’t the default from the beginning on.

Even if AOP is a nicer way to implement this feature, the extbase backport still works pretty straigh forward.

Edit: One thing I’ve to add – Felix is not “just” talking about Signal/Slots – he’s the one to thank for the backport. And now that his blog is running again – this post seems like a summary

TemplaVoila 1.5.4
The current release focussed on 4.5 compatibility. It uses the new sys_language flag “format” to support sprites, it hooks into the new backend-form (TCA) “layout” and add’s it’s fields to the right tabs within the backend forms and adjusts everything to work fine with the new CSRF mechanism.

Besides that bug fixes for the section index, performance improvements and a couple more are included.

One thing in conjunction with 4.5 you should be aware of is that copied elements are hidden by default. In older versions hidden elements won’t show up in the page module by default and therefore it might seem that nothing was copied, but that’s not right. With 1.5.4 the default setting was changed so hidden elements will show up in the page module. Unfortunately the old setting (to skip hidden elements) might still be present in your session settings – so please either clear your session settings or use the “Advanced function” tab in the page module to change to setting and avoid confusion.

Imagemap_wizard 0.6.0
The last versions proved to be very stable and with some additional sponsoring I was able to improve the DAM and TYPO3 workspaces support. Besides that a couple of issues which showed up in 4.4 and 4.5 were fixed. One of the next features will hopefully be a useful point of interest implementation – keep your fingers crossed that someone’s clients want’s to sponsor some time for that

Workspaces 4.5.1 / 4.5.2
Even if it’s shipped with the Core and included in the official release notes, here’s my summary of the improvements. The workspace module itself brought us lot’s of good feedback and also the new workspace preview raised some attention. Even though 4.5.0 was quite stable we weren’t able to get it working perfectly. The fixes made for 4.5.1 made sure that especially the preview window works much more stable, it introduced state persistence (so switching preview modes or module settings are memorized properly) and it brought some performance improvements.
Btw. if you didn’t check out the new workspaces features and improvements the new workspaces documentation from Susanne Moog is a good point to start.

As member of the TYPO3 workspace team I’d like to encourage everyone to send as much feedback as possible for all the workspace related changes and since maintaining TemplaVoila is also still on my list, it would be great if you let me know if you find any TemplaVoila related issues with the new TYPO3 version.

If you’d like to stay up-to-date with the latest changes in the TYPO3 Core, without reading all the newsgroup messages, you might be interested to use the TYPO3 trunk Changelog RSS feed. Besides the feed there’s a great service from the Core team, they started to publish the protocol of their weekly meeting as “Minutes from the meeting of the release 4.5 team” to the typo3.project.v4 newsgroup. I hope this will be kept up in the future.

HTML5 support

The full list of HTML5 tags is now supported in TemplaVoila. The restrictions to specific tags was removed and the TYPO3 integrator is now able to use the full bandwidth of modern HTML. With this change also the tag-icons themself were replaced and the coloring schema was changed. The inspiration for the current color schema came from Josh Duck’s “Periodic Table of the Elements”. In additon same mapping bugs have been resolved too – for details see #13974 and #14881.

Page module with TYPO3 4.4 look&feel

TYPO3 4.4 Look&Feel and docHeader integration

TYPO3 4.4 introduced a new skin and changed the look&feel in the backend radically. Once installed in 4.4 TemplaVoila 1.5 adjusts it’s look and provides the same usability improvements as the official page module. The page-module was optimized to use as much “official” CSS as possible to support designes with their own backend-skins. In addition to the CSS&Markup changes, TemplaVoila also uses the TYPO3 4.4 SpriteIcon API to provide and retrieve backend icons and uses the FlashMessage API to style all backend notifications.

Another important step was the integration of the so called docHeader. This is the area at the very top of each backend module page which provides useful tools and action-icons. With this version TemplaVoila finally provides docHeaders within every backend-part.

Improved TYPO3 integration

Besides the visual changes the general TYPO3 integration has been improved with various modifications.

With the current version there’s no need to give “Edit page” rights to you editors if they want to add or remove content elements. Just the “Edit content” right and access to the “Page>Content” field is enough for them. For details see: #3903

The “advached header link inclusion” is one of the integration steps in the frontend. All resources which are related to an FCE are passed through an TYPO3 API (pageRenderer). This avoids duplicate inclusion of one resource (e.g. CSS files) and enables further post-processing (e.g. compression or merging). It can be enabled using the “advancedHeaderInclusion” within your TypoScript setup which could then look like this:

page = PAGE
page.typeNum = 0
page.10 = USER
page.10.userFunc = tx_templavoila_pi1->main_page
page.10.advancedHeaderInclusion= 1

—
The full list of changes within this version can be found on bugs.typo3.org.
Many many thanks to all contributors and reviewers – it’s great that more people try to help out and it keeps me motivated to continue improving this great TYPO3 extension.

Update: Finally TemplaVoila moved to git.typo3.org – please read the update here

As it seems, souce code version control for TYPO3 will be done with Git in the future. The Phoenix team already uses git.typo3.org, there’s also already the possibility to get the latest updates for the v4 Core via github.com and it won’t take long until git.typo3.org is been used for version 4 as well.

Due to the fact that my TemplaVoila development workflow is also already git based, I thought it might be interesting for some contributors to develop with a git repository upstream. Therefore I started to maintain a TemplaVoila repository on github.com [1]. The Subversion repository on forge.typo3.org [2] is of course still the master, but both repositories are kept in sync automatically.

So once you think about sending an RFC to the typo3.team.templavoila list, feel free to attach a git based patch-file.

[1] http://github.com/tolleiv/TemplaVoila
[2] https://svn.typo3.org/TYPO3v4/Extensions/templavoila/