THEMA: Fehlermeldung bei Anmeldung durch User

Liebe Schachfreunde,
als Administrator unserer Niederbayerischen Website möchte ich folgendes Problem melden. Der Ligamanager, den wir seit 2014 erfolgreich in unserem Bezirksverband nutzen, ist nun technisch bedingt auf einen anderen Server umgezogen. Der Umzug selbst hat mit Akeeba&Kickstart gut und einwandfrei funktioniert. Wir haben daraufhin auch bereits den Saisonwechsel auf 2019/2020 vollzogen. Auch dies hat gut funktioniert. Wir haben in Niederbayern nun allderdings das Problem, dass alle User (also die Mannschaftsführer mit account) sich nicht mehr anmelden können und die berühmt-berüchtigte Fehlermeldung

Ein kritischer Fehler ist bei aktiviertem CLM aufgetreten. Die aufgerufene Website kann daher nicht angezeigt werden. Bitte melden Sie die folgende ID beim jeweiligen Administrator. ID: xyz

erscheint. Ich habe daraufhin die Fehlermeldung eines Users wie in der FAQ beschrieben, exportiert und diese hier stellvertretend als Anhang beigefügt.

CLM läuft in der aktuellen Version 3.7.0 unter Joomla 3.9.8 (also alles aktuell). Als SQL-Datenbank wird die Version 5.x verwendet.

Ich weiß nicht weiter, wie das Problem zu lösen ist. Müssen irgendwelche Links angepasst werden oder Caches geleert werden ? Es ändert auch nichts daran, wenn man einen neuen Testuser anmeldet. Dieser erscheint zwar freigegeben in der Benutzerverwaltung, kann sich dennoch nicht einloggen mit dem Hinweis "er sei gesperrt".

Habt Ihr irgendeine Hilfestellung parat ?

VG Gert Schönbuchner

Die angehängte kleine Fehlerdatei ist genau richtig. Danke, das ist ein guter Startpunkt!

Die Fehlermeldung zeigt, dass die SOAP-Funktionalität nicht aktiviert ist.
Bitte prüfen: im Admin-Bereich anmelden und die Komponente CLM öffnen -> rechts 6.Zeile steht dann SOAP aktiviert oder eben SOAP nicht aktiviert.
Die SOAP-Funktionalität ist u.a. für die direkte Datenübernahme vom DSB zwingend erforderlich.
Für die USER-Anmeldung ist SOAP nur notwendig, wenn unter Einstellungen/Datenschutz der Parameter Mitgliedschaft in Schachorganisation auf notwendig steht. Bitte überprüfen und ggf. kurzzeitig auf nicht notwendig setzen.

Die SOAP-Funktionalität wird meist über die php.ini verwaltet. Bitte prüfen, ob sich dort ein Eintrag extension=soap findet. Ggf. ist nur ein vorangestelltes ;(Semikolon) zu löschen.
Besteht kein Zugang zur php.ini, muss beim Provider angefragt werden.

Sollte das genannte nicht ausreichend helfen, bitte erneut melden. Über PN wären dann ein Admin-Zugang bzw. ein Akeeba-Abzug hilfreich.

Hallo Gert, ich denke auch dass sich das in deinem Fall durch aktivieren von SOAP recht einfach lösen lassen sollte.

die Eintragung in dem zur Verfügung gestellten log-Datei-sniplet:

fopen: yes
soap: no
ist eindeutig.

soap sollte aktiviert sein. Das ist auch bei allen bisherigen Providern mit denen ich zu tun hatte der Fall gewesen. Manchmal gibt es (eigene) Admins die meinen das aus Sicherheitsgründen deaktivieren zu müssen.. das hatten wir auch schon mal...

Interessant ist, wieso bzw. wie bei dir die Einstellung auf "soap: no" überhaupt erfolgen konnte. Welcher Provider ist das, zu dem ihr da umgezogen seid?
Eigentlich müsste so eine (bei manchem hinderliche) Einstellung auch beim "restore" des backups ziemlich am Anfang der restore-Routine aufgezeigt werden, wo die Einstellungen von so etwas über 20 Parametern dargestellt werden.
Wenn da nicht alles als "grün" erscheint, sollte man bei den als "rot" markierten Einstellungen kritisch überlegen, was sie bedeuten.

Auf eine weitere Problematik beim Umzug einer Joomla-website bin ich kürzlich gestossen.
Es gibt Provider, scheinbar auch größere Provider, bei denen funktioniert die Umsetzung des "tmp"-Pfades und des "log"-Pfades beim restore nicht richtig.

Man wird dazu auch beim restore gefragt... Da die root-Pfade aber öfters etwas kryptisch sind (/mnt/a3/954/384594/..., erkennt man das an dieser Stelle manchmal nicht gleich.

d.h. es bleiben bei diesen beiden Paramatern die alten Pfade erhalten.
Merken tut man das zumeist auch dann wenn man das erste akeeba-backup in der neuen Umgebung macht, das dann nicht funktioniert.
Bitte auch dieses gleich mal testen

Auch wenn in Komponenten, die man selbst dazuinstallierte, Pfade durch Konfigurationen verdrahtet sind, werden diese bei der Umstellung zumeist nicht mit umgestellt. akeeba weiss ja von Eigenheiten einer fremden Komponente zumeist nichts. (mann muss da selbst Hand anlegen).

Das dumme ist, das merkt man nicht gleich. Sondern erst wenn man diesen Teil der Komponente benutzt. Und das kann schon ein Stückerl dauern..

Kurzum, auch wenn es erst einige Zeit nach dem Umzug eine Meckerei gibt, dass z.B. eine Datei nicht angelegt werden kann, oder dass etwas nicht beschreibbar sein soll, auch mal daran denken... Es kann sein dass die Software dann wegen nicht umgestelltem Pfad noch auf den früheren Server schreiben will... und das geht zumeist nicht gut...

Hallo Pierre,
hallo kbaerthel,

vielen Dank für Eure Hilfestellungen und Anmerkungen. Der kleine Provider (landshut.org) hat nun gem. Anweisung die php.ini Datei korrigiert, alles läuft jetzt wieder rund und fein.

Ich bitte Euch, hier den Thread noch ein, zwei Wochen offen zu halten, im Falle eines Falles

VG Gert