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.

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.

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/

The high level release notes are:

• page module is now customizable with CSS and JavaScript
• handling of static data structures are improved and fully working now
• wizards are improved, new page wizard is more explaining
• visual cleanups
• new hooks for eTypes (elements added by mapping interface)
• new classes for preview in page module, easy to override by extensions
• added missing localisations
• enhanced drag-and-drop in page module
• over 100 Bugs are fixed
• updated manual

During the installation your TYPO3 Extension Manager will ask to perform a couple of database upgrades. These upgrades aren’t really critical because they just enlarge some database fields, which will make sure that your data really fit’s in.

Just to point one thing out – especially the page module has been improved to be more flexible in certain parts.

These lines of TSConfig can be used to add CSS or JavaScript into the page module and enable easy customizations:

mod.web_txtemplavoilaM1.stylesheet = ../fileadmin/css/tvpagemodule.css

mod.web_txtemplavoilaM1.javascript {
  file1 = ../fileadmin/templates/js/jquery.js
  file2 = ../fileadmin/templates/css/backend.js
}

Further customizations is provided using the “mod.web_txtemplavoilaM1.blindIcons” configuration or with individual content preview classes (configured though “$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['templavoila']['mod1']['renderPreviewContent']” – see ext_localconf.php).

We haven’t discussed what the direction for the next versions really looks like. From my perspective better TYPO3 integration, some kind of code cleanup and also the integration of some features which arise with TYPO3 4.4 will be somehow on our schedule. But since TemplaVoila isn’t a one man show anymore, this isn’t just my decision and in addition I’d like to encourage everyone to send feedback, bugfixes or new features just to give us an impression what you like or dislike in the current version.

Last but not least, I’d like to thank everyone who was somehow involved in the release, especially Steffen Kamper who shared lot of inspiration and who has spent many hours to debug and fix some really tricky issues.

As you might know Steffen Kamper and I joined the TemplaVoilà team some time ago and since Dmitry wasn’t very motivated to maintain the extension anymore, we took over and tried to make TemplaVoilà ready for TYPO3 4.3 (see Dmitry’s clarification below). We also tried to get rid of the over 250 listed bugs from bugs.typo3.org. This went fine for quite some time and we released version 1.4.0 and 1.4.1 in November parallel to TYPO3 4.3. Unfortunately the release come a little too fast for us and a couple of major bugs couldn’t be fixed by that time. After that release we had a meeting with Dmitry and we all agreed to release 1.4.2 in the beginning of January. We found and fixed tons of bugs and also implemented long awaited features in the meantime. We also had the luck that others found new motivation and started to send feedback and started to test TemplaVoilà with us. (Special thanks to Uschi, Jeff and Ron).
Three weeks ago we decided that the current state is “ready to release” and we told Dmitry that it’s up to him to release 1.4.2. Quite some time passed by and today he used several channels (Twitter, Facebook and Newsgroups) to tell the world what he found:

No TV 1.4.2 release soon. Found a bug in page module with unlinking in 1 minute after starting tests. I am severely disappointed by this

He was right – a very obvious bug showed up in the page-module within TYPO3 4.2. Unfortunately nobody saw it and it also seems that some of us are still unable to reproduce it. Anyways — in my opinion — he choose the wrong way to communicate that. Instead of talking to Steffen and me, he decided to talk to anyone else. I wrote him a mail and told him that I didn’t like the way he brought this up and asked for a Skype meeting to discuss how to proceed. After serveral emails back and forth and after others joined the communication, Dmitry decided (without anyone of us asking for it) to leave the team and hand over the leadership. To make it clear to everyone: the discussion started because of one JavaScript error and a few icons in the backend which he didn’t like very much. The Skype meeting never happend – although it would have saved lot’s of time and confusion for all of us.

I’m not very happy with his decision, because this leaves lot’s of questions and because we loose a very diligent developer. But it seems that there’s currently no way to convince him that he might be wrong.

As team Steffen and I will try to continue the development and improvement of TemplaVoilà, especially because it’s one of the most important benefits TYPO3 can offer. I ask everyone to join and contribute some time for testing or feedback. I dislike Dmitry’s approach to fork TemplaVoila and host it somewhere else (see Dmitry’s clarification below). I’m inviting him to rejoin the team at any time and work in a constructive way with us. I’m still convinced that all this just happend because miscommunication and not because of “real” issues.

—
In addition it also seems that others offended Dmitry and asked him not to stop the process anymore – I understand his distraction. He did a very good job in the past, he was open for our improvements and his biggest concern was quality not power or money or anything. Being offended for something you do in your freetime without any payment and being offended by people, who earn money from their clients with your (free) work, is always distracting. Please think about that in future communications with any open source software developer.

—
If you wonder how to get in touch with us: http://bugs.typo3.org lists all known bugs and their status. Report new bugs there or try to add new information to existing ones. Team discussion, in regards to fixed bugs or new features, happens, compareable to the TYPO3 Core, in the “typo3.team.templavoila” list on “lists.typo3.org”. If you need regular feedback or help with TemplaVoilà please use the “typo3.projects.templavoila” list.

—
* Update 05.03.2010: After I posted that the link to that blogpost on Facebook, Dmitry commented it and just to be fair, that’s what he said:

Thanks for your post. It is fair and explains the situation well. I would only clarify two moments: (1) I am not forking TV but creating a version for myself. I do not plan to release it to TER or anywhere. It is a TV for me as personally I like it (2) “Dmitry wasn’t very motivated to maintain the extension anymore” is not exactly so, rather to my taste TV already did all it had to do. I invited others to move TV further because I did not need anything else from it. Thanks again.

The list of things which happend in 1.4 can be seen on bugs.typo3.org (preselected filter). The following list contain my favorite fixes which happened unter the hood:

1) Delete content within the pagemodule (instead of unlinking)
By default you will still see the “unlink” icon within the pagemodule but one small setting within User- or PageTSconfig will show up delete buttons as well. There are two modes:
mod.web_txtemplavoilaM1.enableDeleteIconForLocalElements = 1
will show unlink and delete icons for local elements side-by-side
mod.web_txtemplavoilaM1.enableDeleteIconForLocalElements = 2
will show the delete icon and hide the unlink icon whenever possible.

Details: http://bugs.typo3.org/view.php?id=6869

2) Skip edit screen after a new content element was created
Especially for container items it’s anoying that the TYPO3 edit screen opens up after such an item was created. The setting noEditOnCreation within the meta configuration part of your datastructure can be used to change that.

Details: http://bugs.typo3.org/view.php?id=8079

3) Hide TemplaVoila field values and cleanup the pagemodule
Another problem within large projects is a messed up pagemodule. Very often the field data of flexible content elements shows up without any chance to hide it. Use  disableDataPreview within the meta configuration part of your datastructure to change that.

Details: http://bugs.typo3.org/view.php?id=11520

4) Define default record values
A proper setup contains good default values. Within datastructures you can define default values for your flexform-fields and from now on TemplaVoila also provides the possibility to define default-values for the fields of the parent record. The “default / TCEForms / <fieldname>” parts within the meta configuration part of your datastructure does this. Very useful usage for container elemente is:

<meta type=”array”>
<langDisable>1</langDisable>
<default>
<TCEForms>
<sys_language_uid>-1</sys_language_uid>
</TCEForms>
</default>
</meta>

Details: http://bugs.typo3.org/view.php?id=8759

There’s also a completly new “New content element”-wizard which can be configured with PageTSConfig – this wizard brings some additional feature for default-value configuration. I’m going to bring that up in another post soon.

5) sectionCount / sectionPos register in TypoScript
Rending fields which are nested in sections is not always fun. Expecially when it comes to position detection for the current item. Two new registers try to help in such situtations:

tx_templavoila_pi1.sectionCount holds the overall amount of items within the current section
tx_templavoila_pi1.sectionPos holds the position of the curren titem -starting with 1

Example:
10 = TEXT
10.value = (last item)
10.if.equals.data = register:tx_templavoila_pi1.sectionPos
10.if.value.data = register:tx_templavoila_pi1.sectionCount

Details: http://bugs.typo3.org/view.php?id=7263

noEditOnCreation

new page wizard

That’s pretty easy just paste this into the Page TSConfig of your rootpage and you’re done:
mod.web_list.newPageWiz.overrideWithExtension >
Now you might wonder how TemplaVoila knows what template it should use to render the page – but due to the TV’s default behaviour to inherit the page-template this should not be a problem if there’s at least a TemplaVoila page template assigned for your root-page.

But honestly you should just upload a thumbnail and write some sentences about your page-templates – this should raise the user’s happiness more than just disabling the wizard.