| Autor |
Nachricht |
|
Verfasst am: 05. 11. 2010 [19:31]
|
|
uko
uko
 ProfessionalThemenersteller
Dabei seit: 22.10.2010
Beiträge: 24
|
Wenn ich pdf files hochlade, dann wird der file type als 'application/download' und Label als 'Untitled' ausgewiesen. Wenn ich dann in der Vorschau der Issue auf den Link zur pdf gehe, erzeugt das im php_error.log:
Message: WARNING: assert(): Assertion failed
In file: ..\lib\pkp\classes\template\PKPTemplateManager.inc.php
At line: 61
Stacktrace:
Server info:
OS: WINNT
PHP Version: 5.3.3
Apache Version: Apache/2.2.17 (Win32) PHP/5.3.3
DB Driver: mysql
DB server version: 5.1.51-community
[05-Nov-2010 18:27:20] PHP Fatal error: Call to a member function getRouter() on a non-object in ..\lib\pkp\classes\template\PKPTemplateManager.inc.php on line 64
Wie kann ich das beheben?
Danke, Ute
|
|
Verfasst am: 05. 11. 2010 [22:47]
|
|
fgrandel
Florian Grandel
 ModeratorDabei seit: 24.11.2009
Beiträge: 75
|
Ute, kannst du mir sagen, auf welcher Seite du den Upload machst? Betrifft das den Einreichungsprozess für Autoren oder einen Upload im redaktionellen Prozess? Wenn im red. Prozess, dann wo?
|
|
Verfasst am: 05. 11. 2010 [22:53]
|
|
uko
uko
Professional
Themenersteller
Dabei seit: 22.10.2010
Beiträge: 24
|
hallo floarian, den upload mache ich mit dem quicksubmit. ich weiss nicht, woran es liegt. konnte schon mal eine datei uploaden, wo pdf richtig erkannt wurde. jetzt klappt es aber gar nicht mehr. auf meinem testserver gibt es keine probleme. muss also etwas sein mit apache und php auf der produktionsmaschine. ich hab aber noch nicht herausfinden können, wo genau das problem liegt.
gruß ute
|
|
Verfasst am: 06. 11. 2010 [02:38]
|
|
uko
uko
Professional
Themenersteller
Dabei seit: 22.10.2010
Beiträge: 24
|
Nachtrag: habe Template Cache und Database Cache gelöscht. Server neu gestartet. future issue aufgerufen -> submission editing -> galley file ersetzt; das hat geklappt.
|
|
Verfasst am: 08. 11. 2010 [18:12]
|
|
fgrandel
Florian Grandel
Moderator
Dabei seit: 24.11.2009
Beiträge: 75
|
Ich gehe dann davon aus, dass das nur ein lokales Problem war...
|
|
Verfasst am: 08. 11. 2010 [18:26]
|
|
uko
uko
Professional
Themenersteller
Dabei seit: 22.10.2010
Beiträge: 24
|
Hallo Florian,
Das hoffe ich auch ...
Aufgetreten war das Problem, denke ich, parallel zu meinen Versuchen mit pdftotext enabled/disabled; vielleicht hab ich da hektisch nur zu schnell zu viel versucht.
Aber ich sitze dafür noch an dem Problem mit unkompletten Submissions (Beitrag Volltextsuche, Problem Abbruch im Zusammenhang mit pdftotext) und versuche gerade, diese Beiträge aus der Datenbank zu löschen. Über das Webinterface geht es nicht. Die betreffenden Submissions werden dem Editor als 'ohne Autor' angezeigt und beim Anklicken erscheint auf der dann sich öffnenden Seite submissionEditing bei Initial Copyedit:
Fatal error: Call to a member function getDateNotified() on a non-object in ..\cache\t_compile\%%B0^B03^B0335942%%copyedit.tpl.php on line 61
Ich muss die Löschungen also direkt in der DB vornehmen, da schaue ich mir grad die Tabellen an ...
Wenn ich das richtig sehe, dürfte es dann also nur alle Tabellen article/ article_... betreffen, oder vergesse ich da etwas?
Gruß Ute
|
|
Verfasst am: 09. 11. 2010 [19:24]
|
|
uko
uko
Professional
Themenersteller
Dabei seit: 22.10.2010
Beiträge: 24
|
Mein letzter Eintrag zu galley file information wäre ja eigentlich eher ein neues Thema: unvollständige submissions aufgrund Abbruch (im ZH mit pdftotext). Aber das ist vielleicht zu speziell auf mein Problem bezogen, oder kann man das Umsortieren?
Zumindest wollte ich noch nachtragen, dass ich in der Datenbank gesehen habe, dass Einträge für die betroffenen Artikel auch die Tabelle signoffs betraf (dort fehlten die Artikel).
Jetzt habe ich für alle betroffenen unvollständigen submissions in der Datenbank, Tabelle articles den status auf 0 gesetzt, und nun kann man als Editor über das webinterface / submissionsArchive auch wieder löschen (war vorher nicht mehr möglich). Ich hoffe, damit ist die DB wieder sauber.
Aber das führt mich zu der Frage: es kann ja aus irgendwelchen Gründen während eines Uploads (z.B. über QuickSubmit wie bei mir) zu einem Abbruch kommen. Kann man in solchen Fälle nicht generell bei diesen 'Unkompletten' den Status von 3 auf 0 zurücksetzen, oder geht dass nicht, weil die Abbarbeitung der scripte dann schon ausgestiegen ist? So war es jedenfalls unglücklich, weil man über das Webinterface keine Optionen mehr hatte.
Ute
|
|
Verfasst am: 09. 11. 2010 [20:56]
|
|
fgrandel
Florian Grandel
Moderator
Dabei seit: 24.11.2009
Beiträge: 75
|
Hallo Ute,
das "harte Löschen" von Beiträgen ist bisher tatsächlich nicht vorgesehen, nur das "Archivieren" von Beiträgen. Wenn du möchtest, kannst du gern einen Eintrag für einen "enhancement request" auf unserer Bugzilla-Webseite machen, dann können sich unsere Entwickler und andere Anwender dazu äußern. Wir warten meist ein bisschen ab, ob eine Anfrage mehrfach kommt. Wenn ja, dann setzen wir sie um, zumal das in diesem Fall ja eher eine Kleinigkeit ist.
Es ist übrigens sehr selten, dass in einer produktiven Installation solche Probleme auftauchen, wie du sie beschrieben hast. In deinem Fall war es ja auch nur ein PHP-Konfigurationsproblem, das nichts mit OJS selbst zu tun hatte. Da das Skript bei zu wenig Speicher unkontrolliert an beliebiger Stelle abbricht, gehen dabei fast immer Daten kaputt. Wir könnten diese Situation mit Transaktionskontrolle verbessern aber dazu müssten wir unsere Installationsvoraussetzungen bzgl. MySQL höher setzen, was wir sehr gern vermeiden wollen.
Sollte doch einmal ein Fehler in OJS zu so einen inkonsistenten Zustand in der Datenbank führen, dann haben wir bisher zwei Methoden zur Lösung:
- Entweder wir sorgen dafür, dass beim nächsten Upgrade der Fehler automatisch korrigiert wird.
- Oder wir posten über das Forum eine Anleitung, wie der Fehler in der Datenbank manuell behoben werden kann, so wie du es nun selbst getan hast.
Du warst in dem Fall nur schneller als ich. :-)
Viele Grüße,
Florian
|
