realUrl / tt_news mehrsprachlich mit nicht-redundantem Caching

[tsk]

Hallo zusammen,

manchmal lenkt ja Arbeit doch sehr vom hehren Streben nach der besseren Lösung ab. Ich bemühe mich derzeit, nach kurzer TYPO3 Abstinenz, 4.5.x Projekte reifer für die Zukunft (4.6/4.7) zu gestalten und gleichzeitig lieb gewonnene Unschönheiten zu beseitigen. Ich erstelle fast ausschließlich mehrsprachige Websites. Zu den aufgelaufenen Problemen zählen, neben etwas angestaubten Extensions, speziell Caching Issues. Woher diese rühren, erkennt man bei gezielter Beobachtung der Entwicklung des Caches nach einem „Clear all caches“.

Ein Beispiel (abgeschaltetes realUrl, da wird es deutlicher:sad:

2 Sprachen: default English (L=0), Deutsch (L=1). Start Seite (9) über Shortcut der Root Page.

Aufruf der Domain: http://mydom.tld => (über Redirect 301) => http://www.mydom.tld erzeugt 4 fast identische Cache Einträge (der vorherige Redirect erspart hier eine weitere Verdoppelung)

http://www.example.eu | id=9 
http://www.example.eu | id=9&L=0 
http://www.example.eu | id=9&L=1 
http://www.example.eu | id=9&print=1

Abhängig von der Zahl der Conditions (Browserweiche, Logged-In User/Group...) können dies beliebig mehr werden. Dies ist expected behaviour und kann durch etwas Nachdenken reduziert werden (brauche ich eine Weiche für „print“?) - kurz gesagt: Conditions reduzieren und/oder ausmisten.

Was aber als Ärgernis bleibt, ist folgendes:

http://www.example.eu | id=9 
http://www.example.eu | id=9&L=0

Bedingt durch meinen aktuellen Language Switch auf der Seite (tt_news tauglich) setzt dieser entweder die Sprachvariable L=0 (default) oder L=1 (Deutsch). Dies führt direkt zu Duplicate Content, den es zu vermeiden gilt, sowie zu überflüssigem Caching. Richtiger wäre wohl, dass für die Default Sprache gar kein Language Parameter gesetzt würde. Aber dann bekomme ich Ärger mit tt_news 3.1 und/oder realUrl. Und tt_news 3.1 bringt zusätzlich sprachliche Probleme, die bei 3.01 bereits (manuell) rausgepatched waren (next/prev Page in Single View lokalisiert den Titel nicht mehr und sortiert gem. default Language).

Die realUrl Probleme kann man in den Griff bekommen, wenn man mit folgender Struktur leben kann:

http://www.example.eu/contact/ (default sprache English) 
http://www.example.eu/de/kontakt/ (Deutsch)

also Sprachparameter nur bei nicht-default Sprache.

Dies widerspräche aber meinen Absichten zur .eu Domain, sie soll gerade nicht sprachlich priorisieren, benötigt somit:

http://www.example.eu/en/contact/ 
http://www.example.eu/de/kontakt/

In der Realität sind es mehr als nur 2 Sprachen. Sprachtypische Domains scheiden somit aus (auch wenn teilweise vorhanden:sad:

Jetzt sehe ich zwei theoretische Ansätze:

1) Die Rewrite Engine läuft sowieso schon. Wird die Domain (also ohne weitere Url Parameter) aufgerufen, so mache Redirect auf http://www.example.eu/en/ (oder gar: http://www.example.eu/en/home/, denn die Seite gehört eigentlich in den Cache). Diese Lösung hätte den Charme, TYPO3 dabei komplett raus zu halten. Ich bin mir jedoch nicht sicher, ob ich mir damit selbst ins Knie schieße. Hat da jemand Erfahrungen? Mögliche Probleme würde ich bei ssl, feeds etc. sehen.

2) Die ganzen Nickeligkeiten mit tt_news und realUrl angehen. Mein gewünschtes Url Schema scheint bei realUrl ausschließlich mit folgender Konfiguration zu klappen:

'preVars' => array( 
'0' => array( 
'GETvar' => 'no_cache', 
'valueMap' => array( 
'nc' => 1, 
), 
'noMatch' => 'bypass', 
), 
'1' => array( 
'GETvar' => 'L', 
'valueMap' => array( 
'en' => '0', 
'de' => '1', 
), 
// 'noMatch' => 'bypass', 
'valueDefault' => 'en', 
), 
),

Gibt es irgend eine alternative Variante für realUrl, die immer (zwingend) eine Sprachvariable in der Url führt? Macht hierfür der Bereich 'redirects_regex' oder 'redirects' in realUrl vielleicht Sinn? Ist leider nur sehr rudimentär dokumentiert. Etwas unschön ist auch die fehlende Transparenz zwischen Redirects durch realurl und direkten Redirects durch den Apachen (also vhost settings oder, für Hobbyisten, auch .htaccess). Letztere bieten natürlich gewaltige Performancevorteile gegenüber allen TYPO3-internen Mechanismen.

Wie geht Ihr damit um?

Viele Grüße,

Thomas

[tsk]

Sodelle. Das Thema scheint ja niemanden wirklich zu bewegen - obwohl es Euch wahrscheinlich alle betrifft.

Um es zum Abschluss zu bringen. Alles, was oben steht, stimmt. Duplicate Content ist mit TYPO3 Bordmitteln (inkl. realUrl) und Url/Sprachschema wie genannt nicht zu vermeiden. Dies ist jedoch überhaupt nicht tragisch, denn man regelt es ausschließlich über mod_rewrite. Tut man dies richtig, so gibt es noch genau einen (in Worten EINEN) Cache record pro Seite und Sprache (dito bei News Single, ein Cache record pro Artikel/Sprache). Vorher hat man natürlich bereits alle Typolinks, die man auf der Seite nutzt, hinsichtlich Vollständigkeit und im Sinne der reinen Lehre geprüft und sich bemüht, die eine oder andere Condition in die Tonne zu hauen.

Ein wichtiger Tipp dazu: Berücksichtigt bei (eigenen) Redirects nicht nur die Sprachvariablen, sondern auch ggf. vorkommende no-cache Seiten.

Das Ergebnis der letzten drei Arbeitstage ist somit eine Versechsfachung der Server Performance des Entwicklungssystems, Aufwand: geschätzt 120 Zeichen.

Hastalavista und Glückauf

[Josef F. Glatz]

Das hört sich interessant an. Könntest du uns evtl. mehr Details zur mod_rewrite Anpassung geben?

[tsk]

Gern:

        # Redirect to default language, if no language is set
        RewriteCond %{REQUEST_FILENAME} !-f
        RewriteRule !^(nc/)?(en|de)/?  http://%{HTTP_HOST}/en%{REQUEST_URI} [R=301,L]

        # Redirect to localized start pages
        # Rewrite all urls with set language var only
        # This solves the problem of having multiple cache entries for the start page per language (DC)
        RewriteRule ^en/?$ http://%{HTTP_HOST}/en/home/ [R=301,L]
        RewriteRule ^de/?$ http://%{HTTP_HOST}/de/home/ [R=301,L]

Wichtig: Dies ist nicht zwangsweise Syntax für .htaccess (ich arbeite mit Apache vhost settings, um htaccess nicht zu brauchen). Der restliche Rewrite Kram bleibt wie im Standard. Die Direktiven sind bislang nur lokal getestet, aber bisher ohne besondere Auffälligkeiten (außer sauberem Caching). Betonen möchte ich auch, dass dies nur für multilanguage Sites erforderlich ist, und auch nur, wenn die default Sprache (L=0) Teil der Url sein soll (also zwingend gesetzter L Parameter).

Problempotential: Geht nur mit aktiviertem realUrl

Verbesserungspotential: Statt semantischen Url-Parametern (de/en) die tatsächlichen (TYPO3 internen) L-Parameter nutzen, jedoch ohne 301 (davon darf Google & Co nichts mitbekommen). Dann müsste die Kiste mit und ohne realUrl funktionieren - bei identischer realUrl Konfiguration. Mag ja mal wer ausprobieren und das Ergebnis posten.

Für weitere Verbesserungen bin ich natürlich offen.

[tsk]

So schön meine ausgearbeitete Lösung auch funktioniert, sie fühlt sich falsch an. Warum?

Sie mischt canonical und Url-parameter based rewriting und sie funktioniert, weil die Reihenfolge stimmig ist. Ich denke, wenn man sowas tut, so landet man irgendwann in der Hölle, und dies verdient.

Die einzig wirklich brauchbare Lösung erzwingt nur den L Parameter (L=0), falls im Querystring kein L-Parameter gesetzt ist. Canonical rewriting verstehe ich ja halbwegs, aber hier geht mir die Puste aus. Es geht um diesen Teil:

RewriteRule !^(nc/)?(en|de)/?  http://%{HTTP_HOST}/en%{REQUEST_URI} [R=301,L]

Um den Cache Parameter muss man sich in diesem Fall nicht bemühen (ist er im Querystring, so bleibt er dort auch). Wie bekomme ich diese Rule auf den puren L-Parameter reduziert. Bitte Rewriting Gurus vortreten.

früstelnd,

Thomas