Hallo Liste,

ich hoffe, das Autoexpire-Problem nun gelöst zu haben.

Zur Erinnerung:

Einige (nicht alle!) Artikel wurden vom hermes nicht zum gewünschten
Expire-Date aus dem Programm genommen. Hier empfohlene Eingriffe in das
site/articles/expiry.files mittels admin_expire.pl waren ebenfalls
erfolglos. hermes hat seine expiry-liste stets in 
Expiry.files_timestamp-Dateien umkopiert, aber die Artikel selbst nicht
angefasst.

Fehleranalyse:

Nach einigem hin und her mit dem Support bzgl. Fehleranalyse,
bin ich nach mehreren Stunden intensiver Rechte-Testerei auf die
folgende Logfile-Zeile gestossen:

[Fri Nov 14 10:49:39 2003] ERROR (ExpiryDate): Day '31' out of range 
1..30 at 
/usr/local/apache-test-develop/site/bin/../modules/core/Dynamic/Hermes/ExpiryDate.
pm line 160

und tatsächlich: es gab 2 EXPIRE-Einträge, die am 31.9. hätten 
ausgeführt werden sollen.

Also:

Die Redakteure können ungültige Expire-Angaben machen, das Expire-Plugin 
(angestossen vom hermes) arbeitet alle danach folgenden Sätze im
expiry.file nicht mehr ab, auch wenn diese OK sind :-(

Lösung als Amdin:

- hermes stoppen
- admin_expire.pl im site/articles ausführen
- expiry.new untersuchen, ungültige Datum-Einträge korrigieren
- expiry.new auf expiry.files umkopieren
- hermes starten

Vorschlag an Imperia:

Fixen:
- Plausi auf die Datumsangabe im Autopublish/-expire-Workflowschritt,
   Redakteure machen solche Fehler!
- Alternativ: Expire-Plugin trotz eines falschen Eintrages weiterackern
   lassen.


uff - bis dann
  Jens

© 2001, 2002 marchive.pl Christian Lackas

[HOME]   [MARCHIVE]   [INDEX]   [IMPERIA]   [IMPRESSUM]   [DELTA]