zoe.vc

There are a few nice tipps in the blog of Dmitry Dulepov to speed up the Typo3 performance you should have read. #2 was unknown to me so far.

Also jedes mal, wenn ich eine mehrsprachige Typo3-Seite erstellen, komme ich durcheinander mit den Sprachen. Und ich vergesse jedes mal, wie man einem Frontend-Plugin sagt, dass es die durch $this->pi_getLL($key) ausgegebenen Texte lokalisiert. Und das geht so:

class tx_extkey_piX extends tslib_pibase {
   function main() {
      $this->sys_language_uid = (int) t3lib_div::_GP('L');
      ...
   }
}

Manchmal ist es nötig, die Datenbank von Typo3 auf UTF-8 umzustellen, da man arabische Zeichen oder was auch immer speichern will, und wobei die Kollation der Datenbank latin1_swedish_ci, mit der sich Typo3 standardmäßig installiert, nicht taugt.

Dazu habe ich diesen nützlichen Blogeintrag von Markus Giesen gefunden: Typo3 mySQL-Datenbank auf UTF-8 umstellen bzw. konvertieren

Jedoch ist bei mir im Export nie die Kollation festgeschrieben, diesen Schritt konnte ich de facto überspringen. Auch hatte ich keinen phpMyAdmin, also mussten die Kommandos für die SQL-Konsole zum Anpassen der Kollation her:

Anzeigen der verfügbaren Kollationen auf dem Server:

SHOW COLLATION
SHOW COLLATION LIKE 'utf%'

Ändern der Kollation der aktuellen Datenbank:

ALTER DATABASE DEFAULT COLLATE utf8_general_ci

Und danach weiter nach Markus Giesens Anleitung verfahren und alles wird gut

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...

I'm currently configuring one of my extension for "realurl" within Typo3. My aim is to have the categories and subcategories of an article center within the url. But the functionality of "lookUpTable" does not suffice as I have to observe the nesting of the categories. So I choose "userFunc" and enter the values as given in the realurl documentation:

'fixedPostVars' => array(
	'articlecenter' => array(
		'userFunc' => 'EXT:extkey/class.tx_userxyz.php:
			&tx_realurl_userfunctest->main',
	),
),

then I clear the cache and it happens... nothing. Only a nice error message is presented:

|Function/Class 'E' was not prepended with 'user_'|

Seems that my configured values do not really reach the code they should. And of course that's the way it is. After some searching I detect that my configuration is wrong, because realurl is putting all configured values into a nested array wherein every key-value pair is put in as an array that has a numeric indice in the big array. (I hope you can follow my poor english). But my "userFunc" is not set up this way, its numeric indice is "userFunc" and the array with the key-value pairs is the string "EXT:realurl/class.tx_realurl_userfunctest.php:&tx_realurl_userfunctest->main". As realurl runs through this array using foreach it has only "E" as value (that comes from the "EXT") and furthermore the error is thrown in t3lib_div:callUserFunction.
Now the solution is quite easy, simply nest the userFunc within an additional array:

'fixedPostVars' => array(
	'articlecenter' => array(
		array(
			'userFunc' => 'EXT:extkey/class.tx_userxyz.php:
				&tx_realurl_userfunctest->main',
		),
	),
),

Now everything is working again. You only need to find it out...

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.