David Smeringe weblog

If you need a ‘create new record’ link in BE of TYPO3 and also need to supply some default values, this is the way;

So, what we do is setting up necessary parameters for alt_doc.php to perform cmd actions. In this example I use;

edit[table name][uid OR pid OR -uid]=command – use uid and the command edit to edit a uid, otherswise (as I do  above) use pid and new as command to create a new record in a certain pid. A negative uid together with the new command Creates a new record right after the supplied uid.
defVals[table name][table column]=value – two times. This sets default values for my two fields; name and codename.

Then assemble the parameters with the TYPO3 API call t3lib_BEfunc::editOnClick(); into a javascript call.

I can honestly say that I’m no expert in the typoscript part of TYPO3. I realised this when I tried to find a solution on not using the Hx <-> <typohead..> tag transformation with the RTE. Took me hours to find the solution, but as mostly with typoscript, it’s quite simple. The brutal way was to add a pageTSConfig

RTE.default.proc.typohead = 0

But that just disables the use of typohead right off, breaking all current content on the site. And when reading a bit more I realised that what I really wanted was to use another transformation method than the default set for tinyrte;

RTE.default.proc.overruleMode = ts_css

This nicely allows the typohead tags stored in DB to be there, get transformed to Hx when opened with the rte and then when saved, never seen again

The overruleMode sets the general transformation mode that the rte should use, and afaik ts_css is to be the modern way of transforming data. The ts_css mode is actually a meta mode for a bunch of transformation rules. See the RTE reference for in depth know how about that.

I’ve become a father once again, and once again it was a boy! a truly lovely one as well. See some pictures (“bäbis 08″) at http://people.merea.se/david/site/index.php?id=23

Just for the nerd fun of it and for that I really like the look n feel of my desktop right now – here’s screen dump of my every day ubuntu environment..

TemplaVoila is an incredibly smart tool for templating your TYPO3 website. However it cannot only be used for pages and fragments of pages (FCE:s), but also for templating your own extensions output.

The classic way of adding template support for an extension has been to use an HTML file marked with tags like

or similar that would be replaced by content using the cObj function substituteMarkerArrayCached:

Which is a quite simple and easy to use approach. The TemplaVoila way quite similiar. Let me show you a short example more or less cut from the mininews extension with a few simplifications for us mere mortals;

First off we will load up TV with a hard coded TO (Template Object) record uid. I suggest using some kind of FlexForm setting or similar for that This part normally goes into an init() function or so;

What the code above does is checking if TV exists, instantiates the templavoila HTML markup utility class (tx_templavoila_htmlmarkup), loads a TO record with uid one into it and finally sets some HTML header taggings..

Sooo, we got ourself a loaded TO with HTML template contents and also since TO always has a DS, we got the data structure fields (like field_mainMenu or similar). Next of is adding contents to where we’d like to have it. In our case into the field field_content mapped with TV.

That’s it!

Using TemplaVoila for an extension has many benifits, just as using it for normal page rendering. One of them is the possibility to easily map your template using Templavoila. I suggest that you supply a valid datastructure (DS) xml with your extension, that gets loaded as static ds (again taken from mininews);

For a more detailed documentation around TV and the source to inspiration for this article, see the TemplaVoila extension documentation (http://typo3.org/documentation/document-library/extension-manuals/templavoila/1.3.4/view/1/6/)

A short tip; If you’d like to have syntax highlight for your TypoScript code in jEdit on *.txt files (apart from *.ts),  then you would first install the TypoScript plugin, and then set (for instance) “First line glob” field under Global options to

//TSFILE

and type the same on the first line in you ts file. The next time you open it, it will highlight your code.  Simple and effective.

It was time to do another of those way to late updates. This time my WordPress installation (powering this blogg) was my target. Techie Buzz supplies a really neat update plugin that makes it safe and easy. Check it out

Although the auto update plugin was easy as a breeze to use, it wouldn’t hurt of having some more user friendly error handling when it gets write permission errors and such. They are handled but you get the feeling of being a bit stranded. I had some file writing permission problems.. 

I’m normally doing most of my work with or within the TYPO3 environment, and I must say that the clean and “just working” style of WP is a desirable target for the TYPO3 backend (and others) tool. Really neat.

Recently I wasn’t able to start up my Eclipse (vaugly remembering having an X-hangup – x-windows crach I mean). All I got was a small error dialog with a reference to eclipse log file containing huge traceback of java exceptions.. I didn’t have the time or energy to trace this so I swaped to jEdit for a while.

Sooner or later one has to deal with the problems. The later was today.. My method became deleting each plugin path under [workspace path]/.metadata/.plugins/

The solution was quite simple.. I removed the file .snap in the [workspace path]/.metadata/.plugins/org.eclipse.core.resources/ path and it started working again!

I’m no expert in how Eclipse handles it’s workspace data, but apparently I lost associated projects.. ..but that’s that not so tuff to add again.

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

Due to common confusion of TYPO3 and it’s current version it’s now set to be renamed to TYPO4.

That was a really funny April’s first joke (my kind of humor at least) 

When developing extensions for TYPO3 you often create one or more new tables and/or fields. Quite often you get an annoying report when updating or installing your extension in the EM that says something like:

• ALTER TABLE tx_tentipifr_fieldText CHANGE field_uid field_uid int(11) NOT NULL;
  or
• ALTER TABLE tx_tentipifr_fieldText DROP KEY parent;
• ALTER TABLE tx_tentipifr_fieldText ADD KEY parent (pid);

while the fields are actually just fine and untouched in your db since last update.
This is because the EM is quite strict to how your ext_tables.sql is formatted. Here is a solution to get rid of the two cases above (example from my ext_tables.sql file):

change

to

The integer field notice is fixed by adding DEFAULT ’0′ to the statement and the primary key drop ‘n add thing is fixed solely by removing an extra space right after the field name.

I think these or similar things are fixed or to-be-fixed, but I’m not sure. Just didn’t care to google it. Please let me know if it is so.