Hallo zusammen,
läuft das aktuelle OSP auch unter php 7.x problemlos? Wir müssen unseren Webspace auf einen neuen Server umziehen, der kein php 5 mehr unterstützt.
Grüße
Hallo,
Nein. Derzeit muss die Empfehlung lauten:
Debian 8 LTS mit PHP5.6 für OSP zu verwenden.
Es wird eine aktualisierte Version geben, die dann auch mit aktuellen
PHP Versionen lauffähig ist.
VG
Frank
Hallo Frank, wir müssten ein TYPO3 Update durchführen, wo dann nur auf PHP7 danach am Server lief. Natürlich funktioniert nicht mehr OSP. Deshalb meine Frage: wird es bald unter PHP7 laufen, oder sollen wir es auf einen anderen Server umziehen?
VG, und vielen Dank,
Jack
Hallo,
derzeit verhandelt das Landesinstitut für Schulentwicklung, ob die Aktualisierung für PHP7 “outgesourct” werden kann an die Entwickler von DokuWiki, oder ob ich das alles in m einer Freizeit machen muss.
In jedem Fall wird es bis zum Ende des Jahres eine PHP7 fähige Version geben, auf die Schnelle eher nicht.
Man kann das Wiki in einen Docker Container stecken, das habe ich eigentlich schon gemacht - soll ich das zur Verfügung stellen oder hilft das nix?
VG
Frank
Hallo Frank und danke für die schnelle Rückmeldung.
Könnten wir das mit dem DOCKER CONTAINER ausprobieren? Was genau ist hierbei gemeint? Es hört sich vielversprechend an. Danke im voraus dafür.
VG, Jack
Hallo Frank,
In jedem Fall wird es bis zum Ende des Jahres eine PHP7 fähige Version geben, auf die Schnelle eher nicht.
Man kann das Wiki in einen Docker Container stecken, das habe ich eigentlich schon gemacht - soll ich das zur Verfügung stellen oder hilft das nix?
ich will OSP auch auf dem Ubuntu 18.04 Server mit PHP 7.2 wieder ausrollen.
Gibt’s zu der Dockervariante auch ne Doku für Newbies wie mich, oder wie
sehr Jahresende wird das mit der PHP 7 Unterstützung?
Viele Grüße
Steffen
Hallo Frank,
da ich im Bereich
nach 3 aufeinanderfolgenden (eigenen) Antworten nichts mehr schreiben kann, mache ich hier weiter, da es vielleicht sogar besser passt.-
Ich habe heute nochmals versucht, die Erkennung der Gruppen hinzubekommen. Es scheint so, als ob die Zeile
$conf[‚plugin‘][‚authldap‘][‚groupdelprefix‘] = „p_“;
in der local.php keinerlei Wirkung hat. Es ändert sich nichts, wenn ich sie auskommentiere.
Wenn ich dagegen in der Zugangsverwaltung Regeln für einen einzelnen User setze, dann werden diese übernommen.
Viele Grüße
Wilfried
Hallo,
‚groupdelprefix‘ scheint es nicht mehr zu geben und ich habe auch keinen Ersatz gefunden, der in dem verwendeten Plugin funktioniert.
Lösung: In der Zugangsverwaltung die Rechte für (neue) Gruppen mit dem Prefix ‚p_‘ setzen, dann geht’s. Geändert habe ich auch in der local.php den Befehl für den ldap-admin: $conf[‚superuser‘] = ‚@p_portfolioadm‘;
Außerdem habe ich noch 2 Sachen auf der Login-Seite geändert:
-
Logo erschien nicht: Das Logo liegt bei mir (ohne mein aktives Zutun) nach dem Update unter ‚wiki‘. Damit auch nicht eingeloggte das Logo sehen können, müssen @All in der Zugangsverwaltung Leserechte für den Namensraum ‚wiki‘ erhalten.
vgl. https://www.dokuwiki.org/template:dokuwiki#changing_the_logo -
Den etwas martialischen (und hier so sinnlosen) Text auf der Loginseite „Zugang verweigert …“ kann man ändern, indem man die Datei /portfolio/inc/lang/de/denied.txt ändert. Da der Text aber auch an anderen Stellen zum Einsatz kommt, sollte es ein (freundlicher) Hinweis sein, dass die Berechtigungen fehlen.
Kann sein, dass nach einem Update wieder Eingriffe erforderlich sind. Wahrscheinlich kann man das mit php-Kenntnissen besser und dauerhaft lösen.
Viele Grüße
Wilfried
PS: Das Ganze gilt vornehmlich für die momentan eher schweigsame Masse der 6.2-Nutzer 
Hallo Wilfried, (bin lmn7 user, das ops liegt auf belwue)
ich hätte auch gerne unser Logo-Bildchen schon vor dem Login auf der login-Seite sichtbar.
Leider haben alle User ohne Anmeldung dann die Möglichkeit oben rechts mit dem Suchfenster das ganze Portfolio zu durchsuchen, und das finde ich nicht ganz so ideal 
Wie ist das bei Dir?
Viele Grüße
Matthias
Hallo Matthias,
ich habe eine „Serviceseite“, von der aus u. a. auf die Loginseite des Portfolios verlinkt wird. Versucht sich dort beispielsweise ein Schüler anzumelden, erhält er lediglich die Mitteilung, dass er zu diesem Bereich keinen Zugang habe. Das liegt an der Zugangsverwaltung, in der ganz oben geregelt ist, das @ALL ‚keine‘ Berechtigung hat, also auch nicht ‚lesen‘.
Viele Grüße
Wilfried
Hallo,
unter php 7.2 läuft das aktuelle OSP ja. Hat jemand schon Erfahrungen mit php 7.3 oder höher?
Viele Grüße
Steffen
Hallo Wilfried,
Vielleicht ist mein Problem nicht ganz klar geworden.
Also bei mir ist ganz oben natürlich *(Wurzel) @ALL auch auf „keine Berechtigung“.
-
Wenn bei mir wiki:* @ALL „lesen“:
Ergebnis:
+ logo ist da
- Abschreckende Meldung beim erstmaligen Aufruf der Seite (Zugang verweigert ...)
- Suchfenster rechts oben ist aktiv
Daher habe ich wieder
wiki:* @ALL auf „keine“ gestellt. -
Wenn bei mir (nur): wiki:logo:* @ALL „lesen“:
Ergebnis:
- logo fehlt
- Abschreckende Meldung beim erstmaligen Aufruf der Seite (Zugang verweigert ...)
- Suchfenster aktiv
Durch das Testweise Ein- und Ausschalten der Leserechte habe ich jetzt als angemeldeter User Keine Logos mehr in der Startseite.
Diese bekomme ich aktuell nur wieder, wenn ich wiki: für ALL auf lesen stelle.
Das geht nat. nicht.
Daher nun die aktuelle Lösung:
-
@ALL auf „keine Berechtigung“ und
die Zeile wiki: „keine Berechtigung“ löschen.
Dann habe ich die Logos wieder in der Startseite (kurios) - der Rest halt nicht so schön.
Puh sehr verwirrend.
Kannn es denn sein, dass die Reihenfolge der Einträge in der Liste (auf die ich im Webfrontend keinen Einfluss habe) irgend eine Auswirkung haben?
Eine zusätzliche Regel für ALL, die Leserechte verbietet, dürfte doch keine zusätzliche Auswirkung haben, wenn ganz oben schon ALL keine Rechte mehr hat.
Viele Grüße
Matthias
Hallo Matthias,
das Suchfenster ist bei mir auch da. Nicht berechtigte User können auch suchen lassen, bekommen aber kein Suchergebnis.
Viele Grüße
Wilfried
Hallo Wilfried,
danke für deine Info.
Dann muss ich weiter nach meinen Fehlern suchen.
lg matthias