WordPress 5.5 und viel Neues von Gutenberg

Horst Scheu­er hat dar­an erin­nert, dass der Release – Ter­min für die Word­Press 5.5 ansteht. Vor­ge­se­hen ist der 11. August 2020. Mich hat sei­ne Erin­ne­rung inspi­riert, mir die aktu­el­le Guten­berg-Ver­si­on anzu­se­hen. Ich hat­te vor eini­ger Zeit geschrie­ben, dass der Par­al­lel-Betrieb der im Core vor­han­de­nen Ver­si­on und des Plug­ins nach mei­ner Erfah­rung kei­ne Pro­ble­me bereitet. 

Wie­der mal war ich posi­tiv über­rascht davon, was im Guten­berg-Edi­tor inzwi­schen alles geht. Die Optik wur­de eben­so leicht ver­än­dert. Die Icons sind bei­spiels­wei­se ein wenig krass schwarz gera­ten. Nun, dar­an gewöh­ne ich mich bestimmt auch schnell. 

Bilder im Editor schneiden

Rich­tig gut fin­de ich, dass man per Drop-Down jetzt im Edi­tor die Vor­schau-Aus­wahl für Mobil, Tablet und Desk­top Dar­stel­lung erhält. Nur bin ich so dar­an gewöhnt, die Desk­top-Vor­schau (bis­her Stan­dard) zu nut­zen, dass ich den zwei­ten Klick für die Vor­schau im neu­en Tab im ers­ten Moment ein wenig läs­tig fand. 

Was ich gro­ße Klas­se fin­de, ist, dass man Bil­der jetzt im Edi­tor belie­big zuschnei­den kann. Das Menü zur Ände­rung des Block-Typs und des ‑Stils wur­de etwas auf­ge­bohrt und die Anord­nung wur­de verbessert.

Ich sage mal, es gibt bei die­sen Fea­tures sicher noch Luft nach oben. Aber wenn man die Beschnei­dung eines Bil­des eini­ge Male gemacht hat, wird es sicher schnel­ler bzw. leich­ter von der Hand gehen. Die vor­ge­ge­be­nen For­ma­te (z.B. 16:10 u.s.w.) sind hilf­reich, freie Ska­lie­rungs­mög­lich­kei­ten wären mir aller­dings doch lie­ber. Habe ich sie viel­leicht über­se­hen? Nun ich fand jeden­falls kei­ne Möglichkeit.

Dass man nun aus­ge­wähl­te Blö­cke des­sel­ben Typs auf ein­mal ändern kann, dürf­te eben­falls eine Funk­ti­on sein, die gern und häu­fig genutzt wird. 

Natives Lazy Load im Core

Nach den Infor­ma­tio­nen im Word­press-Blog vom 15. Juli 2020 (Autor: Flo­ri­an Brink­mann) soll mit der Ver­si­on 5.5 das so genann­te nati­ve Lazy Loa­ding für Bil­der kommen. 

Ich habe nati­ve Lazy Load via „Perf­mat­ters“ aus­pro­biert und alter­na­tiv auch die immer noch schlum­mern­de aber längst vor­han­de­ne Chro­me-Ein­stel­lung (Brow­ser) akti­viert. Beson­ders gefal­len haben mir bei bei­den die Resul­ta­te nicht. Ich bevor­zu­ge die Funk­ti­on Lazy Load, das mein Cache-Plug­in „WP-Rocket“ an Bord hat. Zusam­men mit dem The­me „Gene­ra­te­Press“ funk­tio­niert das sehr schön. Ob man mit Lazy Load gut klar kommt, häng mei­ner Erfah­rung nach vor allem vom ver­wen­de­ten The­mes und von den Plug­ins ab, die sonst noch lau­fen. Das Tes­ten der vie­len Mög­lich­kei­ten kann sich zie­hen und ganz schön ner­ven. Soweit ich weiß, spielt Lazy Load bei Goog­le, wie über­haupt die Hand­ha­bung von Fotos, eine wich­ti­ge Rol­le beim Ran­king. Aber wer weiß da schon Genaues? 

Unab­hän­gig von etwa­igen Neu­ig­kei­ten zu Guten­berg bzw. Word­press 5.5 möch­te ich bei der Gele­gen­heit auf etwas hin­wei­sen, das mir nicht erst heu­te auf­ge­fal­len ist und dass ich offen gestan­den auch nicht ganz verstehe.

Block-Bibliothek, Widgets für Sidebar und Footer gängig machen

Auch in der Guten­berg-Block-Biblio­thek gibt es den Bereich „Wid­gets“. Alle Wid­gets las­sen sich auch in der Side­bar oder im Foo­ter eines The­mes nutzen. 

Bei den von Blog­gern wohl häu­fig ein­ge­setz­ten Wid­gets „Neu­es­te Arti­kel“ bzw. „Neu­es­te Kom­men­ta­re“ wer­den im Gegen­satz zu den Wid­gets in den Guten­berg-Blocks aller­dings kei­ne Bei­trags­bil­der bzw. Ava­tare angezeigt. 

Nun kam mir der Gedan­ke, dass die Sache mit den Ava­ta­ren gewis­ser­ma­ßen obso­let sein könn­te. Schließ­lich schal­ten vie­le Blog­ger die­se Anzei­ge aus Grün­den (DVGO) ab. In den erwähn­ten Guten­berg-Blocks kann man die Anzei­ge ein- bzw. ausschalten. 

Voll­stän­dig ver­wirrt hat mich der Unter­schied beim Wid­get für „Neue Arti­kel“. Dort gibt es die mög­li­chen Ein­wän­de (DVGO) ja nicht. Fea­ture Images wer­ten die Anzei­ge auf. War­um also bie­tet Word­Press nach län­ge­rem Ein­satz des Guten­berg-Edi­tors bei den nor­ma­len Wid­gets für Side­bars und Foo­ters nicht die wahl­wei­se Dar­stel­lung von Ava­tars und Fea­ture Images an? 

Dazu habe ich bis­her nichts gele­sen, was das erklä­ren würde. 

Ich fand ein klei­nes (älte­res) Plug­in, das die Auf­ga­be über­nimmt, aus den Guten­berg-Wid­gets „Neu­es­te Arti­kel“ und „Neu­es­te Arti­kel“ in Side­bar und Foo­ter ver­wend­ba­re Wid­gets zu machen. Damit wer­den die optio­na­len Ein­stel­lun­gen der Guten­berg-Wid­gets nutzbar. 

Sidebar Widget Blocks

Das Plug­in heißt: Side­bar Wid­get Blocks“ und kann hier aus der Word­press-Plug­in Biblio­thek her­un­ter­ge­la­den wer­den. Die Hand­ha­bung ist ein­fach. Im Plug­in-eige­nen Edi­tor legt man das Guten­berg-Wid­get an und stellt in den nor­ma­len Blogei­gen­schaf­ten ein, ob man Autor, Datum, Excerpt oder Avatar/​Feature Image aus­ge­ben möch­te. Außer­dem wie vie­le Bei­trä­ge bzw. Kom­men­ta­re ange­zeigt wer­den sol­len. Danach spei­chert man die Datei und es ste­hen in den Wid­gets unter dem Namen „Side­bar Wid­get Blocks“ die ange­leg­ten Guten­berg-Wid­gets zur Ver­fü­gung. Die­ses Wid­get zieht man in die Side­bar oder den Foo­ter und wählt dort das gewünsch­te Menü aus. Unter Menü steht das zuvor ange­leg­te Guten­berg-Wid­get, das nun in Side­bar und Foo­ter ange­zeigt wer­den kann. Mit wenig CSS hat man zwei „neue“ Wid­gets mit Bei­trags­bild und bei den Kom­men­ta­ren mit Avataren. 

Viel­leicht nützt die­ser klei­ne Exkurs ja dem einen oder ande­ren. ¯\_(ツ)_/¯❤

Update, 23.7.2020

Ich habe mich ans Forum von Word​press​.org gewandt und dort die Ant­wort zu mei­nen oben gestell­ten Fra­gen erhal­ten.

Solan­ge kein HTTP2 für eine Web­site ver­wandt wird, wer­den die Datei­en (CSS/​Java Script) sequen­zi­ell gele­sen. Des­halb wird hier eine Zusam­men­fas­sung der Datei­ty­pen emp­foh­len. Sobald eine Sei­te unter HTTP2 läuft, ist dies nicht mehr erfor­der­lich, weil die frag­li­chen Datei­en asyn­chron (meh­re­re Datei­en par­al­lel) gele­sen wer­den. Inso­fern sind die text­li­chen Aus­füh­run­gen (Fazits) der diver­sen Tools für Geschwin­dig­keits­mes­sun­gen als Emp­feh­lun­gen zur Opti­mie­rung einer Web­site auf­zu­fas­sen. Kei­nes von ihnen lie­fert bei Ein­satz von HTTP2 und Ver­zicht auf die erwähn­te Zusam­men­fas­sung von CSS/­Ja­va-Script-Datei­en kor­rek­te Mess­ergeb­nis­se. Der ent­schei­den­de Wert bleibt die Lade­zeit einer Web­site. Die Requests gehen nach oben, der Per­for­mance Grad ohne­hin. Die Lade­zeit bleibt (bei die­ser Sei­te) deut­lich unter 1 Sekun­de. Meist bewegt er sich zwi­schen 500 und 800 ms. Damit ist die Leis­tung voll ok.

Es gibt die­sen Arti­kel (Kom­men­ta­re unbe­dingt auch lesen) aus dem Jah­re 2017, in dem sich der Autor sehr sach­kun­dig mit dem spe­zi­el­len Pro­blem befasst, das ich fälsch­li­cher­wei­se in die­sem Kon­text gese­hen hat­te. Nein, die schlech­ten Mess­ergeb­nis­se beim Ver­zicht auf die Zusam­men­fas­sung von CSS- und Java-Script – Datei­en, fin­den nicht ihren Nie­der­schlag im Ran­king Ihrer Web­site. Dazu lie­fern der ver­link­te Arti­kel und der Kom­men­tar aus­führ­lich Auf­schluss. Irgend­wie blöd, dass der belieb­te „Schwanz­ver­gleich“ ange­sichts die­ser Erkennt­nis­se sinn­los gewor­den ist.