Kein Update von 6.3.2.0 aus möglich

[Luigii]

Beim Aufruf der Update-Fuktion bekomme ich folgende Fehlermeldung:

Parse error: syntax error, unexpected T_CONSTANT_ENCAPSED_STRING, expecting T_STRING or T_VARIABLE or '$' in …/webEdition/liveUpdate/classes/liveUpdateFunctions.class.php on line 111

Gibt es eine einfache Möglichkeite diesen Fehler zu beheben oder muss ich jetzt WE komplett neu auf dem Server installieren?

[Luigii]

Also, hab gerade mal nachgesehen. In der Zeile 111 steht folgendes:

Code: Alles auswählen

if (!(isset("/home/…/iser-webedition") && "/home/…/iser-webedition" == LIVEUPDATE_SOFTWARE_DIR) ) {

und das scheint wirklich Blödsinn zu sein. Es scheint als wäre in der Klasse eine Variable durch den Pfad (hier gekürzt) ersetzt worden zu sein.
Ich habe jetzt mal folgendes eingesetzt

Code: Alles auswählen

if (!(isset($_SERVER['DOCUMENT_ROOT']) && $_SERVER['DOCUMENT_ROOT'] == LIVEUPDATE_SOFTWARE_DIR) ) {

und bekomme dann das Fenster mit der Suche nach einem Update.
Wenn ich aber nun auf suchen klicke, bekomme ich folgende Meldung:

Internal Server Error

The server encountered an internal error or misconfiguration and was unable to complete your request.

Please contact the server administrator, service@webmailer.de and inform them of the time the error occurred, and anything you might have done that may have caused the error.

More information about this error may be available in the server error log.

Welcher Server errored denn da? Was kann ich nun tun?

[ArminSchulz]

Hallo,

welcher Hoster?

Wir werden versuchen eine Austauschdatei zur Verfügung zu stellen, die man dann per ftp in das entsprechende Verzeichnis schiebt

Da das nicht normal ist (hab selber ca. 30 Sites von 6.3.2 auf 6.3.3 ganz normal upgedated) wäre es günstig, die Zugangsdaten (mindestens ftp) zu dem Problempaket zu haben.

diese bitte senden an entwicklung@webedition.org

[Luigii]

Hab jetzt selbst noch was probiert, führt aber nur zu neuen Fehlermeldungen.
Ist meine E-Mail mit den Zugangsdaten angekommen?

[Luigii]

ok, ist ja vielleicht auch ein Supersonderfall. Am Montag werde ich alles neu installieren und schauen, wie es dann aussieht. Vielleicht sind die Probleme ja dann von selbst verschwunden. Ansonsten sage ich Bescheid.

[lukasimhof]

Falls beim Installieren ein von $_SERVER['DOCUMENT_ROOT'] ein abweichender docRoot angegeben wurde, wird u.a. bei Installation und Live-Update $_SERVER['DOCUMENT_ROOT'] durch den explizit genannten docRoot ersetzt.
=> Dies darf natürlich nicht an Stellen geschehen, wo $_SERVER['DOCUMENT_ROOT'] auf der linken Seite einer Bedingung steht.

Damit das Update durchläuft, muss die betreffende Bedingung in /webEdition/liveUpdate/classes/liveUpdateFunctions.class.php, Zeile 111 so geändert werden, dass die Ersetzung nicht stattfindet:

Code: Alles auswählen

if (!(isset($_SERVER['DOCUMENT' . '_ROOT']) && $_SERVER['DOCUMENT' . '_ROOT'] == LIVEUPDATE_SOFTWARE_DIR) )

Der gleiche Fehler muss auch noch in /webEdition/we/include/we_classes/leWizard/liveUpdateFunctions.class.php gefixt werden (identische Kode-Zeile).

Dies war vor 6.3.0 schon mal so, wurde dann fälschlicherweise zu $_SERVER['DOCUMENT_ROOT'] "korrigiert" und anschließend nicht wieder komplett zurückgesetzt...

[Luigii]

Habe die Ersetzung gemacht.
Es bleibt aber der Internal Server Error!!
Ich kann kein Update machen. Wieso taucht da in der Fehlerseite die E-Mailadresse service@webmailer.de auf??

Ich habe Zugangsdaten an entwicklung@webedition.org gemailt, leider keine Reaktion.

Heute habe ich eine weitere Installation gefunden, die keinen Parse Error anzeigt, aber genau denselben "Internal Server Error" produziert. Hier wurden keine Variablen ersetzt. Diese Installation liegt bei Hosteurope.

Kann jemand helfen?

[Luigii]

Hab mich vertan. Es liegen beide Installationen bei Strato!!!

[mokraemer]

@Lukas: beim Update sollte die Ersetzung besser nicht mehr stattfinden - ich vermute stark, das die meisten das eher aus versehen eingegeben haben.

Man könnte das auch direkt beim Update prüfen und dann den Step übergehen!

[Luigii]

Ok, ich habe also alles gelöscht und die aktuelle Version installiert und wieder hat es nicht richtig funktioniert.
Ich hatte die Installation auf einer Subdomain laufen und bei der Installation wurde nicht das korrekte Rootverzeichnis angezeigt. Diesesw musste ich beim Installieren von Hand eintragen.
Jetzt habe ich ins Rootverzeichnis installiert und siehe da, alles ist gut.
Bei Strato scheint es also Probleme zu geben, wenn man nicht in das Rootverzeichnis installiert.

[mokraemer]

so wirklich Unterstützt wurden die Installs außerhalb des Root-Verzeichnisses eigentlich nie.

[Luigii]

Naja, wenn ich eine Subdomain bei einem Hoster auf ein Unterverzeichnis roote, dann ist das Rootverzeichnis der Subdomain eigentlich genau dieses Unterverzeichnis und wird bei der WE Installation auch korrekt erkennt. Nur bei Strato ist das nicht der Fall. Also musste ich das Rootverzeichnis manuell eintragen, obwohl ich unter der Subdomain installiert habe und das war dann scheinbar der Mist.

[lukasimhof]

WE-Installationen anderswo als direkt im Rootverzeichnis werden tatsächlich nicht unterstützt. Dafür war auch die Angabe eines abweichenden Doc-Roots nicht gedacht.

Und es ist natürlich auch richtig, dass $_SERVER['DOCUMENT_ROOT'] bei Subdomains ins Rootverzeichnis der Subdomain verweisen müsste: Was bei einigen Strato-Paketen definitiv nicht funktioniert.
=> Das Problem, dass Strato mit $_SERVER['DOCUMENT_ROOT'] auf Subdomains nicht klar kommt und falsch auf den Domain-Root verweist hatten wir schon mehrmals.

Die Angabe eines abweichenden Rotverzeichnisses ist vor vielen Jahren mal in WE eingebaut worden, als es ähnliche Probleme bei einem anderen Hoster gab (dort lieferte $_SERVER['DOCUMENT_ROOT'] schon bei der Hauptdomain einen falschen Pfad). Die Lösung war auf diesen Fall zugeschnitten (bzw. wurde auf jenem Hoster getestet) und scheint offenbar für das Strato-Problem nicht zu funktionieren.

Aber vielleicht taugen dann einige Stratopakete einfach nicht für WE auf Subdomains? Die Rückgabe eines korekten Wertes für $_SERVER['DOCUMENT_ROOT'] ist ja schon ziemlich wesentlich.
=> In der der bestehenden "Lösung" werden alle mit $_SERVER['DOCUMENT_ROOT'] beginnenden Pfade in den ca. 6000 WE-Systemdateien durch solche mit explizitem Documentroot hart ersetzt. Dies ist nicht gerade elegant und Folgeprobleme bei Update und Seitenumzug sind schwer auszuschließen.

Wollte man das Feature auf Dauer beibehalten müsste man es sicherlich mal neu konzipiren (z.B. mit eine Konstante DOCUMENT_ROOT). Aber dafür, dass - wie schon erwähnt - WE-Installationen woanders als im Documentroot (aber gerne auch dem einer Subdomain) nicht unterstützt werden, und v.a. auch dafür, dass die Verwendung von $_SERVER['DOCUMENT_ROOT'] nicht als kritisch gilt (weil man erwartet, dass die Hoster damit umgehen können...) ist der Aufwand (v.a. der Testaufwand) für eine Neuimplementierung ziemlich groß.

[Luigii]

Wegen mir ist der Aufwand auch nicht nötig. Strato ist nicht mein Favorit und ich werde einfach in Zukunft davon abraten bei Strato zu hosten
Danke für di eErklärung.

[mokraemer]

@Luigii: ich denke jeder Hoster hat sich schon pannen gegönnt - letztens auch DF.
Am schlimmsten scheint immer noch 1&1 zu sein.
Wenn du vom managed Hosting weggehst und selbst administrierst, kenne ich bis dato nichts besseres als Strato.

Der größte Fehler der immer noch gemacht wird ist eh meistens zu versuchen webspace für 1,95€/Monat zu bekommen und dann mit WE eine riesen Präzenz da drauf zu packen - klar das die Hoster da nicht gut abschneiden. Wenn sie für 20€ auch Hosting anbieten wird das nicht das gleiche leisten wie das für 1,95€.