the fancy part of the web

Handling data in TYPO3 with tcemain

TYPO3 is (by definition) a powerful tool when it comes to data. Besides creating, updating and deleting data there are also localizing and versioning, logging and even rollbacks. All this is provided through the GUI of TYPO3 and all the technical stuff in working under the hood of TYPO3 for nearly every piece of data. But what if you’re asked to write a script which imports or updates data, how can you make sure that all this is done in a TYPO3 compatible way?

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.

crawler extension version 3.0.5 released

Quite some time after the 4.3 release of TYPO3, we published the necessary compatibility version of the crawler extension. Besides the compatibility fixes for TYPO3 and also for PHP 5.3 we also included some handy features:

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.

Debugging mod_rewrite… my favorite way

Once a month someone is asking because he has issues to get his mod_rewrite rules to do what he want’s. Writing the rules and the required RegEx for these rules is quite easy, but Apache still behaves strange every now and then and that’s where one of my favorite ways to “debug” mod_rewrite comes in very handy. And I felt that writing something is better than having a silent blog

The following block is what it’s all about. It seems to have it’s origin on WebmasterWorld and Rob Russel’s Blog and looks basically like this:

RewriteCond %{QUERY_STRING} !vardump
RewriteRule (.*) http://www.example.com/$1?vardump&reqhost=%{HTTP_HOST} [R=301,L,QSA]

Pretty easy and quite nice. The first line just prevents recursion, so that you’ll be able to see the first redirect and nothing else. The second line is where you can place in every information you’d like to check. The [R=301,L,QSA] makes sure that you can debug without interruption. The “R=301″ makes sure the browser doesn’t start a second request, but tells him that the location was changed, the “QSA” makes sure that the querystring isn’t lost and the “L” prevents that your server performs other redirection rules.

As shown the first block already unveils some information and places it into the redirection URL, so you could use it to check what the value of HTTP_HOST is and you also know whether mod_rewrite works or not. This way you can debug every variable mod_rewrite offers and you can check environmental variables and results of the regular expressions.

If you’d like to know whether a specific RewriteCond is working or not just place it in that block and you’ll see if it’s still redirecting or not, like this (via):

RewriteCond %{QUERY_STRING} !vardump
RewriteCond %{HTTP:Accept-Language} ^de.*$
RewriteRule (.*) http://www.example.com/$1?vardump&languageMatchedDE [R=301,L,QSA]

Checking a regular expression from an RewriteCond looks like this (used on a server with a pretty strange setup for %{DOCUMENT_ROOT}):

RewriteCond %{QUERY_STRING} !vardump
RewriteCond %{REQUEST_FILENAME} ^(.*\/htdocs\/).*$
RewriteRule (.*) http://www.example.com/$1?vardump&reqfilename=%1 [R=301,L,QSA]

As you see that’s a pretty handy way to debug lot’s of mod_rewrite stuff, it helped me quite often and I hope it does the same for you

TYPO3 4.3 release

Today the TYPO3 Core Team released version 4.3 (release-notes on typo3.org).

Finally the list of improvements is long and the amount of cool new features is outstanding compared to other releases. Imho especially the security and performance-improvements are remarkable as well as the improved usability in the backend. But I guess my favorite improvement is obvious (hint hint)

In addition to TYPO3 4.3 a new major version of the tt_news (ter) extension was released over the weekend (Rupert Germans announcement on lists.typo3.org) and the already mentioned release of TemplaVoilà (ter) was somehow releated as well.

The next TYPO3 release is planned for May 2010… we’ll see if that happens in time

TemplaVoila 1.4 released…

A new version of  TemplaVoila (ter) (forge) has just been released. Besides the great fact that this is the first team-release of TemplaVoila, the high-level improvements within the pagemodule (drag’n'drop),  the mapping module and the FCE editing forms and besides lot’s of bug fixes, there are a few very nice features which make the day-to-day work with TemplaVoila much easier.

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