Leider funktionieren Conditional Commands mit TemplaVoila nicht, da das abschließende HTML-Kommentar nicht ausgegeben wird. Beispiel:
<!--[if lt IE 9]><script src="..."></script><![endif]-->Bis das funktioniert, löse ich das über eine TypoScript Anweisung:
page.headerData.100 = HTML page.headerData.100.value = <!--[if lt IE 9]><script src="..."></script><![endif]-->
Ein kleines Update ist heute veröffentlicht worden. Alle Änderungen sind im Release-Log aufgeführt.
Ich habe seit neustem auf meinem Windows x64 System ein Problem mit dem Zend Server CE (PHP 5.2) 5.6.0 und Typo3 Version 4.6.3. Mit Version 5.5 hat noch alles problemlos funktioniert. Ich weiß nicht, ob es an den “Security Enhancements” in PHP 5.3.9 liegt, aber der Login in den Backend-Bereich von Typo3 ist in dieser Umgebung nicht mehr möglich. Nach Absenden des Login-Formulars erschient eine Meldung ala “Wollen Sie die index.php Datei speichern oder öffnen…”. Darin ist ein 500-HTTP-Status-Code enthalten, jedoch erscheint in den Apache und PHP-Log-Dateien keinerlei Hinweis darauf. In der Ereignisanzeige von Windows sieht das ganz anders aus. Dort scheint die php-cgi.exe einen Fehler zu verursachen.
Ich werde das morgen mit der neuen Typo3-Version testen und auch Bilder und genaue Fehlermeldungen nachliefern.
Update
Eine Aktualisierung auf Typo3 4.6.4 brachte wie vermutet keinen Erfolg. Wie versprochen ein paar Details zu dem Fehler:
Typo3 4.6.3 Login Screen
Fehlermeldung nach Login
Windows Ereignisanzeige - Fehlermeldung
Nochmal als Text (damit Google das findet):
Name der fehlerhaften Anwendung: php-cgi.exe, Version: 5.3.9.0, Zeitstempel: 0x4ef33bca Name des fehlerhaften Moduls: php5.dll, Version: 5.3.9.0, Zeitstempel: 0x4ef33bc8 Ausnahmecode: 0xc0000005 Fehleroffset: 0x00092b20 ID des fehlerhaften Prozesses: 0xd1c Startzeit der fehlerhaften Anwendung: 0x01ccdb33ed105389 Pfad der fehlerhaften Anwendung: C:\Program Files (x86)\Zend\ZendServer\bin\php-cgi.exe Pfad des fehlerhaften Moduls: C:\Program Files (x86)\Zend\ZendServer\bin\php5.dll Berichtskennung: f2e4d78f-4728-11e1-bd4d-005056c00008
Noch eine Meldung in der Windows Ereignisanzeige
Fehlerbucket , Typ 0 Ereignisname: APPCRASH Antwort: Nicht verfügbar CAB-Datei-ID: 0 Problemsignatur: P1: php-cgi.exe P2: 5.3.9.0 P3: 4ef33bca P4: php5.dll P5: 5.3.9.0 P6: 4ef33bc8 P7: c0000005 P8: 00092b20 P9: P10:
Update 2:
Das Problem ist vorübergehend gelöst, indem man die Datei /typo3/contrib/RemoveXSS/RemoveXSS.php in der Größe verändert. Schuld daran ist ein PHP-Bug. Einen herzlichen Dank an Jürgen für den Tip (siehe Kommentare).
Ein Sicherheitsupdate ist heute erschienen, die eine “Remote Code Execution” verhindert. Unter gewissen Umständen kann also PHP-Code ins System eingeschleust werden. Alle Infos dazu auf der Typo-Seite.
Eine Hilfsklasse kann in einer Extbase Extension im Classes Verzeichnis platziert werden. Ich empfehle die Klasse in einem Unterverzeichnis zu platzieren. Der Autoloader ist bei richtiger Bennenung in der Lage die Klasse zu laden.
Beispiel:
myextension/Classes/Helper/MyClass.php (Erster Buchstabe im Dateinamen groß schreiben).
Name der Klasse: Tx_Myextension_Helper_MyClass
Wer sich schon einmal den Wiki-Eintrag zu MSSQL durchgelesen hat, wird schnell merken, dass Typo3 an der einen oder anderen Stelle nicht wirklich rund mit der Microsoft Datenbank zusammenarbeiten wird. Ob diese Info aus dem Wiki noch aktuell ist, steht auf einem anderen Blatt… dort aufgeführte Bugmeldungen wurden jedoch bereits behoben. Ich habe jedoch einige Blog-Einträge (siehe Links unten), gefunden, die von “großem” Aufwand sprechen, ein Typo3 unter MSSQL zu installieren. Die Unterstützung scheint jedoch besser zu werden. Zumindest stellt eine PHP Installation unter Windows kein Problem mehr da. Wer den Typo-Source gern wie unter Linux mittels symbolischen Link in sein Projekt einbinden will, kann das auch unter Windows mit einem kleinen Tool Junction von Microsoft ermöglichen.
Für die Bildgenerierung muß ImageMagick und Ghostscript installiert werden. Auch dies ist für Windows verfügbar.
Das “Rewrite” von URLs erfordert Zusatzaufwand ist jedoch auch in einem Typo3-Wiki-Eintrag beschrieben.
Das größtes Problem, das ich sehe, sind jedoch die Erweiterungen, die nicht unbedingt mit MSSQL kompatibel sein müssen. Diese sind dann entsprechend zu testen.
Wer seine Webseite unter Typo3 betreiben will und Daten von einem Microsoft SQL Server benötigt, könnte auch das Typo3 auf MySQL betreiben. MySQL läuft problemlos auf einem Windows-Server und ist (mitterweile) auch dort nicht wesentlich langsamer als unter Linux. Die Daten des MSSQL-Servers können in einer eigenen (Extbase-)Extension verarbeitet und dargestellt werden. Ich denke da z. B. an ein Produktmodul, dass die Produkteinformationen aus dem ERP-System erhält. Leider habe ich die Vermutung, dass Extbase keine komfortables Möglichkeit für den Zugriff auf MSSQL bietet, zumindest habe ich dazu nichts gefunden. Mag sein, dass das mit Typo5 mit Flow besser wird, da dort wohl Doctrine als Abstraktionsschicht verwendet wird, aber bis dahin wird noch etwas Zeit vergehen.
Aber was spricht dagegen den Zugriff auf die Datenbank mit etwas anderem durchzuführen? Nix (naja, ein paar Argumente gibts sicherlich). Und wie? Beispielsweise mit dem Zend Framework. Ich habe dazu eine Extension geschrieben, die den Autoloader des ZF einbindet (Extension an erster Stelle laden “top”). In jeder anderen Extension kann mittels passendem Zend Adapter eine Verbindung aufgebaut werden. Natürlich gibt es auch damit das eine oder andere Problem z. B. funktioniert der für den Microsoft SQL Server benötigte Adapter nur mit der PHP Erweiterung sqlsrv und wird erst aber Microsoft SQL Server 2005 oder höher unterstützt (darunter funktionierte bei mir die limit(Anzahl, Offset) Funktion nicht korrekt… ich hab den Adapter abgeleitet und diese Funktion überschrieben). Ansonst kann man nicht das ORM von Extbase verwenden, aber zumindest kann man sich daran “orientieren”, indem man die Zugriffe auf MSSQL-Daten in einer Repository-Klasse kapselt.
Fazit:
Wenn man ein Typo3-System auf MSSQL betreiben will, kann dies sicherlich mit etwas Aufwand hinbekommen. Wenn man jedoch die Möglichkeit hat MySQL unter Windows zu betreiben, würde ich das auch tun. Meist liegen die Daten im Business-Umfeld auf Windows-Servern und stammen dann wohl von anderen Anwendungen, die sowieso durch eine spezielle Implementierung aufbereitet werden müssen.
Links:
Szenario: Wir haben eine Übersichtsseite und wollen die Ergebnisse durch einen Filter einschränken. Um das zu bewerkstelligen brauchen wir ein Formular, in dem Kriterien angegeben werden können. Ich gehe davon aus, dass der Controller inkl. Template bereits vorhanden ist. Wir ergänzen im Template also das Form-Element:
<f:form object="{filter}" objectName="filter"> <f:form.textfield property="fulltext" /> <f:form.select property="country" options="{countryOption}" /> <f:form.submit value="ok" /> </f:form>
Im Controller ergänzen wir die Action:
/** * action list * @param Tx_MyExtension_Domain_Model_DemoFilter $filter * @dontvalidate $filter * @return void */ public function listAction(Tx_MyExtension_Domain_Model_DemoFilter $filter=null) { if(!$filter) $filter=new Tx_MyExtension_Domain_Model_DemoFilter(); // Filter verarbeiten und Daten entsprechend Filterwerten holen // $data=...repository->findByFilter($filter); // $this->view->assign($data); $this->view->assign('filter', $filter); $this->view->assign('countryOption', array('DE', 'EN')); }
Das Model möchte ich an dieser Stelle nicht erklären, da es keine Besonderheiten enthält.
<?xml version="1.0" encoding="UTF-8"?> <T3DataStructure> <sheets> <sDEF> <ROOT> <TCEforms> <sheetTitle>Flexform für Typo3 Extbase</sheetTitle> </TCEforms> <type>array</type> <el> <switchableControllerActions> <TCEforms> <label>Standardaktion des Plugins</label> <config> <type>select</type> <items> <numIndex index="0"> <numIndex index="0">Listenansicht</numIndex> <numIndex index="1">MyController->list</numIndex> </numIndex> <numIndex index="1"> <numIndex index="0">Einzelansicht</numIndex> <numIndex index="1">MyController->show;MyController->edit</numIndex> </numIndex> </items> </config> </TCEforms> </switchableControllerActions> </el> </ROOT> </sDEF> </sheets> </T3DataStructure>
// Include flex forms $pluginSignature = str_replace('_','',$_EXTKEY) . '_' . myextensionname; $TCA['tt_content']['types']['list']['subtypes_addlist'][$pluginSignature] = 'pi_flexform'; t3lib_extMgm::addPiFlexFormValue($pluginSignature, 'FILE:EXT:' . $_EXTKEY . '/Configuration/FlexForms/setup.xml');
Das obige Beispiel fügt dem Plugin eine Auswahlbox hinzu, über die der Controller bzw. die aufgerufene Action-Methode des Controllers ausgewählt werden kann. Es können nur Actions aufgerufen werden, die in der Flexform konfiguriert sind. Deswegen muß man dort alle Actions eines Controllers mit Semikolon getrennt aufführen.
Außerdem reicht es aus den Namen des Controllers ohne den Zusatz “Controller” aufzuführen, also wenn der Controller den Klassennamen Tx_MyExtension_Controller_MyController hat, heißt der Wert in der Flexform My->list.
Ausführliche Infos findet man im Typo3 Wiki.
Alles unter Windows 7 x64. Die Basiskompenenten bringt der Zend Server CE mit.
Die Grundinstallation wurde nach Installationsbeschreibung und mit dem Installationstool durchgeführt. Im Anschluß wurde über den Extension-Manager
installiert.
Nach der Installation über den Extension-Manager wurden folgende Schritte durchgeführt:
In den Seiteneigenschaften kann das TemplaVoila-Template nicht ausgewählt werden. Es erscheint folgende Fehlermeldung:
Data Structure ERROR: No source value in fieldname "tx_templavoila_ds"
Es war natürlich nur eine Kleinigkeit – jedoch eine, die mir nicht gleich aufgefallen ist: In den Seiteneigenschaften muß das Template natürlich ausgewählt werden:
Heute ist Typo3 4.6.1 erschienen. Im Typo3 Wiki werden die Änderungen aufgeführt.
Fluid liefert ein sehr hilfreicher Helper mit, mit dem man Zeilenumbrüche in Html-Umbrüche (br) umwandeln kann.
<f:format.nl2br>{mytextwithbreaks}</f:format.nl2br>
Der Helper selbst greift auf die PHP-Funktion nl2br zurück, um diese Umwandlung vorzunehmen.