Hab mir das TYPO3 6.0 Government Package installiert. Als ich versucht habe, ein Inhaltselement anzulegen, kam folgende Fehlermeldung:

Call to undefined method TYPO3\CMS\Core\Utility\GeneralUtility::readLLXMLfile()

TYPO3 ist scheinbar in der Lage aus t3lib_div die korrekte Klasse zu ermittelt, aber der Funktionsname hat sich inzwischen geändert. Zwei Lösungsvarianten:

Datei typo3conf/ext/tt_news/pi/class.tx_ttnews_wizicon.php

Variante 1) Nur den Funktionsnamen ändern

function includeLocalLang()	{
	$llFile = t3lib_extMgm::extPath('tt_news').'locallang.xml';
	$LOCAL_LANG = t3lib_div::readLLfile($llFile, $GLOBALS['LANG']->lang);
	return $LOCAL_LANG;
}

Variante 2) Auch die Klassennamen ändern (mit Namespaces)

function includeLocalLang()	{
	return \TYPO3\CMS\Core\Utility\GeneralUtility::readLLfile(\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::extPath('tt_news') .
		'locallang.xml', $GLOBALS['LANG']->lang);
}

Habe mir TYPO3 Version 6.0 zum Anschauen installiert (XAMPP 1.8.1, Windows 7). Bisher funktioniert alles, außer dass beim Aufruf des Extension Managers der Apache abstürzt und eine leere Seite mit der Fehlermeldung angezeigt wurde, dass die Seite nicht geladen werden konnte. Hab dann ein bisschen gesucht und folgende Lösung gefunden, die tatsächlich schnell geholfen hat.
Ursache „Fluid uses complex regular expressions which require a lot of stack space during the first processing. On Windows the default stack size for Apache is a lot smaller than on unix. You can increase the size to 8MB (default on unix) by adding to the httpd.conf:“.

Also am Ende der httpd.conf-Datei folgendes einfügen und Apache neu starten:
ThreadStackSize 8388608

Quelle: Probleme beim Zugriff auf den Erweiterungsmanager typo3forum.net

Ich dachte, es wäre etwas einfacher, aber es funktioniert wohl (nur) so. Diese Funktion in die Repository-Klasse einfügen:

/**
* Return the current tablename
*
* @return string
*/
protected function getTableName() {
	return $this->persistenceManager->getBackend()->getDataMapper()->getDataMap($this->getRepositoryClassName())->getTableName();
}

Gefunden habe ich es beim TYPO3 Blogger Adventskalender von 2011.

Der große Vorteil von TemplaVoila ist die große Flexibilität bei den Templates. Wenn man nun ein Template erstellt mit z.B. zwei Spalten, bei denen die erste 600px und die andere nur 300px breit ist, ist es sehr schwer einen allgemeinen Wert für maximale Bildgrößen anzugeben. Zum Glück kann man im Data Structure die maximale Bildbreite für eine bestimmte Spalte überschrieben. Dazu in den TypoScript Abschnitt folgendes einsetzen:

<TypoScript>
<![CDATA[
5 = LOAD_REGISTER
5.maxImageWidth = 300
 
10= RECORDS
10.source.current=1
10.tables = tt_content
10.wrap = <!--TYPO3SEARCH_begin--> | <!--TYPO3SEARCH_end-->
 
15 = RESTORE_REGISTER
]]>
</TypoScript>

Die maximale Bildgröße wird dadurch in der Spalte auf nur 300px gesetzt. Hat man am normalen Verhalten bzgl. Bild in Text nichts geändert, dann ist in diesem Fall ein Bild im Text nur 150px breit.

Um Werte aus dem TCA im einenen Plugin zu verwenden, kann man die Funktion t3lib_div::loadTCA(‚fe_users‘) nutzen, um das TCA zu laden. Dann steht es unter $GLOBALS[‚TCA‘][‚fe_users‘] zur Verfügung und kann ausgelesen werden. Leider lädt diese Funktion nur die Felder, die im Core definiert sind. Wenn das TCA durch Extensions erweitert wird, sind diese Felder nicht darin gelistet. Warum das so ist, kann man im TYPO3 Bugtracker nachlesen.
Wenn mann stattdessen folgende Funktion verwendet, werden alle Felder inkl. der Felder aus den Extensions geladen:

$GLOBALS['TSFE']->includeTCA();

Nachdem ich es geschafft habe, dem Fluid Pagination Widget ein eigenes Template aufzuzwingen, musste ich nun weitere Anpassungen vornehmen. Da ich so viele Datensätze habe, umfasste meine Liste mit Seiten über 1000 Stück. Selbst wenn ich sie alle nebeneinander darstellen kann, ist die Blätterfunktion kaum zu gebrauchen. Ich wollte daher folgendes erreichen:
– konfigurierbare Anzahl der Seiten, die neben der aktuellen Seite angezeigt werden
– Link zu allerersten und allerletzten Seite
– falls Seiten übersprungen werden, sollte es erkennbar sein
Mein Ziel also:

Um das zu erreichen, habe ich zunächst den Controller angepasst: ich führe einen neuen Parameter ein (adjacentPagelinks), damit kann die Anzahl der Seiten neben der aktuellen Seite konfiguriert werden. In der Funktion buildPagination, die ich zunächst aus der PaginateController-Klasse von Fluid übernommen habe verarbeite ich den neuen Parameter. Die For-Schleife, die die Links zu den Seiten generiert, beginnt nun nicht mehr bei 1 und endet bei $this->numberOfPages. Stattdessen beginnt sie bei einer erreichneten $firstPage und endet bei $lastPage. Wenn $firstPage größer als 2 ist, dann wurde eine Seite übersprungen und es müssen Punkte (…) angezeigt werden. Das gleiche mache ich mit $lastPage.
Hier ist der komplette PaginationController-Code.

Es müssen natürlich Anpassungen im Template vorgenommen werden. Die im Controller gesetzten Variablen firstPage, spacerAfterFirst, lastPage und spacerBeforeLast müssen im Template entsprechend verarbeitet werden. Ein Auszug aus dem Code des Templates ist hier.

Nach langer Suche über Google bin ich schon fast verrückt geworden – es gibt viele Tipps, Fragen zu dem Thema, aber keine Antwort hat zu irgendwas geführt. Die beste Anleitung fand ich hier: Fluid-Pagebrowser. Nachdem ich sie befolgt habe, hat es immer noch nicht funktioniert, stattdessen bekam ich eine Fehlermeldung: „Sorry, requested view was not found“, genau wie im forge.typo3 beschrieben. Nach ein bisschen ausprobieren, habe ich nun die Lösung gefunden.

1) Zunächst muss der PaginationController erweitert werden. Dazu im Ordner Classes/ViewHelpers/Widgets/Controller einen Datei PaginateController.php erstellen. Darin steht folgendes:

<?php
class Tx_YourExt_ViewHelpers_Widget_Controller_PaginateController extends Tx_Fluid_ViewHelpers_Widget_Controller_PaginateController {
 
	/**
	 * @param Tx_Extbase_MVC_View_ViewInterface $view
	 * @return void
	 * @todo implement logic for overriding widget template paths (tx_extension.view.widget.<WidgetViewHelperClassName>.templateRootPath...)
	 */
	protected function setViewConfiguration(Tx_Extbase_MVC_View_ViewInterface $view) {
		$extbaseFrameworkConfiguration = $this->configurationManager->getConfiguration(Tx_Extbase_Configuration_ConfigurationManagerInterface::CONFIGURATION_TYPE_FRAMEWORK);
		$widgetViewHelperClassName = $this->request->getWidgetContext()->getWidgetViewHelperClassName();
		if (isset($extbaseFrameworkConfiguration['view']['widget'][$widgetViewHelperClassName]['templateRootPath'])
			&& strlen($extbaseFrameworkConfiguration['view']['widget'][$widgetViewHelperClassName]['templateRootPath']) > 0
			&& method_exists($view, 'setTemplateRootPath')) {
			$view->setTemplateRootPath(t3lib_div::getFileAbsFileName($extbaseFrameworkConfiguration['view']['widget'][$widgetViewHelperClassName]['templateRootPath']));
		}
	}
 
}
?>

Der Klassenname enthält den Namen der Extension, also muss Tx_YourExt entsprechend angepasst werden. Der Inhalt dieser Klasse ist das Diff aus dem Ticket im Forge, in dem die Template-Problematik im Paginate Widget besprochen wird.

2) Dann muss ein Template für das Paginate Widget erstellt werden. Dazu am besten die entsprechende Datei aus dem Fluid-Ordner kopieren, individualisieren und anpassen. Template für Paginate Widget in Fluid ist in typo3/sysext/fluid/Resources/Private/Templates/ViewHelpers/Widget/Paginate. Das Template wird kopiert nach Resources/Private/Backend/Templates/ViewHelpers/Widget/Paginate im Extension-Ordner.

3) Dann muss in der Konfiguration einmal die Klasse des Pagination Widgets mittels Dependancy Injection gesetzt werden und der Pfad zum Template muss angepasst werden. Daher folgendes in der Konfiguration der Extension vornehmen (in meinem Fall wars ein Modul):

module.tx_myext {
	view {
		widget.Tx_MyExt_ViewHelpers_Widget_PaginateViewHelper.templateRootPath = {$module.tx_myext.view.templateRootPath}
	}
}
config.tx_extbase.view.widget.Tx_Fluid_ViewHelpers_Widget_PaginateViewHelper.templateRootPath = {$module.tx_myext.view.templateRootPath}

Überall da, wo ich myext eingesetzt habe, kommt der Name der Extension hin.

Nach diesen 3 Anpassungen hat es bei mir funktioniert. Sollte jemand, der es besser weiß (Mitglieder des Fluid-Teams) diesen Beitrag lesen, würde ich mich über Korrekturvorschläge wahnsinnig freuen.

Im Frontend werde die Bilder korrekt angezeigt, Image Magick funktioniert einwandfrei, trotzdem sind keine Bilder im Backend zu sehen. Dank diesem Artikel konnte ich mein Problem lösen, in dem ich die Leerzeile am Ende der RealURL Konfiguration entfernt habe. Alternativ das schließende PHP-Tag entfernen.

Da ich selbst als Trainerin Kurse im Fitnessstudio gebe, ist mir irgendwann aufgefallen, dass es keine Extension gibt, mit der sich Kurspläne gut darstellen lassen. Daher hatte ich Mitte 2009 eine Extension erstellt, mit der man Kurspläne vor allem für Fitnessstudios anlegen und verwalten kann. Die Funktionsweise ist wie folgt: man erstellt eine Liste von Trainern und eine Liste von Kursen, die man in Kategorien einteilen kann, die man vorher erstellt hat. Dann legt man eine Kursplan an und fügt Timeslots hinzu. Ein Timeslot ist eine Uhrzeit mit einem Kurs und einem Trainer. Also z.B. Trainer X gibt am Montag um 19 Uhr den Kurs A. Diese Extension hatte ich zunächst mit lib/div geschrieben und sobald ich das nötige Wissen hatte, habe ich es auf Basis von Extbase umgeschrieben.
Es freut mich sehr, dass diese Extension nun im Einsatz ist – auf http://www.provitaconcept.de/sonstiges/kursplaene/. Der Entwickler der Seite hatte mich auf einige Fehler hingewiesen, die ich daraufhin behoben habe. Die Version 1.4.1 der Extension np_timetable im TER ist nun im Status „beta“ und kann gerne auf weiteren Seiten zum Einsatz kommen.

UPDATE: Aufgrund einer E-Mail von Thomas (danke!) sind wohl noch zwei Dinge offen, die ich so schnell wie möglich beheben werde: Beim Speichern wird der ausgewählte Controller falsch in der DB gespeichert, da das > aus der Auswahl entfernt wird. Zum anderen Unterscheidet Unix im Vergleich zu Windows Groß- und Kleinschreibung, daher werden die Templates nicht gefunden. In diesem Fall die Templates umbenennen, so dass sie mit einem Großbuchstaben beginnen (also Default.html statt default.html).

Die Systemextension felogin hat zahlreiche Einstellungmöglichkeiten, unter anderem kann man nach dem Login direkt zu einer Seite springen. Ich habe die Extension über TypoScript wie folgt eingerichtet:

plugin.tx_felogin_pi1.redirectMode = login
plugin.tx_felogin_pi1.redirectPageLogin = {$orderPage}

Im Content Element selbst stellt man im Tab „Weiterleitungen“ ein „Nach Anmeldung (TS oder Flexform)“ und setzt den Haken bei „Erste unterstützter Modus aus Auswahl“. So weit so gut, aber es funktioniert nicht. Testweise habe ich die Einstellungen aus dem TypoScript in das Inhaltselement übernommen und dort die gleichen Einstellungen per Flexform gemacht. Das Verhalten war irgendwie sonderbar. Nach dem Login wird definitiv nicht redirekted, nach Logout ändert sich die URL zu der Seite, die nach dem Login angezeigt werden sollte, die aber ja nur für eingeloggte User sichtbar ist.
Nach (zum Glück) kurzer Suche habe ich folgenden Beitrag gefunden: TYPO3 Redirect after Frontend User Login. Und da steht drin, dass die Option „Abmeldeformular nach erfolgreicher Anmeldung zeigen“ (im Flexform) bzw. „showLogoutFormAfterLogin“ (in TypoScript) die Ursache dafür ist, dass das Redirect nicht funktioniert. Und siehe da: diese Option über TypoScript auf 0 gesetzt, im Flexform den Haken an der Stelle entfernt und schon funktioniert es. Ich muss dem Artikelschreiber zustimmen – ich sehe das eher auch als Bug und die Dokumentation bzw. die Beschriftung des Feldes könnte besser sein.