[Typo3-german] Staging System in Typo3

[christian reiter]

Hallo Michael,

>  grob fahrlässig, ersteinmal reflexartig "geht natürlich" zu sagen
> und nachher hier in den Listen nach Lösungen zu fragen.

Absolut richtig

> 3. Wenn eine Anforderung kommt, die mit Budget X nicht zu lösen ist,
> dann ist es weder herablassend noch besserwisserisch, dem Kunden zu
> sagen, dass TYPO3 das nicht kann.

Ebenso, dies ebenfalls Teil einer Beratungsleistung

> Über Leute, die *zusagen*, solche Kundenanforderungen zu erfüllen, es
> dann aber nicht können, darf man sich doch durchaus lustig machen, oder?

Klar

> Die Tatsache, dass wir nach so vielen Jahren und unzähligen Versuchen
> immer noch kein zuverlässiges und komfortables Staging haben, mag ein
> Indiz dafür sein, dass das Problem nicht so einfach zu lösen ist,
> und/oder dass nicht so starker Bedarf auf Kundenseite bestand, der sich
> in entsprechendem Sponsoring niederschlagen würde.

Vielleicht liegt es auch daran dass immer zu grosse Lösungen gesucht wurden?

Eine typische Kundenanforderung *für uns* ist ein seitenbasiertes
Publishing - dh. der Kunde kann nicht damit leben, dass immer nur die
gesamte Datenbank (die womöglich mehrere Websites aus verschiedenen
Verantwortungsbereichen enthält) livegeschoben wird.

Er braucht aber nicht eine "Total Information Awareness" jedes Objektes. Die
Freigabe/Veröffentlichung/Rückholung erfolgt seitenbasiert, weil der größte
Teil der Workflows bei klassischen Unternehmenskunden sowieso ausserhalb des
IT-Systems erfolgt (und wer dagegen anrennt, brauch die Energie von Mao
Tse-Tung bei der Kulturrevolution, und die gleichen Methoden)

Das bedeutet dann, es erfordert ein Publishing Tool welches für eine
bestimmte Page ID einen Status mitverfolgt und die Möglichkeit mitbringt,
allen Content der zu dieser ID gehört auf dem Liveserver zu löschen (dank
'pid' Feldern und TCA keine Magie, oder?), die dazugehörigen Dateiressourcen
zu identifizieren und zu löschen - oder genauso eben die DB Inhalte und
Dateien zu aktualisieren oder neu anzulegen; und natürlich dazugehörige
Cache-Einträge zu löschen etc. Das ist PHP/MySQL Arbeit die erst mal einige
Hacks an der Source erforderte und seit Existenz der "hooks" wesentlich
leichter geworden ist da die HAcks sich auf die gelegentliche Neueinführung
eines Hooks beschränken mag.

Konkret hatten wir zu Typo3 3.5 Zeiten einen Kunden, der ein bereits
existierendes PHP-MySQL CMS hatte welches auf ähnlichem Weg Daten
publizierte und dann von selbst auf uns zu kam mit der Frage "was haltet Ihr
von Typo3" und seinen Fähigkeiten im Vergleich. Dem haben wir auch gesagt
dass es das seitenbasierte Publishing so wie er es kannte in Typo3 3.5 nicht
gibt. Dafür konnte schon damals  Typo3 viele Dinge welches das andere System
nicht konnte (ganz zu schweigen von einigen kommerziellen Lizenzen die beim
Kunden herumlagen und ungenutzt blieben weil schon erste
Implementationsversuche böse endeten). Da der Kunde nur eine
Gleichwertigkeit zum reichlich simplen Publishingmodell des alten Systems
brauchte und erwartete - also keine in XML frei konfigurierbaren n-stufigen
Workflows, sondern einfach "diese Seite mit ihren Inhalten und Bildern
rüberschieben wenn wir das wollen" wurde das Publishing Modul des alten
Systems auf die Typo3 Datenbank angewendet.

Ganz generell ist es auch so - das Hinterfragen von angeblich "vom Himmel
gefallenen" Dingen ist zwar intellektuell immer löblich. Arbeitet man zB für
eine bestimmte Produkt-Abteilung einer nationalen europäischen Tochter eines
globalen Konzerns, dann kommen diese Vorgaben oft aus der globalen Zentrale
und liegen damit in der Tat jenseits der Wolkendecke. Die Hinterfragung ist
sehr oft schon von den lokalen Abteilungen des Konzerns gemacht worden und
ändert nichts daran, dass die Corporate Entscheidungen bleiben, und aus der
Sicht der Funktion die sie erfüllen sollen, oft auch absolut sinnvoll sind
(insgesamt wird ein bisschen zu oft über die Schlipsträger gelästert. Nicht
jede Entscheidung ist sinnlos, bloss weil am Hals unter dem Kopf der sie
traf ein Schlips hing).

Demzufolge war es in unserer Situation so: Hätte der Kunde ein FE-Portal
oder ein totales Versioning aller einzelner Contentelemente mit frei
definierbaren JSRxxx compliant Workflows gefordert, hätten wir ihm bestimmt
nicht gesagt "Nehmt Typo3" und hätten ihm ein selbst entwickeltes Interesse
an Typo3 auch ausgeredet, da es einer Unkenntnis der Funktionen entsprochen
hätte. Eher sogar noch hätten wir ihm diese Anforderungen angesichts unserer
Kenntnisse seiner tatsächliche Arbeitsweise wahrscheinlich ausgeredet (da
wie gesagt meist ein "Wetware-Workflow" vorliegt).

Die Realität war aber, der Kunde kam auf uns zu  und sagte, Wir haben hier
ein überschaubares Projekt, wir wollen mal wieder einen Versuchsballon mit
einem neuen CMS machen (Kommentar: Dieser Kunde hat in der Dotcom Ära
relevante Geldmengen in eine kommerzielle CMS-Katastrophe versenkt, die nie
auch nur irgendwetwas live brachte. Selbstverständlich sind wir für diesen
Kunden heute deshalb am Arbeiten, weil wir damit nichts zu tun hatten .)

Da heisst es dann -  Da gibt es doch dieses Open Source Zeugs, meint ihr
eigentlich man kann dieses Typo3 gebrauchen? Kriegen wir damit Benefits zum
existierenden System, und können wir Dinge die gegenüber dem alten System
nicht da sind, ersetzen? Da die Benefits erkennbar waren, der Kunde ein
seitenbasiertes Datenbank+Datei-Publishing gewohnt war, und an der
Infrastruktur nichts zu rütteln war und ist, zeigte sich eine Typo3
Umsetzung mit einem solchen Publishingtool als gangbarer Weg. Insbesondere
weil - und das muss man bei einer Diskussion, bei der es um das geht, was
Typo3 per default nicht kann, mal sagen - Typo3 bei der Basisanforderung
"Umsetzen  der gewollten Website" sich eben als durchschlagender Erfolg
gegen die Konkurrenz erwies.

Was man hier sehen muss, ist dass jeder seine eigene Kundenspezies hat. Für
unsere Kundenspezies geht zB Templavoila total am Thema vorbei. So wie deren
Seiten aussehen brauchen die das nie und nimmer. Deswegen würde ich aber
niemals hergehen und Templavoila als überflüssig oder unnötig bezeichnen
oder jene, die besonders viel Energie in seine Weiterentwicklung stecken
oder besonders laut nach solcher Weiterentwicklung schreien, dafür kasteien,
dass sie Energien in die falsche Richtung lenken. Denn es gibt eben andere
Kundensituationen wo es unerlässlich sein mag (schliesslich kam es ja aus
einer Kundenanforderung) und vielleicht steht bei uns ja auch mal so einer
auf der Matte.

und darum noch mal zurück zum ursprünglichen Posting:

"auf einer Webseite habe ich gelesen das T3 standardmäsig ein Stagingsystem
beinhaltet, also einen "Entwicklungserver" und einen "Liveserver". Jetzt bin
ich doch schon ein paar Jahre mit Typo3 am arbeiten aber habe diese Funktion
noch nicht entdeckt.
Kann mich jemand illuminieren?" ---"ich habe hier von einem Kunde die
konkrete Anforderung  ...Er sieht das  Problem im ändern von Livedaten.
Editiern von bestehenden  Inhalten wirken sich unmittelbar auf die Liveseite
aus."

Aus diesem Posting lese ich nicht ubedingt heraus, dass jemand einem Kunden
verkauft hat "Wir liefern euch eine Typo3 Lösung weil die das beste LPE mit
unterschiedlichen Servern haben",  und für diesen Fall mögen die Workspaces
ja wirklich auch die Lösung sein. Denn es geht ja nur auf die Forderung dass
Inhalte sich nicht auf "Live" auswirken sollen. Wenn der Kunde aber gleich
schon mit einer Situation anrückt, wo getrennte Server vordefiniert sind und
es ein generelles Verbot für die Existenz jeglicher
Administrationsoberflächen auf dem Liveserver gibt, sieht die Welt schon
wieder anders aus.

christian