Skip to content

Google Chrome als Chromium unter Linux testen... ::: WordPress Adminbereich

Nach einem Tipp von onli in den Kommentaren, habe ich es mal mit dem Google Chrome probiert.
  • utele.eu screenshotWordPress Dashboard Google Chrome
  • Direkt für Linux gibt's das Ding von Google natürlich immernoch nicht. Das ist ja üblich und war auch bei Google Earth schon so, dass ewig dauerte bis eine Linuxversion gab. Installiert habe ich deshalb Chromium von codeweavers, bekannt für viele Anpassungen von Windowsprogrammen über CrossOver. In den meisten Fällen kostet es so um die 30$ pro Jahr und Lizenz, für Chromium ist es jedoch kostenlos, holen kann man sich den Browser auf der Downloadseite. Die Installation im User klappte problemlos und auf Anhieb, wie auch schon bei anderen Produkten von codeweavers.
  • Der Browser selbst, naja.
  • kopieren wie gewohnt klappt nicht
  • das Teil ist nicht wirklich integriert
    • z.B. kann ich es nicht von einer auf eine andere Arbeitsfläche verschieben
    • das Fenster selbst kann gar nicht verschoben werden
    • Größenänderungen des Fensters klappen, wenn überhaupt, dann nur mit Fehlern
      • auf volle Größe geht gar nicht
      • zurück auf eine kleinere Größe lässt sich zwar das Fenster ziehen, aber die Inhalte sind dann einfach nicht mehr da => um danach zu beenden geht nur noch ein Shortcut, denn der Fenster-schließen-Knopf ist weg
    • Systemmeldungen und Einstellungen des Browsers sehen schon sehr nach altem Windows aus
  • Flash läuft nicht
  • Geschwindigkeit ist eher langsamer als Opera
  • keinen Fehler mit Absätzen in visueller Ansicht
  • Bedienung insgesamt zumindest mit dieser Version haklig, beim Tippen und Löschen hängt das Ding immer etwas nach, ich lösche also mehr als beabsichtigt und muss dann nochmal korrigieren
  • Absturz bei der ersten Suche, manchmal klappt's aber so richtig stabil wirkt das noch nicht
  • wahrscheinlich kein Fehler des Browsers selbst, sondern Problem der Installation über wine und crossover irgendwo hängt noch eine Leiste auf der Arbeitsfläche, die sich nicht entfernen lässt, wenn der Browser offen ist
  • Eingaben in die Adresszeile reagieren nicht so recht auf die Maus wenn ich z.B. an die bestehende Adresse www.utele.eu noch /blog anhängen möchte, geht es nicht per Maus, sondern nur, wenn ich über die Tastatur ans Ende navigiere

Firefox, Opera, Browser im WordPress Adminbereich und ihre Wirkung, z.B. auf Icons

Screenshot utele_wp_admin_icons verschobenMein Problem mit der Geschwindigkeit ließ sich ja eindeutig auf den Firefox zurückführen. Daher setze ich in den letzten Tagen für die Adminbereiche von WordPress Opera ein, denn dreimal schneller ist schon ein sehr klares Argument. Leider verhält sich Opera jedoch nicht wie Firefox. Für mich ist Opera so wie im Moment nicht auf Dauer benutzbar.
  1. normalerweise kann Opera so wie Firefox auch etwas mit der mittleren Maustaste Kopiertes wieder einfügen. Das klappt z.B. um einen Link in die Adressleiste einzufügen. Es klappt jedoch nicht, wenn ich kopierten Text im WordPress-Editor einfügen will, dann öffnet er eine Suchseite oder wechselt zum Linkziel oder so. Er tut jedenfalls nicht, was ich will, nämlich schlicht den Text einfügen.
  2. Beim Überfahren (hover) von Links zeigt mein Firefox mir brav das Linkziel, ich nutze das häufig. Firefox kann es nicht im Adminbereich von WordPress oder bei manchen merkwürdig mit JavaScript erstellten Seiten. Opera allerdings kann es gar nicht, zumindest konnte ich keine Einstellung finden, die mir das ermöglicht.
  3. Von Opera werden keine automatischen Ergänzungen bei Formulareingaben angeboten, wer das wie ich gewohnt ist, ist deutlich irritiert, wenn es fehlt.
  4. Bis hierhin wäre es noch akzeptabel, jetzt kommt jedoch noch ein Bug dazu, mit dem kann ich nicht arbeiten. Schreibe ich mit Opera im TinyMCE von WordPress in der visuellen Ansicht, dann killt Opera alle Zeilenumbrüche und Absätze. Listen und Überschriften sind möglich, alles andere verschwindet einfach. Aus einem nett formatierten Beitrag wird plötzlich eine Textsuppe ohne Absatz oder Zeilenumbruch.
miradlo_bloggt Screenshot wp_admin_icons verschobenBleibe ich in der HTML-Ansicht ist alles ok, dann bleiben Absätze und Zeilenumbrüche auch mit Opera erhalten, aber ein Wechsel mit Speichern zur visuellen Ansicht und alle Umbrüche sind weg. Damit ist Opera definitiv keine Dauerlösung, denn so kann ich nicht arbeiten. Ja, ich weiß es gibt andere Wege mit benutzerdefinierten Feldern und in HTML-Ansicht zu arbeiten. Mir geht's jedoch nicht nur um mich und meine Möglichkeiten, sondern es geht auch um ungeübte Nutzer. Einer der Gründe WordPress zu nutzen ist ja der einfach Editor, der ähnlich wie die gewohnten Office-Programme funktioniert.

Icons (Symbole) im Adminbereich verschoben

Screenshot utele_wp_admin_icons Opera

Vor kurzem habe ich auf uteles Blog einige Beiträge mit Videos erstellt. Nach mehrfachem Testen und Recherchieren fand ich einen recht einfachen Weg, die Dinger auch in valider Version da reinzubasteln. Auf keinen Fall klappte es mit dem ganz offensichtlichen Button gleich oberhalb unter "Hochladen/Einfügen". In der Reihe der erweiterten Symbole für den TinyMCE gibt es jedoch noch einen Knopf "Medien hinzufügen". Über diesen ließen sich relativ schnell die Videos so einbinden, dass nicht alles mögliche hinzugefügt wird, was ich nicht haben will und nachher zu invaliden Seiten führt. Ich erstellte nacheinander mehrere Beiträge mit Videos, und irgendwann zerbröselte die Optik im Adminbereich. Ich bin einiges gewöhnt und beschloss es zu ignorieren, weil ich annahm, dass nach dem nächsten Booten alles wieder passt.

Das war nicht so, in uteles Blog blieben die Symbole und Beschriftungen verschoben. Nun gut, auch das ist kein Weltuntergang, ich suchte also nicht, sondern ließ es einfach so.

Worauf ich jedoch nicht gekommen wäre: Auch das ist ein Fehler, der browserabhängig ist, denn im Opera sieht auch uteles Blog so aus, wie die anderen, da ist kein Symbol verschoben. Browserfehler im Sinne von, etwas sieht in einem Browser etwas anders aus, als im nächsten kenne ich ja, aber was mir neu war, sind so starke Auswirkungen auf einen Browser, weil er sich bei einer Aktion mal verschluckt hat... Da Opera also auch noch keine echte Alternative ist, habe ich mal weiter getestet, mehr dazu, demnächst...

WordPress Adminbereich Geschwindigkeitsproblem mehr oder weniger gelöst...

Schon mal kurz am Rande hatte ich ja geschrieben, dass ich zumindest eine teilweise Lösung für den extrem verlangsamten Adminbereich von WordPress 2.7 und 2.7.1 gefunden habe. Nach nochmaligem Recherchieren gab's den Tipp mal zu prüfen, ob es am Browser liegt. Tja und tatsächlich, es liegt am Browser.

Geschwindigkeit je nach Rechner und Browser

Derselbe Rechner, dieselben Blogs und ihre Adminbereiche ergeben mit Firefox beim Speichern eines Artikels Zeiten von 15 bis 20 manchmal bis zu 26 Sekunden.

Beim ersten Versuch mit Opera: Huch, das war schnell, jedenfalls beim ersten Speichern, nochmal?! Ja, reproduzierbar klappt das wesentlich schneller. Nehme ich also Opera auf diesem Rechner mit denselben Blogs so liegen die Zeiten fürs Speichern plötzlich nur noch bei 5 bis 10 Sekunden.

Je nach Laptop ließen sich diese Zeiten  noch etwas verändern, aber nicht wesentlich. Der Firefox wird noch langsamer, wenn mehrere Tabs offen sind, insbesondere wenn es auch noch mehrere WP-Adminbereiche sind.

Mit einem 64-Bit-Tower und statt W-LAN, altmodischer direkter Ethernetverbindung, in einem Firefox der keine Plugins hat, lässt sich auch hier eine Zeit von etwa 5 bis 10 Sekunden wie bei Opera erreichen. Als erste Lösung bezogen auf die Geschwindigkeit ist Opera prima. Die dreifache Geschwindigkeit beim Speichern macht schon einen deutlichen Unterschied.

Wer also genervt ist vom langen Warten beim Speichern eines Beitrags in WordPress oder vom langsamen Umschalten zwischen verschiedenen Seiten im Dashboard, sollte mal testen, ob es mit Opera oder einem anderen Browser besser klappt. Leider gibt's da andere Probleme, dazu in den nächsten Tagen nochmal mehr zum Thema Browser und WordPress.

Eigene kleine Anpassungen an WordPress oder ähnliche CMS

Klar, für fast alles gibt es ein Plugin, aber aus verschiedenen immer mal wieder auch erwähnten Gründen, versuche ich nicht noch mehr Plugins einzusetzen, als sowieso schon sein müssen. Für manches lohnt ein Plugin auch nicht, manchmal gäbe es nur eins, welches viel mehr macht, als eigentlich gewünscht. Diese Tipps am Rande beziehen sich jetzt auf WordPress, das Prinzip klappt in ähnlichen Systemen jedoch genauso. In älteren Versionen von WordPress gab es sowas wie letzte Beiträge im Admin. Irgendwann hatte ich auch schon einmal vorgesehene Beiträge eingebaut. Immer mal wieder kommt die Frage auf, wann begann dieses Blog, seit wie vielen Tagen gibt es das. Manches ist nicht unbedingt nötig, aber nett, anderes ist mir wichtig, für meinen Überblick. Als ich die 2.7 erstmals näher ansah fand ich einiges gut, z.B. dass ich jetzt selbst einiges an die Stellen packen kann, an denen ich es bevorzuge. Prima ist die Möglichkeit manches zu- oder abzuschalten, das erhöht die Übersichtlichkeit. Die Oberfläche insgesamt gefällt mir persönlich deutlich besser, als die ihrer Vorgänger. Aber perfekt ist es trotzdem nicht. Denn offensichtlich gibt es Funktionen, die die Ersteller nicht für nötig hielten:
  • vorgesehene Beiträge im Dashboard
  • letzte Beiträge in der Übersicht
  • Blogalter im Adminbereich
Das sind jetzt die, die mich grad interessieren, bei anderen sind es andere Ansichten und Informationen. Deshalb finde ich es sinnvoll, selbst Hand anlegen zu können, für solche Kleinigkeiten. Je nachdem worum es geht, findet man mit ein bisschen Suchen eine Möglichkeit bei jemand anderem. Klappte z.B. für die vorgesehenen Beiträge bei Frank Bültge. Er wollte es aus anderen Gründen und auch nicht für den Adminbereich, aber prinzipiell fand ich da die Form. Welche Variable ist zuständig und muss abgefragt werden, das ändert sich nicht, wenn ich es im Dashboard möchte statt innerhalb des Blogs.

Um- und Einbau fremder Codeschnipsel

Ich achte dabei drauf, von wem sie kommen. Wenn irgendein Neuling irgendwas rumprobiert bin ich vorsichtiger, als bei einem langjährigen Plugin-Autor. Trotz allem, solche Spielereien teste ich selbstverständlich immer erst einmal lokal. Sobald die passende Stelle zum Einbau festgelegt ist, schaue ich nach:
  • dem Pfad zur Datei (steht in der Adresszeile)
  • dem Quelltext (der zeigt die Stelle, an der es sich einbauen lässt)
Habe ich das, dann bastele ich  es rein und schaue erstmal, ob es überhaupt klappt. Wenn alles geht und angezeigt wie erwartet, passe ich das Ganze noch so an, wie ich es haben möchte. Kennt man die Namen der Aufrufe, ist es einfach weitere Informationen zu finden, was es sonst noch geben könnte. Ähnlich lief es beim Blogalter, es braucht eine Funktion, die vom ersten Beitrag ausgehend die Anzahl an Tagen, die seither vergangen sind berechnet.

Eigene Codeschnipsel basteln

Die englischen Begriffe in WordPress helfen herauszufinden, wie eine gesuchte Funktion heißen könnte. Um die letzten Beiträge anzuzeigen habe ich nach "recent posts" gesucht. Damit gibt mir die Codex-Site von WordPress unter anderem den Hinweis auf wp_get_archives. Mit ein bisschen überlegen, weiterem Nachlesen und ausprobieren bekam ich so eine Version, die zeigt was mir wichtig ist. Nicht für jede Kleinigkeit muss meines Erachtens ein Plugin sein und vieles lässt sich auch ohne tiefere Programmierkenntnisse realisieren. Wenn man dann zunächst lokal testet und sich bei den ersten Versuchen auf den Adminbereich beschränkt, dann besteht wenig Gefahr, dass da viel schiefgehen kann.

Weisheit, Erkenntnis und Hinweis

Nur kurz: bin grad nicht ganz anwesend, bekomme wohl grad einen Weisheitszahn. Kommentare beantworte ich sobald mein Hirn wieder wie gewohnt funktioniert.

Kurz zum langsamen Adminbereich von WordPress

Nach den Kommentaren dazu, habe ich nochmal recherchiert, das Problem ist  hier für alle betroffenen Blogs gelöst. Firefox braucht weiterhin  ewig für jegliche Aktion im Adminbereich. WordPress Bug-Tracking usw. waren keine Hilfe, das traf alles nicht zu. Teils bestand das Problem nur für 2.7 gar nicht für WP 2.7.1 Nach einem Tipp von hier habe ich es mal kurz ausprobiert: Opera hat ganz normale Antwortzeiten. :)

Perfekte Testerin oder Ute, Horror für alle Entwickler

Hä, wie jetzt? Ja, genau das ist das Problem. Einerseits ist es gut, wenn jemand wirklich jeden Fehler entdeckt und sei er auch noch so versteckt - perfekte Testerin. Andererseits müssen Fehler auch korrigiert werden -  deshalb Ute, der Alptraum aller Entwickler und Programmierer.

Windows, Elektronik und ich

Wie ich hier ja zuweilen schon erwähnt habe, nutze ich Windows nur, wenn es sein muss, also meist nur zum Testen. Dafür gibt es einen einfachen Grund, wir sind nicht kompatibel. Windows "merkt" wenn ich drangehe und zeigt dann jeden Fehler, den es bei anderen bis dahin nie hatte. ;-) Nur Windows? Nö, auch bei allen anderen Systemen, Programmen oder so, einfach bei allem was irgendwie mit Elektronik funktioniert tauchen in meiner Gegenwart deutlich mehr Fehler auf, als bei anderen. Dieses Phänomen ist schon immer so und zog sich auch immer durch. Im ersten Praxissemester lief nur mein Rechner mit identischer Hard- und Software nicht wie alle anderen. Manche Programme hatten Fehler, die ich durchaus reproduzieren konnte, die jedoch bis dahin nie bei jemandem auftauchten. In der FH konnte ich beispielsweise mit meinem Studikonto während des gesamten Studiums nicht wie alle anderen drucken. Wenn es elektronische Eingänge, Zugänge oder ähnliches gibt, tendieren sie dazu, immer dann auszufallen, wenn ich in der Nähe bin.

Informatikerin

Ja, einerseits ist es eine blöde Idee, dass ich genau diesen Bereich ausgesucht habe. Diese Anhäufung von Fehlern bei allem was irgendwie elektronisch ist, fiel nicht sonderlich auf, solange ich als Gärtnerin arbeitete, klar. ;) Es ist andererseits jedoch auch eine Fähigkeit. Meine Jungs und alle Entwickler, die je mit mir zu tun hatten, wissen, wenn ein Programm keinen Fehler mehr zeigt, nachdem ich dran war, dann ist die Chance, dass noch Fehler vorhanden sind, sehr gering. Wenn ich nichts mehr finde, dann kann man ziemlich beruhigt ausliefern.

Gute Tester sind nichts für schwache Nerven

Manchmal nervt es mich selbst, dass ich Fehler so leicht entdecke. Mancher Fehler fiel über lange Zeit niemandem auf, doch wenn er erst einmal bekannt ist, kann er nicht mehr ignoriert werden. Meine Jungs kennen es inzwischen schon und wissen, dass nachdem ich getestet habe, eigentlich immer nochmal irgendwas repariert werden muss. Fast schon peinlich war es mir dagegen in letzter Zeit bei zwei Plugin-Entwicklern.
  • Bei Joern, der das Quote Comments Plugin schrieb, gab es mehrere Runden, in denen alle mit dem Ding zufrieden waren, nur ich fand Fehler. Inzwischen ist es im Grunde behoben, aber es war doch die ein oder andere Anfrage bis es passte. Im Grunde behoben, weil es nur klappt, wenn Link Indication nicht gleichzeitig aktiviert ist.
  • Frank dessen copyfeed-Plugin viele nutzen, hatte seit längerem keine Änderung daran gemacht und es lief auch, sogar bei mir. Allerdings gab es Fehler in den Error-Logs des Servers, sobald etwas geändert wurde, ein Artikel  oder ein Kommentar geschrieben wurden. Das Problem ist bei mir behoben, Frank hat mir mehrfach per Mail Updates geschickt, die auch irgendwann in seine nächste Version einfließen sollen.
An diesen Beispielen wird einer der Gründe deutlich, warum ich Fehler finde:
  • ich teste immer mal wieder ob noch alles valide ist
  • ich schaue ab und zu auch mal die Error-Logs
  • ich schaue auch mal in Webmastertools bei Google
  • ich probiere nicht nur eine Variante, z.B. bei den Kommentaren, sondern mehrere
  • ich teste den Best-Case, aber auch den Worst-Case
    • z.B. mal ausprobieren was die Suche macht, mit Begriffen, die ganz sicher im getesteten Blog vorkommen
    • aber ebenso mal schauen, was passiert, mit Begriffen, die sicher nicht existieren
    • ähnliches gilt für Tests von Seiten, klar teste ich wie ein neues Blog aussieht, ob die Einzelansicht passt, wie die Sucheseiten aussehen...
    • und ebenso teste ich, kommt die Fehlerseite, wenn ich was falsches eingebe, sieht sie so aus, wie gedacht
Wer ernsthaft testet ist nicht schnell fertig. Es gehören einige Punkte dazu, manche mehr oder weniger wichtig. Die Kunst, um es in praktikablem Rahmen zu halten ist zu wissen, was man unbedingt immer testen muss und wo man auch mal weniger genau sein darf. Es geht um Grenztests, am Beispiel eines Blogs:
  • jede Funktion (Artikel erstellen, Kommentare schreiben, Einstellungen anpassen) muss getestet werden
  • ich nutze Blogs nur mit selbst erstellten Themes, da kenne ich schon einige Knackpunkte, bzw. kann manche vermeiden
    • die Startseite testen, weil die z.B. nur die Artikel, aber keine Kommentare zeigt
    • die Einzelansicht eines möglichst langen und eines kurzen Artikels testen
    • die Seitenansicht bei statischen Seiten prüfen
    • die Archivseiten testen
    • die Sucheseiten
  • bei Blogs, die ich betreue, habe ich immer:
    • den Feed abonniert
    • den Kommentarfeed abonniert
    • das Mailabo
    • mehrere Feedreader ausprobiert, z.B. meinen Liebling, den Akregator, aber auch die Feeds im Opera und im Google-Reader
  • validieren der Startseite und mindestens einer Einzelansicht mit Kommentaren, sollten immer mal wieder auch zwischendurch zum Standard gehören

WordPress 2.7.1 automatisches vs. herkömmliches Update

Um Vergleiche anzustellen ist es ja schon praktisch mehr als ein Blog zu betreuen. ;-) Vor jedem Update lohnt es sich ans Sichern nicht nur zu denken, sondern es auch zu tun, siehe: Ablauf bei Aktualisierungen ( Dieser Ablauf der mit Sicherungen der Dateien, Beiträge usw. ist versionsunabhängig, wurde jedoch ursprünglich für die 2.3.2 geschrieben.) Dieses Mal konnte erstmal die automatische Update-Funktion genutzt werden. Ich habe bewusst beide Versionen probiert, in Kurzfassung:

Automatisches Update

  • schnell
  • überschreibt alles
  • läuft direkt auf dem Server

Herkömmliches Update

  • dauert länger, weil ich ausgepackte und getestete Dateien dann einzeln hochlade
  • testbar
  • läuft erst einmal lokal, dann jedoch logischerweise ebenfalls auf dem Server

Klappte gut

  • WordPress selbst lief in allen Fällen problemlos weiter (wie meist, wenn es kein Versionssprung mit Datenbankänderungen ist)
  • auch automatisiert gab es keine Probleme beim Aktualisieren

Passte nicht so ganz

  • die automatische Aktualisierung installiert erneut das unsägliche "Hello Dolly"-Plugin, was ich noch nie haben wollte
  • das ein oder andere Plugin verschluckte sich beim ebenfalls gerade durchgeführten Update (automatisch aktualisiert, heißt, es kann nicht vorher getestet werden)
  • leider sind da noch immer einige Stellen, sowohl bei Plugins, wie auch im Core, an denen ich keine andere Lösung habe als selbst im Code zu fummeln, die müssen nach einem Update natürlich angepasst werden
    • passende Werkzeuge erleichtern das natürlich mit Eclipse und SVN für die Projekte ist es relativ einfach Unterschiede festzustellen und eigene Änderungen wieder anzupassen.
  • beim herkömmlichen Update blieb in einigen Blogs die Meldung: WordPress 2.7.1 ist verfügbar
    • ich musste ein bisschen suchen, weil sich da wohl beim Hochspielen irgendwas verschluckt hatte
    • meine erste Idee, die Versionsdatei wäre nicht da, verwarf ich, als ich sah, dass die Datei mit neuem Datum auf dem Server lag
    • irgendwann suchte ich nochmal, weil keine Fehler sonst auftauchten, war es unwahrscheinlich, dass es etwas Größeres sein könnte
    • die Datei hatte zwar das neue Datum, war theoretisch auch geändert worden, aber als ich sie mir anschaute, sah ich, dass da eben doch noch 2.7 stand, das konnte nicht gehen

Verhalten von WordPress 2.7.1

Insgesamt ist in keinem der Blogs ein Unterschied spürbar. Leider erfüllte sich meine Hoffnung nicht, dass eins der über sechzig geschlossenen Tickets ein bisschen mehr Geschwindigkeit im Adminbereich bringt. :-(  Unter meinen Bedingungen bleibt es bei den 15 bis 20 Sekunden fürs Speichern eines Artikels im WordPress-Editor mit visueller Ansicht. Klar, ich schreibe vieles auch direkt in der HTML-Ansicht und die ist meist etwas  schneller. Da hatte ich zwar auch schon Zeiten von fast 25 Sekunden fürs Speichern, aber zumindest beim Link einfügen kostet es nur halbsoviel Zeit, ist allerdings auch nicht ganz so komfortabel. Keins der Tickets scheint sich auf etwas, was mir in einem der Blogs aufgefallen wäre, bezogen zu haben.

Unterm Strich

Ich halte die Funktion des automatischen Updates nicht für ungefährlich. Das gilt jedoch noch mehr für Plugins, als für ein Zwischenupdate von WordPress selbst. Denn ohne Versionssprung hatte ich da selten Probleme. Lästig finde ich, dass alles wieder drüber gespielt wird, eben auch noch nie genutzte Plugins. Dieses Einspielen neuer Versionen ohne irgendeinen Test vorher, halte ich für eine schlechte Idee. Automatische Plugin-Updates sind jedoch, wie erwähnt, noch gefährlicher, denn da gibts kaum eins, bei dem ich nicht an der ein oder anderen Stelle in den Code eingreifen musste, da lohnt es selten es automatisch zu aktualisieren. Denn die eigenen Änderungen muss ich sowieso noch mit einspielen und mir ist nicht wohl ohne Tests. Bei den Plugins ist es meist eher ein Glücksspiel, ob das automatische Aktualisieren überhaupt klappt. Das ein oder andere schafft es zwar alles zu löschen, aber das Einspielen der neuen Version passte nicht mehr.

1234567890 Unix-Timestamptag statt Valentinstag ::: PHP-Zeitfunktionen

Die Idee gabs via Joern er wies bereits Mitte Januar auf das Ereignis hin. Natürlich habe ich jetzt diesen Artikel so exakt, wie mit WordPress möglich, veröffentlicht. Sekundengenau veröffentlichen geht nicht, deshalb geht der Beitrag eine halbe Minute zu früh raus. Mal zum Thema  Suche 1234567890 als Unix-Timestamp:

<?php $timestamp = strtotime('2009-02-14 00:31:30'); echo $timestamp; // Ausgabe 1234567890 ?> Der Unix-Timestamp gibt genau das am 14. Februar 2009 um 0:31:30 Uhr aus. Dieses Jahr also eher Timestamp-Tag statt Valentinstag. Als UTC ist es bereits etwas früher so, die 1234567890 wird dann bereits am 13. Februar 2009 um 23:31:30 Uhr erreicht.

Einfach erklärt werden einige PHP-Zeitfunktionen, z.B. hier. Ausführlich und mit vielen Spielereien erklärt es das PHP-Manual.

Informatiker haben noch eine Zukunft ;-)

Rechner, die Zeiten als eine 32-bit-Zahl speichern, können damit nur bis  19. Januar 2038 um 3:14:08 betrieben werden. Dann wird der Timestamp größer als diese 32 bit.

Immer aktuell live angezeigt, wird der Unix-Timestamp beispielsweise hier. Weiteres zum Unix-Timestamp, der Grundlage der Zeitberechnung auf allen mir bekannten Systemen gibts auch Wikipedia.

In diesem Zusammenhang nochmal der Hinweis, nicht immer und in jedem Fall braucht man ein Plugin, das ein oder andere lässt sich auch mal eben selbst regeln...

Adminbereich WordPress extrem langsam seit WP 2.7

Wenn es nach mir geht, gibt es nur eins was eine weitere WordPress-Version haben muss:

Geschwindigkeit im Adminbereich

Die vielen neuen Spielsachen und das neue Design sind teils sehr nett und auch praktisch. Beispielsweise das Verschieben der einzelnen Boxen finde ich schon prima. Es ist gut, wenn sich jeder selbst aussuchen kann, welche Informationen und Felder ihm/ihr am wichtigsten sind. Auch das neue Design gefällt mir weitaus besser als bisher. Zwischendurch war es aus meiner Sicht so katastrophal, dass ich es per Plugin angepasst hatte. Jetzt ist es wieder gut so, wie es ist. Ich weiß, dass Blogs langsamer sind als andere Seiten, weil es da einige Funktionen und Basteleien gibt, die eben auch mehr tun.
  • WordPress Admin-OberflächeWordPress Link einfügen

Jedoch das Blog vs der Adminbereich

Unsere Blogseiten brauchen bei meiner Verbindung, DSL 16 MBit, so zwischen 2 bis zu 4 Sekunden, um geladen zu werden. Das ist nicht grad schnell, aber noch akzeptabel. In allen Adminbereichen jedoch, dauert das Umschalten zwischen zwei Seiten oder das Speichern eines Artikels oder was auch immer zwischen 15 und 20 Sekunden! Damit ist das Dashboard und der gesamte Adminbereich etwa 5- bis 7-mal langsamer als das Blog selbst. Übrigens, das sind keine gefühlten Werte, die liegen sowieso noch deutlich drüber ;-) sondern mit dem Firefox-Plugin YSlow gemessene Werte immer mal wieder über einige Tage und verschiedene Blogs verteilt. Für mich gehört ständiges Zwischenspeichern zum normalen Ablauf, wenn ich das jedoch regelmäßig mache, krieg ich Zustände. Im Adminbereich etwaige Änderungen durchführen ist mit dieser Langsamkeit ein Geduldsspiel und macht wirklich keinen Spaß. Selbst das Einfügen eines Links über den Editor ist ein Geduldsspiel, denn da muss eine schicke JavaScript-Verdunklung geladen werden, erst dann kommt irgendwann das Fensterchen. Das Minifenster zeigt mir Vorschläge etwaiger Links, die jedoch sowenig des ganzen Pfads zeigen, dass ich es dann doch lieber selbst tippe oder reinkopiere. Ich muss nicht erwähnen, dass sich das Fenster in der Größe nicht anpassen lässt, dass ich auch nicht den unsäglichen und bei mir überflüssigen "Target" rausnehmen kann, oder?!

Arbeitsbereich und Darstellungsbereich

Welcher Logik folgt das denn? Für mich muss arbeiten
  • schnell
  • einfach
  • intuitiv
sein. Im Darstellungsbereich gibt es aus meiner Sicht kleine Kompromisse, die möglich sind. Für einige nette und hilfreiche Funktionen darf die Gesamtgeschwindigkeit ein bisschen abnehmen. Was mich jedoch maßlos ärgert ist, wenn ich nicht arbeiten kann. Ein Adminbereich, der zwar schick, aber nur mühsam nutzbar ist,  ist extrem störend.

Wunschliste für WordPress 2.8

  • schneller Zugriff auf das Dashboard
  • schnelles Editieren innerhalb des Adminbereichs
  • möglichst viel anpassbar, insbesondere Fenstergrößen (aber das muss nicht per JS sein, ein konventionelles Auswahlmenü würde genügen, bzw. bei Fenstern verstehe ich nicht, warum sie eine fixe Größe haben)
  • einen klare Linie was WP-Core ist, was etwaige Core-Plugins und was sonstige Plugins (mehr dazu was da diskutiert wird gibts bei Frank: Core Plugins )
Ich denke, dass das nur lösbar ist, wenn weniger über JavaScript gelöst wird und mehr über Grundfunktionen von PHP. Wenn vieles ganz einfach per JS jederzeit anpassbar sein muss, dann kostet das Zeit.

...mal eben zwischendurch Serien angepasst und strukturiert : Organize Series

Integriert hatte ich das Plugin Organize Series schon einige Zeit, aber bislang hatte ich noch keine Gelegenheit es auch zu nutzen. Morgen beginnt jedoch eine neue Serie, deshalb war es jetzt sinnvoll, die noch nötigen Anpassungen zu machen. Bei der Gelegenheit habe ich schon mal zwei ältere Serien ebenfalls mit den Möglichkeiten des Plugins angepasst.

Sorry

Leider fiel WordPress jetzt auf, dass es das ein oder andere Ping zu einem Artikel vergessen hatte, das holte es jetzt nach, deshalb sehen die letzten Kommentare grad ein wenig komisch aus...
  • Mitarbeiterblog mit Serienartikel in EinzelansichtSerie mit Icon

Serien nutzen

Das Plugin nutze ich in anderen Blogs schon länger und in unterschiedlicher Form. Mir gefällt, dass die Leser zusätzliche Informationen bekommen, sobald sie einen Artikel aus einer Serie aufrufen. Im Artikel selbst steht zu welchem Teil der Serie er gehört. Die Box am rechten Rand zeigt die Überschrift der Serie und die dazugehörigen Beiträge. Der aktuelle Beitrag wird einsortiert, aber nicht verlinkt. Außerdem setze ich das dazugehörige Widget ein. Damit kann man in der Seitenleiste unter Serien sich die bestehenden Serien aussuchen. Wählt man eine Serie, dann werden die dazugehörigen Artikel in umgekehrt chronologischer Reihenfolge angezeigt. In der Seitenleiste werden statt der zuletzt veröffentlichten, dann ebenfalls die aktuellsten Serienartikel angezeigt. Wählt man einen Artikel in seiner Einzelansicht, dann erscheint eben die Serien-Übersichtsbox, mit den Links zu den anderen Artikeln. Am Ende eines Serienartikels gibt es noch die Seriennavigation. Stehe ich mitten in einer Serie, kann ich den vorigen und den nächsten Artikel direkt wählen. Logischerweise klappt das beim ersten und letzten Artikel nur in eine Richtung. Mir gefällt diese Funktion, ich selbst nutze sie gern. In unserem Mitarbeiterblog bekommen die Serien auch noch ein eigenes  Bild siehe Abbildung, hier wollte ich das vorerst nicht, es ist jedoch möglich. Prima finde ich, dass sogar im RSS der Link zur Serie mit erscheint, wer also von dort aus weiterstöbern will, steht direkt in der Übersicht der Serienartikel.

Aktualisiert 15.2.

  • Das Plugin verschluckt sich noch ab und zu beim ein oder anderen, das ist schade, aber ich finde es nicht so schlimm, dass ich deshalb drauf verzichten möchte:
  • In der Seitenleiste passt es manchmal nicht, was angezeigt wird.
  • Beim Zurückschalten auf  keine Serie ändert sich die Ansicht nicht mehr.
  • Erstellt man mehrere Artikel im Voraus dann kommt es vor, dass sich das Plugin verschluckt, falls man die Nummerierung des Serienteils nicht von Hand passend eingibt.
    • Im Normalfall muss man keine Nummer angeben, wenn der jeweils neueste Beitrag der letzte der bisherigen Serie sein soll.

Plugins vertragen sich nicht: Link Indication und Quote Comments

Teil 871 der "never ending story". Ich bastele ja in letzter Zeit, nach dem Update auf WordPress 2.7 an einigen Blogs, um das ein oder andere an zusätzlichen Möglichkeiten miteinander zu verbinden. Dabei habe ich einige Plugins eingebaut, manche wieder entfernt und hatte teils auch engeren Kontakt mit den Autoren. Schlussendlich lief Quote Comments, war valide, tat was es soll und alles war gut. Je nach Blog fand ich die Idee, Links zu markieren, ob sie intern sind oder nach außen führen gut. Eine weitere nette, zusätzliche Möglichkeit, die es erleichtern kann, sofort einzuschätzen wohin ein Link führt. Ich testete das Link Indication Plugin, wie immer erst lokal, es klappte alles prima, es lief und zeigte im ein oder anderen Blog, wohin die Links führen, prima!

Zitate vorführen

Ein, zwei Tage später wollte ich jemand zeigen, wie die Zitate funktionieren, dass ein ganzer Kommentar zitiert wird, wenn man auf den Link klickt, bzw. eben nur Teile davon, wenn man den gewünschten Text markiert. Tja, wollte! Denn das klappte nicht, da kam kein Zitat, weder direkt, noch nach Markieren eines Textteils. Och nö, nicht schon wieder! :-( Inzwischen testete ich mal genauer. Zunächst suchte ich nach anderen Plugins, die sich auf die Kommentare beziehen, aber da gab es keinen Fehler. Daher suchte ich dann nach allem, was geändert war, seit ich das letzte Mal Quote Comments getestet hatte und fand dabei was nicht klappt:

Link Indication und Quote Comments vertragen sich nicht

Läuft nur eins von beiden ist alles gut, es tut was es soll. Sind beide aktiviert, dann läuft Link Indication weiterhin, aber Quote Comments zitiert nichts mehr. Ich weiß nicht, was sich da verhakt. Ich kann auch nicht einschätzen, welches der beiden "schuld ist" oder ob es einfach ein unglücklicher Zufall ist. Ich lasse jetzt mal verschiedene Kombinationen stehen und schreibe die Autoren an, vielleicht hat ja einer der beiden eine Idee. Sonst muss ich halt in Zukunft je nach Blog entscheiden, was wichtiger ist.

Eckpunkte

  • alle getesten Blogs laufen mit WordPress 2.7
  • am Theme liegt's nicht auch mit dem Default-Theme läuft es nicht
  • aktivieren und deaktivieren anderer Plugins hat keinen Einfluss auf das Verhalten der Zitate

Blogs und Varianten der Plugins

Aktiviert ist/sind:
  • hier im Blog nur Quote Comments
    • und es funktioniert
  • in Rolands Guggat emol Blog nur Link Indication
    • und es funktioniert
  • in uteles Blog Link Indication und  Quote Comments [aktualisiert: 13.2. da mir dort die Zitate wichtig sind habe ich jetzt auch hier Link Indication deaktiviert]
    • damit läuft Link Indication weiterhin
    • Quote Comments zitiert nicht mehr
Jetzt bin ich mal gespannt, ob einer der Autoren eine Idee hat.  Ärgerlich finde ich einmal mehr, dass tatsächlich jede kleine Änderung sich an ganz anderer Stelle auswirken kann. In Kombination mit automatischen Aktualisierungen nicht nur von Plugins, sondern demnächst auch von WordPress selbst ist das ziemlich ungeschickt. Denn das automatische Aktualisieren führt noch leichter dazu, dass mal eben per Knopfdruck etwas geändert wird, mit dem Risiko, dass an anderer Stelle plötzlich irgendwas nicht mehr funktioniert. So schön die vielen Möglichkeiten mit Plugins sind, wer Wert auf ein stabiles und funktionierendes System legt muss schon sehr intensiv testen, um sich das zu erhalten. Ich wünsche mir eine Sicherheitsschicht mit definierten Schnittstellen für Plugins, so dass die sich nicht in die Quere kommen können. Nö, mich interessiert dabei nicht, dass das so nicht machbar ist... ;-)

Twitter Tools zeigt nur eine Fehlermeldung an : Problemsuche

Das Plugin Twitter Tools ließ sich bei einigen WordPress-Blogs problemlos installieren und einbinden. Zu sehen ist die Anzeige der Meldungen beispielsweise in der rechten Seitenleiste auf uteles Blog, da gibts grad auch einen Beitrag über Twitter und Identica, Microblogging eben. Ich habe mir einige Möglichkeiten angeschaut, wie sich Twitter einbinden lässt. Bei der Wahl eines Plugins schaue ich auf Funktionen, teils auf den Autor und auf mein Gefühl wie sich ein Plugin verhält, für Twitter fiel meine Wahl auf Twitter Tools.

Wie war das mit Twitter Tools?

Mal der Ablauf in Stichworten beim Installieren und Aktivieren:
  • mehrfach problemlos
  • dann lokal alles ok
  • hochgespielt bei 1&1 - nichts passiert, außer
  • "Keine Tweets vorhanden."
  • deaktiviert/aktiviert
  • Tabelle des Plugins gelöscht und wieder neu angelegt
  • Tabellen verglichen zwischen funktionierender Einbindung und dem Problemblog
  • Datensätze für
    • id,username... waren auf latin, nicht auf utf8
    • für die Daten des Datums war kein Grundwert gesetzt
  • Datensätze entsprechend angepasst über mysqladmin
  • danach nochmal update,
  • reset
  • update mit Änderungen
  • und jetzt gehts...
Ich vermute es war nur ein Initialisierungsproblem, denn seither klappt alles wie gewünscht...

Validieren : Kommentarfeeds : Pluginverhalten

Wie schon geschrieben, hatte ich Probleme mit validem Code und dem Kommentarfeed. Zwischendurch gab's dann eine Lösung. Allerdings nur bis zum nächsten Update. :-( Plugin aktualisiert, nach Lesen des Hinweis mit valide, auf der Seite des Entwicklers. Heute wunderte ich mich mal wieder über den fehlenden Kommentarfeed. Beim Validieren eines einzelnen Artikels mit Kommentaren war dann klar, dass es nicht gehen konnte. Bei dem Googlebeitrag vor kurzem, gabs ja einigen Austausch. Jeder Kommentar, der am Anfang oder Ende einen Smiley nutzt führt zu einem Fehler, weil das <p> nicht geöffnet oder nicht geschlossen wird.

Plugins die nicht tun was sie sollen

Beim nochmal genauer Hinschauen fiel mir auf, dass heute auch dessen Seite nicht validiert, obwohl sie transitional nutzt, nicht strict wie wir. Damit flog jetzt "Quote Comments" erstmal wieder raus. Ich mag das Plugin und seine Eigenschaften, ich finde es auch praktisch, aber dafür über 20 Fehler in einer Seite lohnt sich nicht. Doch dann kam innerhalb weniger Stunden auf meinen Hinweis hin ein weiteres Update des Autors. Noch einmal probiert, klappte zunächst. Bis ich wieder den Kommentarfeed testete, der ging nicht mehr. Also nochmal deaktiviert, nochmal den Autor angeschrieben und tatsächlich ging er nochmal dran, inzwischen geht alles, inklusive des Kommentarfeeds. Jetzt läuft Quote Comments hier wieder und macht genau das was es soll! :-) Gestern habe ich schon wieder umgestellt.  In aktueller Version fand "search everything" bei mir gar nichts mehr. Selbst wenn es je nach Einstellung klappen könnte, das will ich nicht. Ich habe einige Plugins für Social Bookmarks probiert, das ein oder andere gefiel mir nicht, manche sahen einfach nicht so aus, wie ich wollte... Jetzt nutze ich ein leicht angepasstes "Sociable". Das warf zwei Fehler bei mir, einmal target="blank" und das language-Attribut bei JavaScript, beides darf und muss auch in XHTML strict nicht enthalten sein. Noch bin ich nicht gerade glücklich mit WordPress und seinen Plugins, aber mal sehen, wie sich das entwickelt...

Apropos validieren

Wer es jetzt mit einem einzelnen Beitrag prüft, wird feststellen, dass der Validator einen Fehler meldet:
Validation Output: 1 Error 1. Error Line 556, Column 114: there is no attribute "aria-required". …size="22" tabindex="1" aria-required='true' /> You have used the attribute named above in your document, but the document type you are using does not support that attribute for this element.
Mir geht's da wie Monika, den lasse ich gern stehen, da muss der Validator dazulernen. Das Attribut hilft Webapplikationen zugänglicher zu machen, für diejenigen, die keinen grafischen Browser nutzen können. Somit können Webanwendungen mitteilen, wenn es Pflichtfelder gibt, das erleichtert z.B. Screenreader-Nutzern das Ausfüllen von Formularen.
tweetbackcheck