von 4.8.18 zurück nach 4.8.15

[hohorstmann]

Liebe Leute,
nachdem ich mit 4.8.18 einen undefinierbaren Fehler habe (siehe http://forum.contenido.org/viewtopic.php?f=62&t=32488) und hier im Forum keine Lösung in Sicht ist, habe ich mich zu einem Downgrade auf 4.8.15 entschlossen. So würde ich es machen:

• Ich installiere 4.8.15 in ein neues Unterverzeichnis auf dem Webserver,
  Die angepassten Dateien (css, template, ...) kopiere ich manuell
  Die Datenbank soll erhalten bleiben
  Frontend-User und Backend-User möchte ich neu anlegen, da ich dort im Umfeld von 4.8.18 einen Fehler vermute

Ist die DB kompatibel?
Kann ich das so machen?
Gibt es eine bessere Lösung für mein Vorhaben?

Aus dem Westen, Ho

[xmurrix]

Hallo hohorstmann,

ist es sicher, dass das Problem am 4.8.18 liegt, nicht dass das nach einem Downgrade immer noch besteht.

Außerdem wäre es vielleicht eine Überlegung wert und vielleicht einfacher, das Problem einzugrenzen und zu beheben...

Zur Datenbank:
Es gab einige Änderungen an der Datenbank, diese müsstest du auch Rückgangig machen. Schau dir mal die Unterschiede innerhalb von "setup/data" in beiden Versionen an.

Gruß
xmurrix

[hohorstmann]

Hallo xmurrix,

nein, ich bin mir nicht sicher, ob das Problem nach dem Downgrade beseitigt ist. Und dann auch noch die Änderungen der Datenbank
Aber da ich im Forum kaum Hilfe finde,weiß ich mir auch keinen Rat mehr.
Ich habe den Fehler soweit ich konnte in dem Thread beschrieben. Was kann ich noch zur Eingrenzung des Fehlers tun?

Gruß, Ho

[xmurrix]

Wenn du möchtest, kannst du mir die Zugangsdaten per PM schicken (Backend und FTP), und ich schau mir das dann unverbindlich an.

Gruß
xmurrix

[xmurrix]

Problem ist gelöst, es lag an Anfragen zum Frontend mit verschienen Domains, mit und ohne "www.".

Einen Beitrag dazu findet ihr unter Tipps & Tricks:
http://forum.contenido.org/viewtopic.php?t=32548

[hohorstmann]

Hallo zusammen,

ich wieder mit dem gleichen Problem, dem Zugriff auf den geschützten Bereich von http://www.studium-taw.de

Ausprobieren kann man das nachdem man sich auf der Startseite einlogged. Dafür habe ich einen speziellen Bereich geschaffen, der über den Benutzer browser mit dem Passwort test aufgerufen wird.
Erscheint die Meldung, dass man eigelogged ist, das läuft die Seite fehlerfrei
Erscheinen Fragmente des Login-Formulars für den Backend, dann handelt es sich um den besagten Fehler.
Das Fehlverhalten tritt bei "allen" Browsern auf: Firefox, IE, Chrome, Opera, ...

Seitdem alle hier aufgeführten Maßnahmen inklusive des Löschens des Cache etc durchgeführt wurden, lief CONTENIDO eigentlich fehlerfrei.
Nachdem nun ca. 300 User den geschützten Bereich nutzen, haben ca. 10% das o.a. Fehlverhalten und zwar immer.

Eine Befragung zu Betriebssystem, Browser uns Systemumgebung bringt mich nicht weiter: es geschieht durch alle Möglichkeiten hinweg.

Frage: gibt es bei jemanden ebenfalls dieses Fehlverhalten?
Und wenn ja, hat jemand eine Erklärung dafür?

Ich wäre dankbar ... Ho

[Spider IT]

Hallo Ho,

eine Erklärung habe ich nicht, aber wenn du die betroffenen Accounts löscht und neu anlegst, dann noch die Tabelle con_phplib_active_sessions leerst (nicht löschen!), sollte alles wieder funktionieren.

Gruß
René

[hohorstmann]

Hallo René,

ok, die Accounts kann ich löschen und neu anlegen.
Aber kann ich mit dem Leeren der Tabelle con_phplib_active_sessions auch keinen Schaden anrichten?

Frühen Gruß, Ho

[Spider IT]

Nein, habe ich schon oft gemacht wenn Einloggen nicht möglich war.
In der Tabelle stehen nur die aktiven Sessions, die werden eh irgendwann gelöscht.
Schlimmstenfalls muss ein gerade aktiver User sich erneut anmelden

Gruß
René

[xmurrix]

Code: Alles auswählen

...Seitdem alle hier aufgeführten Maßnahmen inklusive des Löschens des Cache etc durchgeführt wurden, lief CONTENIDO eigentlich fehlerfrei.
Nachdem nun ca. 300 User den geschützten Bereich nutzen, haben ca. 10% das o.a. Fehlverhalten und zwar immer....

Welche Caches genau wurden gelöscht?

• Manche Firmen verwenden einen Proxy-Caches, und liefern Seiten direkt aus dem Cache, anstatt die den Request an den Server zu schicken.
• Manche User haben den Browser-Cache, der die Seite vom Cache liefert, anstatt die den Request an den Server zu schicken.

Ich bezweifle zwar, dass das mit dem Login ein Problem mit dem Cache ist, aber man weiß ja nie. Gibt es irgendwelche Gemeinsamkeiten in diesen 10% Usern, wie z. B. gleiches Netzwerk, gleiche Firma, usw...?

Die User sollen doch mal den Browsercache leeren und es nochmal probieren, eine Versuch ist es wert...

Gruß
xmurrix

[hohorstmann]

So, jetzt haben wir eine Umfrage beendet, in der in der Regel

• Windows 7 als Betriebssystem
  Firefox, Internetexplorer (32 und 64 bit), Google, Safari als Browser in der neusten Version liefen

Auch andere Plattformen wie Mac, Smartfone sind davon betroffen.
Wir haben Caches lokal und im Proxy löschen lassen und uns teilweise überzeugt, ob das auch richtig geschehen ist.
Ebenso haben wir die con_phplib_active_session geleert.

Es verbleiben ca. 10% der Anwender (von 350), bei denen der login auf den hier beschrieben Fehler läuft.
Kann es da eine Lösung geben?

Gruß, Ho

[Oldperl]

Hallo Ho,

Kann es da eine Lösung geben?

Kann es, aber dazu müßte man den Fehler konkreter am betroffenen System debuggen. Eventuell sollte man dafür die Loginversuche loggen und Session und Variable mitschreiben. Ist z.B. Nutzer und Uhrzeit bekannt, könnte man dann anhand des Logs versuchen herauszufinden ob es Unterschiede zwischen funktionierendem und nicht funktionierendem Login gibt.

Gruß aus Franken

Ortwin

[hohorstmann]

Das werde ich tun ...