Absurditäten I

25. Juni 2010

Ich habe beschlossen, eine neue Kategorie einzuweihen. Die Kategorie “Community Absurditäten” soll aufzeigen, worauf man so alles stößt, wenn man als Programmierer ein Problem hat, und dieses via Google Suche zu lösen versucht. Wie oft ist es mir inzwischen schon passiert, dass ich ein bestimmtes Problem suche, in einem Forum auf einen Eintrag stoße, wo genau dieselbe Frage gestellt wird, die auch mich quält, und die Community dann statt einer Antwort eine völlig sinnentleerte Bemerkung parat hat. Wahrscheinlich fühlt sich so eine RTFM Bemerkung unglaublich gut an, aber hilfreich ist sie nunmal gar nicht. Wie viele Stunden Recherche hätte ich mir erspart, wenn die entsprechenden Leute statt einer solchen Bemerkung eine wirklich hilfreiche Antwort gegeben hätten?

Okay, starten wir mit Beispiel 1. Auf meiner Suche nach der Lösung für mein typo3 Problem mit der language detection Extension stieß ich auf diese Seite mit folgender, hochnäsiger Antwort:

Hi,

warum suchst du nicht einfach im TER nach language detection? zu schwer?

georg

Dieser Typ sollte sich mal fragen, wem dieser Beitrag irgendwas bringt. Das ist für alle verschwendete Zeit, für ihn verschwendete Zeit die er mit dem Schreiben einer so sinnlosen Bemerkung verbringt und für alle anderen Zeit, die das Lesen dieser Unverschämtheit kostet. Es ist ab und an durchaus legitim, jemanden aufzufordern, erstmal die Doku zu lesen, aber wenn man schon das Bedürfnis hat, derjenige welcher zu sein, warum ist es dann nicht möglich, wenigstens einen Link mit anzugeben? War wohl zu schwer für “georg”. Davon abgesehen ist meiner Meinung nach die Doku sowohl von typo3 als auch von der Extension wenig bis gar nicht hilfreich. Also wenn er findet, dass die Antwort auf die Frage leicht in der Doku zu finden ist, wäre es doch möglich, einen Link zum entsprechenden Thema zu posten und so dem Fragesteller indirekt doch zu helfen.

Irgendwo fragt man sich halt doch, wem hier was “zu schwer” ist. Für “georg” scheint’s jedenfalls schwierig zu sein, kompetent auf Fragen hilfloser Typo3 Neulinge zu antworten, stattdessen nutzt er die Gelegenheit, um sich aufzuplustern. Man weiß ja, was die Psychologen über diejenigen sagen, die sowas nötig haben…

Language Detection

25. Juni 2010

Die Extension rlmp_language_detection dient dazu, auf einer mehrsprachigen Seite eine automatische Sprachumschaltung anhand der Browsersprache zu ermöglichen, und dies, zumindest in der Theorie, möglichst schnell und einfach. Natürlich weiß ich inzwischen, dass bei typo3 gar nichts schnell oder gar einfach geht. Bei meinem ersten Versuch, dieses Addon dazu zu bewegen, zu funktionieren, brauchte ich knappe 2 Tage. Heute, um ein paar Erfahrungen reicher, brauchte ich nur noch eine gute Stunde. Und da eine Google Suche wie immer nur mäßig hilfreich war und eher dazu beigetragen hat, meinen Frustrationspegel in die Höhe zu treiben, will ich mal erläutern, wie genau ich nun vorgegangen bin, um meine Extension zum Laufen zu bringen. Ich möchte betonen, dass vielleicht gar nciht alle Schritte notwendig sind. Ich beschreibe einfach mal, was ich getan habe, ohne Anspruch auf Richtigkeit oder Vollständigkeit.

1. die Extension aus dem Repository runtergeladen und im Extension Manager installiert

2. im Root Typoscript folgendes hinzugefügt:

  1. plugin.tx_rlmplanguagedetection_pi1 {
  2. defaultLang = de
  3. useOneTreeMethod = 1
  4. }

3. erwartungsfroh probierte ich es das erste mal aus – keine Reaktion. Nach einer Recherche fügte ich dem Typoscript code folgendes hinzu:

  1. page.1000 =< plugin.tx_rlmplanguagedetection_pi1

4. ein Update der Seite brachte mir jetzt folgende Fehlermeldung:

NO entry in the $TCA-array for the table “static_languages”.

5. google teilte mir nach kurzer Recherche mit, dass man für meine Extension eine weitere braucht: static_info_tables. Also hab ich diese installiert, getestet: keine Reaktion. Vom letzten mal habe ich gelernt, dass für rlmp_language_detection unter keinen Umständen eine Standardsprache definiert sein darf. ALso habe ich in meinem TS folgende Zeile auskommentiert:

  1. #config.sys_language_uid = 0

6. Auch das brachte kein nennenswertes Ergebnis. Da ich tief in meinem Herzen trotz der zermürbenden Stunden und Tage meines Lebens, die Typo3 mich schon gekostet hat, doch eine PHP Programmiererin bin, hab ich beschlossen, die Sache so anzugehen, wie es eigentlich in meiner Natur liegt. Statt mich über die Typo3 Community mit ihren wenig hilfreichen Antworten zu ärgern, hab ich die Datei typo3conf/ext/rlmp_language_detection/pi1/class.tx_rlmplanguagedetection_pi1.php geöffnet und Schritt für Schritt geprüft, was in der main Funktion so passiert. Und was stellte ich fest? In folgendem Absatz brach das Script ab:

  1. // Break out if the session tells us that the user has selected language
  2. if (!$this->conf['dontBreakIfLanguageAlreadySelected']) {
  3. if($GLOBALS["TSFE"]->fe_user->getKey('ses','tx_rlmplanguagedetection_languageSelected') == TRUE) {
  4. return $content;
  5. }
  6. }

7. Aha, soso! Eine Variable namens dontBreakIfLanguageAlreadySelected. Selbstverständlich hab ich bei meinen Tests immer die Index Seite aufgerufen, auch mal den Cache gelöscht, trotzdem gings nicht. Aber anscheinend geht das Script davno aus, dass eine Sprachauswahl schon stattgefunden hat. Also habe ich folgende Zeile meinem Typoscript hinzugefügt:

  1. plugin.tx_rlmplanguagedetection_pi1.dontBreakIfLanguageAlreadySelected = 1

8. Und plötzlich gings.

Das wirklich unglaublich frustrierende, zeitraubende, Nerven kostende an Typo3 ist, dass man, wenn etwas nicht funktioniert, völlig alleine gelassen wird. Man recherchiert bei Google und stößt so oft auf Beiträge, wo genau die Frage gestellt wird, die man selber hat. DAs mag eine dumme Frage sein, aber die Antwort ist dann eine herablassende Bemerkung a la “lies doch in der Doku nach”. Die Doku ist in diesem Fall – so wie meistens bei typo3 und seinen Extensions – einfach nur dürftig. Da hab ich weder was von static_info_tables noch darüber gelesen, dass dontBreakIfLanguageAlreadySelected wichtig werden könnte.

BildPosition: oben mitte als einzige, ausgewählte Option

25. Juni 2010

Im Grunde gibts dazu ja schon einen Beitrag, aber ich muss es trotzdem nochmal ganz deutlich schreiben, da Typo3 einfach der größte Mist auf Erden ist und prinzipiell immer anders reagiert. In Typo3 4.3.3. gelang es mir, die Bildposition auf eine Option, nämlich “oben mitte” zu beschränken und diese auch gleich als ausgewählt zu definieren:

  1. TCEFORM.tt_content.imageorient.removeItems = 1,2,8,9,10,17,18,25,26
  2. TCEFORM.tt_content.imageorient.default = 0
  3. TCEFORM.tt_content.imageorient.disableNoMatchingValueElement = 1

Typo3: nach Serverumzug geht weder BE Login noch Installer Login

24. Juni 2010

Die Überschrift beschreibt das Problem ja schon relativ treffend. Nachdem ich ein Typo3 Projekt auf einen neuen Server überspielen musste, ging plötzlich nur noch das Frontend. Weder war ein Login im Backend möglich, noch im install Tool. Wie üblich war eine Google Suche zu dem Thema ein mehrstündiges Unterfangen ohne viel Erfolg, bis ich dann schließlich doch auf etwas gestoßen bin, nämlich diese Seite.

Der Forennutzer “steffenK” hat, anders als die meisten Typo3 Snobs, eine Frage tatsächlich nicht nur beantwortet, sondern auch eine Lösung parat gehabt, die auch mir geholfen hat. Vielen Dank an den tapferen Poster, auch dafür, dass ich nicht wie schon so oft auf eine gestellte Frage eine Antwort a la “Lies doch in der Doku nach” oder “die Frage wurde schon gestellt” lesen musste.

Um das nochmal zu wiederholen, die Lösung in meienm Fall sah so aus, dass ich in der t3lib/class.t3lib_userauth.php folgenden Abschnitt auskommentiert hab:

  1. /*
  2. if ($_SESSION['login_challenge'] !== $loginData['chalvalue']) {
  3. if ($this->writeDevLog) t3lib_div::devLog('PHP Session stored challenge "'.$_SESSION['login_challenge'].'" and submitted challenge "'.$loginData['chalvalue'].'" did not match, so authentication failed!', 't3lib_userAuth', 2);
  4. $this->logoff();
  5. return FALSE;
  6. }
  7. */