Ihre Kommentare
Wir benutzen dazu ganz normal Imperia-Dokumente. "Rubrikenantrag",
1. Schritt aus Liste auswählen welche Rubrik geändert werden soll (bei uns Select-Liste)
2. Schritt : per Codeinclude sind die Felder, die änderbar sein sollen mit den bisher existierenden Wertenbefüllt und können nun geändert werden.
3. Schritt: am Ende kommt ein Transform Schritt, der die geänderten meta-Variablen in die Rubrik zurückschreibt.
Vorteil:
* mit dem Imperia-Template kann man haarklein festelgen welche Felder bearbeitet werden dürfen (Bsp Test auf MemberOf)
* man kann genau festlegen, ob für bestimmte Felder nur feste Werte (Select-Liste) möglich sein soll, oder Freitext erlaubt ist.
den "Rubrikenänderungs-Antrag" werfen wir hinterher komplett weg (shredder)
Wir lösen das anders.
1) als Imperia-Backend nehmen wir dasselbe,
es wird nur per Skript eine andere Rubriken-Grundstruktur importiert, ansonsten achten wir drauf, dass Templates und Flexe über all gleich sind.
2) Live-Modus der Templates ist nur ein Codeinclude, dass den Datensatz als json ablegt.
3) Preview / Frontend sind per Variable (wir pflegen auch die "php"-Variable via system.conf-Variable)
unterscheidbar
und werden vom php-Frontend ausgeliefert.
Routing.php Skript bekommt den Pfad (dir/file) und kann es sich aus einer Elasticsearch holen, oder von der Platte als json und dann für das "gewünschte" Frontend per php-view-templates ausliefern.
Der Vorteil das Template nicht bereits beim Erstellen voll durchgenerieren zu lassen ist, dass man auch später noch mal Bildformate oder Layout ändern kann, ohne dass man alle 300000 Dokumente reparsen müsste (was bei Imperia nicht nur einige Stunden dauert).
Wir benutzen in I9 immer noch:
"MAM_ADD_USER_FIELDS" = "copyright:Copyright,tags:Stichworte"
Da gerade das Copyright bei uns als Pflichtfeld von enormer Wichtigkeit ist, um teure Abmahngebühren zu vermeiden. Zumindest ist das Ziel, dass der Redakteur darüber nachdenkt.
(ob das für die IWE auch genommen wird, ist mir nicht bekannt)
In Imperia9 sieht man dort alle Rollen, nicht nur die angenommenen
Die zweite Möglichkeit mit der Checkbox ist verlockend.
Ich gebe nur zu bedenken, dass die Menü-Aktion "Rekursiv löschen" vorab Ängste erzeugt, den Knoten doch mit zu erwischen, da unklar ist, dass man ja noch einmal zusätzlich gefragt wird, ob man wirklich will und was.
Klarer wäre deswegen ein eigener Menu-Unterpunkt, der dann gerne auf die selbe Aktion (nur mit bereits aktivierter Checkbox) linken darf.
Vielleicht kann man ähnlich wie für die MAM-Zusatzfelder per system.conf konfigurierbar machen, so dass man auch auf "meta:xyz" meta Variablen zugreifen kann
Ein gepflegtes "__imperia_publish_elements" Feld hat ausserdem den Vorteil, dass man Live mittels Hermes-Plugin diverse Aktionen auch auf die referenzierten Assets ausüben kann (rechte gerade rücken, oder wir übertragen immer nur das Original-Bild und können dann abhängig vom live-Frontend und der system.conf dort die Bilder in unterschiedlichen Größen vorrendern.)
Ich wünschte mir sowas Ähnliches für das LÖSCHEN von Dokumenten.
Genauer gesagt, wenn das letzte Dokument live gelöscht wird, dass noch ein Asset referenziert, dass dann auch das Asset live gelöscht werden kann.
Jetzt bleiben immer mal wieder Assets live liegen, die da nicht mehr hingehören und im Zweifel abgemahnt werden können.
Hast Du ein Beispiel?
Ansonsten gibt es für die Steuerung ja die Rechtevergabe für die verschiedenen Controller...
Zu klären ist, wie man mit den Dokumenten umgeht,
* die in einer früheren Archiv-Version Live sind
* im Redaktionssystem aktualisiert (beendet, oder auch nicht beendet) wurden, wenn also die "aktuelle" Version nicht der "Live"-Version entspricht.
Wir haben hier in Berlin auch ständig damit zu kämpfen, wegen ständiger Umbenennungen von Behörden und Umstrukturierungen nach jeder Wahl.
Leider war in den seltensten Fällen ein eindeutiges Mapping möglich, da die Sprache Deutsch so ihre grammatikalischen Eigenarten hat (männlich, weiblich, sächlich - auch bei Objekten, die keine Menschen sind).
So dass wir den Leuten nur Listen zur Verfügung stellen, wo noch alte Begriffe zu finden sind.
Alternative aus Imperia7-Zeiten:
* Schreibe ein Transform-Plugin "WorteReplace"
* Baue im Workflow einen Extra-Pfad für Reparsen ein (IfElse und Check auf die Variable: __IMPERIA_XREPARSE), Ziel, die Dokumente die dort durchlaufen, nur automatisch verarbeiten und gleich freischalten.
* dann einfach den ganzen Baum per xreparse reparsen
Das Worte-Replace Plugin kann man dann jederzeit mit neuen Worten / Ersetzungen bestücken.
Das "autopublish" Problem lösen wir da derzeit in i) für Dokumente ohne publish_date dadurch, dass wir beim reparsen das publish_date auf 1.1.2001 setzen. Beim Reimport wird ein 1.1.2001 immer von uns gelöscht.
Customer support service by UserEcho
Schön wäre bei "FERTIGGESTELLT" ein kurzer Link zur Dokumentation oder ein Stichwort, wie man das jetzt in sein Template einbauen kann.