zoe.vc

Manchmal muss man beim Entwickeln für Typo3 TypoScript an den unterschiedlichsten Stellen auslesen. Im folgenden zwei Beispiele, die mich gerade ein wenig auf die Probe gestellt haben.

TypoScript bei Nutzung von eID

Das Skript, welches mit eID angesprochen wird, ist ja lightweight und lädt erstmal nahezu nix vom Typo3-Kern. Nutzer und Datenbank sind schnell initialisiert, aber wenn man z.B. Werte aus dem TypoScript Setup des Plugins auslesen will geht das nicht nur mit einer Zeile Code. Dem eID-Skript muss auf irgendeine Weise die PageID übergeben werden (ich mache das mit einer Get-Variable), die braucht man nämlich, um das TSFE (das ja nicht da ist), ordentlich zu initialisieren. Man instanziiert sich eine tslib_fe Klasse, verbindet zur Datenbank, initialisiert den Nutzer, das Template und die Config und schon ist man fertig:

// eID specific initialization of user and database
tslib_eidtools::connectDB();
tslib_eidtools::initFeUser();
 
// initialize TSFE
require_once(PATH_tslib.'class.tslib_fe.php');
require_once(PATH_t3lib.'class.t3lib_page.php');
$temp_TSFEclassName = t3lib_div::makeInstanceClassName('tslib_fe');
$GLOBALS['TSFE'] = new $temp_TSFEclassName($TYPO3_CONF_VARS, $pid, 0, true);
$GLOBALS['TSFE']->connectToDB();
$GLOBALS['TSFE']->initFEuser();
$GLOBALS['TSFE']->determineId();
$GLOBALS['TSFE']->getCompressedTCarray();
$GLOBALS['TSFE']->initTemplate();
$GLOBALS['TSFE']->getConfigArray();

Nun kann man altbekannt via

$GLOBALS['TSFE']->tmpl->setup['plugin.']['extensionkey.']['your_value']

auf die Daten zugreifen. Mit der letzten Codezeile kann man übrigens auch in nicht vollständig initialisierten Plugins das TypoScript beliebig auslesen.

TypoScript in Backend-Modulen

In Backend-Modulen ist es auch manchmal notwendig, auf das TypoScript Setup zuzugreifen, zum Beispiel beim Senden einer Email, um den Absender auszulesen etc. Der Ablauf ist ähnlich wie bei eID, jedoch ermitteln wir selber die RootPageID und nutzen die t3lib_pageSelect und t3lib_tsparser_ext Klassen. Ich habe das ganze in eine Funktion gepackt, da man das ja nicht unbedingt immer braucht:

/**
 * Loads the TypoScript for the given extension prefix, e.g. tx_cspuppyfunctions_pi1, for use in a backend module.
 *
 * @param string $extKey
 * @return array
 */
function loadTypoScriptForBEModule($extKey) {
	require_once(PATH_t3lib . 'class.t3lib_page.php');
	require_once(PATH_t3lib . 'class.t3lib_tstemplate.php');
	require_once(PATH_t3lib . 'class.t3lib_tsparser_ext.php');
	list($page) = t3lib_BEfunc::getRecordsByField('pages', 'pid', 0);
	$pageUid = intval($page['uid']);
	$sysPageObj = t3lib_div::makeInstance('t3lib_pageSelect');
	$rootLine = $sysPageObj->getRootLine($pageUid);
	$TSObj = t3lib_div::makeInstance('t3lib_tsparser_ext');
	$TSObj->tt_track = 0;
	$TSObj->init();
	$TSObj->runThroughTemplates($rootLine);
	$TSObj->generateConfig();
	return $TSObj->setup['plugin.'][$extKey . '.'];
}

Und damit hätte man wieder ein paar Typo3-Probleme weniger...

In Typo3 ist es des öfteren sinnvoll, die erstellbaren Elemente auf einer Seite zu limitieren. Vor allem bei SysFoldern in denen man jeweils nur bestimmte Elemente speichern will macht das Sinn, denn im SysFolder "Nutzer" möchte ich eher keine anderen Elemente haben. Außerdem erhöht das die Übersichtlichkeit und bringt Redakteure nicht dazu, neue Elemente "einfach irgendwohin" zu speichern.

In der TSConfig der entsprechenden Seite muss man einfach nur:

mod.web_list.allowedNewTables = db_tablename,db_tablename_2

angeben, wobei db_tablename entsprechend die Namen der Datenbanktabellen der Elemente sind.