CONTENIDO Forum

wir arbeiten ja sehr viel mit contenido und haben auch zahlreiche kunden für die wir auch den inhalt pflegen. bei fremdpflegeseiten haben wir immer ein riesen problem: der kunde will die websites, ohne sich ins backend einloggen zu müssen, vorher sehen, seine änderungen danach durchgeben (per mail oder fax, kommt beides bei uns vor), die wir danach durchführen und erst bei ok vom kunden freischalten. in der zwischenzeit soll der alte inhalt nach wie vor auf der website sichtbar sein.

momentan lösen wir das auf eine sehr unelegante art, indem wir den artikel duplizieren, in irgend eine kategorie werfen oder direkt den link zum artikel zum kunden geben, der später einfach nur weiter querverlinkt wird.

das ganze ist suboptimal und geht mal mit 1,2 artikeln gut, aber nicht wenn ich hier änderungen bekomme, die 20 seiten auf einmal abdecken. ich kann und will in dem fall auch nicht den kompletten kategoriebaum nochmals abbilden, nur um eine vorschau zu haben. noch schlimmer wird es bei sicherheitskritischen seiten, die in geschützten bereichen liegen, denn die muss man dann entweder einzeln schützen oder der kunde muss mitunter in kauf nehmen, dass er sich mehrmals einloggen muss.

das ganze ist so nicht tragbar für den professionellen produktiveinsatz, daher will ich hier mal so ein paar ideen und meinungen von euch abfragen, wie ihr das vll. löst und wie man es besser gestalten kann.

variante 1 die ich mir jetzt mal so überlegt habe:
man gibt jedem artikel eine neue flag, ob der inhalt zur freigabe soll oder nicht. wenn der flag gesetzt ist, wird der artikel automatisch gesperrt, und der bearbeitete text landet danach in einer temporären artikeltabelle, originaltext bleibt unverändert. über einen url-parameter ähnlich dem force parameter könnte man dann im frontend statt des original textes, den in der temp tabelle laden - oder noch besser: das ganze previewzeugs in einen extra mandanten auslagern, der einfach noch das flag in der config gesetzt bekommt. das ganze system ist natürlich dann übel, wenn man ein mehrmandanten system hat - das kann uferlos enden. das größere problem an der geschichte ist: wie handhabe ich änderungen im kategoriebaum?

ich hoffe ich stehe nicht als einziger mit dem problem da, so dass wir gemeinsam nach einem eleganten lösungsansatz für solche geschichten suchen können

hallo stese

speicherplatz ist ja nicht mehr ganz so teuer und ich würde daher folgendes vorschlagen:

(1) jeder artikel wird mit einem zusätzlichen flag versehen (per modul oder durch anpassung des cores). dieses flag kann einen folgender werte annehmen: neu, überarbeitet, gelöscht, freigegeben, unverändert.

(2) die ganze site wird dupliziert und in eine subdomäne verschoben, welche passwortgeschtützt ist. die datenhaltung liegt in der gleichen datenbank, jedoch mit anderen tabellen-präfixes.

(3) der kunde schaut sich die site in der subdomäne an und gibt änderungswünssche durch. wenn alles in ordnung ist, wird der artikel als freigegeben qualifiziert.

(4) mit einem script erfolgt die übertragung von der vorproduktions-db auf die produktions-db. übertragen werden müssten diejenigen artikel, die als neu, gelöscht oder freigegeben qualifiziert sind.

letztlich handelt es sich um ein staging.

eine andere variante wäre folgende:

(1) man erstellt ein modul, welches erlaubt, für einen artikel einen vorgängerartikel anzugeben.

(2) bei einer überarbeitung eines artikels wird dieser dupliziert und bei der kopie die ursprüngliche version als vorgänger angegeben (könnte vollautomatisch durch das modul erfolgen). gleichzeitig ist der artikel (der neue) offline zu stellen.

(3) das modul würde weiter erlauben, bei richtigem login die neue version der seite anzuzeigen und diese gleich als freigegeben zu qualifizieren.

(4) im letzten schritt würde das modul dann den ursprünglichen artikel leeren und den inhalt des neuen artikels an dessen stelle kopieren.

das wäre so die varianten, die ich so prima vista sehen würde.

gruss,
andreas

Meinst du optische Änderungen am Quellcode?

Bei uns (nicht mit Contenido) läuft es so, dass wir Änderungen am HTML-Dummy vornehmen und vom Kunden abnehmen lassen. Bei okay vom Kunde werden dann die Änderungen ins CMS übernommen.

Weiterer Vorschlag:
Parameter an die URL hängen, im Template/Modul diesen Parameter abfragen und dann entsprechend den Quellcode ausgeben lassen. Ist eigentlich die einfachste und sicherste Art das schnell zu lösen.

nein keine optischen änderungen, sondern inhaltliche änderungen. die optik ist nur am anfang eines projektes wichtig - wir setzen die seiten erst auf das cms, wenn die freigabe des html codes gegeben wird. sprich der code ist ein html-dummy ...

die staging version ist da schon die elegantere variante wie kummer das beschrieben hat. das muss ich mir mal durch den kopf gehen lassen, wie man das so verallgemeinern kann, dass das bei jedem projekt easy realisieren kann.

theoretisch wäre das ganze ja schon eine vorstufe zu einer (schon länger gewünschten) versionierung und dokumentenhistorie einzelner artikel. das kann man evtl. verbinden.

hallo stese

ich habe mir das ganze mal genauer angeschaut. im prinzip sollte es nicht allzu schwierig und mit einem modul zu lösen sein.

das besagte modul würde in jede seite eingepflegt, die durch den kunden freigegen werden können müsste. grundsätzlich hätte das modul drei funktionen: artikel duplizieren, artikel freigeben und versionskopie erstellen.

die funktion 'artikel duplizieren' ist in contenido ja bereits realisiert. das sollte sich ja grundsätzlich verwenden lassen. ich gehe davon aus, dass es ausreichen sollte, den eintrag in der tabelle 'cat_art' sowie in den tabellen 'cat_art_lang' und 'cat_content' zu duplizieren. im moduleintrag des neu geschaffenen artikels wird die idartlang des ursprünglichen artikels eingepflegt.

der duplizierte artikel kann nun normal bearbeitet werden. wenn der kunde eingeloggt ist, gibt das modul den inhalt der neuen seite unterhalb der bisherigen seite aus. gleichzeitig hat dort der kunde die möglichkeit, den artikel freizugeben.

wenn die freigabe durch den kunden erfolgt ist, müsste das modul lediglich die einträge in der tabelle 'con_content' mit der bisherigen (alten) idartlang löschen und die einträge mit der neuen idartlang auf den wert der bisherigen idartlang updaten und den neuen artikel gänzlich löschen.

für die versionierung schliesslich würde ich eine kopie der tabelle 'con_content' erstellen (=con_content_history). das feld 'version' ist ja bereits vorhanden, wird dabei allerdings der einfachheit halber in einen integer unsigned gewechselt. im rahmen der freigabe müssten nun bloss die einträge der con_content in die con_content_history kopiert werden, wobei der wert für die version um eins erhöht wird (relativ zum max(version) der bereits bestehenden idartlang).

eine weitergehende versionierung sehe ich nicht, ohne dass der kern des cms verändert wird. mit dieser funktion wäre es allerdings immerhin möglich, einen artikel, der sich bloss inhaltlich (jedoch nicht strukturell) verändert hat, wieder in einen früheren zustand zurück zu versetzen.