Zeitschrift Setup weg

Nach dem Upgrade von 2.3.x über 2.4.x auf 3.0.2. ist die Zeitschrift www.fzwp.de zwar zugänglich, aber das Setup nicht. Bei Einstellungen > Zeitschrift ist zum Beispiel steht oben:

Impressum [http://fzwp.de/index.php/logos/$$$call$$$/tab/settings/journal-settings-tab/show-tab?tab=masthead]
Kontakt
Rubriken der Zeitschrift

Dann nichts. Die Links reagieren nicht. Habe zum Testen eine neue Zeitschrift eingerichte, da geht alles. Was ist bei der alten Zeitschrift schiefgelaufen?

Könnte ich vielleicht irgendwie eine neue Zeitschrift einrichten und dann die alten Inhalte unterschieben?

In phpmyadmin ist mir noch aufgefallen, daß einige Tabellen die Kollation “utf8-general-ci” und einige “latin1-swedish-ci”. Aber daran wird es wohl nicht liegen.

Hi @Aragon

Könnten Sie im Error-Logfie sehen ob ein Fehler auftritt wenn Sie die Seite Einstellungen > Zeitschrift öffnen?

Haben Sie das upgrade von 2.3.x auf 2.4.x gründlich getestet, ob da alles gut gelaufen ist?

Sie haben nicht so viele Artikel so dass eine Neueinrichtung ginge. Nichts­des­to­trotz müssten Sie alles neu eingeben, Zeitschrifteneinstellungen und Artikeln. Die Workflow-Schritte (z. B. Begutachtungen) können Sie in dem Fall nicht migrieren.
Aber, eigentlich sollte Upgrade gut laufen.

Ihre Datenbank scheint nicht richtig konfiruriert zu sein – anscheinend wurde nicht überall die utf8 konfiguriert.

Viele Grüße
Bozana Bokan

Im error.log sind Meldungen folgender Art:

[Mon Mar 06 16:35:16 2017] [warn] [client 212.77.58.73] mod_fcgid: stderr: PHP Warning: json_encode(): Invalid UTF-8 sequence in argument in /var/www/clients/client45/web141/web/cache/t_compile/3996a06a2f7618f5df83cf95386f2ae83d33c766^%%E9^E9A^E9A4A4CC%%linkActionOptions.tpl.php on line 23, referer: http://fzwp.de/index.php/logos/submissions

[Mon Mar 06 16:35:16 2017] [warn] [client 212.77.58.73] mod_fcgid: stderr: PHP Warning: json_encode(): Invalid UTF-8 sequence in argument in /var/www/clients/client45/web141/web/cache/t_compile/3996a06a2f7618f5df83cf95386f2ae83d33c766^%%E9^E9A^E9A4A4CC%%linkActionOptions.tpl.php on line 23, referer: http://fzwp.de/index.php/logos/submissions

[Mon Mar 06 16:35:21 2017] [warn] [client 212.77.58.73] mod_fcgid: stderr: PHP Notice: unserialize(): Error at offset 614 of 2673 bytes in /var/www/clients/client45/web141/web/lib/pkp/classes/db/DAO.inc.php on line 347, referer: http://fzwp.de/index.php/logos/submissions

[Mon Mar 06 16:35:21 2017] [warn] [client 212.77.58.73] mod_fcgid: stderr: PHP Warning: file_exists(): open_basedir restriction in effect. File(/lib/pkp/js/lib/jquery/plugins/validate/localization/messages_de_DE.js) is not within the allowed path(s): (/var/www/clients/client45/web141/web:/var/www/clients/client45/web141/private:/var/www/clients/client45/web141/tmp:/var/www/fzwp.de/web:/srv/www/fzwp.de/web:/usr/share/php5:/usr/share/php:/tmp:/usr/share/phpmyadmin:/etc/phpmyadmin:/var/lib/phpmyadmin) in /var/www/clients/client45/web141/web/lib/pkp/classes/template/PKPTemplateManager.inc.php on line 571, referer: http://fzwp.de/index.php/logos/submissions

[Mon Mar 06 16:35:24 2017] [warn] [client 212.77.58.73] mod_fcgid: stderr: PHP Notice: unserialize(): Error at offset 614 of 2673 bytes in /var/www/clients/client45/web141/web/lib/pkp/classes/db/DAO.inc.php on line 347, referer: http://fzwp.de/index.php/logos/management/settings

[Mon Mar 06 16:35:24 2017] [warn] [client 212.77.58.73] mod_fcgid: stderr: PHP Warning: json_encode(): Invalid UTF-8 sequence in argument in /var/www/clients/client45/web141/web/lib/pkp/classes/core/JSONMessage.inc.php on line 162, referer: http://fzwp.de/index.php/logos/management/settings

Soll ich die Datenbank-Tabellen per Hand auf utf8-general-ci umstellen?
Dankend, Daniel von Wachter

Ist das reparierbar, oder ist der einzige oder einfachste Ausweg jetzt eine Neuinstallation? Wir haben bisher nur ganz wenige Artikel. Können wir denn dann auch Ausgaben früherer Jahre, z.B. “2013” erzeugen? Wie können wir die existierenden Benutzer (in der Tabelle “users”) importieren?

@Aragon

Haben Sie Backup von der alten 2.3.x Installation?

Ich kann keinen Error im Error-Logfile sehen, daher weiß ich immer noch nicht was der Fehler ist bzw. warum die Einstellugns-Seite nicht ganz lädt.

Was DB tabellen und Einstellungen angeht: ja, man sollte alles auf utf8 setzten (alles in der DB und OJS config.php.inc). Manchmal ist auch ein update der DB-Daten nötig, falls die Daten in einer anderen Kodierung gespeichert waren. Außerdem sollte die DB-Konfiguration so sein, dass beim erstellen einer neuen Tabelle oder Spalte automatisch utf-8 genommen wird – das ist z. B. wichtig für spätere Updates, die eine neue Tabelle oder Spalte einfügen… Ich werde hierzu versuchen einige Links im Internet zu finden, die für Sie vielleicht hilfreich sein könnten…

Beste Grüße
Bozana Bokan

Ich habe die Backups schon, aber wenn wir nicht wissen, wo der Fehler liegt, kann dasselbe wieder passieren. Wir versuchen jetzt unter neu.fzwp.de eine Neuinstallation von 3.0.2. Dabei kommt die Fehlermeldung

open_basedir restriction in effect. File(/lib/pkp/js/lib/jquery/plugins/validate/localization/messages_en_US.js) is not within the allowed path(s): (/var/www/clients/client45/web141/web:/var/www/clients/client45/web141/private:/var/www/clients/client45/web141/tmp:/var/www/fzwp.de/web:/srv/www/fzwp.de/web:/usr/share/php5:/usr/share/php:/tmp:/usr/share/phpmyadmin:/etc/phpmyadmin:/var/lib/phpmyadmin) in /var/www/clients/client45/web141/web/ojs/lib/pkp/classes/template/PKPTemplateManager.inc.php on line 571

Solche Fehlermeldungen stehen auch im error.log. Muß ich und kann ich etwas dagegen tun?

PS. Die Installation läuft durch, die Datenbanktabellen werden und die Verzeichnisse im
files_dir = /var/www/clients/client45/web141/private/ojsdateien
werden gebildet. Aber wenn ich mich dann als admin einlogge, kommt nichts; nur das, was man unter http://neu.fzwp.de sieht. Mache ich einen Fehler, oder liegt es am “open_basedir restriction in effect”? Im Error.log finde ich außer “open_basedir restriction in effect” Meldungen Meldungen folgender Art:

[Tue Mar 07 18:06:13 2017] [warn] [client 79.255.16.203] mod_fcgid: stderr: PHP Notice: unserialize(): Error at offset 614 of 2673 bytes in /var/www/clients/client45/web141/web/ojsalt/lib/pkp/classes/db/DAO.inc.php on line 347

PPS: Auf ERROR AFTER UPGRADE OJS 3.0.2 from 2.4.6 - #12 by asmecher steht: “[file permissions are] not just a question of numerical permissions (e.g. 755, read/write, etc.) but also file ownership.” Da ich nur FTP-Zugang habe, kann ich owner nicht ändern. Kann das der Fehler sein? Habe die Permissions jetzt versuchtshalber auf 777 gesetzt, nützt auch nichts.
Bei php ist FAST-CGI eingestellt. Laut https://pkp.sfu.ca/wiki/index.php/PKP_Frequently_Asked_Questions#I.27m_having_file_permission_problems.3B_how_should_I_set_file_permissions.3F müßte das gehen.

Ratloser Gruß,
Daniel von Wachter

Hier nochmal alle Fehlermeldungen, die bei einer Neuinstallation von 3.0.2 beim ersten Aufrufen der URL erscheinen:

Warning: file_exists(): open_basedir restriction in effect. File(/lib/pkp/js/lib/jquery/plugins/validate/localization/messages_de_DE.js) is not within the allowed path(s): (/var/www/clients/client45/web141/web:/var/www/clients/client45/web141/private:/var/www/clients/client45/web141/tmp:/var/www/fzwp.de/web:/srv/www/fzwp.de/web:/usr/share/php5:/usr/share/php:/tmp:/usr/share/phpmyadmin:/etc/phpmyadmin:/var/lib/phpmyadmin) in /var/www/clients/client45/web141/web/ojs/lib/pkp/classes/template/PKPTemplateManager.inc.php on line 571

Warning: file_exists(): open_basedir restriction in effect. File(/lib/pkp/js/lib/jquery/plugins/validate/localization/messages_de.js) is not within the allowed path(s): (/var/www/clients/client45/web141/web:/var/www/clients/client45/web141/private:/var/www/clients/client45/web141/tmp:/var/www/fzwp.de/web:/srv/www/fzwp.de/web:/usr/share/php5:/usr/share/php:/tmp:/usr/share/phpmyadmin:/etc/phpmyadmin:/var/lib/phpmyadmin) in /var/www/clients/client45/web141/web/ojs/lib/pkp/classes/template/PKPTemplateManager.inc.php on line 571

Warning: file_exists(): open_basedir restriction in effect. File(/lib/pkp/lib/vendor/moxiecode/plupload/js/i18n/de_DE.js) is not within the allowed path(s): (/var/www/clients/client45/web141/web:/var/www/clients/client45/web141/private:/var/www/clients/client45/web141/tmp:/var/www/fzwp.de/web:/srv/www/fzwp.de/web:/usr/share/php5:/usr/share/php:/tmp:/usr/share/phpmyadmin:/etc/phpmyadmin:/var/lib/phpmyadmin) in /var/www/clients/client45/web141/web/ojs/lib/pkp/classes/template/PKPTemplateManager.inc.php on line 588

Warning: file_exists(): open_basedir restriction in effect. File(/lib/pkp/lib/vendor/moxiecode/plupload/js/i18n/de.js) is not within the allowed path(s): (/var/www/clients/client45/web141/web:/var/www/clients/client45/web141/private:/var/www/clients/client45/web141/tmp:/var/www/fzwp.de/web:/srv/www/fzwp.de/web:/usr/share/php5:/usr/share/php:/tmp:/usr/share/phpmyadmin:/etc/phpmyadmin:/var/lib/phpmyadmin) in /var/www/clients/client45/web141/web/ojs/lib/pkp/classes/template/PKPTemplateManager.inc.php on line 588

Ist das nicht doch die Ursache des Problems?

Hmmm… ich bin etwas überfragt… Ich weiß es nicht ob das die Ursache ist, aber es scheint eine Restriktion auf dem Server zu geben… S. auch Moved OJS 3.o to new domain and server issue - #20 by ctgraham
Vielleicht doch sich an den Server-/Hosting-Provider zu wenden?

Der Provider weigert sich. Sagt, für so etwas muß man einen eigenen Server haben. Wir spielen jetzt Version 2.4. wieder ein.

Hmmm… aber woran lag es, was war das eigentliche Problem?

Haben Sie denn bei der Einrichtung von OJS3 auch sämtliche Schritte durchgeführt inkl. Composer?

Ich weiß nicht, was der “Composer” ist, aber ich habe die Anleitungen genau befolgt. Inklusive in der Config “installed” auf Off setzen, Rechte auf 775 setzen etc.

Selbst bei der Neuinstallation kam “open_basedir restriction in effect”.

Jetzt haben wir eine altes Backup eingespielt, da kam jetzt in error.log auch eine Fehlermeldung, als ich in die Website-Verwaltung gehen wollte:

[Wed Mar 08 16:18:49 2017] [warn] [client 212.77.58.73] mod_fcgid: stderr: PHP Fatal error: Call to undefined function session_is_registered() in /var/www/clients/client45/web141/web/ojsalt/lib/pkp/classes/session/Session.inc.php on line 64, referer: http://fzwp.de/index.php/logos/user

[Wed Mar 08 16:19:06 2017] [warn] [client 212.77.58.73] mod_fcgid: stderr: PHP Fatal error: Call to undefined function session_is_registered() in /var/www/clients/client45/web141/web/ojsalt/lib/pkp/classes/session/Session.inc.php on line 64, referer: http://fzwp.de/index.php/logos/user

[Wed Mar 08 16:33:28 2017] [warn] [client 163.172.66.26] mod_fcgid: stderr: ojs2: 404 Not Found

Frage mich, ob es bei unserem Server eine Einstellung gibt, die sich mit OJS nicht verträgt. Vielleicht das Fast-CGI?

D.h. Sie haben die Submodules ebenfalls geupdated mit git submodule update --init --recursive und haben anschließend in Ordner lib/pkp folgende Befehle über die Kommandozeile ausgeführt:
curl -sS https://getcomposer.org/installer | php php composer.phar update

Sie müssen auch beim Update auf 2.4.x eigentlich die Submodules entsprechend updaten (und den Branch mittels git checkout ojs-stable-[die jeweilige Versionsnummer] zuvor im lib/pkp Ordner auswählen).

Sind Sie so vorgegangen?

1 Like

Danke für diese Hinweise! Jetzt bin ich doch erstaunt, denn im README steht nichts dergleichen. Wir können diese Dinge nicht tun, weil wir OJS bei einem Provider installiert haben, so daß wir nur über FTP und über phpmyadmin Zugriff haben. Heißt das, daß wir OJS jetzt nicht so bei einem Provider betreiben können? Dann müßten wir uns einen OJS-Dienstleister suchen. Als wir 2009 OJS 2.2.3 installierten, klappte das ohne weiteres.
Besten Gruß, Daniel von Wachter

Prinzipiell müsste es auch möglich sein, die Daten lokal so zusammenzustellen und dann zu kopieren. Den Branch mittels git zu wählen ist prinzipiell komfortabel und ratsam, aber nicht zwingend notwendig, Sie können auch die Dateien herunterladen, dann entfällt die Branch-Wahl und, so gehe ich mal davon aus, auch das Updaten der submodules. Der Composer muss aber einmal ausgeführt werden, um externe Dritt-Software zu laden, die OJS benötigt, um korrekt zu funktionieren. Das müssten Sie aber immer tun, wenn Updates anstehen und es ist sehr ratsam, die Updates auch regelmäßig zu installieren, um Patches/Bugfixes zu erhalten. Hier wäre sicherlich ein OJS-Hosting-Provider die komfortabelste und für Sie sorgenfreiste Lösung, wenn auch formal kostenintensiver verglichen mit einem der großen Web-Provider wie Strato, Hosteurope, Hetzner, etc. Berücksichtigt man allerdings den Support (Installation, Pflege, Updates, etc), dann lohnt sich durchaus ein entsprechender OJS-Hosting-Provider, wenn man sich mit der Serveradministration nicht beschäftigen möchte/kann.

Es gibt viele einfache Hosting-Angebote, bei denen man auch SSH-Zugriff bekommt, ohne einen ganzen Server zu mieten (was auch nicht sonderlich teuer ist bei vielen der gängigen Hosting-Provider). Ihnen würde dann zwar git fehlen, sie müssten also die Dateien händisch hochladen und das jedes Mal wiederholen, wenn Sie ein Update installieren wollen. Sie müssen auch beachten, ob das Hosting-Angebot cronjobs unterstützt, da diese für manche Plugins/Funktionen notwendig sein können.

1 Like

Danke. Ich muß nochmal nachfragen, weil unsere Entscheidung, ob wir OJS weiter selbst betreiben können, davon abhängt. Wir haben 2009 die Installation und 2011 ein Update genau so gemacht, wie es im Readme beschrieben ist. Die Installation haben wir im Browser in Gang gesetzt. Da steht nichts von Branches, Submodulen und Composer. Wir haben keine Daten zusammengestellt, sondern die Vollersion von https://pkp.sfu.ca/ojs/ojs_download/ genommen. Ist es nicht (mehr) möglich, OJS so nur mit Zugang über FTP und phpmyadmin zu installieren und zu aktualisieren? Ich hatte die Vermutung, daß unser Provider irgendwelche besonderen, mit OJS unverträglichen Einstellungen verwendet (siehe oben), die wir bei einem anderen Provider nicht hätten. SSH-Zugriff könnten wir sicher bekommen, aber wenn die im Readme beschriebene Methode nicht mehr ausreicht, wird mir das zu arbeitsintensiv. Danke für die Hilfe, Daniel von Wachter

PS. Gerade habe die Installation bei einem anderen Provider probiert. Wieder Fehlermeldungen:

Warning: file_exists(): open_basedir restriction in effect. File(/lib/pkp/js/lib/jquery/plugins/validate/localization/messages_en.js) is not within the allowed path(s): (/home/web7d8yi5/:/tmp/:/opt/php-5.6/lib/php/:/opt/php-7.0/lib/php/:/dev/urandom) in /home/web7d8yi5/html/ojs/lib/pkp/classes/template/PKPTemplateManager.inc.php on line 571

Strict Standards: Declaration of DevelopedByBlockPlugin::getSeq() should be compatible with BlockPlugin::getSeq($contextId = NULL) in /home/web7d8yi5/html/ojs/plugins/blocks/developedBy/DevelopedByBlockPlugin.inc.php on line 0

Deprecated: Non-static method Application::getName() should not be called statically, assuming $this from incompatible context in /home/web7d8yi5/html/ojs/lib/pkp/classes/install/form/InstallForm.inc.php on line 146

Das sind keine Fehlermeldungen, sondern Warnungen. Ich habe mir einmal den Paketinhalt der Download-Version angeschaut und der Inhalt des Vendor-Verzeichnisses (also der Ort, an dem die externen Libraries gespeichert werden) unterscheidet sich von meiner Version, die mittels Composer zusammengestellt wurde.

Wie haben Sie bisher den files-Ordner geschützt vor Zugriffen? Haben Sie dafür eine .htaccess-Datei erstellt?

Nein, htaccess-Datei habe ich keine erstellt, aber der files-Ordner ist nicht im Web-Verzeichnis.
Aber: Jetzt auf einmal konnte ich (beim alten Provider) OJS 3 neu installieren. Ich nehme an, daß der Provider inzwischen etwas geändert oder repariert hat. Bei der alten, wieder aufgespielten Version 2.3. klappt die Zeitschriftenverwaltung und das Logout nicht, aber wir werden die Zeitschrift neu bei OJS 3 einrichten.
Also: Problem vorerst gelöst, vielen Dank für die Hilfe.