Ich selber nutze zwar gar kein Windows mehr und da ich seit geraumer Zeit auch auf lighttpd statt auf Apache setze, hat der folgende Linktipp noch weniger Relevanz für mich, aber ich will die ausführliche Anleitung von Stefan trotzdem würdigen.

Wer tatsächlich unter Windows ein entsprechendes TYPO3-System installieren möchte (muss? ) und eine Schritt-für-Schritt-Anleitung benötigt, die nach jedem einzelnen Kapitel ein immer noch lauffähiges System hinterlässt, kann ich euch das Folgende nur ans Herz legen:

Stefans TYPO3 Seite – Manuelle Installation eines WAMP Servers

Weil ich so ein fauler Mensch bin, zitiere ich einmal aus der Wikipedia:

OpenID ist ein dezentrales Authentifizierungssystem für Webseiten und andere webbasierte Dienste. Es erlaubt einem Benutzer, der sich bei seinem sogenannten OpenID-Provider einmal mit Benutzername und Kennwort angemeldet hat, sich nur mit Hilfe der sogenannten OpenID (einer URL) ohne Benutzername und Passwort bei allen das System unterstützenden Webseiten und -diensten anzumelden.

Da ich langsam keine Lust mehr habe, mich bei diversen Webseiten immer wieder aufs Neue anzumelden, werde ich OpenID in Zukunft wohl vermehrt nutzen, wo es mir über den Weg läuft. Außerdem habe ich mir testweise in zwei TYPO3- Installation die Möglichkeit geschaffen, mich mit meiner OpenID, die ich von Google habe, einzuloggen. Dazu muss man lediglich die System-Extension “OpenID authentication” (openid), die bei jedem TYPO3 seit Version 4.3 enthalten ist, installieren und bei seinem User-Account die OpenID-Url angeben. Im Fall von Google entspricht das dem Muster http://www.google.com/profiles/username. Beim nächsten Login ins Backend kann man nun auf das OpenID-Login wechseln und sich mit dieser URL anmelden – man wird kurz zu Google weitergeleitet, authentifiziert die entsprechende Seite (d.h. die TYPO3-Installation), und ist nun angemeldet.

Es besteht zwar die Gefahr, dass man mit dem Verlust seiner OpenID-Identität ebenfalls die Kontrolle über zig andere Webseiten verliert, aber wenn man sein zentrales Passwort sicher hält und regelmäßig ändert, wird die Benutzung verschiedener Webseiten doch deutlich komfortabler.

Ja, dieses Blog ist in den letzten Monaten klinisch tot gewesen. Ich habe einfach nicht regelmäßig relevanten Content, um ihn hier zu publizieren, aber heute ist es dann doch einmal wieder so weit gewesen.

Ich nutze in einer neuen TYPO3-Installation die Extension T3BLOG in Zusammenarbeit mit coolURI. Um damit auch sprechende URLs generieren zu können, habe ich die Datei CoolUriConf.xml um diesen Part erweitert:

<uriparts>
<part>
<parameter>tx_t3blog_pi1[blogList][category]</parameter>
<lookindb>
<to>SELECT catname FROM tx_t3blog_cat WHERE uid=$1</to>
<translatetoif>
<match>^[0-9]+$</match>
</translatetoif>
<t3conv>1</t3conv>
</lookindb>
</part>
<part>
<parameter>tx_t3blog_pi1[blogList][year]</parameter>
</part>
<part>
<parameter>tx_t3blog_pi1[blogList][month]</parameter>
</part>
<part>
<parameter>tx_t3blog_pi1[blogList][day]</parameter>
</part>
<part>
<parameter>tx_t3blog_pi1[blogList][showUid]</parameter>
</part>
<part>
<parameter>tx_t3blog_pi1[blogList][showUidPerma]</parameter>
</part>
</uriparts>

Update am 12. September 2011 – siehe Kommentare unten:

  <uriparts>
    <part>
      <parameter>tx_t3blog_pi1[blogList][category]</parameter>
        <lookindb>
          <to>SELECT catname FROM tx_t3blog_cat WHERE uid=$1</to>
            <translatetoif>
              <match>^[0-9]+$</match>
            </translatetoif>
            <t3conv>1</t3conv>
        </lookindb>
    </part>
    <part>
      <parameter>tx_t3blog_pi1[blogList][year]</parameter>
    </part>
    <part>
      <parameter>tx_t3blog_pi1[blogList][month]</parameter>
    </part>
    <part>
      <parameter>tx_t3blog_pi1[blogList][day]</parameter>
    </part>
    <part>
      <parameter>tx_t3blog_pi1[blogList][showUid]</parameter>
        <lookindb>
          <to>SELECT title FROM tx_t3blog_post WHERE uid=$1</to>
            <translatetoif>
              <match>^[0-9]+$</match>
            </translatetoif>
            <t3conv>1</t3conv>
        </lookindb>
    </part>
    <part>
      <parameter>tx_t3blog_pi1[blogList][showUidPerma]</parameter>
        <lookindb>
          <to>SELECT title FROM tx_t3blog_post WHERE uid=$1</to>
            <translatetoif>
              <match>^[0-9]+$</match>
            </translatetoif>
            <t3conv>1</t3conv>
        </lookindb>
    </part>
  </uriparts>

Vielleicht hatten schon mehrere Leute das Problem, dass die (wunderbare) Extension “cooluri” für TYPO3 so ihre Probleme mit der Standardsprache hat. TYPO3 hängt an Links nicht immer den Sprachenparameter L=0 (Default-Language) an, so dass “cooluri” die URL nicht in der Form “www.domain.tld/de/seite.html” sondern “www.domain.tld/seite.html” generiert.

Das führt bei mehrsprachigen Seiten zu dem unschönen Ergebnis, dass einige URLs den Sprachparameter enthalten – und andere nicht. Neben dem kosmetischen (und für mich allerdings entscheidenden!) Aspekt gibt es jedoch noch das Problem mit der doppelten Indexierung bei Suchmaschinen, wenn die Seiten doch mit Sprachparameter aufgerufen wurden.

Leider ist das Folgende keine 100% “saubere” Lösung, aber es ist eine, die funktioniert. Ich habe sie zufällig hier gefunden:

1. Fügt in eurer XML-Konfiguration bei den Sprachenparamtern einen weiteren Eintrag hinzu:

   <value key="de"></value>

2. Ändert die Datei \cooluri\link.Translate.php ungefähr in Zeile 467 (Durchlauf der Valuemaps), so dass die Bedingung der If-Abfrage folgendermaßen lautet:

   ((string)$val==$params[(string)$vm->parameter] && (string)$val['key'])

3. Kommentiert diese Abfrage (und natürlich die geschweiften Klammern!) aus:

   if (isset($params[(string)$vm->parameter]))

(Der gesamte Code-Block ist in der oben angegeben Quelle zu finden)

Eigentlich absoluter Standard – aber ich bin gerade bei der Suche via Google etwas verzweifelt, weil ich nur jede Menge Foren- und Mailinglistenpostings gefunden habe, in dem irgendwelche Leute Probleme mit der Einrichtung von realurl und daraus resultierenden 404-Fehlern haben.

Dabei wollte ich doch “nur” eine “custom 404 page” erstellen können, um die typische “Reason: Segment “[...]” was not a keyword for a postVarSet as expected!“-Meldung zu ersetzen. Zum Glück bin ich dann doch noch auf folgenden Link gestoßen:

typo3.intervation.de::Extensionen::realurl::Error-Meldung umleiten