Webseiten-Renovierung
14. Februar 2017 um 16:12 Uhr von Atari-Frosch
Gestern habe ich endlich mal meine statische Website und dieses Blog hier „renoviert“. Die nüchtern-weißen Seiten mit den harten grünen und blauen Linien gefielen mir schon länger nicht mehr. Jetzt gefällt es mir wesentlich besser. Wie findet Ihr das neue Design?
Ich baue ja recht selten Webseiten, aber wenn, dann gestalte ich das HTML so, daß ich in den meisten Fällen einer Design-Änderung nur das zentrale CSS anfassen muß. Das hätte diesmal auch fast geklappt, wenn …
… ja, wenn ich dem <img>-Tag, also dem, mit welchem man Bilder einbindet, eine bestimmte CSS-Deklaration hätte mitgeben können. Aber das wollte nicht funktionieren. Und es ging ausgerechnet um das Logo, also eine Datei, die auf wirklich jeder Einzelseite eingebunden wird. Hier beim Blog ist das ja kein Problem, weil das Theme (das Design) zentral liegt, während die Daten bei Aufruf jeweils aus der Datenbank dazugeklebt werden, aber bei der statischen Site war das dann doch etwas aufwendiger, denn ich mußte an der Stelle ein zusätzliches <div> einfügen. In. Jede. Einzelne. HTML-Datei. Ja, meine statische Site ist schon recht umfangreich.
Also bändigte ich mal wieder die Würgeschlange (wie Alex das gerne ausdrückt) und scriptete mir die Umsetzung. Erfahrungsgemäß ist es nämlich die Arbeit einer Woche, Änderungen in alle HTML-Dateien der statischen Website einzupfriemeln. Dann lieber ein Python-Script basteln. Das hatte den Vorteil, daß ich direkt noch weitere systematische Änderungen vornehmen konnte, insbesondere am Seitenfuß. Zudem ersetzte ich einige HTML-Entities durch die entsprechenden UTF8-Zeichen. Das sollte ja heutzutage kein Problem mehr sein.
Es dauerte zwar ein paar Stunden und Testläufe (und die üblichen „wah, bin ich doof!“-Momente durften natürlich auch nicht fehlen), aber schließlich kam das raus, was ich haben wollte. Trotzdem ging ich danach noch stichprobenartig durch die Einzeldateien – man weiß ja nie.
Nachdem das erledigt war, wollte ich dasselbe Design auch fürs Blog haben. Da, so dachte ich mir, müßte es einfacher sein, weil ja, wie gesagt, das HTML durch die PHP-Dateien des Themes jeweils neu erzeugt wird und ich die gewünschten Änderungen daher nur an jeweils einer Stelle machen muß. Auf der anderen Seite arbeitete ich damit quasi im Produktivsystem, denn ich habe hier derzeit lokal kein WordPress installiert, mit dem ich herumspielen könnte.
Im Blog mußte ich, vom jetzt neuen CSS der statischen Website ausgehend, teils margins und paddings (Abstände eines Elements nach innen und außen) noch ein wenig anpassen. Außerdem habe ich im Blog oben ein zusätzliches kleines Menü mit eigenem Aussehen („zur Website | Impressum“), dafür stehen keine Zeitstempel im Fuß. So nebenbei kopierte ich mir die Links zum Weiter- bzw. Zurückblättern (auf den jeweils nächsten bzw. vorherigen Artikel) nochmal nach unten, weil es mich selbst schon öfters gestört hatte, daß die nur über dem Artikelanfang zu finden waren.
Dadurch, daß die Linien wegfielen und die Bereiche jetzt durch unterschiedliche Farben bzw. Farbtöne voneinander abgegrenzt werden, mußte ich auch deren Zusammenspiel in der Breite ein wenig anpassen. Der Contentbereich wurde dadurch minimal schmaler. (Wer sich an die alte Version erinnert: Die Sidebar hing bewußt ein Stückchen in den Content-Bereich, das ist jetzt weg, weil das mit dem neuen Design ein wenig unübersichtlich wurde.)
Als ich fast fertig war, bekam ich von Alex die Rückmeldung, daß sein mobiler Browser das Logo bei den Einzelartikeln zwar laden, aber nicht wie vorgesehen in einem weißen Kreis darstellen, sondern es ganz oben in die linke Ecke setzen würde. Ohne Kreis. Mir war das teilweise auch in meinen Desktop-Browsern aufgefallen, außerdem wurde dann der Kopfbereich insgesamt deutlich „länger“ dargestellt, als er sein sollte. Da hatte ich jedoch schnell festgestellt, daß ich erst nochmal einen expliziten Reload durchführen mußte, damit der Kopfbereich korrekt dargestellt wird. Zu dieser Zeit vermutete ich allerdings noch das Browser-Caching als (alleinige) Ursache.
Inzwischen hatte ich noch die Links zum Weiter- bzw. Zurückblättern oben über dem Artikel gelöscht und ließ sie nur noch unten stehen. Damit löste ich das Problem, daß auf Artikelseiten und auf der Startseite jeweils ein unterschiedlicher Abstand zwischen Content-Bereich und Kopfbereich dargestellt wurde. Das allein hätte noch nicht gestört, wenn dann die Sidebar daneben nicht ein Stück tiefer gehangen hätte als der Content-Bereich. Das sah ein wenig … unprofessionell aus.
Das von Alex gemeldete Problem mit dem verschobenen Logo ohne Kreis auf seinen diversen (!) mobilen Browsern blieb. Dabei vermute ich außerdem, daß ein Teil dieser Browser mein Blog noch nie im Cache gehabt hatte. Also auch nicht die alte Version. (Es sei denn, auf Smartphones teilen sich mehrere installierte Browser einen Cache, und das glaube ich jetzt nicht so wirklich.)
Spät nachts, ich war eigentlich schon so halb im Bett, schaute ich mir das nochmal mit meinem eigenen Smartphone an (Android 5, „hauseigener“ Browser). Und tatsächlich: Das Logo hing auf den Einzelartikel-Seiten links oben am Canvas-Rand, der Kopfbereich war viel höher als vorgesehen, und der weiße Kreis um das Logo fehlte. Auf der Startseite stimmte alles. Außerdem fiel mir auf den Artikelseiten auf, daß die Links zum Weiter- und Zurückblättern oben standen, und zwar nur oben. So, als hätte WordPress hier einen meiner Zwischenstände herausgegeben statt der aktuellen Version. Oder nur das geänderte CSS, aber nicht die entsprechend geänderten HTML-Daten.
Damit wurde mir klar, daß das Problem nicht (nur) an den mobilen Browsern liegen kann, denn mit dem Smartphone-Browser war ich nicht auf den Zwischenständen gewesen, sondern nur vorher auf der alten und jetzt auf der komplett neuen Version. Was ich da aber zu sehen bekam, war definitiv ein Zwischenstand – sonst wären die Links zum Weiterblättern nicht oben gestanden.
Ein expliziter Reload brachte mir dann übrigens die aktuelle Version.
Also nochmal: Mein Smartphone-Browser „kannte“ keinen der Zwischenstände (hatte also keinen davon im Cache), zeigte mir aber trotzdem einen solchen an. Daraus schließe ich, daß WordPress einen Zwischenstand auslieferte, obwohl ich das Theme seitdem noch ein paarmal geändert hatte. Das galt allerdings wiederum nicht für die Blog-Startseite, denn die wurde sofort richtig dargestellt.
Daraus schließe ich wiederum:
- WordPress kann vermutlich unterscheiden, ob es einen mobilen oder einen Desktop-Browser bedient. So weit, so gut, und für sich genommen keine schlechte Sache.
- WordPress bzw. PHP cached offenbar für mobile und Desktop-Browser unterschiedliche Versionen der Scripte (und die Teile des Themes sind ja PHP-Scripte) und liefert unter Umständen entsprechend unterschiedliche Versionen aus.
- Dabei achtet der Cache für die Bedienung mobiler Browser offenbar nicht so sehr darauf, ob sich an den Originalen was geändert hat, (eventuell) insbesondere dann, wenn es relativ schnell mehrfach hintereinander Änderungen gibt, was dazu führen kann, daß veraltete Versionen ausgeliefert werden.
Man könnte noch vermuten, daß die Browser noch das alte HTML im Cache hatten und das mit dem neuen CSS zusammen darstellen wollten. Dem widerspricht allerdings, daß ein Teil der mobilen Browser die Seiten eben nicht vorher im Cache gehabt hatten. Also, gar nicht, in gar keiner Variante.
Zugegeben, das sind mehr so Spekulationen. Ich kenne das Innenleben von WordPress nicht gut genug, um wirklich zu wissen, was da ablief. Aber so richtig in Ordnung ist das für mich nicht. Auch die mobilen Browser müßten sofort die geänderten Versionen bekommen, und zwar sowohl in HTML (also aus PHP heraus) als auch vom CSS her.
Aber für mich ergibt sich die Erkenntnis: Wenn man in WordPress ein Theme ändert, muß man beim Testen mit mobilen Browsern wohl besonders aufpassen und lieber mindestens einmal explizit auf Reload gehen, bevor man dem glaubt, was man zu sehen bekommt. Denn sonst testet man sich zu Tode, wenn alte Versionen angezeigt bzw. alte und neue Daten gemixt werden.
15. Februar 2017 at 8:09
https://www.nginx.com/resources/wiki/start/topics/examples/dynamic_ssi/
„This makes it easy to have a common style (headers and footers) without resorting to PHP or a framework.“
Wäre das nicht auch etwas für deine statische Seite? (vielleicht, wenn du sie das nächste Mal anpasst)
15. Februar 2017 at 14:21
Nee, eher nicht. Ich denke aber dran, mir ein Python-Script zu bauen, mit dem ich die Seiten – ähnlich wie WordPress das macht – zusammenbaue, bevor ich sie hochlade. Also nicht dynamisch jedesmal bei Aufruf, sondern eben vorher, und der Webserver liefert dann weiterhin statische Seiten aus.
23. Februar 2017 at 14:58
Hallo,
ist ja alles ganz gut und schön was du hier getrieben hast aber die Webseite sieht immer noch ziemlich altbacken aus und so richtig „mobile friendly“ ist die immer noch nicht (die sidebar nimmt zu viel platz ein, der text darin ist zu klein, links sind zu eng beieinander, und noch vieles mehr).
Wenn du schon selber ein erstellen willst dann schau dir mal bootstrap an oder wenn du ein fertiges theme umbauen wilst, sie dir mal ignite (https://www.competethemes.com/demos/?theme=ignite) an. das sieht deinem hier recht ähnlich, ist aber full responsive
ansonsten noch… comic sans! ernsthaft?!?
25. Februar 2017 at 19:05
@Zwangseinweisung: Daß das auf Smartphones noch nicht so gut ist, weiß ich. Immer eins nach dem anderen. Das kommt noch.
Wenn ich ein Theme oder Layout erstelle, dann mache ich das grundsätzlich ganz altmodisch per Hand.
Und Comic Sans ist hier nicht explizit eingestellt. Aus der CSS-Datei:
Es kann sein, daß einige Browser auf „cursive“ mit Comic Sans reagieren. Explizit beabsichtigt ist die Benutzung dieser Schrift hier nicht.
12. März 2017 at 15:51
[…] Webseiten-Renovierung […]