it-swarm.com.de

Staging-Site kann nicht so angezeigt werden wie Live-Site. Völlig ratlos

Hintergrund

Ich habe eine Situation, die mich die Wand hochgetrieben hat. Nach vielen Stunden (mehr als ich zugeben möchte) konnte ich es nicht lösen. Ich denke also, es muss einen besseren Weg geben, dies zu tun. Es gibt offensichtlich etwas, das ich übersehen habe.

Ich habe eine WordPress-Website von einer Live-Domain in eine Staging-Domain repliziert.

Ein früherer Entwickler hat die Site erheblich angepasst und sie in die Themendateien gehackt. Es ist ein professionelles Thema mit regelmäßigen Updates (die er deaktiviert hat), daher habe ich keine Ahnung, warum dies der Ansatz war. Aber das ist eine Seite. Der Eigentümer möchte das Thema aktualisieren können. Meine vorgeschlagene Lösung bestand darin, den gesamten benutzerdefinierten Code und die Dateien zu identifizieren und in ein untergeordnetes Thema zu migrieren.

Die Angelegenheit

Aus irgendeinem Grund wird die Homepage der Site auf der Live-Site anders geladen als die Staging-Kopie. Es ist ein Styling-Problem. Es gibt ein Formular, das anscheinend auf jeder Site unterschiedliche CSS verwendet. Ich verstehe nicht warum und konnte es nicht herausfinden. Dies betrifft auch das Hauptmenü/die Kopfzeile.

Was ich probiert habe

Ich habe Firebug- und Chrome-Entwicklertools verwendet, um das gerenderte HTML und das CSS sehr detailliert durchzugehen. Ich habe BBEDIT verwendet, um eine vollständige Site-Suche (mit einer Offline-Kopie aller Dateien) nach relevanten CSS-Selektoren usw. durchzuführen, um festzustellen, woher die problematischen CSS-Eigenschaften auf der Live- und Staging-Site stammen . Ich habe auch Suchvorgänge in einem Speicherauszug der Datenbank ausgeführt.

Trotz aller Bemühungen konnte ich nicht herausfinden, wie und woher das fehlerhafte CSS stammt.

Als Umgehungslösung habe ich begonnen, neue CSS-Definitionen mit !important hinzuzufügen, um einfach zu erzwingen, dass die Staging-Site die richtigen Eigenschaftsattribute aufweist. Aber dann stellte ich fest, dass das Formular auf der Live-Site reagiert und auf der Staging-Site nicht. Anstatt zu versuchen, herauszufinden, warum es nicht reagiert, und um das Problem zu beheben, versuche ich, herauszufinden, wie und warum sie auf jeder Domain ganz anders rendern.

Fragen

1) Wie würden Sie empfehlen, die Quelle von CSS zu identifizieren, die auf eine gerenderte Seite angewendet wird? (unter Berücksichtigung, dass ich es bereits mit Firebug und Chrome Developer Tools durchgesehen habe)

2) Gibt es hier jemanden, der bereit wäre, sich die Websites für mich anzusehen und mir zu zeigen, was ich übersehen habe? Mir ist klar, dass es für zukünftige Zuschauer nützlicher wäre, wenn ich bestimmten Code hier posten würde, aber WordPress ist so, wie es ist, eigentlich keine Option. Ich kann das gesamte Problem nicht in einer Geige oder hier wiederholen.

3) (Neue Frage) Gibt es eine Liste oder würde mir jemand sagen, welche Prioritätsreihenfolge WordPress für Style-Deklarationsquellen hat?

Ich weiß, dass style.css im untergeordneten Thema Vorrang vor style.css im übergeordneten Thema hat. Aber was ist mit Styles, die in der Datei functions.php deklariert sind, und anderen Stylesheets, die JS oder functions.php aufrufen? Es scheint, dass auch mit dem !important-Attribut (untergeordnetes Thema) style.css keine Priorität vor Deklarationen in functions.php hat.

Ist es ratsam, Stildeklarationen in der Datei functions.php (untergeordnetes Design) in die Datei style.css zu verschieben? (um die Organisation zu vereinfachen und zukünftige Änderungen zu vereinfachen). Oder wird dies als fehlerhaft angesehen, da dadurch viel mehr Style-Deklarationen unnötigerweise aus style.css analysiert werden (d. H. Sie werden auch dann analysiert, wenn sie nicht benötigt werden, wenn die betreffende Funktion nicht aufgerufen wird)?

Schnappschüsse des Problems

Der Header und ein Formular auf der Live-Site:  snapshot of form and header on live site 

Derselbe Header und dasselbe Formular auf der Staging-Site:  staging site 

Falls jemand bereit ist zu helfen, indem er sich die Site direkt ansieht, ist die Live-Site unter folgender Adresse erreichbar:

~ ENTFERNT (zum Schutz der Privatsphäre) ~

und die Staging-Site ist bei:

~ ENTFERNT (zum Schutz der Privatsphäre) ~

Ich möchte gerne wissen, wie Sie dieses Problem lösen können. Wenn Sie sich also die Website ansehen und eine Antwort darauf geben, teilen Sie mir bitte mit, wie Sie es herausgefunden haben. oder wie ich es herausfinden könnte. Vielen Dank.

3
omega33

Es gibt viele Unterschiede in den CSS-Dateien beider Websites. Schauen Sie sich zum Beispiel das div mit der Klasse et-top-navigation an, indem Sie es im Browser überprüfen.

Sie werden feststellen, dass bei der Staging-Website Top-Padding und Left-Padding angewendet werden, während dies bei einer Live-Website nicht der Fall ist.

Suchen Sie auf ähnliche Weise nach anderen CSS-Änderungen auf der Staging-Website oder sichern Sie einfach alle CSS-Dateien auf der Staging-Website und platzieren Sie diese Dateien von der Live-Website.

Ich hoffe, dass dies Ihr Problem lösen wird.

1

Ich weiß nicht, ob meine Erfahrung hilfreich sein könnte, aber in meinem Fall hat die benutzerdefinierte Vorlage eine eigene Einstellungsseite im Administrationsbereich von Wordpress Theme (nicht die in Wordpress eingebaute Einstellungsseite, ich beziehe mich auf die Einstellungsseite dieser Vorlage). .

Meine Staging-Version lautet "css different", bis ich die Einstellungen dieser Vorlage importiere (oder manuell einfüge). Ich kann nicht verstehen, warum das Klonen von DBs und FTPs (mit offensichtlich vollständigen Domain-Ersetzungen) nicht ausreicht;) Aber ich kann die fehlenden Einstellungen auf diese Weise manuell korrigieren.

0
Elena

Ich kann die Sites jetzt nicht ansehen, da die Links entfernt wurden, und weiß nicht, wie Sie die Dinge in das untergeordnete Thema verschoben haben. Wenn Sie jedoch der Meinung sind, dass es ein Problem mit der Reihenfolge ist, in der Stylesheets geladen werden, würde ich das tun Schauen Sie sich add_action()-Aufrufe an, die wp_enqueue_style() aufrufen. Ein manchmal verwendetes drittes Argument kann an add_action() übergeben werden, das eine Priorität für den Rückruf festlegt. Möglicherweise kommt etwas add_action() aus dem übergeordneten Thema nach der add_action() des untergeordneten Themas.

WP add_action () docs

Stylesheets, die andere außer Kraft setzen müssen, sollten zuletzt in die Warteschlange gestellt werden.

0
J Garcia