Das ist jetzt auch mein Gedanke.
Vielen Dank für deinen Input.
Das ist jetzt auch mein Gedanke.
Vielen Dank für deinen Input.
Danke für die schnelle Antwort. Jetzt funktioniert der Login. Ich hatte die Session-Cookies nicht geleert 🙈
Allerdings bleibt das Update (von 9.1.2 auf 9.1.6 oder 9.1.3) beim Schritt "Datenbank aktualisieren" stehen und im Log stehen u.a. folgende Fehler:
Access denied; you need (at least one of) the RELOAD privilege(s) for this operation
Uncaught mysqli_sql_exception: Access denied; you need (at least one of) the RELOAD privilege(s) for this operation in xyz/webEdition/we/classes/database/we_database_mysqli.class.php:54
Siehe auch Update bleibt bei Datenbank aktualisieren stehen
Allerdings habe ich nicht die Möglichkeit, die Rechte des DB Users zu ändern
Jetzt habe ich dieses Problem wohl auch.
Finn Wie genau deaktiviert man die Sessionverschlüsselung in der we_conf_global.inc.php?
Ist das define('SYSTEM_WE_SESSION_CRYPT', 1);?
Wenn ich das auf 0 setze bringt das leider auch nichts.
einfach weiter gehen ohne Rebuild.
Das Problem ist (leider) nicht der Rebuild sondern das Update selbst, bei dem die Einträge direkt aus der tblContent verschwinden. Selbst wenn wir auf der 8.0.5 "nur" eine Update-Wiederholung durchführen verschwinden die Inhalte.
Super! Wird's das in der 9.1.6 geben? 9.2 können wir leide aufgrund des fehlenden Shop-Moduls bei einigen Kunden nicht verwenden.
Wenn ich den versionCheck() "deaktiviere" kann man die Login-Seite wieder ohne Probleme aufrufen. Natürlich weiß ich nicht, ob das weiter reichende Auswirkungen hat. Aber im Moment ist es mir wichtiger, dass die Kunden wieder ins CMS kommen.
Muss dieser Check denn an dieser Stelle unbedingt sein?
Ich verstehe schon, dass diese Verbindung vom Server aus aufgebaut wird. Aber wenn dieser Server dann geblockt wird kann die Login-Seite nicht mehr aufgerufen werden und man kann sich nicht mehr ins CMS einloggen.
Leider haben wir in den letzten Tagen einige Beschwerden von Kunden, dass Sie entweder /webEdition gar nicht aufrufen können (timeout) oder es sehr lange dauert. Das solltet ihr aus meiner Sicht schnellstmöglich ändern, da derzeit offensichtlich einige Kunden immer wieder mal überhaupt nicht ins CMS kommen und dies (verständlicherweise) uns anlasten. Oder ihr teilt uns mit, wie man diesen Update-Check auf der Login-Seite auskommentieren kann.
Also tatsächlich schon wenn man die Login-Seite /webEdition aufruft? Das würde erklären, dass aufgrund des Problem bei euch unsere Kunden nicht einmal mehr die Login-Seite aufrufen konnten.
Aber findet das nicht erst statt nachdem man sich eingeloggt hat? Oder findet das bereits statt wenn man die Login-Seite /webEdition aufruft?
Gibt es schon eine Rückmeldung vom Support?
Der Server-Admin hat mich informiert, dass der betreffende Server kein IPv6 hat.
Danke für das (wie immer) schnelle Feedback.
Hallo zusammen,
seit gestern haben wir das Problem, dass vom Server eines Kunden keine Verbindung mehr zum Update-Server (zur Suche nach Updates) möglich ist. Auch das Feed-Widget kann den Feed nicht laden. Der Server-Admin meint, dass wget upate.webedition.org auf diesem Server nicht funktioniert. Auf anderen Servern funktioniert das. Wäre es möglich, dass die Requests von diesem Server blockiert werden?
Vielen Dank im Voraus für eure Hilfe.
Schöne Grüße
Michael
Vielen Dank für die schnelle Lösung.
Hallo zusammen,
Wir haben gestern zwei Updates durchgeführt, bei beiden hat der Partner-Code problemlos funktioniert. Gerade wollten wir ein weiteres Update durchführen. Jetzt funktioniert der identische Partner-Code (aber auch ein zweiter eines anderen Kunden) nicht mehr. Im nächsten Schritt wird angezeigt, dass die GPL-Version installiert wird. Da wir das Update jetzt durchführen müssen haben wir das gemacht und haben nun leider die GPL-Version.
Was läuft da schief? Wo kann man nachträglich die GPL-Version in eine Partner-Version umwandeln?
Vielen Dank im Voraus für eure Hilfe
Michael