Manchmal muss man eine Extension per Hand entfernen, weil durch ihre einbundung nur noch weiße Seiten erscheinen. Es gibt mehrere Stellen, an denen man eventuell Veränderungen vornehmen muss:

  • typo3conf/PackageStates.php
  • typo3conf/LocalConfiguration.php
  • und notfalls auch typo3temp löschen

Bei der Website http://netzdurchblick.de arbeiten wir mit einem grafischen Menü, bei dem die Buttons für NO, RO und ACT aus dem Ressourcen-Feld der jeweiligen Rubriken Startseite entnommen haben.

temp.hauptmenue = HMENU
temp.hauptmenue {
   special = list
   special.value = 238,197,247,165,1197,901
   1 = GMENU
   1 {
      NO = 1
      NO {
        5 = IMAGE
        5 {
            file.import.field = media
            file.import = uploads/media/
            file.import.listNum = 2
        }
        ATagTitle.field = subtitle 
        XY = [5.w],[5.h]
        transparentBackground = 1
        wrap = |
      }
      RO < .NO
      NO.5.file.import.listNum = 4
      ACT < .NO
      ACT.5.file.import.listNum = 4
   }
}

Bei der neuen Version funktioniert das leider nicht mehr, da eine Abstraktionsebene vor das Dateisystem gelegt wurde. Nach vielen mühsamen Experimenten habe ich folgende Lösung für das gleiche Problem gefunden (mit Hilfe von http://www.typo3.net/forum/thematik/zeige/thema/118444/):

temp.hauptmenue = HMENU
temp.hauptmenue {
  special = list
  special.value = 238,197,247,165,1197,901
     
  1 = GMENU
  1 {
     expAll = 1
     noBlur = 1
     NO = 1
     NO {
       XY = [5.w],[5.h]
       format = png
       quality = 100
       backColor = transparent
       5 = IMAGE
       5 {
         file {
         format = png
         import.cObject = FILES
         import.cObject {
           references {
             table = pages
             uid.field = tsfe:id
             fieldName = media
           }
           maxItems = 1
           begin = 2
           renderObj = IMG_RESOURCE
           renderObj {
             required = 1
             file.import.data = file:current:publicUrl
           }
          }
         }
       }
       ATagTitle.field = subtitle // title
     } # ende NO

     RO < .NO
     NO.5.file.import.cObject.begin = 4

     ACT < .NO
     ACT.5.file.import.cObject.begin = 3
  }
}

Frustrierenderweise funktionierte dann der RO-Effekt trotzdem nicht. Erst der Hinweis unter http://www.typo3.net/forum/thematik/zeige/thema/114717/ hat mich dann darauf gebracht im Haupttemplate noch die folgende Zeile unterzubringen

page.jsInline.10 = TEXT
page.jsInline.10.value (
var version = "n3";
)

Ein paar Hinweise findet man unter:

  • http://wiki.typo3.org/File_Abstraction_Layer#How_can_I_access_the_typolink-field_from_the_meta-data_of_one_file.3F
  • http://wiki.typo3.org/File_Abstraction_Layer#How_to_use_.22levelmedia.22_with_6.x_.3F
  • https://www.merec.org/typo3/verwendung-von-fal-file-abstraction-layer-typo3-6-0-mit-templavoila

Beim Update auf Typo3 6.2 gibt es Probleme mit einigen Extensions, bei mir sind es vor allem die von Georg Ringer, die ich bisher gern benutzt habe. Für viele Extensions gibt es einfach keine Anpassung an die neue Typo3-Version. Ein Hauptbroblem sind wohl die Veränderungen im Zusammenhang mit dem Pfad t3lib, der nicht mehr exisitiert. Daher laufen alle Programme ins Leere, die hier nach Bibliotheken suchen.

Einnen Versuch wert ist es, die entsprechende Require-Zeile einfach auszukommentieren in der jewiligen Datei typo3conf/ext/<extension>/pi1/class.tx_<extension>_pi1.php:

#require_once( PATH_tslib . 'class.tslib_pibase.php' );

Geklappt hat das bei mir mit

  • macina_searchbox
  • rgtabs (weiter Probleme analog zu https://forge.typo3.org/issues/43834 und https://forge.typo3.org/issues/41632, Lösung hier unter #8 )
  • dropdown_sitemap
  • chgallery (eine angepasste Version ist unter https://github.com/derhansen/TYPO3.ext.chgallery und https://github.com/georgringer/TYPO3.ext.chgallery verfügbar)
  • rgmediaimages (zusätzlich in typo3conf/ext/rgmediaimages/class.tx_rgmediaimages_fe.php)
  • rgsmoothgallery (eine angepasste Version ist unter https://forge.typo3.org/issues/58818 verfügbar, funktioniert nur mit der Anpassung wie bei rgtabs)

Bei manchen Extensions kann die Zeile in mehreren Dateien auftauchen.

Bei manchen Extensions weiss ich überhaupt nicht mehr, ob sie in dem System benutzt werden. Ich kenne momentan nur einen Weg das zu ermitteln und zwar von phpMaAdmin aus mittels

SELECT * FROM `tt_content` WHERE `list_type` like "%flash%"

Hier auf der Suche nach dem st_flashplayer.

Nur damit es ich nicht vergesse, die unter https://forge.typo3.org/issues/41632, Lösung hier unter #8 vorgeschlagene Lösung sieht folgendermaßen aus:

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;
}

DerHansen löst das bei chgallery folgendermaßen:

function includeLocalLang()     {
 $llFile = t3lib_extMgm::extPath('chgallery').'locallang.xml';
 return $GLOBALS['LANG']->includeLLFile($llFile, FALSE);
 }

Die zweite Lösung wirkt auf mich korrekter.

Nachdem nun endlich auch TemplaVoila verfügbar ist kann ich an die Updates der „alten“ Systeme gehen. Dabei habe ich erste Erfahrungen gemacht:

  1. Vor der Aktualisierung sollten alle selbst installierten Extensions deaktiviert werden. Bei mir vor allem rgtabs und dropdown_sitemap. Sonst gibt es hinterher Probleme.
  2. Dann möglichst alle Caches löschen, dazu den Ordner typo3temp vollständig leeren.
  3. Nun den Link auf die neuen Sourcen setzen und die Seite aufrufen.
  4. Man muss dann ins Install-Tool (Hoffentlich ist das Passwort noch präsent, sonst einfach in der Konfigurationsdatei neu setzen) und folgt den dort angegebenen Schritten
  5. Important actions: datenbank überprüfen, tt_address und tt_news deaktivieren, Extensions checken,
  6. Menüpunkt Upgrade Wizard, alle Updates durchführen (das kann schon mal einige Minuten dauern, bei umfangreichen Projekten)
  7. Folder structure untersuchen und reparieren lassen
  8. Im Backend anmelden
  9. Dann gibt es manchmal es ein Problem mit der Extension-Liste. Die Lösung war unter https://forge.typo3.org/issues/52859 zu finden, die Zeile muss in die Datenbank:
    INSERT INTO tx_extensionmanager_domain_model_repository VALUES ('1', '0', 'TYPO3.org Main Repository', 'Main repository on typo3.org. This repository has some mirrors configured which are available with the mirror url.', 'http://typo3.org/wsdl/tx_ter_wsdl.php', 'http://repositories.typo3.org/mirrors.xml.gz', '1346191200', '0');
  10. Weitere Probleme kann es mit der Dateiliste geben. Eventuell wird eine zusätzliche Freigabe automatisch erzeugt, die dann Probleme bereitet (s.u.).
  11. Die Extensionliste aktualisieren, Extensions aktualisieren und ggf. wieder aktivieren.
  12. Spracheinstellungen vornehmen und aktualisieren

Wenn keine besonderen Extensions auftauchen, dann sollte es das gewesen sein.

Beim Erzeugen von Grafiken muss man in der Regel die Zeile

file.treatIdAsReference = 1

hinzufügen.

Gelegentlich taucht ein Fehler auf, der unter http://wiki.typo3.org/Exception/CMS/1319455097 beschrieben ist:

Oops, an error occurred! Error while fetching permissions for More information regarding this error might be available online.
exception raised in the upgrade wizard from Version 4.5.29 LTS to 6.2.2 LTS. Step: "Migrate all file links of RTE-enabled fields to FAL"
no error messages appeared in /var/log/apache/error_log
I found the solution;-) I had a new file storage in fileadmin which was automatically created by the upgrade process.
how to solve this; go to your mysql database; use  select uid, name from sys_file_storage;
find entries which are new and not necessary! (be very careful - this could destroy your typo3 installation!!)
delete from sys_file_storage where uid = xxx;

Das geschieht anscheinend immer dann, wenn man weitere Verzeichnisfreigaben gemacht hat. Ich lösche dann dem Tipp folgend alle Einträge mit einer uid>1, danach kommt man dann auf alle Fälle weiter.

 

Wenn ein normaler Redakteur (nicht Admin) versucht ein Bild einzubinden und die Meldung „Access denied“ bekommt, dann muss man die Zugriffsrechte auf die (neue) Tabelle File Reference bearbeiten: http://www.npostnik.de/2013/07/

Es ist nicht ganz einfach Informationen zu finden, wie man bei Typo3 zu korrekten Fehlerseiten kommt, die auch einen 404er Fehlercode zurückliefern, vor allem wenn man mit simulatestatic arbeitet. Untersuchen kann man den gelieferten Fehlercode übrigens recht einfach mit der Firefox-Extension Firebug. In der Rubrik Netzwerk wird dort bei einem Seitenaufruf auch der Statuscode mit angezeigt.

Es gibt bei Typo3-Seiten eigentlich zwei unterschiedliche Situationen:

  1. Typo3 wird direkt (/index.php?id=000) oder indirekt (/000.html) mit einer illegalen id aufgerufen
  2. Die Domain wird mit einer URL aufgerufen, die nicht zur Typo3-Installation passt, z.B. mit einem Unterverzeichnis (/mediawiki/..)

Der erste Fall ist relativ einfach zu regeln, man erstellt in Typo3 eine Fehlerseite (hier fehler404.html) und erweitert die Konfigurationsdatei typo3conf/localconf.php folgendermaßen:

[FE][pageNotFound_handling] = /fehler404.html
[FE][pageNotFound_handling_statheader] = HTTP/1.0 404 Not Found

Damit wird für den Fall einer illegalen id die Fehlerseite aufgerufen und ein 404er Fehlercode zurückgeliefert.

Bleibt noch der zweite Fall. Typo3 würde in der Regel die Startseite liefern, egal was aufgerufen wurde. War in der aufgerufenen URL ein Unterverzeichnis angegeben, so wird das in dem Sinne berücksichtigt, dass Typo3 das Stylesheet nicht mehr findet. Die ausgelieferte Seite sieht also ganz komisch aus.

Um das zu ändern muss man an die Datei .htaccess ran, die man für simulatestatic ja aktivieren musste. Hier die .htacess, so wie sie von Typo3 geliefert wurde, ich habe alle Kommentarzeilen entfernt. Verändert habe ich lediglich die vorletzte Zeile:

<FilesMatch "\.(js|css)$">
  <IfModule mod_expires.c>
    ExpiresActive on
    ExpiresDefault "access plus 7 days"
  </IfModule>
  FileETag MTime Size
</FilesMatch>

<IfModule mod_rewrite.c>

RewriteEngine On

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.+)\.(\d+)\.(php|js|css|png|jpg|gif|gzip)$ $1.$3 [L]

RewriteRule ^(typo3/|t3lib/|fileadmin/|typo3conf/|typo3temp/|uploads/|favicon\.ico) - [L]

RewriteRule ^typo3$ typo3/index_re.php [L]

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-l

RewriteRule .* index.php?id=000 [L]

</IfModule>

In vielen Versionen der Datei werden nur Dateien mit der Endung .html ersetzt (RewriteRule ^[^/]*\.html$ index.php), hier wird jetzt immer die index.php aufgerufen, wenn die ursprüngliche Datei nicht gefunden wurde. Die index.php wird aber mit einer illegalen id aufgerufen, so dass ein Fehler nach Punkt 1 erzeugt wird. Typo3 wertet die übergebene id als String aus und nicht numerisch, eine id 000 wird es als sicherlich nicht geben, da beim Erzeugen einer Seite die id numerisch festgelegt wird. Die Idee dazu stammt von http://typo3.toaster-schwerin.de/typo3_dev/2008_04/msg00492.html.

Sofern die ursprünglich aufgerufenen id gültig war, spielt diese fehlerhafte id keine Rolle. Eine Erklärung dafür habe ich nicht, eventuell hat das etwas mit der Auswertungsreihenfolge von GET/POST Daten zu tun. Von daher ist nicht sichergestellt, dass dieser Trick auch in zukünftigen Typo3-Versionen funktioniert.

Ein Problem gibt es aber, wenn ein Slash (/) im Dateinamen auftaucht, dann gibt es zwar einen korrekten 404er Returncode, aber eine nackte Fehlerseite, da wieder das CSS nicht gefunden wird.

Mit

RewriteRule ^[^/]*\.html$ index.php [L]

stattdessen werden nur Adresse ohne Slash (/) ersetzt, bei anderen Adressen wird die Fehlerseite des Apache gezeigt, mit korrektem Fehlercode. Nun gibt es zwei unterschiedliche Fehlerseiten, einerseits die in Typo3, andererseits die vom Webserver. In beiden Fällen wird aber ein korrekter Fehlercode geliefert.

 

Nach der Aktualisierung von Typo3 oder der Übersetzungen in Typo3 kann es Probleme mit dem Extension-Manager geben. Dort steht dann nur die „neue“ Version zur Verfügung und nicht mehr die Punkte für die  „alte Version“.
Wir haben nun zwei Möglichkeiten:

1. Wir lassen sich von Herrn Weiland erzählen, wie die neue Version funktioniert:
http://jweiland.net/typo3-hosting/service/video-anleitungen/typo3-version-45-extension-manager.html

2. Wir schalten das alte Interface wieder frei:
man muss dazu unter Adminwerkzeuge -> Erweiterungen -> Lokale Erweiterungsliste  auf  Extension Manager klicken.
Dort unter Konfiguration bei Alte Module anzeigen den Haken entfernen. Unten auf Aktualisieren klicken, den Haken wieder setzen, erneut auf Aktualisieren klicken.
Also einmal raus, dann wieder rein!!!
Danach oben auf den Blitz Alle Caches löschen.
Nun sollte die komplette Auswahl wieder zur Verfügung stehen, wenn nicht nochmal F5 zum Aktualisieren des Browsers.

Die Anmeldung mit der Extension feuser_register haute nicht mehr hin. Es gab nur in der Logdatei eine Fehlermeldung:

Core: Exception handler (WEB): Uncaught TYPO3 Exception: #1294681467: Validation failed for: domain.de <Klaus.Test@domain.de> | Exception thrown in file /srv/www/htdocs/typo3_src-4.5.6/t3lib/mail/class.t3lib_mail_rfc822addressesparser.php in line 184

Es finden sich hierzu mehrere Problembeschreibungen im Web. Anscheinend ist es so, dass die Typo3-Programmierer mit ihrem Code im Recht sind aber zu pingelig und dadurch viele Extensions nicht mehr funktionieren, die sich nicht so genau an die Regeln halten. Solche ärgerlichen Dinge gibt es leider immer wieder. Für eine Lösung müssen wir wohl auf eine Aktualisierung von sr_feuser_register warten.

Geholfen hat mir der Text http://www.typo3.net/forum/beitraege//103507/ hiernach ist zumindest ein Workaround:

Ich habe im Installtool folgende Einstellung vorgenommen:

[MAIL][substituteOldMailAPI] = 0

 

 

Veröffentlicht unter typo3.

Das Backend von Typo3 sieht in den Seiteneigenschaften mehrere Felder für Meta-Informationen vor. Will man die Einträge auch in die Seite eingebunden haben, so muss man das Template entsprechend anpassen. Folgender Typoscript-Code leistet das (hier als Beispiel die Version meiner Schule):

page.meta{
 keywords.field = keywords
 keywords.ifEmpty (
   Stadtteilschule, Richard-Linde-Weg, Lohbrügge, Bergedorf, Hamburg, Bildung, Medien
 )
 description.field = description
 description.ifEmpty (
   Stadtteilschule Richard-Linde-Weg
 )
}

Wenn in das jeweilige Feld ein Eintrag gemacht wurde, dann wird dessen Inhalt genommen, ansonsten der Default-Eintrag hinter der ifEmpty Bedingung.

Es gibt noch ein drittes Feld namens Inhaltsangabe, dass kann man unter der Bezeichnung abstract erreichen.
Ein Alternative zu diesem Ansatz sollen folgende Zeilen bilden:

page.meta.keywords = Stadtteilschule, Richard-Linde-Weg, Lohbrügge, Bergedorf, Hamburg, Bildung, Medien
page.meta.keywords.override.field = keywords 
page.meta.description = Stadtteilschule Richard-Linde-Weg
page.meta.description.override.field = description

Ich habe eben eine paar Stunden damit verbracht ein weiteres Mal cal dazu zu bringen, seine Daten mit einem Google-Kalender zu synchronisieren. Beim ersten Mal ging alles ganz einfach, ich habe es damals aber leider nicht dokumentiert.

Zwei Voraussetzungen müssen gegeben sein.

  1. Ein Google-Kalender muss eingerichtet und freigegeben sein
  2. Typo3 muss mindestens in der Version 4.3 vorliegen, damit die Extension Scheduler zur Verfügung steht

Bevor man mit der Einrichtung des Kalender beginnen kann sollte man Typo3 mindestens auf die Version 4.3 aktualisiert haben. Die folgende Beschreibung bezieht sich aber im Zweifelsfall auf Version 4.5.2. Seit der Version 4.3 liefert Typo3 eine Systemextension namens Scheduler mit. Diese ist für alle zeigesteuerten Prozessse innerhalb der Typo3-Installation zuständig.

Damit der Scheduler arbeiten kann benötigt er auf Systemebene einen Cronjob, der folgenden Art:

5,35  *   *   *   *   /usr/bin/php5 /srv/www/httpdocs/typo3/cli_dispatch.phpsh scheduler > /dev/null

Hier wird zweimal pro Stunde der Scheduler aktiviert, immer auf 5 und 35. Die Pfade zu dem Script cli_dispatch.phpsh können bei anderen Installationen natürlich abweichen.

Nun kann der Scheduler innerhalb von Typo3 zeitgesteuerte Vorgange verwalten.

Für den Kalender cal geschieht die Einrichtung automatisch, wichtig ist nur, dass der Google-Kalender erst eingerichtet wird, wenn der Scheduler vorhanden ist. Mich hat viel Zeit gekostet, dass ich mit einem System 4.2.17 begonnen und dort den Kalender schon eingerichtet hatte. Ich musste den Kalender löschen und neu einfügen, dann wurde er auch automatisch im Scheduler berücksichtigt.

Google-Kalender mit cal

Das Feld Scheduler-ID wird dabei automatisch ausgefüllt.

Bleibt noch die Frage, wo bekommt man die Externe Kalender Adresse (URL) her? Die muss man sich von den Google-Kalender-Seiten holen. Wählt man dort Einstellungen (ganz links unten), so landet man auf der Übersichtsseite für die Kalender-Einstellungen. Hier klickt man in der Zeile mit dem zu benutzenden Kalender auf Freigeben: Einstellungen bearbeiten. Nun findet sich weit links oben ein Link Kalenderdetails. Klickt man hierauf, so öffnet sich das folgende Fenster:

Google-Kalender URL

In diesem Fenster kopiert man mit der rechten Maustaste den Link vom unteren Ical-Button. Ich habe dabei auch jeweils das Protokoll von https auf http geändert. Den Link fügt man dann ins Typo3-Formular ein.

Veröffentlicht unter typo3.

Die Website meiner Schule ist unter mehreren Domains erreichbar. Das gibt Probleme mit dem Google API-Key und  pit_googlemaps. Die Extension sieht die Nutzung mehrerer Keys nicht direkt vor. Das Problem ist aber über das Setup im Template ganz einfach lösbar, indem man folgenden Code am Ende anfügt:

[globalString = ENV:HTTP_HOST = *schulerlw.de]
 plugin.tx_pitgooglemaps_pi1.googleAPIKey = ABQIAAAAQ4awX-q5a_T3PuHs7qabUxTeO06x_derRestistgeheim
[globalString = ENV:HTTP_HOST = *richard-linde-weg.de]
 plugin.tx_pitgooglemaps_pi1.googleAPIKey = ABQIAAAAQ4awX-q5a_T3PuHs7qabUxTeZaE-derRestistgeheim
[GLOBAL]

Damit sucht sich Typo3 den Key aus, der zur jeweiligen Domain passt.