Moduleinstellungen unter Contao

Während der Modulentwicklung kommt man schnell an den Punkt, wo man verschiedene Einstellungen zu einem Contao Modul hinterlegen möchte. Das kann eine Weiterleitungsseite sein, ein Text oder ein x-beliebiger Wert aus einem Auswahlfeld oder ähnliches. Jeder Eintrag in den Modulen einer “Theme” entspricht einem Datensatz in der Tabelle tl_module. Dort werden auch alle Einstellungen zu einem Modul hinterlegt.

Contao tl_module Tabelle

Auszug aus der Tabelle tl_module

Um eine dieser bestehenden Spalten in einem Modul nutzen zu können, muß man in der DCA eine Zeile ergänzen:

$GLOBALS['TL_DCA']['tl_module']['palettes']['mymodule'] = '{title_legend},name,headline,type,customLabel';

Schon steht im Modul ein einfaches Textfeld zur Verfügung. Da diese Einstellung bereits von Contao verwendet wird, gibt es bereits eine Felddefinition und eine Übersetzung für die Einstellung customLabel. Damit wir keine neue Spalte in der tl_module anlegen müssen, können wir das Feld für etwas anderes “mißbrauchen”. Ich will nur demonstrieren, wie man Änderungen vornehmen kann, die im Prinzip auch bei einem neuen Feld notwendig sind.

Die Übersetzung wird beispielsweise folgendermaßen gesetzt bzw. überschrieben:

$GLOBALS['TL_LANG']['tl_module']['customLabel']=array('View', 'Please select a view type.');

Den Feldtyp können wir folgendermaßen beeinflussen:

$GLOBALS['TL_DCA']['tl_module']['fields']['customLabel'] = array(
  'label' => &$GLOBALS['TL_LANG']['tl_module']['customLabel'],
  'inputType'  => 'select',
  'options'    => array(1=>'Overview', 2=>'Detail')
);

Somit haben wir jetzt folgendes im Backend erreicht:

Angepasstes Backend-Modul

Das angepasste Backend Modul mit neuem Feld

Eines sollte jedoch klar sein, wenn man bestehende Felddefinitionen verändert: Auch in den Modulen, in den die Einstellung bereits verwendet wird, kann unter Umständen die Veränderung greifen. Das wiederum hängt von der Reihenfolge ab, wie die Module abgearbeitet werden (alphabetisch).

Vollbild-Modus im Browser

Nachfolgend eine komplettes Beispiel mit jQuery und der neuen Fullscreen-API ein HTML-Element im Vollbild-Modus anzuzeigen. Funktioniert nur in den neusten Browser von Safari, Firefox und Chrome und sieht auch nur im Firefox gut aus… aber hier gehts einfach nur um die Funktion.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
  <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
  <script type="text/javascript" src="jquery.js"></script>
  <style>
    .white {
      font-family:verdana;
      margin-top:200px;
    }
    .white div
    {
      background-color:white;
      width:50%;
      margin:auto;
      -moz-border-radius: 5px;
      border-radius: 5px;
      -moz-box-shadow: 5px 5px grey;
      -webkit-box-shadow: 5px 5px grey;
      box-shadow: 5px 5px grey;
      padding:25px;
    }
    .hidden {
      display:none;
    }
  </style>
</head>
<body>
 
<div id="fullscreen-container">
  <div>
    <div>
      Here is your Fullscreen!
    </div>
  </div>
</div>
<p>
  <a href="#" id="fullscreen-link">Show me fullscreen container...</a>
</p>
<script type="text/javascript">
//<![CDATA[
(function($) {
  $.fn.extend({
    fullscreen:function(params) {
      var conf = {};
      $.extend(conf, params);
      return $(this).each(function() {
          var e=$(params);
          var element=e[0];
          $(this).click(function() {
              e.removeClass('hidden');
            if(element.requestFullScreen) {
              element.requestFullScreen();
              jQuery(document).bind("fullscreenchange", function() {
                if(!document.fullScreen) e.addClass('hidden')
              });
            }
            else if (element.mozRequestFullScreen) {
              element.mozRequestFullScreen();
              jQuery(document).bind("mozfullscreenchange", function() {
              if(!document.mozFullScreen) e.addClass('hidden')
            });
            }
            else if (element.webkitRequestFullScreen) { 
              element.webkitRequestFullScreen();
              jQuery(document).bind("webkitfullscreenchange", function() {
                  if(!document.webkitIsFullScreen) e.addClass('hidden')
              });
            }
          });
      });
    }
  });
})(jQuery);
 
jQuery('#fullscreen-link').fullscreen('#fullscreen-container');
 
//]]>
</script>
</body>
</html>

 

Typo3 4.6.4 Update und Zend Server

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

Typo3 4.6.3 Login Screen

Fehlermeldung nach Login

Fehlermeldung nach Login

 

Inhalt der Datei index.php

Inhalt der Datei index.php
Windows Ereignisanzeige Fehlermeldung

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

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

Umleitung mit Apache-Rewrite-Modul

Umleitung von einer Domain mit www auf eine Domain ohne www:

RewriteCond %{HTTP_HOST} ^www\.test\.tobias-seckinger\.de [NC]
RewriteRule ^(.*) http://test.tobias-seckinger.de/$1 [R=301,L,QSA]
  • [NC] = No case. Damit spielt die Groß- oder Kleinschreibung keine Rolle
  • [R=XXX] = Redirect mit HTTP-Status-Code XXX. Im Beispiel wird mittels 301 umgeleitet
  • [L] = Last. Letzte Regel, die beachtet werden muß.
  • [QSA] = Query String Append. Hängt neue Parameter an die ursprünglichen Parameter an. Wird für obige Regel nicht zwingend benötigt.
    Beispiel:

    RewriteRule ^source\.php$ /target.php?bar=foo [QSA,L]
    # Eingabe: http://tobias-seckinger.de/source.php?foo=bar
    # Umleitung zu: http://tobias-seckinger.de/target.php?foo=bar&bar=foo

Spam-Kommentare

Na wunderbar. Heute über 50 neue Kommentare mit kurzen schmeichelhaften Sätzen inklusive Rechtschreibfehler. Bei genauem Hinsehen, kommen einige Kommentare von der gleichen IP-Adresse, aber mit komplett anderen Namen und E-Mail-Adressen. Teilweise finden sich bei Google die gleichen Kommentare auch in anderen Blogs…

Mir erschließt sich leider nicht, wozu das gut sein soll. Hier zwei der besagten Kommentare:

  • “That’s the best asewnr of all time! JMHO”
  • “You rlaely saved my skin with this information. Thanks!”

Mehrsprachige Inhalte kennzeichen

Google unterstützt die Kennzeichnung von inhaltlich ähnlichen bzw. gleichen Inhalten, die aber in verschiedenen Sprachen vorliegen mit einem zusätzlichen Attribute.

<link rel="alternate" hreflang="de" href="http://www.example.de/page-de.html" />
<link rel="alternate" hreflang="en" href="http://www.example.de/page-en.html" />

Das Attribute hreflang kennzeichnet die verwendete Sprache. Für Inhalte, die nicht als HTML-Seite zur Verfügung stehen, dann dies über einen HTTP-Header gekennzeichnet werden:

Link: ; rel="alternate"; hreflang="es"

Die möglichen Werte müssen sich an der ISO 6391-1 und optional für Regionen an ISO 3166-1 Alpha 2 orientieren.

Hilfsklassen unter Extbase

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