Erzeugen einer Tabelle für ein OJS-PlugIn

Startseite » Forum » e-Journal Systeme » OJS, OCS, OMP, Harvester » Erzeugen einer Tabelle für ein OJS-PlugIn

Erzeugen einer Tabelle für ein OJS-PlugIn

Autor	Nachricht
Verfasst am: 21. 09. 2010 [17:33]
PlugInSchreiber Advanced Themenersteller Dabei seit: 21.09.2010 Beiträge: 8	Ich habe ein PlugIn geschrieben, welches eine Tabelle für seine Datenverwaltung benötigt. Diese ist in einer schema.xml beschrieben und wird von meiner PlugIn-Klasse referenziert: PHP function getInstallSchemaFile() { return $this->getPluginPath() . '/' . 'schema.xml'; } Ich habe die Dokumentation so verstanden, dass wenn ich mein PlugIn installieren möchte, ich dieses einfach ins PlugIn-Verzeichnis der OJS-Installation kopieren muss und das dann beim Start von OJS die Tabelle automatisch angelegt wird. Dies ist leider nicht der Fall. Über den Debugger habe ich festgestellt, dass die Methode getInstallSchemaFile() zwar aufgerufen wird, die Tabelle wird aber nicht erzeugt. Muss ich noch weitere Dinge anmelden/registrieren? Muss mein PlugIn anders installiert werden? Vielen Dank
	Profil
Verfasst am: 21. 09. 2010 [18:35]
fgrandel Florian Grandel Moderator Dabei seit: 24.11.2009 Beiträge: 65	Hallo PlugInSchreiber, PlugInSchreiber schrieb: Muss ich noch weitere Dinge anmelden/registrieren? Muss mein PlugIn anders installiert werden? Die Datei mit den Tabellen wird durch einen sogenannten "Hook" installiert. Der spezielle Hook in diesem Fall ist "Installer::postInstall". Dieser Hook wird bei der Installation und beim Upgrade aufgerufen, nicht aber wenn OJS normal verwendet wird. Das heißt, Sie müssen nach Installation eines Plug-Ins normalerweise noch ein "Upgrade" durchführen, außer Sie verwenden das Plug-In Uploadformular von OJS 2.3. Ich nehme an, Sie haben das Plug-In selbst ins Verzeichnis kopiert. In dem Fall müssten sich noch folgenden Befehl in der Kommandozeile ausführen (bitte erst Backup machen!): cd [ihr OJS Verzeichnis] php tools/upgrade.php upgrade Dies sollte das Schema installieren. Florian Grandel Software-Entwickler Public Knowledge Project (PKP) http://pkp.sfu.ca/people#fg jerico.dev(at)gmail[dot]com
	Profil
Verfasst am: 21. 09. 2010 [21:38]
PlugInSchreiber Advanced Themenersteller Dabei seit: 21.09.2010 Beiträge: 8	Danke, über das Update hat es funktioniert. Ich werde dann noch ein SQL-Skript schreiben mit dem man auch die Tabelle erzeugen kann. So wird man nicht zu einem Update von OJS gezwungen.
	Profil
Verfasst am: 21. 09. 2010 [22:19]
fgrandel Florian Grandel Moderator Dabei seit: 24.11.2009 Beiträge: 65	Schön, dass es geklappt hat. PlugInSchreiber schrieb: Ich werde dann noch ein SQL-Skript schreiben mit dem man auch die Tabelle erzeugen kann. So wird man nicht zu einem Update von OJS gezwungen. Das Upgrade sollte eigentlich nichts tun außer das PlugIn installieren. Sie haben ja vorher und nachher dieselbe OJS-Version installiert. Es werden zwar sämtliche Schemata abgeglichen, aber solange die Datenbank nicht händisch verändert wurde (nicht empfohlen!!) heißt das nur, dass alles beim Alten bleibt. Das Upgradeskript sollte also alle installierten Funktionen und existierende Daten unangetastet lassen. Das Backup ist zur Sicherheit trotzdem notwendig, da wir ja auch mal Fehler machen. ;-) Ähnlich funktioniert es, wenn Sie die Online-Installationsfunktion für PlugIns ab OJS 2.3 nutzen. Dort sollte auch nur das PlugIn installiert werden und sonst weiter nichts passieren. Allerdings ist diese Funktion relativ neu und noch nicht so gut getestet. Vorteil der Upgrade-/Online-Installationsmethode: Sie können auch über die Schemainstallation hinaus andere Installationsaufgaben erledigen, z.B. initiale Daten installieren, Default-Settings laden, etc. Ab Version 2.3 ist eine Installation des PlugIns über OJS auch deshalb ratsam, weil nur so die version.xml-Datei gelesen und die entsprechenden Daten in die Tabelle versions eingetragen werden. Das ist wiederum Voraussetzung für saubere zukünftige Upgrades und für das sogenannte "lazy-load" von PlugIns. Sie finden in der neuesten Version von OJS, die jetzt herauskommt, viele Beispiele für solche "lazy-load" PlugIns (z.B. alle vorinstallierten Block- und Generic-PlugIns). Wir haben durch konsequenten "lazy-load" einen Performance-Vorteil von bis zu 40% von OJS 2.3.3 gegenüber OJS 2.3.2 gemessen wenn viele PlugIns aktiv sind. Natürlich funktionieren "old style" PlugIns auch weiterhin. Sie nutzen eben nur nicht die neue Funktionalität. Sie brauchen aber auch dann kein Skript zu schreiben, wenn Sie den vollen Upgrade-Prozess umgehen wollen. Es gibt in OJS eine Möglichkeit Schemata unabhängig von anderen Funktionen zu installieren: php tools/dbXMLtoSQL.php execute pfad/zu/ihrer/schemaDatei.xml Das hat den Vorteil, dass eventuell bereits existierende Daten in Ruhe gelassen werden und nur neue Tabellenspalten eingefügt oder obsolete Spalten gelöscht werden (idempotentes Upgrade). SQL-Skripts werden sonst bei späteren Upgrades ziemlich kompliziert, da Sie alle evtl. irgendwo bereits installierten Versionen im Skript explizit berücksichtigen müssen. Ich gehe dabei davon aus, dass entweder Sie selbst oder jemand anders aus der Community Ihr PlugIn später weiter entwickeln will. Darum der ganze Bezug auf zukünftige Versionen. Viele Grüße! Florian Grandel Software-Entwickler Public Knowledge Project (PKP) http://pkp.sfu.ca/people#fg jerico.dev(at)gmail[dot]com
	Profil
Verfasst am: 21. 09. 2010 [23:11]
PlugInSchreiber Advanced Themenersteller Dabei seit: 21.09.2010 Beiträge: 8	Welche Struktur muss denn das tar.gz haben, damit die Installation über den Upgrade-Mechanismus in der 2.3 funktioniert? Ich habe schon verschiedene Varianten probiert, aber immer erhalte ich diese Fehlermeldung: Es sind Fehler bei der Bearbeitung des Formulars aufgetreten.: * Version.xml wurde im Plug-In-Verzeichnis nicht gefunden Die version.xml ist aber enthalten. [Dieser Beitrag wurde 1mal bearbeitet, zuletzt am 22.09.2010 um 00:25.]
	Profil
Verfasst am: 22. 09. 2010 [04:57]
fgrandel Florian Grandel Moderator Dabei seit: 24.11.2009 Beiträge: 65	Oh, an dieser oft irreführenden Fehlermeldung bin ich auch schon hängen geblieben. Das tut mir leid. Wir haben für OJS 2.3.3 etwas bessere Fehlermeldungen für die Plugin-Installation eingebaut. Die Struktur im Zip sollte sein: pluginFolder --version.xml --settings.xml (optional) --index.php --XyzPlugin.inc.php --weitere pluginspezifische Dateien --locale (optional) ----en_US ----de_DE ----etc. Der Fehler kann aber auch andere Ursachen haben. Können Sie mir das Plugin (egal wie strukturiert) als Zip-Dateianhang im Forum hochladen oder wenn das nicht geht: per Mail schicken? Es wäre auch gut, wenn Sie mir die genaue OJS-Version nennen könnten, mit der Sie arbeiten. Wir haben kürzlich mehrere Fehler im Plugin-Installer behoben. Kann sein, dass Sie in Ihrer Version auf einen inzwischen behobenen Fehler treffen. Florian Grandel Software-Entwickler Public Knowledge Project (PKP) http://pkp.sfu.ca/people#fg jerico.dev(at)gmail[dot]com
	Profil
Verfasst am: 22. 09. 2010 [10:39]
sdaniel Stefan Daniel Administrator Dabei seit: 21.10.2009 Beiträge: 35	Anm. Admin: Dateiupload soeben fehlerfrei mit ZIP Datei getestet, bitte melden, falls größere Dateien hochgeladen werden sollen, dann setze ich das derzeitige Limit von 1 MB pro Datei herauf. S. Daniel Niedersächsische Staats- und Universitätsbibliothek Göttingen - (Elektronisches Publizieren) daniel(at)sub.uni-goettingen[dot]de http://www.carpet-project.net
	Profil WWW Skype
Verfasst am: 22. 09. 2010 [19:06]
PlugInSchreiber Advanced Themenersteller Dabei seit: 21.09.2010 Beiträge: 8	Ich habe mal ein Dummy-Projekt erstellt, bei dem ebenso das Problem auftritt. Probiert habe ich die Installation mit der OJS-Version 2.3.2.0. Schonmal vielen Dank für Hilfe Dateianhang
	Profil
Verfasst am: 22. 09. 2010 [20:51]
fgrandel Florian Grandel Moderator Dabei seit: 24.11.2009 Beiträge: 65	Hallo PluginSchreiber, ich habe gerade auf einer frischen Installation von OJS 2.3.2.0 das Dummy-PlugIn problemlos installiert. Ich habe auch nachgeprüft: Die Verbesserungen zur PlugIn-Installation sind bereits in 2.3.2 enthalten. Hier eine Checkliste, die Ihnen hoffentlich hilft, das Problem zu beseitigen: 1) Stellen Sie bitte sicher, dass Sie das tar-Programm installiert haben. 2) Prüfen Sie bitte, ob der Paramteter "tar" im Abschnitt [cli] der config.inc.php korrekt auf das tar-Programm zeigt. 3) Die folgenden Ordner im OJS-Verzeichnis müssen für den Webserver-User (auf Linux normalerweise httpd oder www-data) schreibbar sein: --files --files/temp (falls vorhanden) --plugins --plugins/generic 4) Löschen Sie eventuell aus vorangegangen Versuchen vorhandene Dateien im Ordner files/temp sowie den Ordner plugins/generic/dummyPlugIn. Falls diese für den Webuser nicht überschreibbar sind, kann es auch zu Problemen kommen. Falls Sie all das geprüft haben und immer noch nicht weiterkommen, dann können wir das Problem weiter einschränken, indem wir sehen bis wohin der Installationsprozess gekommen ist. 1) Prüfen Sie, ob im Ordner files/temp eine temporäre Datei (Zufallsfolge von Buchstaben und Zahlen, keine Endung) angelegt wurde (=Upload hat funktioniert) 2) Prüfen Sie bitte, ob ein Ordner dummyPlugIn im Ordner files/temp angelegt wurde (=Auspacken mit tar hat funktioniert). 3) Prüfen Sie bitte, ob der Ordner dummyPlugIn im Ordner plugins/generic angelegt wurde (=Kopieren hat funktioniert) 4) Loggen Sie sich in die Datenbank ein und prüfen Sie bitte, ob das folgende SQL-Statement ein Ergebnis liefert (=Installation hat funktioniert): SQL SELECT * FROM versions WHERE product='dummyPlugIn'; Ich denke so werden wir das Problem schon erwischen ;-) Noch ein Tipp: Sie sollten produktiv nur mit OJS 2.3.2.1 arbeiten, da in 2.3.2.0 ein Sicherheitsrisiko entdeckt wurde. Florian Grandel Software-Entwickler Public Knowledge Project (PKP) http://pkp.sfu.ca/people#fg jerico.dev(at)gmail[dot]com
	Profil
Verfasst am: 22. 09. 2010 [21:06]
PlugInSchreiber Advanced Themenersteller Dabei seit: 21.09.2010 Beiträge: 8	fgrandel schrieb: 1) Stellen Sie bitte sicher, dass Sie das tar-Programm installiert haben. Ich bin mehr oder weniger in das OJS reingerutscht und gebeten worden ein PlugIn zu entwickeln. Deswegen sind meine Kenntnisse über das eigentliche OJS nicht sehr umfangreich, was die Konfiguration etc. angeht. Ist mit dem ersten Punkt gemeint, dass auf dem Server tar installiert sein soll, oder handelt es sich hierbei auch um ein PlugIn für OJS?
	Profil
Verfasst am: 22. 09. 2010 [22:49]
fgrandel Florian Grandel Moderator Dabei seit: 24.11.2009 Beiträge: 65	PlugInSchreiber schrieb: Deswegen sind meine Kenntnisse über das eigentliche OJS nicht sehr umfangreich, was die Konfiguration etc. angeht. Das ist überhaupt kein Problem. Dafür gibt's ja dieses Forum. :-) Ich bin eben manchmal auch schon ein bisschen betriebsblind. PlugInSchreiber schrieb: Ist mit dem ersten Punkt gemeint, dass auf dem Server tar installiert sein soll, oder handelt es sich hierbei auch um ein PlugIn für OJS? Damit war gemeint, dass auf dem Server das tar-Programm installiert sein soll. Das wird bei der PlugIn Installation benötigt, um die PlugIn-Datei auszupacken. Ein gesondertes OJS-PlugIn ist nicht notwendig, nur die korrekte Konfiguration in der Datei config.inc.php im OJS Ordner, damit OJS das tar-Programm auf dem Server findet. Florian Grandel Software-Entwickler Public Knowledge Project (PKP) http://pkp.sfu.ca/people#fg jerico.dev(at)gmail[dot]com
	Profil
Verfasst am: 23. 09. 2010 [01:44]
PlugInSchreiber Advanced Themenersteller Dabei seit: 21.09.2010 Beiträge: 8	Nach zahlreichen Versuchen ist es mir nun gelungen das PlugIn zu installieren. Das Problem war, dass tar immer auf Fehler gelaufen ist (es gab/gibt unter Windows Probleme mit dem "forken"). Und es hat einige Zeit gedauert, bis ich dahinter gekommen bin. Um mich jetzt damit nicht auch noch weiter rumzuärgern habe ich es so gelöst, dass ich den PlugIn-Ordner (ausgepacktes tar-Archiv) in das Temp-Verzeichnis kopiert und in PluginManagementHandler.inc.php die Zeile PHP 153: exec('tar -xzf ' . escapeshellarg($temporaryFile->getFilePath()) . ' -C ' . escapeshellarg($pluginDir)); auskommentiert habe. Dies sollte der Ausführung von tar an dieser Stelle entsprechen. Dabei ist mir aufgefallen, dass an dieser Stelle der entsprechende Eintrag in der Config für tar anscheinend gar nicht ausgewertet wird (exec('tar...')). Ich hätte jetzt so etwas erwartet wie ich es in TranslatorAction.inc.php gefunden habe PHP $tarBinary = Config::getVar('cli', 'tar'); if (empty($tarBinary) \|\| !file_exists($tarBinary)) { // We can use fatalError() here as we already have a user // friendly way of dealing with the missing tar on the // index page. fatalError('The tar binary must be configured in config.inc.php\'s cli section to use the export function of this plugin!'); } $command = $tarBinary.' cz'; ... Aber das nur am Rande. Erfreulicherweise habe ich letztendlich die Meldung erhalten, dass mein PlugIn erfolgreich installiert worden ist. Allerdings ist die entsprechende Tabelle in der Datenbank wieder nicht erzeugt worden.
	Profil
Verfasst am: 24. 09. 2010 [02:16]
fgrandel Florian Grandel Moderator Dabei seit: 24.11.2009 Beiträge: 65	Hallo PlugInSchreiber, PlugInSchreiber schrieb: Dabei ist mir aufgefallen, dass an dieser Stelle der entsprechende Eintrag in der Config für tar anscheinend gar nicht ausgewertet wird ([i]exec('tar...') Dieser Fehler ist in der neuesten OJS-Version, dort Zeile 165, behoben. Ich nehme an, dass es bei mir deshalb mit OJS 2.3.2.0 funktioniert hat, weil tar bei mir im Pfad ist. Ich habe, die PlugIn-Installation auf Windows ausprobiert. Dort benutze ich cygwin, um Programme wie tar zu installieren. Bisher hatte ich beim Aufruf von cygwin-Programmen aus PHP heraus dabei keine Probleme. PlugInSchreiber schrieb: Allerdings ist die entsprechende Tabelle in der Datenbank wieder nicht erzeugt worden. Ich habe hierzu einen Bug-Report eröffnet. Es wäre nett, wenn Sie dort für meinen Kollegen, der den Installationsprozess entwickelt hat, das Plug-In mit der Schematabelle hochladen oder uns sonst einen Tipp geben könnten, wie wir den Fehler eingrenzen können. Der PlugIn-Installer ist wie gesagt ganz neu und offensichtlich noch nicht fehlerfrei. Dass Sie sich trotzdem rangewagt haben ist für uns sehr hilfreich! Vielen Dank dafür. Sie müssen aber nicht warten, bis dieser Fehler behoben ist, um Ihr PlugIn zu veröffentlichen. Es gibt ja noch den klassischen Installationsprozess, wie ich ihn am Anfang beschrieben hatte (PlugIn in Ordner kopieren und Upgrade-Skript ausführen), der bei Ihnen auch gleich funktioniert hat. Diese Art der PlugIn-Installation ist wahrscheinlich den meisten OJS-Betreibern vertraut. Einen technischen Nachteil hat der manuelle Prozess gegenüber dem Upload über die Webseite nicht. Er vermeidet genauso alle Nachteile eines selbstgebauten SQL-Skripts: Eintrag in die versions-Tabelle, Installation von Default-Settings, einfaches Upgrade auf zukünftige Versionen und Unterstützung von "lazy-load". Florian Grandel Software-Entwickler Public Knowledge Project (PKP) http://pkp.sfu.ca/people#fg jerico.dev(at)gmail[dot]com
	Profil
Verfasst am: 24. 09. 2010 [23:57]
PlugInSchreiber Advanced Themenersteller Dabei seit: 21.09.2010 Beiträge: 8	Ich habe mir den eben Bug-Report durchgelesen und festgestellt, dass ich wohl etwas langsam war ;-) Vielen Danke! Ich habe mein PlugIn dementsprechend geändert (install.xml hinzugefügt und dieses anstatt des schema.xml referenziert). Damit funktioniert auch das Erzeugen der Tabelle beim installieren :-) Nur leider musste ich dann feststellen, dass mein PlugIn anscheinend nicht ganz kompatibel zu der 2.3.2 ist. Aber das muss ich mir noch genauer anschauen, warum, wieso, weshalb... Dazu bin ich noch nicht gekommen. Noch eine kleine Zusatzfrage zu der install.xml und version.xml. Muss man in beiden die Versionsnummer pflegen? Wenn ja, wozu dieser doppelte Aufwand? Es wird vermutlich in den wenigstens Fällen die Tabellenbeschreibung geändert, ohne das sich das PlugIn ändert und damit auch seine Version, oder? [Dieser Beitrag wurde 1mal bearbeitet, zuletzt am 24.09.2010 um 23:59.]
	Profil
Verfasst am: 25. 09. 2010 [00:26]
fgrandel Florian Grandel Moderator Dabei seit: 24.11.2009 Beiträge: 65	PlugInSchreiber schrieb: Vielen Dank! Ich habe mein PlugIn dementsprechend geändert (install.xml hinzugefügt und dieses anstatt des schema.xml referenziert). Damit funktioniert auch das Erzeugen der Tabelle beim installieren :-) Ich bin noch nicht ganz zufrieden mit dem Ergebnis des Bug Reports. Für mich ist es nicht einleuchtend, weshalb ein install.xml notwendig sein soll. Normalerweise müsste die ursprüngliche Lösung genauso funktionieren, auch um die Rückwärtskompatibilität früherer PlugIns zu garantieren. Ich habe meine Zweifel im Bug Report dokumentiert, s. dort. PlugInSchreiber schrieb: Noch eine kleine Zusatzfrage zu der install.xml und version.xml. Muss man in beiden die Versionsnummer pflegen? Wenn ja, wozu dieser doppelte Aufwand? Es wird vermutlich in den wenigstens Fällen die Tabellenbeschreibung geändert, ohne das sich das PlugIn ändert und damit auch seine Version, oder? Ja, diese Frage ist berechtigt. Ich bin wie gesagt der Meinung, dass in 99% der Fälle ein install.xml überhaupt nicht sinnvoll ist, dann fällt auch diese Inkonsistenz weg. Ich schlage vor, Sie abonnieren sich den Bug Report, dann bekommen Sie automatisch mit, wie die Diskussion weitergeht. Jedenfalls haben Sie da sehr berechtigte Fragen gestellt. Florian Grandel Software-Entwickler Public Knowledge Project (PKP) http://pkp.sfu.ca/people#fg jerico.dev(at)gmail[dot]com
	Profil
Verfasst am: 26. 09. 2010 [20:46]
PlugInSchreiber Advanced Themenersteller Dabei seit: 21.09.2010 Beiträge: 8	Nachdem nun die beiden Installationsmechanismen imkompatibel zueinander sind: OJS 2.2.4: php tools/upgrade.php upgrade -> Referenzierung der schema.xml, kann mit install.xml nichts anfangen OJS 2.3.2: Update-PlugIn -> Referenzierung der install.xml, kann mit schema.xml nichts anfangen Gibt es eine Möglichkeit zu ermitteln, solange diese Inkompatiblen bestehen, herauszufinden, welcher Mechanismus gerade verwendet wird, um die "richtige" Referenz liefern zu können? Oder sollte man unterschiedliche Versionen ausliefern? Oder nur auf eine Technik setzen?
	Profil
Verfasst am: 27. 09. 2010 [16:59]
fgrandel Florian Grandel Moderator Dabei seit: 24.11.2009 Beiträge: 65	PlugInSchreiber schrieb: Gibt es eine Möglichkeit zu ermitteln, solange diese Inkompatiblen bestehen, herauszufinden, welcher Mechanismus gerade verwendet wird, um die "richtige" Referenz liefern zu können? Oder sollte man unterschiedliche Versionen ausliefern? Oder nur auf eine Technik setzen? Wenn die Zeit knapp ist, dann würde ich mich ausschließlich auf den manuellen Installationsprozess konzentrieren. Erstens ist das der Prozess, den die meisten Nutzer bereits kennen und nutzen und zweitens werde ich alles dafür tun, dass der neue webbasierte Installationsprozess spätestens in OJS 2.3.4 mit dem manuellen Prozess kompatibel wird. Das ist für mich ein klarer Fehler, den wir beheben müssen. (Für OJS 2.3.3 ist es wahrscheinlich zu spät, das kommt wohl diese Woche schon raus.) Wenn mich nicht alles täuscht, dann unterstützt ihr PlugIn aber inzwischen so wie so schon beide Prozesse. Denn Sie haben ja nun sowohl ein install.xml als auch die getInstallSchemaFile()-Methode implementiert. Wenn Sie die Doppelung zwischen install.xml und getInstallSchemaFile() und install.xml und version.xml (wegen der Versionsnummer) nicht zu sehr stört, dann wäre es aus Nutzersicht wahrscheinlich besser, Sie lassen einfach beides drin und ändern das PlugIn erst in zukünftigen Versionen, wenn wir die Inkonsistenzen in den beiden Installationsprozessen beseitigt haben. Florian Grandel Software-Entwickler Public Knowledge Project (PKP) http://pkp.sfu.ca/people#fg jerico.dev(at)gmail[dot]com
	Profil