Ist Typo3 Mandantenfähig?

[M1985]

Hallo zusammen,

wir evaluieren gerade Typo3, Version 4.5.2, als Basis für unsere neuen Webauftritt. Wir als Reiseveranstalter bieten Winter- und Sommerreisen an.

Dafür haben wir pro Sparte einen Web-Auftritt geplant, welcher in verschieden Sprachen angezeigt werden kann. Pro Sprache soll ein Fallback existieren, der in der jeweiligen Sprache anzeigt, dass die Übersetzung fehlt. Vor allem die Sortierung im Menü und die Anordnung einiger Inhaltselemente können abweichen.
Es gibt auch ein paar Elemente, die Auftritts-übergreifend existieren müssen, z.B.: Impressum, AGB, Kontakt-Formular.

Das schwierigste, was wir bisher nicht zufriedenstellend abbilden können:

Es gibt Partner, die auf unsere Seiten verweisen. Bestimmte Layout-Elemente sollen ausgeblendet bzw. hinzugefügt werden können. In wenigen Fällen ist es auch so, dass ein Partner ein Layout komplett hinterlegen muss, so dass der Shop an seine CI angepasst werden kann.
Partner können selbstständig bei bestimmten Texten Änderungen vornehmen.

Ist Typo3 in diesem Hinblick Mandantenfähig? Partner würden wir in diesem Fall als Mandanten verstehen.

Partner und Sprache werden für jeden Shop über die Domain festgelegt.
Beispiel:
example-produkt1.de => Deutsch
example-produkt1.com => Englisch
example-produkt2.de => Deutsch
example-produkt2.com => Englisch
partner1.example-produkt1.de => Deutsch
partner1.example-produkt1.com => Englisch
partner1.example-produkt2.de => Deutsch
partner1.example-produkt2.com => Englisch

Wie kann man das möglichst geschickt (ohne Eingriffe in den Core) in einer Typo3-Instanz umsetzen? Kennt jemand ein Beispiel, wo sowas schon mal so oder ähnlich umgesetzt wurde?

Im Anhang ist ein Aktivitätsdiagramm zur Klarstellung der Regelung von den einzelnen Inhaltselementen

MFG

Markus


PS: Vielen Dank schon mal für den kommenden Feedback

[Stefan_G]

Hallo,

(…)

Dafür haben wir pro Sparte einen Web-Auftritt geplant, welcher in verschieden Sprachen angezeigt werden kann.

Möglichkeit: Eine TYPO3-Installation - Mehrbaumlösung – pro Sprache ein eigener Seitenbaum.

Pro Sprache soll ein Fallback existieren, der in der jeweiligen Sprache anzeigt, dass die Übersetzung fehlt. Vor allem die Sortierung im Menü und die Anordnung einiger Inhaltselemente können abweichen.

In der Mehrbaumlösung ist ein Fallback nicht nötig bzw. überflüssig. Sprache = eigener Seitenbaum = eigene Seiten.

Es gibt auch ein paar Elemente, die Auftritts-übergreifend existieren müssen, z.B.: Impressum, AGB, Kontakt-Formular.

Kein Problem: kein man über Typoscript-Referenzen oder Mount-Pages lösen. Ob das Sinn macht ist eine andere Frage, denn die jew. Sprache sollte ja auch individuell lokalisierte Inhalte haben.

Es gibt Partner, die auf unsere Seiten verweisen. Bestimmte Layout-Elemente sollen ausgeblendet bzw. hinzugefügt werden können. In wenigen Fällen ist es auch so, dass ein Partner ein Layout komplett hinterlegen muss, so dass der Shop an seine CI angepasst werden kann.

Das sind jetzt viele Begriffe/Anforderungen auf einmal und das nicht so einfach zu beantworten: Eigene Templates pro Sprache = Auswahl (Frontend-Layout oder via TS bzw. TV) = kein Problem. Ob via TemplaVoila, via Typoscript oder per Autoparser – da stehen Dir in TYPO3 sehr fette und leistungsfähige Varianten zur Verfügung.

ABER: TYPO3 += moderne Shoplösungen = das ist IMO nach wie vor nicht empfehlenswert.

Partner können selbstständig bei bestimmten Texten Änderungen vornehmen. .

Kein Problem. Das (Rechte- & Benutzermanagement) ist eine der Stärken von TYPO3.

Ist Typo3 in diesem Hinblick Mandantenfähig? Partner würden wir in diesem Fall als Mandanten verstehen.

Wenn Du Mandantenfähigkeit so definierst wie Deine Anforderungen: Ja – definitiv. Es wäre nur abzuwägen wie komplex die Anforderungen an den Shop sind und ob man da nicht besser mit Magento o.ä. kombiniert.

Wie kann man das möglichst geschickt (ohne Eingriffe in den Core) in einer Typo3-Instanz umsetzen?

Mit den Boardmitteln von TYPO3, einer Mehrbaum-Sprachlösung und einem durchdachten Benutzerverwaltungs-Konzept sollte das problemlos ohne Eingriffe in den Core möglich sein.

Kennt jemand ein Beispiel, wo sowas schon mal so oder ähnlich umgesetzt wurde?

Ohne Shop habe ich sowas mal für einen Kunden umgesetzt: Hier editieren (entfernt ähnlich zu Deinen Anforderungen) fremdsprachige Redakteure in fremdsprachigen Seitenbäumen, mit verschiedenen Domains, speziell definierten Rechten und z.T. globalen Inhalten.

//Stefan

[M1985]

Vielen Dank für deine ausführliche antwort. Im gegensatz zu manch anderen Foren / Mailinglisten, bekommt man hier dann doch schon ein etwas größeren Feedback. Ich müsste vllt dazu sagen das wir schon einen bestehenden Buchungsprozess haben, so das dieser maximal als Plugin hinzugefügt werden müsste. Lediglich die Texte sollen über das CMS verwaltet werden.

Mit den Boardmitteln von TYPO3, einer Mehrbaum-Sprachlösung und einem durchdachten Benutzerverwaltungs-Konzept sollte das problemlos ohne Eingriffe in den Core möglich sein.

Das ganze wäre demnach nicht in einen Baum abzubilden? Es ist doch möglich über die enthaltende Mehrsprachigkeit eine Typo Seite zu übersetzen.

[Stefan_G]

Hallo,

(...)
Das ganze wäre demnach nicht in einen Baum abzubilden? Es ist doch möglich über die enthaltende Mehrsprachigkeit eine Typo Seite zu übersetzen.

Doch, das wäre auch möglich: Einbaumlösung -> Sprachen werden als alternative Seitensprachen angelegt -> Inhalte werden in der jew. Seite lokalisiert -> Redakteure/Rechte auf Sprachebene. D. h., dass die Benutzerrechte so eingestellt werden, dass Redakteur B beispielsweise nur englische Inhalte bearbeiten kann.

(... aus dem ersten Posting: ) Vor allem die Sortierung im Menü und die Anordnung einiger Inhaltselemente können abweichen.

Meiner Erfahrung nach ist sowas aber leichter handelbar, wenn sprachspezifische Redakteure in einem eigenen Seitenbaum arbeiten. Vor allen Dingen, wenn Seiten-, Navigations- und Inhaltsstruktur unterschiedlich sind.

Beide Lösungen sind aber denkbar.

//Stefan

[M1985]

Morgen,

vielen Dank, da wir die Partnerabweichenden Seiten selber pflegen und nicht den Überblick verlieren möchten hatten wir an folgende Baumstruktur gedacht. Diese hat allerdings bisher zu mindest für uns einige tücken.


Root (Haupttemplate) ID 1
--Startseite (Startseiten Template) ID 2
------PartnerStartseite 1 ID 3
------PartnerStartseite 2 ID 4

Kurze ausführlichere Schilderung:
Ich möchte das die Seite beim ersten aufruf vom Root auf die Startseite verweist.
Sprich partnerseite.de würde dann den Inhalt von der Partnerseite 2 anzeigen. Dabei soll die Config von dem Startseiten Template aufgerufen werden, um über ein Switch Case die jeweilige Partnerseite zu laden, sofern eine hinterlegt ist.

Bisher konnte ich lediglich den Inhalt von der Startseite im Root aufrufen, jedoch nicht das dazugehörige Config TS des Template von der Startseite.



Ist dies überhaupt mit TypoScript möglich die pid zu wechsel, so dass auch die darüber liegenden oder enthaltende Config TS ausgeführt werden?

Grüße


PS: Link ist nun entfernt ^^

[Stefan_G]

Moin,

(...)
Ist dies überhaupt mit TypoScript möglich die pid zu wechsel, so dass auch die darüber liegenden oder enthaltende Config TS ausgeführt werden?

Eine Möglichkeit: Über Conditions kannst Du ja die URL abfragen und dann z.B. eine http-weiterleitung auf die Unterseite machen.

[globalString = IENV:HTTP_HOST=www.URL.ENDUNG]
page.headerData.999 = TEXT
page.headerData.999.value = <meta http-equiv="refresh" content="0; URL=SEITE_IM_SEITENBAUM_VOLLER_PFAD">
[end]

//Stefan

lol, edit: mach mal bei Dir im letzten Post den Link bei www. partnerseite .de... weg. War doch sicher nicht absichtlich... ;-)

[M1985]

Vielen Dank für die Idee mit dem Header. Allerdings hat dies, wenn ich es richtig in Erinnerung hab, den nachteil das die partnerseite.de Domain nie über google initialisiert, sondern lediglich partnerseite.de/startseite.

Danke nochmal für den Hinweis mit dem Link und nein es war keine Absicht

[Stefan_G]

Hallo,

mit Conditions, Realurl-Konfigurationen und baseurl-Einstellungen wirst Du das über TS auch in den Griff bekommen. Wie gesagt: Ich denke, dass es mit einer Mehrbaumlösung einfacher, sauberer und besser durchschaubar anzulegen wäre.

//Stefan