Seit nun zwei Wochen befinde ich mich am Roten Meer zum Tauchen. Wie jedes Jahr ist auch die gesamte Kollektion an TYPO3 T-Shirts dabei, da ich diese ansonsten so selten ausführen kann. Daher ist jeden Tag ein anderes T-Shirt auf dem Boot, mal T3DD, mal T3Camp oder einfach nur “Inspire to share”.

Interessanter Nebeneffekt: Ich wurde diese Woche bereits zwei mal auf TYPO3 angesprochen, von Anwendern die verschiedene Bauchschmerzen haben, in einem Fall das typische “Redakteur arbeitet mit Adminzugang ==> TYPO3 ist kompliziert”. Sicherlich beides keine Millionenaufträge, aber die Resonanz ist erfreulich.

Auch gut ist, dass die UMTS-Abdeckung (mit Etisalat SIM [25EUR für 6GB Pre-Paid], wahrscheinlich aber auch mit Vodafone) hervorragend ist. Das erlaubt es nicht nur mittels Skype den 1-stündigen Videocall zur Familie zu machen, man kann auch schnell mal was in TYPO3 zu zeigen.

Also: “Wear TYPO3!”

------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!

Fokus des ersten Tages war, wie man bei den Vorträgen unten leicht erkennen kann, die Zusammenareit von TYPO3 und Magento, in den verschiedensten Spielarten. Die Vorträge waren allesamt interessant, wenngleich der Vortrag über das Performancetuning/Caching am Beispiel kress.de definitiv zu spät am Tag angesetzt war, um die Zuhörer noch zu erreichen (die Menge an Informationen übertraf die verbleibende Aufnahmefähigkeit bei weitem).

Die Bewirtung, von morgens bis zum Dinner, war sehr gut und jederzeit reichlich. Die Cocktailbar am Abend konnte ich (da mit Auto angereist) leider nicht nutzen.

Spontan fällt mir nur ein negativer Punkt ein: die Twitterwall (großer Flachbildschirm mit dem #t3ak10 Tweet), der zur einige Anwesende zu Abgabe konsequent inhalts- und bedeutungsloser Tweets provozierte und sicher nicht der Konzentration auf die Vorträge dienlich war. Schauen wir mal wie das morgen sein wird.Themen des Tages:

- Vorstellung der Performancemassnahmen am Beispiel kress.de, inkl. des Caching-Frameworks und der Ext. enetcache

- Volker Graubaum stellte das Projekt kress.de vor, inkl. der verschiedenen Features. Einsatz des Caching Frameworks der Version 4.3

- Und noch einmal TYPO3 und Magento mittels Middleware. jimConnector und weitere Elemente in der Kommunikation zwischen TYPO3 und Magento

- Weiter gehts nach dem Mittag mit einem Vortrag über TYPOGENTO durch TOCO3. Als Beispiel eines Shops für Frottee Frisbees. Es wird gezeigt, wie Teile der Magentoausgabe direkt durch TYPO3 ausgegeben werden.

- Ingo Schmidt (Marketing Factory) spricht über die wichtigen Punkte für SEO. An sich ein Thema wo man denkt “Nicht schon wieder”, aber mal ganz andere (und interessante) Gesichtspunkte. Inkl. der Bedeutung der robots.txt, XML-Sitemap etc. Empfehlung für dd_googlesitemap (Multidomainfähig u.a.) ==> Fazit: Das Problem ist dann doch wieder der Redakteur, der die Inhalte nicht pflegt. Dagegen gibt es noch keine Extension, leider.

Interessanter Konfigurationskey: config.meaningfulTempFilePrefix = 100, um den Namen der originalen Datei als Bestandteil der temp. Datei integriert, was dann wieder zu Keywords in Dateinamen führt.

Mit Realurl nicht übertreiben, denn für Google kann das aussehen, als wenn die Seite auf einer tiefen Verzeichnisstruktur liegt und dadurch weniger relevant ist. Wie oft: viel hilft nicht viel.

- Stefan Willkommer von TECHDIVISION stellt das große Lindner-Projekt vor: Weltweit verteiltes Internet/Intranet. Schon spannend was man alles aufbauen kann. Inkl. Anbindung an diverse LDAP-Server für weltweites Login.

- …mit dem Vortrag von Sebastian Böttger bzgl. eCommerce und TYPO3. Die Marit AG hat das Haus voll bekommen, der Kaffee ist gut, die Brezen auch. Derzeit werden die verschiedenen verfügbaren Systeme vorgestellt.

Mehr Details folgen….

------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!

Oft trifft es aber zu, dass in den verschiedenen Plugins gewisse Basisdaten der Konfiguration gebraucht werden, die für alle Plugins gelten. Dies können Formatierungen und Templates sein, aber auch jegliche andere Konfiguration.

Um diese Daten jedem Plugin zur Verfügung zu stellen gibt es verschiedene Ansätze. Der allgemeinste Ansatz wäre das Kopieren der Daten im Typoscript Template, in welchem dann folgender Code die Einstellungen vom Plugin1 zum Plugin2 kopieren würde:

plugin.mytest_pi2 < plugin.mytest1

Allerdings ist diese Lösung alles andere als ideal, da dies eine Zeile im Typoscript Template ist, welche einfach gelöscht oder vergessen werden kann. Die Auswirkungen können sehr unterschiedlich ausfallen. Daher ist es besser diese Daten im PHP-Code der Extension zu kopieren, wobei die Daten bei diesem Vorgang zusätzlich auch noch verifiziert und gegebenenfalls modifiziert werden können.

Im PHP-Code der Extension kann jederzeit auf die Typoscript Daten zugegriffen werden:

$ts = $GLOBALS['TSFE']->tmpl->setup['plugin.']['mytest_pi1.'];

Da bei dieser Methode des Zugriffs nicht die Notwendigkeit gegeben ist sich an strikte Namenskonventionen zu halten, kann allgemeiner Code der mehrere Plugins der Extension betrifft auch in einen allgemeinen Teil umverlagert werden, wie der folgende Code zeigt:

$ts = $GLOBALS['TSFE']->tmpl->setup['plugin.']['mytest.'];

In diesem Fall wären alle allgemeinen Einstellungen im Typoscript Template in Bereich plugin.mytest anzugeben, spezielle Einstellungen pro Plugin jedoch weiter hin als plugin.mytest_pi1 etc.

Durch diese Aufteilung und die Verteilung innerhalb des PHP-Codes wird die beste Kombination zwischen Flexibilität, Sicherheit und Übersichtlichkeit getroffen.

Eine Anmerkung ist an dieser Stelle jedoch wichtig: Daten die im “allgemeinen Teil (mytest)” gespeichert sind, stehen NICHT automatisch in $this-conf zur verfügung und müssen bei Bedarf im PHP-Code dorthin übetragen werden. Auch wichtig anzumerken ist, dass dies nur EINE Möglichkeit der Vereinfachung darstellt, die je nach Anwendung mehr oder weniger gut umzusetzen ist.

------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!

$confFile  .= file_get_contents($File);

geschehen, woraufhin der Inhalt der Datei in $confFile steht. Die Variable $confFile enthält den Text der Datei, aber noch kein auswertbares TS-Array. Um dies zu erhalten muss der Parser die Daten erst noch verarbeiten und in ein TypoScript-Array konvertieren, was mit dem folgenden Code geschehen kann:

$tsParser  = t3lib_div::makeInstance('t3lib_TSparser');
$tsParser->parse($confFile);
$tsArray = $tsParser->setup;

In der ersten Zeile wird eine Instanz des TSparsers erzeugt, deren Methode parse() anschliessend anschliessend die eingelesene Datei übergeben wird. Nach Ausführung von parse() steht das TS-Array in der Variable $tsParser->setup zur weiteren Verarbeitung zur Verfügung und kann wie jedes Array verarbeitet werden.

Auf die einzelnen Schlüssel kann dann wie im folgenden Beispiel zugegriffen werden:

$parseFunc = $tsArray['lib.']['parseFunc.']

------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!

Eine davon wäre dazu da, News zu verwalten die unter der Backend-Loginbox angezeigt werden. Verwalten soll zumind. heissen, dass ContentElemente ausgegeben werden die in einem oder mehreren Foldern liegen und auch Dinge wie START/STOP, Hidden u.ä. der ContentElemente beachtet werden.

Um nun nicht nur für die eigene Schublade zu schreiben, möchte ich an dieser Stelle dazu aufrufen Ideen/Wünsche (so vorhanden) zu äussern. Auch falls es sowas schon gibt und mir nur nicht bekannt ist, wäre ein Hinweis wunderbar.

------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!

Eine weitere Möglichkeit ist die Eingabe der Werte über ein TS-Template, womit die Werte der Extension im conf[]-Array zur Verfügung stehen. Dies wird jedoch spätestens dann aufwändig, wenn die Extension aus mehreren Untermodulen (pi1, pi2, pi3…) besteht und die Parameter allen Untermodulen bekannt sein muss.

In diesem Fall bietet sich eine einfachere Möglichkeit an: ext_conf_template.txt.

Hierbei handelt es sich um eine Textdatei die im Hauptverzeichnis der Extension existieren kann. Ist sie vorhanden, so wird sie eingelesen. In dieser Datei werden nun die Variablen definiert, wobei die Syntax die selbe wie beim ConstantEditor ist. Sollen Variablen thematisch gruppiert werden können sie in eine geschweifte Klammer eingeschlossen werden.

Gruppenname {
    variablen
}

Die zu konfigurierenden Variablen finden Sie, wenn Sie im Extension Manager auf den Namen der Extension klicken, um die Informationsseite aufzurufen. Jede Variable wird mit der angegebenen Beschreibung angezeigt. Wird das Formular  gesendet werden die Daten in einem serialisierten Array in der localconf.php gespeichert.

HINWEIS: Falls Sie in einer der Variablen Dateien auswählen wollen, so sollten sich diese im Unterverzeichnis /res der Extension befinden.

Falls Sie die Eingaben im Formular vor dem Speichern in der localconf.php noch prüfen oder modifizieren wollen müssen Sie einen Hook des Extension Managers nutzen und Ihre Funktion in folgendem Aufruf registrieren:

$TYPO3_CONF_VARS['SC_OPTIONS']['typo3/mod/tools/em/index.php']['tsStyleConfigForm'][] = “function"

Um die Variablen später anwenden zu können müssen selbige aus dem serialisierten Array ausgelesen werden. Dies kann recht einfach mit dem folgenden Code geschehen:

$Config = unserialize($GLOBALS['TYPO3_CONF_VARS']['EXT']['extConf']['extension_key']);
$var = $Config['var_name'];

------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!

Das Erzeugen eines Links zu anlegen einer neuen Seite…:

$params = '&edit[pages][111]=new';
$output.= 'Some Text'

…zum Editieren der Seite mit UID=21…

$params = '&edit[pages][21]=edit';

…zum Editieren der Seite mit UID=21 mit eingeschränkten Feldern…

$params = '&edit[pages][21]=edit&columnsOnly=title,hidden';

…und mit Defaultwerten.

$params = '&edit[pages][21]=new&defVals[pages][title]=New%20Page';

------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!

In einem Template würde man hierzu z.B. folgendes definieren:

page.10.marks.dynamik = COA_INT
page.10.marks.dynamik {
    10 = USER
    10.userFunc = funktion
}

Umstände können es jedoch notwendig machen den Marker aus der Extension heraus zu befüllen, z.B. wenn sich der Inhalt des Markers aus anderen Daten ergibt, die ausserhalb der Extension nicht bekannt sein können. Dann muss obiger Code innerhalb der Extension generiert und ausgegeben werden. Dies kann mit folgendem PHP-Code erreicht werden:

function PageViewCounter() {
    $TS['conf']='COA_INT';
    $TS['conf.']['950']='USER';
    $TS['conf.']['950.']['userFunc']='funktion';
    $ret = $this->cObj->cObjGetSingle($TS['conf'],$TS['conf.']);
    return $ret;
}

Abschliessend wird der Rückgabewert der Funktion in der Extension an einen Marker ausgeben:

$markerArray['###FIELD_CREATEDATE###'] = $this->funktionName

------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!

Eine der häufigsten Funktionen von Erweiterungen in TYPO3 ist das Abfragen von Datensätzen aus der Datenbank. Dabei sind Seiten in der Tabelle pages gespeichert, die Inhalte in der Tabelle tt_content. Handelt es sich um eine einsprachige Website ist die Abfrage sehr einfach.

Nachdem die UID der relevanten Seite ermittelt oder vorgegeben wurde, können mit selbiger alle Datensätze aus der Tabelle tt_content abgefragt werden, bei denen das Feld PID gleich der UID der Seite ist. Damit stehen alle Seitenelemente zur Verfügung. Zusätzlich zur obigen Bedingung wird in den meisten Fällen auch noch getestet, ob die Elemente als gelöscht markiert sind oder anderen Zugriffsbeschränkungen unterliegen. Das ist unter anderem deshalb wichtig, da Seiten beim Löschen nicht aus der Tabelle tt_content entfernt, sondern nur das Feld deleted gesetzt wird.

Bei einer mehrsprachigen Site würde dieses Vorgehen jedoch alle Inhaltselemente der Seite als Ergebnis liefern, unabhängig davon welcher Sprache die einzelnen Inhalte zugeordnet sind. Daher müssen in einer mehrsprachigen Website weitere Felder beachtet werden.

Die Sprachen werden in der Tabelle sys_language abgespeichert. In dieser Tabelle steht die UID für den Wert der Sprache, welcher auch im L-Parameter zu finden ist und welcher in TS-Conditions anzugeben ist. Das Feld title repräsentiert den anzuzeigenden Namen, der Inhalt des Feldes flag die anzuzeigende Flagge.

Mit dem Wert UID aus der Tabelle sys_language steht nun fest nach welchem Wert zu fragen ist, wenn Inhaltselemente und Seiten einer bestimmten Sprache zu finden sind. Vorgegeben sei die Sprach-UID=1 und die Seiten-UID=12, zu der nun alle entsprechenden Daten (Titel der übersetzten Seite und Inhaltselemente) gefunden werden sollen.

Da Sprachvarianten einer Seite in der Tabelle page_language_overlay gespeichert sind, kann die Übersetzung hier gefunden werden, wenn nach PID=12 und sys_language_uid=1 gesucht wird. Diese Abfrage fördert für die Übersetzung alle Eigenschaften der übersetzten Seite. Die Eigenschaften sind die selben wie für eine originale Seite (hidden, deleted, navtitle usw.), welche natürlich in der Übersetzung von der originalen Seite abweichen kann.

Die Inhaltselemente der übersetzten Seite können ermittelt werden, indem aus der Tabelle tt_content alle Datensätze mit der pid=12 und der sys_language_uid=1 abgefragt werden. Die Datensätze mit pid=12 und sys_language_uid=0 wäre die Standardsprache, pid=12 und sys_language_uid=3 die Inhalte für die Sprache mit der UID=3. Welche Sprache dies ist beantwortet wiederum die Tabelle sys_language.

------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!

Relationen zwischen Datensätzen spielen in datenbankbasierten Anwendungen eine wichtige Rolle, spätestens wenn die Datensätze umfangreicher werden, bzw. Teilmengen der Daten an verschiedenen Stellen der Anwendung in verschiedenen Kontexten benötigt werden.

Ein typischer Anwendungsfall ist ein Produkt, dem ein Hersteller zugeordnet werden soll. Hierzu steht eine Auswahlliste zur Verfügung in welcher die verschiedenen Hersteller ausgewählt werden können, die dem Produkt zugeordnet sind.

Ansatz 1: Die kommaseparierte Liste

An dieser Stelle existieren nun zwei verschiedene Wege, wie eine derartige Relation realisiert werden kann. Der “althergebrachte” Weg besteht darin, dass eine Liste der UIDs der Herstellerdatensätze in dem Feld des Produktdatensatzes gespeichert werden. Bei diesem Feld handelt es sich daher um ein Textfeld, in welchem die UIDs, mit Komma getrennt, eingetragen sind. Sollen nun die einzelnen Herstellernamen zusammen mit dem Produkt angezeigt werden, so muss der Inhalt des Datensatzfeldes geholt, in einzelne UIDs zerlegt und der Herstellername für jede einzelne UID aus der Herstellertabelle angefragt werden. Ein recht aufwendiger Weg, welcher sich nicht komplett mit SQL umsetzen lässt.

Ansatz 2: Relationstabellen

Der zweite Ansatz involviert eine zusätzliche Tabelle, die die Zuordnung der Datensätze der einzelnen Tabellen enthält. Diese Zuordnungstabelle enthält also die IDs der Produktdatensätze und die der Hersteller. Für jeden, dem Produkt zugeordneten Hersteller enthält diese Tabelle einen einzelnen Datensatz. Durch diese durchgängige Datenbanknormalisierung kann die Abfrage der Daten über die drei Tabellen (Produkt-, Hersteller- und Zuordnungstabelle mittels SQL erfolgen. Zeitgleich mit der Datenabfrage können weitere Kriterien und Filter in die SQL-Abfrage eingefügt werden, um die Datenabfrage weiter einzuschränken.

Um den Ansatz 2 weiter zu vereinfachen hat die Klasse t3lib_DB eine spezielle Funktion für diese MM-Abfrage. Der Namen der Funktion ist exec_SELECT_mm_query() welche die folgenden Parameter übernimmt:

• $select
• $local_table
• $mm_table
• $foreign_table
• $whereClause
• $groupBy
• $orderBy
• $limit

Die letzten vier Parameter, also angefangen mit $whereClause, haben jeweils Defaultwerte, können also bei Nichtgebrauch weggelassen werden.

Mit diesen Defaultwerten aufgerufen ist die Funktion sehr einfach anzuwenden:

$res = $GLOBALS['TYPO3_DB']->exec_SELECT_mm_query(
 $select,
 $local_table,
 $mm_table,
 $foreign_table);

Da die Funktion um den Aufbau einer MM-Relation in TYPO3 weiß, werden die Zuordnungen von lokaler und foreign UID automatisch beachtet. Dadurch dass ein JOIN über die Tabellen ausgeführt wird erhalten Sie als Ergebnis einen “Gesamtdatensatz” der also die Felder des Produktes und zusätzlich die Felder des Herstellers enthält. Dies ist der Fall bei dem Aufruf der folgenden Funktion.

$ret = $GLOBALS['TYPO3_DB']->sql_fetch_assoc($res);

Möchte man nun statt aller Werte nur einen betsimmten erhalten, so muss selbiger abschliessend aus dem Ergebnissarray entnommen werden.

$manArray[$cnt] = $ret['manufacturer'];

Wird obige Funktion in einer Schleife für jeden Ergebnisdatensatz ausgeführt, so entsteht ein Array mit allen Herstellernamen.

Anmerkung: Wenn man eine MM-Relation im Kickstarter aufbau, so erhält die Produkttabelle ein Feld für die Relation. Allerdings wird in diesem Datenbankfeld KEIN Bezug zu einem Herstellerdatensatz eingesetzt. Die Zahl die Sie in diesem Datenbankfeld finden ist die Anzahl der in verbindung stehenden (Hersteller)-Datensätze. Haben Sie einem Produkt also vier Hersteller zugeordnet, so enthält das Feld die VIER. Dadurch kann ohne jeden weitern Aufwand abgefragt werden wieviele Hersteller ein Produkt ohne diese erst abfragen zu müssen.

------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!

Die meisten Extensionen die für TYPO3 geschrieben werden, benutzen Klassenstrukturen statt eines prozeduralen Ansatzes. In Klassen gibt es für die Initialisierung und das abschliessende Aufräumen die Funktionen:

• function __construct() und
• function __destruct()

Diese werden automatisch beim Erstellen (__construct()), bzw. Zerstören einer Instanz (__destruct()) aufgerufen.

In “normalem” PHP wird zum Erstellen einer Instanz die Funktion new(‘Klassenname’); aufgerufen. Auch in einer Extension für TYPO3 wäre dies machbar, jedoch wird dringend davon abgeraten. Die Funktion new() erzeugt die Klasse nämlich direkt auf PHP-Weise, ohne dabei auf TYPO3-Spezifitäten wie XCLASSes einzugehen. Liegt eine Klasse als XCLASS vor und würde eine neue Instanz mit new() erzeugt, so würde die Erzeugung fehlschlagen.

Kommt dagegen makeInstance(‘Klassenname’) zum Einsatz wird das Vorhandensein einer XCLASS geprüft und entsprechend beachtet. Bis zur Version 4.3 war es allerdings nicht möglich makeInstance(), und dadurch dem __construct(), weitere Parameter zu übergeben.

Vor der Version 4.3 war daher mittels des Funktionsaufrufes makeInstanceClassName(‘Klassenname’) der korrekte Klassenname geprüft werden., welche den korrekten und geprüften Klassennamen zurück gibt (Im Falle einer XCLASS würde diesem Namen ein ux_ vorangestellt). Der Rückgabewert konnte dann risikofrei mit new() verwendet werden, wobei dem Konstruktor natürlich auch Parameter mitgegeben werden können.

Ab Version 4.3 ist dies nun wesentlich einfacher. Parameter können nun ohne obigem Umweg per makeInstance(‘Klasse’,Param1,Param2, etc) übergeben werden. Diese werden an den eigentlichen Konstruktor mittels ReflectionClass->newInstanceArgs() übergeben.

------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!