PHP Fatal error:  Call to undefined method TYPO3\\CMS\\Core\\Utility\\General
Utility::readLLXMLfile() in /srv/www/htdocs/typo3conf/ext/we_gmanfahrt/pi1/
class.tx_wegmanfahrt_pi1_wizicon.php on line 61, referer: ...

Es stellte sich heraus, dass die Extension „we_gmanfahrt“ eine veraltete Funktion namens „t3lib_div::readLLXMLfile()“ verwendete.
Diese Funktion ist seit TYPO3 4.6 veraltet und wurde in Version 6.0 entfernt. Seit dem sollte die Funktion „t3lib_l10n_parser_Llxml::getParsedData()“ verwendet werden.
Gesagt, getan.
Die Übergabeparameter sind gleich geblieben und somit sollte durch einen Tausch der Funktionen das Problem behoben sein.
Sollte…den das Phänomen beim Anlegen eines neuen Inhaltselements blieb.
Im Errorlog fand sich nun ein neuer Eintrag:

PHP Fatal error:  Call to undefined method tx_wegmanfahrt_pi1_wizicon::
getCharset() in /srv/www/typo3/typo3_src-6.1.0/typo3/sysext/core/Classes/
Localization/Parser/LocallangXmlParser.php on line 54, referer: ...

Wie sich herausstellte, hängt dies mit dem „neuen“ TYPO3 zusammen. Eine Lösung wurde von Thomas Dudzak im Bugtracker bereitgestellt:

/**
  * Reads the [extDir]/locallang.xml and returns the $LOCAL_LANG array found in that file.
  *
  * @return    The        array with language labels
  */
  function includeLocalLang()    {
    $llFile = t3lib_extMgm::extPath('td_calendar').'locallang.xml';
    $version =  class_exists('t3lib_utility_VersionNumber')
              ? t3lib_utility_VersionNumber::convertVersionNumberToInteger(TYPO3_version)
              : t3lib_div::int_from_ver(TYPO3_version);
    if ($version >= 4007000) {
      $object = t3lib_div::makeInstance('t3lib_l10n_parser_Llxml');
      $LOCAL_LANG =  $object->getParsedData($llFile, $GLOBALS['LANG']->lang);
    } else {
      $LOCAL_LANG =  t3lib_div::readLLXMLfile($llFile, $GLOBALS['LANG']->lang);
    }
    return $LOCAL_LANG;
  }

Cannot find configuration. This file is probably executed from the wrong location.

Kann damit gerechnet werden, dass der Pfad zur localconf.php nicht gefunden wird.

Dies liegt entweder daran, dass die Datei- und/oder Verzeichnisrechte falsch gesetzt (chmod und chown der entsprechenden Dateien/Verzeichnisse helfen hierbei), oder das über PHP Beschränkungen definiert sind. In diesem Fall hilft ein Blick in die Ausgabe von „phpinfo()“, speziell der Bereich safe_mode (sollte off sein) und open_basedir (sourcen sollten erreichbar sein).

Standardwerte von „Text mit Bild“ per Typoscript ändern

# Bildposition "Neben dem Text links"
mod.wizards.newContentElement.wizardItems.common.elements.textpic.tt_content_defValues.imageorient = 26
# Anzahl der Spalten auf 1
mod.wizards.newContentElement.wizardItems.common.elements.textpic.tt_content_defValues.imagecols = 0

Standardwert von „Nur Bilder“ per Typoscript ändern

# Bildposition "Oben links"
mod.wizards.newContentElement.wizardItems.common.elements.image.tt_content_defValues.imageorient = 2
# Anzahl der Spalten auf 1
mod.wizards.newContentElement.wizardItems.common.elements.image.tt_content_defValues.imagecols = 0

page.10 = TEMPLATE
page.10 {
  template = CASE
  template {
	key.cObject = TEXT
	key.cObject {
	  field = backend_layout
	  ifEmpty.cObject = TEXT
	  ifEmpty.cObject.data = levelfield: -2, backend_layout_next_level, slide
	}
	1 = FILE
	1.file = fileadmin/templates/startseite.html
	2 = FILE
	2.file = fileadmin/templates/zweispaltig.html
	default = FILE
	default.file = fileadmin/templates/allgemein.html
  }
}

Die Zeile „ifEmpty.cObject.data = levelfield: -2, backend_layout_next_level, slide“ sorgt dafür, dass das entsprechende Template der aktuellen Seite verwendet wird. Ist auf der aktuellen Seite kein Backend-Layout gesetzt, wird die darüber liegende Seite geprüft. Ist dort ein Template vorhanden, wird dies verwendet, andernfalls wird wiederum die Seite darüber abgefragt. Liegt kein Backend-Layout vor, greift der „default“-Eintrag und das Template „allgemein.html“ wird verwendet.

Auf ein visuelles Gut bin ich beim Durchschauen der Änderungsliste gestoßen… das Grid View. Mit ihm lässt sich die bisherige Spaltenansicht (Links, Normal, Rechts, Rand) so anpassen, dass diese wie im Frontend dargestellt werden. Also nicht nur nebeneinander wie bisher, sondern auch darüber, darunter, über mehrere Zeilen hinweg, und und und. Was in Zeiten vor CSS mit „Layouttabellen“ realisiert wurde, kann jetzt dementsprechend im Backend mit einem komfortablen Wizard erstellt werden.

TemplaVoila!-User kennen diese Art der Darstellung ja schon, für diejenigen die zum ersten Mal damit arbeiten wollen, findet sich nachfolgend eine kleine Einführung.

Das Grid View kann auf jeder Seite eingebunden werden. Dazu wählt man links in der Navigation das Listenmodul und legt einen neuen Datensatz vom Typ „Backend Layout“ an. Hier kann der Titel, ein Bild und eine Beschreibung hinterlegt werden. Der Dreh und Angelpunkt des Datensatzes ist jedoch der Konfigurationsbereich. Glücklicherweise wurde hier ein Wizard implementiert, über den die Konfiguration einfach und intuitiv erstellt werden kann. Wie zu erwarten, lassen sich über das Plus-Zeichen am rechten, bzw. unteren Rand weitere Felder hinzufügen und über das Minus-Zeichen die Felder wieder entfernen. In den Feldern selbst, kann die Position über die Pfeile verschoben werden und bei einem Klick auf das Stift-Symbol der Name, bzw. die Spaltennummer bearbeitet werden. Die Spaltennummern sind uns besser bekannt als „colPos“, daher sollten diese von 0 aufsteigend nummeriert werden. Über die Spaltennummer wird später im Typoscript der Inhalt an einen Marker gebunden und so im Frontend ausgegeben.

Nach dem Speichern des Grid View, muss dieses in den Seiteneigenschaften einer Seite zugeordnet werden. Hierbei kann man eine Darstellung für die aktuelle Seite, sowie für die darunter liegenden Seiten definieren. Wurden die Änderungen in den Seiteneigenschaften gespeichert, ist das Grid View aktiv und der Seiteninhalt kann in die entsprechenden Felder eingebunden werden.

Jetzt muss nur noch per Typoscript festgelegt werden, welches Feld auf der Website wo ausgegeben werden soll und wir haben das Grid View fertig integriert.

page.10.marks{
 LOGO = CONTENT
 LOGO {
  table = tt_content
  select.where = colPos=0
 }
 ...
 LINKE_SPALTE{
  select.where = colPos=3
 }
 ...
 ADVERTS{
  select.where = colPos=x
 }

Aus meiner Sicht ist das Grid View eine große Bereicherung für das Backend von TYPO3 daher gehen Komplimente an alle, die daran mitgearbeitet haben.

Genug geschrieben, jetzt ist eure Meinung gefragt.

1. In der Datei „AndroidManifest.xml“ der Anwendung (App), muss diese als debugbar definiert werden. Dazu wird der Application-Tag um android:debuggable=“true“ erweitert. Alternativ kann auch im Reiter „Application“ der Wert von „Debuggable“ auf „true“ geändert werden.
vorher:

nachher:

2. Das Gerät (in meinem Fall ein Archos 10.1), muss angeschlossen sein und das „USB-Debugging“ aktiviert sein. Zur Kontrollen kann dies über ‚Einstellungen -> Anwendungen -> Entwicklung‘ geprüft werden. Hier muss bei ‚USB-Debugging‘ der Haken gesetzt sein.
3. Nun muss für die Verwendung eines Gerätes eine Regel erstellt werden. Diese Regeln (engl. rules) sind an den Hersteller gebunden. Sollten also mehrere Geräte zur Entwicklung verwendet werden, müssen in der Regel auch mehrere Einträge erstellt werden. Um eine Regel zu erstellen, wechselt man mit ‚su‚ zum root-user. Anschließend wird in das Verzeichnis ‚/etc/udev/rules.d‘ gewechselt. Hier erstellt man mit ‚vi 51-android.rules‚ eine neue Datei und füllt diese mit nachfolgendem Inhalt (i drücken um in den insert-Modus von vi zu gelangen):

SUBSYSTEMS=="usb", ATTRS{idVendor}=="0e79", MODE="0666", SYMLINK+="android_adb"
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0e79", MODE="0666", SYMLINK+="android_fastboot"

Stehen noch weitere Geräte zum debuggen zur Verfügung, müssen diese darunter definiert werden. Hierzu können die beiden Zeilen kopiert und an der Stelle ‚0e79‘ abgeändert werden (0e79 steht hierbei für den Hersteller Archos). Mit der Esc-Taste wird in den command-Modus von vi gewechselt. Hier lässt sich mit dem Befehl :wq<Enter> die Datei speichern und schließen.

Nun kommt der Schritt, der in der Beschreibung zu Ubuntu nicht genannt wird. Unter OpenSuSE muss in der Datei ‚adb_usb.ini‘ (zu finden im Home-Verzeichnis im Ordner .android) zusätzlich die Hersteller-ID eingetragen werden. In meinem Fall also ‚0x0e79‘. Im Anschluss daran, kann per ‚adb kill-server‚ und ‚adb devices‚ überprüft werden, ob das Gerät erkannt wurde, oder nicht.

PS: Sollte die Hersteller-ID (idVendor) nicht bekannt sein, kann diese nach dem Anschließen des Gerätes mit folgendem Befehl ermittelt werden: ‚tail -f /var/log/messages‚. Dort sollte ein Eintrag, ähnlich dem nachfolgenden, erscheinen:

usb 1-5: New USB device found, idVendor=0e79, idProduct=1411

In Eclipse kann nun bei einem Klick auf ‚Run‘ die Anwendung auf dem Gerät getestet werden.