As extension maintainer there are several ways to use these new parts of the API you can either just use it to display core icons, you can include your own icons and retrieve it with the new API or you can include your own sprite and retrieve the separate icons.

Use sprite icons

Using sprite icons is pretty easy, to get a checkmark icon you could use this:

t3lib_iconWorks::getSpriteIcon('status-dialog-ok');

The list of all available icons can be retrieved using the ‘spriteiconoverview‘ extension which I just recently pushed into the TER

Add your own icons

The API also provides the possibility to include your extension’s icons using either single icons or your own icon sprite.
Using single icons can be done with the following code in your ext_tables.php or ext_localconf.php:

$icons = array(
     'myicon' => t3lib_extMgm::extRelPath('myextension') . 'myicon.gif'
);
t3lib_SpriteManager::addSingleIcons($icons, 'myextension');

Using this icon is easy again:

t3lib_iconWorks::getSpriteIcon('extensions-myextension-myicon');

If your extension comes with a larger amount of icons you might want to use your own sprite. This includes your sprite as a image file and a CSS file. The css file should look like this:

.t3-icon-extensions-myextension {
     background-image:url(../../typo3conf/ext/myextension/myextension_sprite.gif);
}
.t3-icon-extensions-myextension-icon1 {	background-position: 0px 0px; }
.t3-icon-extensions-myextension-icon2 {	background-position: 0px -16px; }

The path to your sprite needs to be relative to the typo3temp/sprites/ folder, from where the (temporary) merged CSS file will be included.
This sprite can be included using:

$icons = array(
     'extensions-myextension-icon1',
     'extensions-myextension-icon2'
);
t3lib_SpriteManager::addIconSprite(
     $icons,
     t3lib_extMgm::siteRelPath('myextension') . 'myextension_sprite.css'
);

As you see it’s quite easy to include the new API, the API provides some further options for overlays and further modifications which I didn’t mention here. And as a final motivation this is a comparison between old and new API to get a “back” button:

// old API
$icon = '<img' . t3lib_iconWorks::skinImg($this->doc->backPath,'gfx/goback.gif','width="14" height="14"') . 'alt="" />';

// new API
$icon = t3lib_iconWorks::getSpriteIcon('actions-view-go-back');

—-
The sprite API is quite new and my knowledge about how to use it is also relatively fresh – so please let me know if you’ve any remarks or questions.
Btw. special kudos for his involvement during the implementation of this nice feature and many many thanks for helping me to understand it, to Steffen Ritter
—-
Further reading:

• If you’ve never heard of sprites you might want to read this article an alistapart.com
• TYPO3 4.4 release notes
• news.typo3.org – T3DD10: It’s all about sprites
• spriteiconoverview extension

—-

Feel free to Flattr this post at flattr.com, if you like it.

Btw. at the beginning I didn’t belief that a Git workshop could fill 4 hours – now I don’t think that shorter workshops make any sense

Feel free to Flattr this post at flattr.com, if you like it.

There are basically 2½ different tasks during the “daily” development.

0. Create a local working copy a.k.a clone the repository
1. Fix a bug or implement a feature and create a patch file with the changes
2. Receive a patch and review it – eventually commit the changes

0. Repository initialization

Getting started and creating the repository from an existing Subversion repository looks like this:

mkdir templavoila
cd templavoila
git svn init -t tags -b branches -T trunk https://svn.typo3.org/TYPO3v4/Extensions/templavoila
git-svn fetch

This will pull the entire SVN history into your local Git repository – use “git-svn fetch -r ” to reduce the amount of imported revisions.

To keep your repository up-to-date you need these commands:

git stash
git-svn fetch
git rebase trunk
git stash apply

If you followed the SVN trunk/tags/branches convention you should see that it also finds tags and branches during the import. But using “git branch” afterwards you’ll see that there’s only one local branch called “master”. That’s where Git shows it’s strength the first time, because it distinguishes between local and remote branches. Work can only be done within local branches, whereas the existing SVN branches are only recognized as “remote” branches so far. To list all remote branches you can use “git branch -r”. If you followed the trunk/tags/branches convention, you should see your SVN tags and branches within this list – otherwise you might want to read [8]. To make a remote (SVN) branch available in your local repository use:

git checkout --track -b tv_1-4 templavoila_1-4

1. Working with the repository

Starting to work on a new feature or a bug always starts with a new branch in git:

git branch issue00012345
git checkout issue00012345

You’re now working in the “issue00012345″ branch and all commits will just be committed to that branch. Once you made changes you can either just commit all modifications with:

git commit -a

or add particular files and commit only these files with:

git add fileA
git add fileB
git commit

or with a nice pre commit preview which lets you decide which lines you want to commit:

git add --patch
git commit

Preparing the patch for the mailingslist:
In a pure Git workflow “git format-patch” is used to communicate patches, but due to the fact that there’s a Subversion repository involved either the old style diff / patch or a workaround needs to be used to communicate changes.
Creating a patch which works for the mailinglist can basically be done using:

git diff --no-prefix master > myPatchFile.patch

An alternative workaround to create proper SVN diff files (including svn revision etc..) can be found in [10] it’s used very straight forward:

git svn-diff > mySvnPatchFile.patch

2. Review and commit patches

Reviewing the patch someone sent to the list:
As “usual”

patch -p0 < myPatchFile.patch

can be used to apply patch files.

Once the files passed the review the changes can be committed using “git add” and “git commit” as shown before.

Committing to Subversion:
Once you committed everything to your local repository you’re able to perform this command to “forward” your commits to the Subversion repository.

git svn dcommit

Practically every single commit within git will also be reflected as a single Subversion commit. For several reason this might not always suit your situation.As a workaround you could merge all commits during the merge of your feature branches into the master branch using:

git merge --commit --squash issue00012345
git svn dcommit

Of course I don’t recommend to do this for your regular work since have small granular commits is always better.

Sources and further reading

[1] Patch-oriented development made sane with git-svn
[2] An introduction to git-svn for Subversion/SVK users and deserters
[3] Git – SVN Crash Course
[4] Getting the GIT checkout
[5] An Illustrated Guide to Git on Windows
[6] git svn workflow –
feature branches and merge
[7] whygitisbetterthanx.com
[8] Multiple branches using git-svn
[9] Effectively using Git with subversion
[10] Git Workflow with Upstream SVN

Notes

• Don’t try to dcommit to https://svn.typo3.org/TYPO3v4/Extensions/templavoila unless you know what you’re doing – I just used it to show you that it’s even working with large history projects.
• For projects hosted on forge.typo3.org there might be a native git support soon – stay tuned
• Let me know if you had problems with any of the snippets
• Further information about the review process for the TYPO3 Core and several other TYPO3 related projects can be found on typo3.org

Feel free to Flattr this post at flattr.com, if you like it.

The good news is that these times are over and that some important changes to improve workspace handling are planned for
the upcomming TYPO3 4.5 (read more on TYPO3.org) and the cool news is that I was lucky enough to be part of that team and that I was able to attend a great “kickoff” meeting two weeks ago.

What changes we plan can be found on TYPO3.org, a detailed protocol of the meeting can be found here in addition.

I’m happy to be part of that and I hope everyone on the team can keep up his/her motivation.

Feel free to Flattr this post at flattr.com, if you like it.

Just to keep this blog alive this is what I found interesting during the last weeks:

For TYPO3 enthusiasts especially the changes within the TYPO3 Core regarding the integration of further T3UX09 results and all the small changes which happen to get 4.4 ready might be of the biggest interest (https://svn.typo3.org/TYPO3v4/Core/trunk/ChangeLog). Besides that Sebastian Kurfürst tweeted that he finished the last chapter of his Extbase/Fluid book and Amazon says that they deliver it in the first weeks of July. I think once his book is out we’ll see much more people starting to work with Extbase and Fluid.
It also seems that the TYPO3 v5 project — called “Phoenix” — is getting more and more relevant. They decided to scrumify the delvelopment and started to do Sprints to achieve quick and visible results. Sounds like a good way to go – let’s see how long they keep that up. Besides that there’s also an interesting mail Robert Lemke posted in a newsgroup to answer the rumors about the why v5 takes so long and why they had to start from scratch and so on – very interesting statements.

Besides that you might like these bits and bytes:

• Sebastian Bergmanns “testing untestable code” series
• CSS3 browser compatibility checklist
• TYPO3 4.3 Treasure Trove: the system registry

Feel free to Flattr this post at flattr.com, if you like it.

Besides that, Kasper just released the podcast with me talking about version 3.0 of the crawler and about further improvements for the staticpub extension. You’ll find that on typo3.org/podcasts/kasper.

Feel free to Flattr this post at flattr.com, if you like it.

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.

Feel free to Flattr this post at flattr.com, if you like it.

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.

Feel free to Flattr this post at flattr.com, if you like it.

The lazy programmers approach is to write up SQL, but that’s not what’s recommended if you still want the full TYPO3 featureset to be available for you (without reinventing the wheel). In this case the TYPO3 core class tslib_tcemain (short tcemain) is what you’re looking for. For the mentioned tasks there are two main functions relevant – process_cmdmap() and process_datamap(). The process_cmdmap() performs actions like “move”, “copy”, “localize”, “version” (create, stage, swap, flush), “delete” and “undelete”. The process_datamap() does the rest – creating records, updating datafields. Controlling both of them is done with configuration arrays and that’s how it looks like**:

Creating a record*:

$data = array();
$data['tt_content']['NEW'] = array(
	'pid' => 100,
	'header' => 'A new thing'
);

$tce = t3lib_div::makeInstance ('t3lib_TCEmain');
$tce->start ($data, array());
$tce->process_datamap ();

echo "The new element has the uid ".$tce->substNEWwithIDs['NEW'];

Creates a new tt_content record on page 100 with the header set to “A new thing”.

Updating data*:

$data = array();
$data['tt_content']['110'] = array(
	'header' => 'A really new thing'
);

$tce = t3lib_div::makeInstance ('t3lib_TCEmain');
$tce->start ($data, array());
$tce->process_datamap ();

Updates the header field of the content element with the uid 110 to “A really new thing”.

Move data from one page to another*:

$cmd = array();
$cmd['tt_content']['110']['move'] = 101;

$tce = t3lib_div::makeInstance ('t3lib_TCEmain');
$tce->start (array(), $cmd);
$tce->process_cmdmap ();

Moves the tt_content record with the uid 110 to the page 101.

Copy data from one page to another*:

$cmd = array();
$cmd['tt_content']['110']['copy'] = 101;

$tce = t3lib_div::makeInstance ('t3lib_TCEmain');
$tce->start (array(), $cmd);
$tce->process_cmdmap ();

Copythe tt_content record with the uid 110 to the page 101.

Localize your record*:

$cmd = array();
$cmd['tt_content']['110']['localize'] = 5;

$tce = t3lib_div::makeInstance ('t3lib_TCEmain');
$tce->start (array(), $cmd);
$tce->process_cmdmap ();

This creates a localization for the language 5 of the tt_content record with uid 110 (assuming that the tt_content record 110 is a default language record).

Delete*:

$cmd = array();
$cmd['tt_content']['110']['delete'] = true;

$tce = t3lib_div::makeInstance ('t3lib_TCEmain');
$tce->start (array(), $cmd);
$tce->process_cmdmap ();

Deletes the tt_content record with the uid 110.

Undelete*:

$cmd = array();
$cmd['tt_content']['110']['undelete'] = true;

$tce = t3lib_div::makeInstance ('t3lib_TCEmain');
$tce->start (array(), $cmd);
$tce->process_cmdmap ();

Restores the tt_content record with the uid 110 – if it’s deleted.

—-

* Running the codes requires a TYPO3 backend context with a logged in backend user who has the right to perform all these actions. In addition tcemain has some configuration options to change the behaviour of the actions, e.g. “$enableLogging” or “$bypassWorkspaceRestrictions” – they come with useful defaults but you might need to change them in certain situations ~ so looking into the code documentation might save you some time.

** I left out the “version” part since this requires some more explanation than just a few lines of code.

Feel free to Flattr this post at flattr.com, if you like it.

First of all there’s now, besides the CLI interface, also a full integration with the scheduler extension, which is available in TYPO3 4.3. This enables to setup crawler runs and manage all crawler releated tasks through the TYPO3 backend.

The “crawler_flush” interface was added to the CLI (and scheduler). It helps to clean up the crawler queue and enables to remove finished or unfinished entries.

In addition the CLI was cleaned up a little bit and behaves more intuitive in most situations. Also the help pages should now really tell you what options you have.

And last but not least we’ve added the possibility to avoid an additional HTTP request and have the crawler rendering the page directly.

Big kudos for their work and their support goes especially to Mick, Fabrizio and Timo from AOE media.

Feel free to Flattr this post at flattr.com, if you like it.