Backend wird nach Anmeldung nicht mehr angezeigt

oxid6

#1

Ich habe meinen Shop testhalber bei einem Provider installiert, leider mit folgenden Effekt: melde ich mich im Backend an, erscheint bis auf einen kleinen roten Streifen am oberen Seitenrand nichts mehr.

Dabei scheint es sich nicht um das hier im Forum öfters beschriebene ‘Weiße Seite’-Problem zu handeln, denn der Quellcode der Seiten scheint vom Server vollständig ausgeliefert zu werden, er wird vom Browser nur nicht dargestellt.

Ich kann sogar einzelne Frames aus dem Frameset des Backends aufrufen, die dann auch angezeigt werden, so wie das Dashboard des Backends aus dem Hauptframe.

Da die Seiten ausgeliefert werden, wird leider auch kein Fehler in die log files geschrieben. Hat jemand eine Idee, was das Problem sein könnte?

Ich habe, wie in einige Fornebeiträgen beschrieben, mit SQL über die Datenbank alle Module deaktiviert und jedesmal die Dateien des tmp-Ordners gelöscht, leider ohne Erfolg.


#2

ich würde als erstes einen anderen Browser probieren.
Hat deine SQL Query auch alle TPL-Blocks deaktiviert? Denn diese sind von dem “aktiv” Status des Moduls abgekoppelt und haben dafür eigene “an/aus-Felder”.
UPDATE oxtplblocks set oxavtive = 0;
Wurden zufällig admin templates angepasst? ggf ist irgendwo so ein <!-- das nicht wieder geschlossen wird.

Ansonsten habe ich noch nie von so einem Problem gehört und mich würde zumindest ein Screenshot interessieren.


#3

Ich habe den gleichen Effekt mit Firefox/Chrome auf Ubuntu sowie Firefox auf Windows 7.

Danke für den Hinweis mit den tpl Blocks, das habe ich noch nicht gemacht.

Die Änderungen an den Admintemplates überprüfe ich nochmals, allerdings läuft auf meinem lokalen Rechner alles einwandfrei.

Den Screenshot kann ich erst später einstellen.


#4

Habe jetzt noch gesehen, dass der HTML Code der Startseite vom Backend doch nicht so korrekt aussieht.
In der Quelltext-Ansicht vom Firefox sehe ich, dass eine Fehlermeldung beim frameset: “Verirrtes Start-Tag frameset” angezeigt wird.

Warum auch immer wird der Frameset erst nach dem schließenden HTML-Tag der Seite ausgegeben. Ich werde also erst noch einmal überprüfen, ob alle Dateien korrekt auf den Server übertragen wurden bzw. vorhanden sind.


#5

ich habe bei mir das Problem so gelöst

x-Frame-Options security header sollte auf allow gesetzt werden in die Datei /etc/apache2/conf-available/ssl-params.conf
wenn du auf deny setzt sollte die Zertifikat von einer zertifizierungsstelle sein also nicht selbst definierte ssl Zertifikate,


#6

Bin mit meinem Latein am Ende. Nachdem ich festgestellt habe, dass die Tabelle oxtplblocks leer war, hat mir der Provider meinen Dump nochmals eingespielt, nun habe ich auch Einträge in der Tabelle oxtplblocks.

Dann habe ich via SQL

delete from oxconfig where oxvarname in (
‘aDisabledModules’,
‘aLegacyModules’,
‘aModuleFiles’,
‘aModulePaths’,
‘aModules’,
‘aModuleTemplates’
);

und

UPDATE oxtplblocks set oxactive = 0;

Module als auch die zugehörigen Templates deaktiviert. Leider ohne Erfolg.

Dann dachte ich, dass die Ausgabe des HTML Codes für die Einstiegsseite des Backends (source/Application/views/admin/tpl/start.tpl) nicht korrekt wäre, da das Frameset erst nach dem schließenden HTML-Tag ausgegeben wird. Wie ich gesehen, ist das nicht nur lokal auf meinen Rechner so (ohne Probleme mit der Anzeige) sondern auch bei der OXID Installation in meinem Job, da arbeiten wir mit der Version 5.3 und da klappt seit Jahren auch alles.

Das Komische ist, dass das Dashboard vom Hauptframe als auch die Menüleiste rechts oben einzeln aufrufbar sind, bei allen anderen Seiten/Frames bekommen ich nur weiße Seiten, die allerdings den kompletten HTML Code der jeweiligen Seite enthalten. Daher erhalte ich auch keinerlei Fehlermeldungen, weder im OXID Log noch im Server Log (habe auch über die php.ini und die config.inc.php die display_errors aktiviert. Finde keinen Hinweis auf irgendwelche Probleme.

Habe auch nach der Datei /etc/apache2/conf-available/ssl-params.conf gesucht, die es lokal bei mir am Entwicklungsrechner nicht gibt (da habe ich auch keine Probleme), auf dem Server habe ich allerdings keinen Zugriff und werde da morgen noch einmal den Support kontaktieren).

Da der HTML Code vollständig ausgegeben wird und ich mich am Backend auch anmelden kann: ist das evtl. irgendeine (Sicherheits)Einstellung der Browser? Evtl. weil die Installation nicht verschlüsselt und erst mal nur über eine temporäre URL des Providers aufgerufen wird? Das Frontend funktioniert übrignes problemlos, egal ob mit aktiven oder nicht aktiven Modulen. Allerdings habe ich den gleichen Effekt auf Windwos 7 (Firefox, Chrome und Internet Explorer) als auch auf meinen Entwicklungsrechner mit Ubuntu (Firefox, Chrome).


#7

Es kann doch nicht so schwer sein, die lokale Installation von OXID die mit meinen eigenen Modulen anstandslos läuft, auch bei einem Provider zum Laufen zu bringen. Oder wenigstens eine Fehlermeldung zu bekommen, sollte etwas nicht stimmen :frowning:


#8

An dem kaputten Markup liegt es wahrscheinlich nicht, das ist schon ewig so: https://bugs.oxid-esales.com/view.php?id=5604


#9

Der Vollständigkeit halber noch die (unbefriedingende) Lösung:

Ich habe das System komplett neu installiert, danach funktionierte das Backend erst mal wieder. Dann habe ich mein Theme sowie die Module nacheinander eingespielt und aktiviert. Die Änderungen an den Datenbanktabellen habe ich dann für das jeweilige Modul manuell durchgeführt und nicht mehr über einen Dump eingespielt. Ich hatte die Hoffung, das ich so das Modul identifizieren kann, welches Probleme machte.

Nun läuft aber alles ohne Probleme (bisher), einzige Ausnahme ein Modul zum Abschalten des Preisalarms, das nicht von mir ist. Dieses hat sich immer wieder selbst deaktiviert. Jetzt habe ich es rausgeschmissen und den Preisalarm vorerst über das Template rausgenommen.

Hätte schon ganz gerne gewusst, was die Ursache des Problems mit dem Backend war, hoffe nur, das passiert nicht wieder.


#10

Ich hatte es befürchtet: Nachdem die Neuinstallation die letzten 2, 3 Wochen problemlos lief und ich Shop sowie Module einrichten und installieren konnte, habe ich gestern nun die endgültige Domain zu Profihost umgezogen und das SSL Zertifikat eingerichtet.

Das Frontend funktioniert immer noch einwandfrei, aber das Backend ist nach erfolgreicher Anmeldung wieder nur ein feiner roter Streifen am oberen Seitenrand, der Rest fehlt. Kein Fehler, nix. Der Shop als auch meine Module liefen die letzten Wochen ja auch problemlos unter http://stage.domain.de. Jetzt unter https://www.domain.de wird das Backend wieder nicht angezeigt (der HTML Code ist ja da).

Ich habe die URLS in der confic.inc.php angepasst (Shop und Admin), den Cache immer wieder gelöscht und die Jungs von Profihost haben auch keine Idee. Mich nervt’s nur noch, aber vielleicht hat ja hier doch noch jemand eine Idee. Kann doch nur irgendeine blöde Einstellung sein.


#11

Hoffnetlich der letzte Eintrag zu dem Thema

Mir ist das Verhaltendes Backends völlig schleierhaft, die Netzwerkanalyse im Firebug zeigt, dass die Startseite des Backends einfach nach der Zeile

<script type=“text/javascript” src=“https://www.meindomainname.de/out/admin/src/oxid.js”></script>

das Laden aufhört. Der Status des Ladens der oxid.js ist entweder 200 oder 304 (not modified), also nichts ungewöhnliches. An den Dateien des Backends habe ich keine Änderungen durchgeführt. Mir ist nur aufgefallen, dass der Effekt immer nur bei Umstellungen des Aufrufs auftrat, von

http://meindomainname.de.cloudx-vmxxx.de-nserver.de/ auf http://stage.meindomainname.de
und von
http://stage.meindomainname.de auf https://www.meindomainname.de

Eine Neuinstallation des Systems durch Profihost unter der jeweils neuen Adresse hat das Problem dann behoben, ohne jegliche Änderung an irgendwelchen Dateien. Ehrlicherweise hinterlässt das kein gutes Gefühl für den Livegang und den zukünftigen Betrieb, muss ich doch immer wieder damit rechnen, dass dieser Effekt wieder auftritt.

Aber für’s erste scheints zu funktionieren und ich habe auch nicht vor, die Domain nochmals zu ändern. Ich habe nun noch zwei “alte” Installationen, mit denen ich weiter testen möchte, vielleicht finde ich die Ursache ja noch…


#12

Sehr sehr seltsam. Hattest Du nicht Änderungen im Admin vorgenommen? Wenn es nicht mal Fehler im Server-Log gibt, kann das auch heissen, dass PHP durch irgendeine Aktion derart abgeschossen wird, dass es gar nicht mehr dazu kommt, einen Fehler zu schreiben (premature end of script… )


#13

vielleicht irgendwelche verschlüsselten Module, denen der loader/encoder fehlt.


#14

Also ich bin meinem Latein am Ende. Seitens Hoster konnte mir auch nicht weitergeholfen werden. Nach neuerlicher Installation läuft jetzt erst mal alles und da jetzt alles über die endgültige Domain läuft hoffe ich, dass das für die Zukunft erledigt ist. Wenn ich wieder Nerven dafür habe, forsche ich mit den bestehenden “alten” Installationen vielleicht noch nach. Aber trotzdem vielen Dank für die Unterstützung.
Verschlüsselte Module habe ich übrigens nicht im Einsatz.


#15

Hast du mal geschaut, ob es die Ordner source/Application/Admin/tpl und /source/out/admin/… gibt?

Dann im Ordner /source/admin befindet sich die index.php, könntest du da den Debug-Code hier einfügen:

<?php
/**
 * Copyright © OXID eSales AG. All rights reserved.
 * See LICENSE file for license details.
 */

define('OX_IS_ADMIN', true);
define('OX_ADMIN_DIR', basename(dirname(__FILE__)));

// Includes main index.php file
die('TEST 1');
require_once dirname(__FILE__) . "/../index.php";
die('TEST 2');

Einfach um zu schauen ob TEST 1 ausgegeben wird, falls ja bitte die Zeile entfernen und schauen ob TEST 2 ausgegeben wird.


#16

views neu generiert bzw mal deaktiviert?