[TYPO3-german] Bitte um Brainstorming - Filtermenü

Sat Nov 19 21:58:25 CET 2011

Hallo zusammen.

Zunächst mal hat Duplicate Content nicht die Bedeutung wie oft
angenommen: Es gibt keinen pauschalen Strafbonus wenn man Inhalt
wiederverwendet oder unter unterschiedlichen URLs anbietet. In dieser
Beziehung gibt es genau zwei Situationen die sich negativ auswirken
können:

1.: Bei bewusster Manipulation des Index wird Google Maßnahmen
treffen. Wie diese aussehen weiß nur Google, allerdings liegt der
Focus auf "bewusst". Sofern der doppelte Inhalt nicht zur
absichtlichen Täuschung/Manipulation des Index erstellt wurde, greift
Google nicht zusätzlich regelnd ein.

2.: Wenn mehrere URLs den gleichen Inhalt aufweisen, kämpfen diese im
Index gegeneinander. Hier kommen dann alle sonstigen
Rankingmechanismen zum Tragen, je weniger sinnvoll/bekannt/beliebt
eine URL ist desto weiter unten wird sie im Index auftauchen, bzw. die
URL mit der größten Relevanz (häufig die einzige der vielen möglichen
die von anderen Seiten außer der eigenen, verschachtelten Menüliste
verlinkt wird) ist der für Google relevante Suchtreffer. Kurz: Google
wird aus den vielen URLs die den gleichen Inhalt präsentieren einen
möglichst sinnvollen Repräsentanten wählen und alle anderen als
unwichtig klassifizieren weil sie "nichts neues" bieten.

http://www.google.com/support/webmasters/bin/answer.py?hl=de&answer=66359

Zum eigentlichen Problem: Es ist also nicht wirklich
wiederverwendbarer Inhalt sondern vielmehr eine Verschlagwortung von
Seiten gewünscht. Es sollen also nicht viele unterschiedliche
Inhaltsblöcke nach Bedarf auf Seiten verteilt werden um dem Redakteur
die Arbeit zu ersparen, Inhalte mehrfach tippen zu müssen sondern es
sollen vielmehr einer Seite einzelne Schlagworte zugeordnet werden, in
Verbindung mit einem Schlagwort-Auswahlmenü als Navigationshilfe im
Frontend und einem Schlagwort-Auswahlmenü als Konfigurationselement im
Backend.

Das hierarchisch abzubilden dürfte schwer bis unmöglich sein,
insbesondere wenn es um SEO-URLs geht. Angenommen die SEO-URL enthält
die Schlagworte immer alphabetisch sortiert und ein Schlagwort immer
doppelt. Bei nur zwei Schlagwörtern ergeben sich vier URL-Varianten
(kein Schlagwort, je eines de Schlagwörter, beide Schlagwörter), bei
drei Schlagwörtern schon acht (kein Schlagwort, 3* je eines, 3* je
zwei, 1* alle drei Schlagwörter). Bei n Schlagwörtern dann 2^n
Kominationen. SEO-URLs dafür würde ich deshalb praktisch ausschließen,
das ist also kein Punkt über den wir uns groß Gedanken machen müssen.

Was der Benutzer an solch einer Stelle gerne hat ist facettierte
Navigation. Wenn er SchlagwortA angeklickt hat und es keine Treffer
mit SchlagwortA&SchlagwortB dafür aber 10 Treffer mit
SchlagwortA&SchlagwortC gibt, sollte man dem Benutzer in der
Navigation die Option von SchlagwortB überhaupt nicht geben, dafür
SchlagwortC mit dem Hinweis über die zehn zu erwartenden Treffer
geben. Siehe das Produktmenü bei Amazon.

Wenn sowas eine relevante Konfiguration ist würde ich einen Blick
Richtung Apache Solr werfen. Das geht allerdings nur ganz begrenzt
generisch, jedenfalls ist das kein Plug'n'Play-Plugin sondern benötigt
Kenntnis über die eigenen Daten sowie zusätzlich eine
Solr-Server-Instanz. Grundsätzlich ließe sich damit zwar ein
generisches Taggingsystem realisieren, allerdings hatte ich bisher
noch nicht die Anforderung, das auf tt_content zu verwirklichen.
Deshalb kann ich leider nicht mit einer fertigen Konfiguration für
tt_content dienen. Meine bisherigen Solr-Integrationen befassten sich
stets mit sehr kundenspezifischen ExtBase- oder FLOW3-Models.

Auch wenn das jetzt vielleicht ein wenig übers Ziel hinausgeschossen
ist, aber vielleicht ist es ja auch genau das richtige. Ich kenne
immerhin die Größenordnung deines Projekts nicht:
http://media.netlogix.de/community/details/artikel/apache-solr-storage-backend-for-extbase-our-little-christmas-gift-for-you
http://forge.typo3.org/projects/extension-nxsolrbackend/repository
Leider ist das zugehörige Repository zur Zeit etwas hinten dran weil
unser FLOW3-Solr-Storage und unser ExtBase-Solr-Storage dieselbe
Codebase sind und die letzten Änderungen  im FLO3-Zweig nicht so
einfach in den ExtBase-Zweig unseres Solr-Projekts einzugliedern sind.

Grüße,
  Stephan Schuler.

Am 19. November 2011 19:07 schrieb Robert Wildling <robertwildling at gmail.com>:
>> Allerdings musst du auch bedenken, dass bei so einem System dann alle Tags
>> wieder für alle Records zu Verfügung stehen. Aber du willst bestimmte Tags
>> vielleicht nur für News Records verwenden, manche nur für den Kalender,
>> manche für Content Elemente und zugleich für Adressen.
>> Also müsste man konfigurieren können, wo was angezeigt wird - zumindest
>> wenn
>> man ein Lösung für alles anstrebt. Außerdem musst du noch bedenken, dass
>> verschieden Backend Benutzer verschiedene Rechte haben.
>> Ach, und Workspaces gibt es auch ;)
>
> Ufff... das wird ja 'ne lange Kette an ifs und elses und cases undundund...
>
> Wie wäre es, wenn man es als CE anbietet, so wie "Text And Images" ein
> "Content To Page selector". Damit könnte man vielleicht schon mal eine
> Schwelle nehmen, indem man es nicht allen erlaubt, es zu verwenden.
>
> Eine 2. wäre vielleicht genommen, wenn man sich zur Bedinung macht, dass die
> Inhalte an sich schon exisiteren und diese Ext ja nur eine Zuordnung
> vornimmt. Damit könnte man vielleicht auch das Workspace-Problem umgehen?
> (Mit dem ich mich sowas von überhaupt gar nicht auskenne, auch weil ich
> Workspaces noch nie verwendet habe...)
>
>> Toll wäre es wenn es eine Core Lösung gäbe. Dann würden zumindest die
>> meisten Extensions das gleiche System verwenden.
>> Dagegen steht die Komplexität um es universell zu machen.
>
> A-ha... gibt es vielleicht mehrere, die diese Idee gut finden? Vielleicht
> wollen sich da noch andere zu Wort melden??? Philipp - du bist
> Core-Entwickler, oder? Ist dein letztes Statement bezügl Komplexität und
> universell ein ultimatives? Oder meinst du, man kann das zumindest mal wo
> als Idee einbringen?
>
> Danke für deine Antwort übrigens!
> LG, Robert
>
> _______________________________________________
> TYPO3-german mailing list
> TYPO3-german at lists.typo3.org
> http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german