Die Überschriften in TYPO3 umzubenennen, so dass die Bezeichnungen für den Redakteur sprechender sind, ist recht einfach. Dazu braucht man folgenden Schnipsel im User oder Page-TS Config:

TCEFORM.tt_content.header_layout {
	altLabels.1 = H1: groß und blau
	altLabels.2 = H2: groß und schwarz
	altLabels.3 = H3: mittel und blau
	altLabels.4 = H4: mittel und grau
}

Natürlich wäre es schön, wenn die Überschriften im RTE auch die entsprechenden Bezeichnungen hätten, dazu einfach folgendes in die RTE Konfiguration rein und schon klappts (allerdings seit TYPO3 4.3).

RTE.default {
...
	buttons.formatblock.items {
		h1.label = H1: groß und blau
		h2.label = H2: groß und schwarz
		h3.label = H3: mittel und blau
		h4.label = H4: mittel und grau
	}
...

Über einer Navigation in der linken Spalte soll der Titel der übergeordneten Seite aus Level 1 dargestellt werden. Da im Web keine Silbentrennung existiert, habe ich mir gedacht, dass das Wort inklusive Silbentrennung in den subtitle geschrieben wird. Wenn das Feld subtitle befüllt ist, dann soll statt titel der Inhalt von subtitle ausgegeben werden. Hier ist mein TypoScript:

lib.navigation.sub = COA
lib.navigation.sub.10 = TEXT
lib.navigation.sub.10 {
	data = levelfield: 1, title
	wrap = <h3>|</h3>
	override.required = 1
	override.data = levelfield: 1, subtitle
}

Ich hatte die letzten zwei Mal schwierigkeiten die neueste TYPO3 Version 4.5.x auf Localhost (XAMPP) zu installieren. In XAMPP ist der Datenbank-User, der bereits eingerichtet ist root ohne Passwort. Solange man lokal arbeitet ist es ja auch in Ordnung. Im Install-Tool kann man das Feld Passwort nicht einfach frei lassen, da es erforderlich ist. Also überspringe ich den 1-2-3-Modus und will die Datenbankzugangsdaten selbst in localconf.php eingeben. Das funktioniert aber auch nicht – TYPO3 Install Tool meldet noch immer “Keine Verbindung zur Datenbank”. Ich versuche einen neuen Datenbank-Benutzer über phpMyAdmin anzulegen – mit Passwort – und trage die Daten dann in localconf.php ein. Immer noch kein Erfolg. Nachdem ich schließlich den Datenbank-Namen in die Konfigurationsdatei geschrieben habe und eine Fehlermeldung auftauchte “ADONewConnection: Unable to load database driver”, hatte ich zumindest eine Fehlermeldung, nach der ich Suchen konnte.

Meine Recherche ergab, dass die Fehlermeldung auftaucht, wenn die Extensions adodb und dbal installiert sind, aber nicht korrekt konfiguriert sind (Quelle jweiland.net). Da es aber eine ganz neue TYPO3 Installation ist, konnte ich noch keine Extensions manuell aktivieren, also ist das wohl die Standardkonfiguration. Um die Extensions zu deaktivieren, habe ich in der localconf.php in der Extension Liste (extList) den Eintrag dbal entfernt. Und siehe da, es funktioniert sofort und die Verbindung zur Datenbank steht.

(attach object errors to a specific field)

Es gibt die Möglichkeit in Extbase Validatoren für Objekte zu definieren. Wenn man also ein Model mit dem Namen “Domain_Model_ObjectModel” hat, wird falls vorhanden der Validator mit dem Namen “Domain_Validator_ObjectValidator”. Dabei wird nachdem die einzelnen Felder geprüft wurden mit dem angegebenen Validator das komplette Objekt überprüft. So kann man wie in meinem Beispiel feststellen, ob der Titel bereits vergeben worden ist (Unique). Normalweise wird die Fehlermeldung bei einer nicht erfolgreichen Validierung an das Objekt drangehängt. Da ich die Fehlermeldungen neben dem Feld ausgebe (siehe dazu Fehlermeldung mit Fluid direkt neben dem Feld ausgeben), wollte ich den Fehler an das Attribut title dranhängen.

class Tx_MyExtension_Domain_Validator_ObjectValidator 
	extends Tx_Extbase_Validation_Validator_AbstractValidator
{
 
    /**
     * Check if there is a object with the same name
     * @param  Tx_MyExtension_Domain_Model_Object $object
     * @return bool
     */
	public function isValid($object) {
		$objectRepository = t3lib_div::makeInstance('Tx_MyExtension_Domain_Repository_ObjectRepository');
		$sameNameCount = $objectRepository->countByTitleExcludeUid($object->getTitle(), $object->getUid());
		if($sameNameCount > 0) {
			if (!isset($this->errors['title'])) {
				$this->errors['title'] = new Tx_Extbase_Validation_PropertyError('title');
			}
			$error = new Tx_Extbase_Validation_Error(Tx_Extbase_Utility_Localization::translate('error.object_title_exists', 'MyExtension'), '1312448731');
			$this->errors['title']->addErrors(array($error));
			return FALSE;
		}
		return TRUE;
    }
 
}

Am 1. und 2. Oktober fand in Frankfurt am Main die 10. TYPO3 Konferenz (T3CON) statt. Nach der offiziellen Konferenzeröffnungsrede, bei der auch einige Mitglieder der Community ausgezeichnet wurden, hielt Kasper Skårhøj, der Erfinder von TYPO3 eine unterhalsame Präsentation, die sich vor allem mit der Entwicklung der Community in den letzten Jahren befasste. Er zeigte einige Webseiten bekannter Marken und Hersteller, die alle mit TYPO3 umgesetzt worden sind und zeigte Anhand von anschaulichen Grafiken die weite Verbreitung von TYPO3 in Deutschland.

Da mich die Entwicklung der neuen TYPO3 Version 5 (Codename Phoenix) und des dazugehörigen Frameworks FLOW3 besonders interessiert, habe ich mir viele Vorträge zu dem Thema angeschaut. Beim Vortrag “The current state of TYPO3 Phoenix” von Robert Lemke (einer der Hauptentwickler von Phoenix) wurden viele der neuen Entwicklungen vorgestellt, meistens anhand von beeindruckenden Beispielen – so z.B. der neue Editor Aloha, das User Interface und die Security Implementation.

Eintrag weiter lesen »

Nachdem ich im Juli die Prüfung abgelegt habe und lange gewartet habe, nun die freudige Nachricht – ich bin Certified TYPO3 Integrator. Ich fand die Prüfung nicht einfach, die Fragen waren schon sehr kniffelig, manche so einfach, dass man daran zweifelt, ob man die Frage richtig verstanden hat. Manche so schwer, dass ich fast raten musste, was von den mehreren Antworten möglich sei. Dann noch die Schwierigkeit, dass man nicht weiß, wie viele Antworten denn nun richtig sind. Aber das Warten und Bangen ist endlich zu Ende – Juhuu!

Der Service metaExtract für DAM sucht alle möglichen Informationen aus den Meta-Daten des PDFs raus, aber irgendwie wird der Titel ignoriert. Dieser ist (aus dem Adobe PDF Reader) über Dokument > Eigenschaften (oder auch Strg + D) im Tab Beschreibung zu finden. Ein Blick in den Service hat ergeben, dass es nicht vorgesehen ist, den Titel aus dem Dokument als Titel des Datensatzes zu übernehmen. Abhilfe schafft die kleine Zeile Code in der Klasse des Service:

switch ($name) {
// neu ab hier
	case 'Title':
		$this->out['fields']['title'] = $value;
	break;
// bis hier
	case 'Producer':
		$this->out['fields']['file_creator'] = $value;
	break;

And it works!

Eingentlich ist das kein Voodoo, wenn mans weiß. Zunächst mal befand sich ein Hinweis darauf, dass es möglich ist, Inhalte aus PDFs beim Extrahieren in die Datenbank zu schreiben, um z.B. danach zu suchen, in diesem Artikel auf t3n: Digital Asset Management mit TYPO3.

Dann fand sich im Manual des DAM Indexers (dam_index) ein Hinweis, dass es eine Liste der Services gibt. Ich habe allerdings ein wenig gesucht, bis ich diese Liste gefungen habe. Dazu im Modulmenü (linke Spalte) auf Media > Tools klicken und dann (wenn nicht bereits ausgewählt), im Drop Down oben Indexing Setup auswählen, dort bekommt man dann eine Ansicht, wie im Manual zu dam_index beschrieben.

Da man ja nun weiß, dass der Service textExtract heißt, braucht man nur im TER danach zu suchen und findet die Extension cc_txtextexec. Diese Extension muss man installieren und dann den Indexer erneut laufen lassen, dabei ist wichtig, den Haken bei reindex zu setzen.

Im BackEnd steht die Konfiguration aus dem Setup nicht zur Verfügung. Daher muss man sich alles selbst zusammenbauen. Die Konfiguration bezieht sich natürlich auf eine Seite, die dem PageObject mitgegeben werden muss, damit die Konfiguration richtig ausgelesen werden kann.

$sysPageObj = t3lib_div::makeInstance('t3lib_pageSelect'); 
$rootLine = $sysPageObj->getRootLine($pageId);
$TSObj = t3lib_div::makeInstance('t3lib_tsparser_ext');
$TSObj->tt_track = 0;
$TSObj->init();
$TSObj->runThroughTemplates($rootLine);
$TSObj->generateConfig();
$subject = $TSObj->setup[...];

Evtl. könnte auch dieser Eintrag von mir interessant sein: Neuer Name für Page Select
Quelle: old.nabble.com

Seit TYPO3 Version 4.2.X heißt die Klasse, die ein Seitenobjekt repräsentiert zwar immer noch pageSelect, liegt aber nicht wie zuvor in der gleichnamigen Datei, sondern in t3lib_page.php. Das hat zur Folge, dass wenn man ein Objekt der Klasse erzeugen möchte, man zunächst die Datei richtig inkludieren muss.
Vorher hat also das ausgereicht:

Nun ist auch das notwenig (wobei der Pfad zu t3lib auch in einer anderen Variable stecken kann, in meinem Kontext war nur diese verfügbar):

Mein Vorschlag ist, zu prüfen, ob die Datei t3lib_page.php exisitert und diese bei Bedarf zu laden, so sollte das Erzeugen des Page Objektes sowohl in alten als auch in neuen TYPO3 Versionen funktionieren.

UPDATE:
Gleiches Problem bei den Basic file funcitons: