[TYPO3-german] Multidomaininstallation mit eigenen domainrootbereichen

[bernd wilke]

Am Mon, 08 Feb 2010 00:30:23 +0100 schrieb Stephan Schuler:

[...]
> Mehrere Installationen in eine Datenbank ohne dass die sich gegenseitig
> beeinflussen? Halte ich für unwahrscheinlich. Wie schon angesprochen
> wurde sind da zunächst mal alle Records, die die PID0 tragen. Die lassen
> sich schon mal grundsätzlich nicht zweifelsfrei einer Installation
> zuordnen sofern nicht jedem Datensatz der potenziell die PID0 tragen
> kann ein zusätzliches Installations-Marker-Attribut verpasst. Das müsste
> allerdings nachträglich an milliarden Stellen ins Backend eingebaut
> werden. Angefangen mit be_usern und be_groups, aber erweiterbar auf
> ausnahmslos alle Tabellen die ich in die PID0 kriege.

ich denke dass diese Probleme nicht so überwältigend sind, weil sie auch 
in einer MultiDomain-MultiTree-Umgebung auftreten (und dort gut lösbar 
sind)
 
> Installationen die sich gegenseitig sehen und beeinflussen? Ist möglich,
> erfordert aber "redaktionelle Disziplin". Beispiel?
> * Administrator meldet sich auf Instalation1 an, hat deshalb auch
> Zugriff auf Dateien im Fileadmin. * Sieht allerdings den kompletten
> Seitenbaum, legt Seite im Seitenbaum von Installation2 an * Hier wird
> eine Datei aus fileadmin1 verknüpft, TYPO legt seine diversen Kopien in
> uploads1 und typo3temp1 an * Die Seite wird nun übers Frontend
> angerufen. Hier geht s aber nur über Frontend2, weil die Seite ja im
> Seitenbaum von Installation2 liegt * Der Seite fehlt jetzt der
> typo3temp2- und der uploads2-Ordner, weshalb die Datei nicht gefunden
> werden kann.
> 
> Solange Redakteure ausnahmslos auf überschneidungsfreie Teilbäume
> zugriff haben, können die dieses Problem schon mal nicht erzeugen. Es
> hängt dann also primär an der Disziplin der installationsübergreifenden
> Administratoren.

s.o.
  
> Bei unterschiedlichen Installationen besteht aber potenziell über die
> Gefahr, dass jede Installation für sich plötzlich Anforderungen
> entwickelt, die die andere Installation nicht erfüllen kann oder will.
> Irgend eine Extension die einen Bug erzeugt, der nur in dieser einen von
> fünf Installationen auftaucht. Behoben werden kann der Bug dadurch, dass
> die betroffene Extension auf eine neue Version geupdatet wird. Wenn sich
> diese neue Version jetzt allerdings an einigen Stellen anders
> konfigurieren lässt als die vorherige Installation ist hier Nacharbeit
> erforderlich, sprich personeller Aufwand. Für die Installation die auf
> den Bug stößt ist das kein Problem, hier wird ja durch diesen Aufwand
> der Bug beseitigt. Die anderen vier Installationen haben allerdings
> keinerlei Vorteil an diesem updatebedingten Aufwand. 

die Konfiguration dürfte nicht so das Problem sein, auch nicht dass eine 
Installation andere Quellen als die anderen hat.
Was ist, wenn sich mit einem Update/Patch die Datenbankstruktur ändert?

das wird zu Chaos führen. Wobei neue Felder nicht unbedingt Probleme 
machen. Die alten Quellen wissen nichts von den neuen Feldern und lassen 
sie in Ruhe und die neuen Quellen sollten nicht mit den Datensätzen der 
alten Sourcen zu tun haben (andere Installation, andere PID).
grundsätzlich sind Datensätze ohne PID (bzw PID=0) schon als Probleme 
erkannt, da sie nicht mehr einer Installation alleine zugeordnet werden 
können.
Felder mit unterschiedlicher Definition in den verschiedenen Versionen 
einer Extension (in den verschiedenen Installationen) dürften die richtig 
großen Probleme produzieren. Das kann man nämlich nicht mehr abfangen 
bzw. voreinander verbergen.

[...]

bernd
-- 
http://www.pi-phi.de/cheatsheet.html