Bei Umstellungen und Migrationen erlebe ich es häufig, dass einzelne Rubriken nicht mehr benötigt werden und gelöscht werden sollen - insbesondere im MAM.

Wenn man eine großen Rubrikenbaum hat, dann muss man jede einzelne Rubrik anklicken und im Kontextmenü 'Rekursiv Löschen' auswählen, da ja einige der Nachbarrubriken erhalten bleiben sollen.

Hier wäre es schön, wenn man einen Weg finden würde Checkboxen anzubieten, mit denen man alle gewünschten Rubriken anklicken und anschliessend löschen kann. Dass der Todo-Job dann im Hintergrund lange braucht ist schon klar.

Erzeugen von Varianten eines Bildes in gleicher Größe, jedoch mit unterschiedlichen Bildqualitäten sollte z.B. via MAM Processing Instruction möglich sein.

Was schön wäre, wenn es zum Löschen von Archiv-Versionen auch differenziertere Kriterien gäbe. Das Skript admin_sanitisearchive lässt nur zu, pauschal alle unfinished-Versionen zu löschen.

Wunsch : Erweiterung der Parameter um eine Zeitangabe von-bis, z.B.

admin_sanitisearchive.pl - type 'unfinished' -timerangefrom 12-11-2014 18:00 -timerangeto 12-12-2014 08:00

Bei einem Kunden bleibt der FTS-Index immer an einem PDF-Dokument hängen.

Auch wenn man versucht die Datei mit pdftotext in text umzuwandeln, bekommt man kein Resultat.

Mögliche Lösung: Timeout-Mechanismus für das DPF Plugin

Für jede zu parsende Datei wird ja das PDF-Plugin (über eval) aufgerufen. Diesen Aufruf könnte man z.B. mit Sys::SigAction o.Ä. klammern. Wenn ein Dokument nicht in 5 Minuten geparst werden konnte, dann wird abgebrochen und eine Fehlermeldung ins Log geschrieben und die nächste Datei wird verarbeitet.

NiceToHave 1: Die Timeout-Zeit kann in der index.conf angegeben werden. FTS_PARSE_TIMEOUT_IN_S

NiceToHave 2: Der Timeout wird nicht im DPF-Plugin sondern in der PlugIn-Schnittstelle umgesetzt, so dass dieser Mechanismus auch für cat2doc (Office-Dokumente) funktioniert.

NiceToHave 3: FTS-Index misst die maximale Parse-Dauer der einzelnen Datein und ziegt diese am Ende an:

Max-Parse-Dauer: 24s

Sie sollten FTS_PARSE_TIMEOUT_IN_S auf 48s einstellen (Sicherheitsfaktor:2)

Ich wünsche mir ein Imperia 10 Widget zum Ausführen der FTS auf DEV und LIVE (Analog zum Hermes).

Wie auch beim Hermes würde ich mich besonders freuen, wenn dies auch noch per FTP gehen würde. Wenn dies nur bei local und SSH geht, sollte man dies auch strikt kommunizieren. ;-)

Möglicherweise wäre das local-remote-fts-start-per-ssh Feature bei meinem Kunden ein Grund noch mal über die Übertragungsmethode nachzudenken. ;-)

Wie kann man Benutzerdefinierte Menüeinträge auf vielen Servern einrichten, ohne kommende Updates am Menü zu verlieren?

Aktuell pflege ich eine Datei "/menu/mainmenu.conf.sample" und rolle diese auf den Servern aus. Initial wird diese Datei dann (mit Backup) über "/menu/mainmenu.conf" kopiert.

Jetzt wird mit imperia 10.2 der neue Menüeintrag für die Piwik-Views kommen. Werden diese dann in meine Menüdatei gemerged?

Ich wünsche mir einen Weg wie man zuätzliche Menüs updatesicher hinzufügen kann.

Dabei reicht es mir, wenn das nur für das aktuelle Major-Release gilt.

Die aktuell vorhandene Volltextsuche ist leider nur wirklich sinnvoll, wenn man direkt HTML-Seiten veröffentlicht und in einer Umgebung arbeitet, wo man CGI-Scripte ausführen kann. Wenn dies nicht zutrifft, z.B. bei Veröffentlichung von Templates, die zur Anzeige in eine JAVA-Applikation integriert werden, ist dieses Feature leider nutzlos. Die Veröffentlichungen können nicht direkt über die in den Rubriken-Informationen Daten (Directory und Filename) über URL referenziert werden und CGI ist auch nicht direkt integrierbar. Hier sollte es eine eher generische Schnittstelle zur Einbindung geben, z.B. über Webservices.

Wäre es möglich, die Views so anzupassen, dass diese rollenabhängig statt pauschal verwendet werden? Aktuell kann durch Setzen von VIEW_TEMPLATE_DIRS in der system.conf das Template-Verzeichnis konfiguriert werden. Wir bräuchten eine Möglichkeit, dies in Abhängigkeit von der Rolle des jeweils angemeldeten Benutzers zu setzen, so dass der superuser die von Imperia mitgelieferte Default-Ansicht erhält und z.B. ein Redakteur eine angepasste Version. Das Duplizieren oder Anpassen bestehender Inhalte scheidet aufgrund des Verlusts der Update-Fähigkeit aus.

Ich wünsche mir die Möglichkeit, für unser Imperia-System unterhalb der Loginmaske etwas HTML updatesicher darstellen zu können. Dies kann z.B. ein Link "Passwort vergessen" sein, ein Link zu einer Hilfeseite oder der Hinweis auf aktuelle Änderungen am System oder Downtimes.

Wir benötigen einen Hook für Aktionen innerhalb von Imperia um eigene Plugins/Addons in das Backend integrieren zu können.

Aktuell kann man nur per Workflows oder Messagecheck eingreifen, nicht aber wenn der Nutzer eine bestimmte Aktion innerhalb des Backends ausführt.

Um nicht auf bestimmte Ereignisse beschränkt zu sein, würde eine Möglichkeit ähnlich den Messagechecks funktionieren.

Z.B. Imperia::Core::Backends::Addons::MeinAddon

Alle Module werden eingelesen und der angesprochene Controller mit Parametern wird an das Modul übergeben.

Es müsste ein Pre- und Post- Handler geben wobei im Prehandler ein Rückgabewert bestimmt ob der Controller ausgeführt werden darf.