in den letzten 23 jahren habe ich jeden einzelnen blog-geburtstag verpasst. natürlich habe ich gelegentlich über das (blog) alter gesprochen, aber jubuläums-artikel habe ich, glaube ich, nie geschrieben (und irgendwie auch albern gefunden). aber das lässt sich ja ändern …

voilà hier ist jetzt ein jubiläums-artikel, weil der erste unter der domain wirres.net verfasste artikel am 20.04.2002 veröffentlicht wurde. und das ist nach meiner berechnung — und der von carbon — jetzt 23 jahre her.

aber natürlich ist das im grunde total egal, weil ich schon viel früher das bedürfnis hatte ins internet zu schreiben, wie ich kürzlich in „30 jahre bloggen“ erwähnt habe. trotzdem: auf die nächsten jahre.

und in den nächsten jahren wird’s vielleicht auch interessant, denn in 29 jahren bin ich so alt, wie mein vater heute geworden ist. in acht oder neun jahren werde ich 25 jahre lang als arbeitskollege mit dasnuf gearbeitet haben. in elf jahren werde ich mein rentenalter erreicht haben — und so wie es aussieht, kann man auch im rentenalter noch lesenswertes ins internet schreiben. und in acht jahren werde ich 25 jahre mit der beifahrerin verheiratet sein. (den tag meines hochzeitstag kann ich mir gut merken, weil wir heiligabend in las vegas geheiratet haben, aber das jahr konnte ich mir nie merken. jetzt kann ich die site-suche benutzen um meinen hochzeitstag zu finden.)

ich hab meine rückseite schön gemacht. früher™ war ich wahrscheinlich der beste besucher der rückseite, weil ich sie mir als übersicht über die aktivitäten rund um mein blogdings gebaut habe. auch jetzt finden sich dort ein paar metadaten und zugänge ins archiv.

besonders interessant (für mich): offensichtlich habe ich im jahr 2015 am meisten veröffentlicht. keine ahnung warum, vielleicht war das die zeit in der ich fast täglich lange, kommentierte linklisten veröffentlich habe oder jeden pups von instagram und twitter in mein blog gezogen habe. und jetzt wo ich diese übersicht erstellt habe, sehe ich auch, dass meine blogpause effektiv fünf jahre lang war (2020 bis 2025). und das korrespondiert mit dem einzug von frida. offenbar hab ich da andere prioritäten gesetzt. insgesamt summieren sich die veröffentlichungen auf wirres.net auf ca. 10.800 „artikel“.

die tagcloud ist naturgemäss etwas chaotisch. ich hab sie aber auch reduziert auf die einträge der letzten 6 jahre und ein paar einträge extra. wenn ich jetzt anfange konsistent zu taggen, ist die tagcloud dann also in fünf, sechs jahren übersichtlich und klar. vielleicht.

ausserdem neu, der RSS-feed zeigt ab jetzt nur noch die sachen an, die auf der startseite sichtbar sind. so kann ich bilder oder notizen mittenrein oder auf die rückseite von wirres.net posten, ohne ein schlechtes RSS-gewissen zu bekommen. alles was mir relevant genug scheint, erscheint weiterhin auf der startseite.

in den letzten tagen haben kirby und ich uns besser kennengelernt. für mich ist der neubau meiner website wie weihnachten und geburtstag zusammen. ich freue mich schönes geschenkt zu bekommen und dann an die wand zu hängen oder in eine vitrine zu stellen. aber meine liebsten geschenke sind sachen aus denen ich selbst schönes bauen kann. so freue ich mich zum beispiel bis heute darüber weihnachten vor 14 jahren und weihnachten vor 12 jahren damit verbracht haben zu dürfen … eine küche aufzubauen.

so sollen gute geschenke sein: man bekommt einzelteile, oder besser gesagt ein system von bau- und gestaltungselementen, aus denen man selbst etwas eigenes bauen kann. dabei muss man nicht bei null anfangen, weil sich viele kluge menschen bereits gedanken über potenzielle probleme und lösungen gemacht haben und man sich einfach auf deren schultern stellen kann.

mit dieser idee lässt sich der erfolg von lego, minecraft und sicherlich zum teil auch von ikea erklären. ikeas genialster marketingtrick ist wahrscheinlich, dass man bei kunden eine art stockholm-syndrom auslöst. weil man durch die mühen und schmerzen des selbst-aufbaus durchsteht, schätzt man das ergebnis am ende positiver ein, als wenn man es fertig gekauft hätte.

natürlich ist auch der weg ein ziel. in meinen auseinandersetzungen mit kirby lerne ich wieder dinge über das programmieren. sehr hilfreich in sachen kirby, aber auch als einführung in die moderne php-programierung, sind zum beispiel die screencasts in der kirby guide von bastian allgeier. wenn ich mir die ansehe, muss ich ständig pausieren um schnell mal was auszuprobieren und staunend bei mir im zimmer rum zu stehen.

anders als ein leeres blatt papier, sind systeme wie kirby, aber auch home assistant, prall gefüllte werkzeugkisten, die einem zurufen: mit uns kannst du genau das bauen, was du schon lange bauen wolltest. und unterwegs lernst du viel über dich selbst, darüber wie teile der welt funktionieren und am ende hast du eine schön anzusehende baustelle, an der du — wenn du lust hast — die nächsten 10 jahren weiterbauen kannst.

---

jedenfalls habe ich in den letzten tagen viel im maschinenraum gearbeitet. wie bastian allgeier in den screencasts immer sagt, code getrocknet, eleganter gemacht und unterwegs viele abbiegungen entdeckt, die ich noch erkunden möchte. das alte wirres.net war sensationell gut suchmaschinen-optimiert. teilweise haben sich einträge minuten nach der veröffentlichung schon im google index gefunden. das ist durch die längere inaktivität und vor allem das einjährige von der bildfläche verschwinden, natürlich alles hin. und alles was den code angeht, die kleinen helfer für suchmaschinen und crawler, müssen neu her. dafür gibt’s viele helfer, aber es ist auch viel handarbeit und feinschliff nötig.

aber mit dem zwischenstand bin ich ganz zufrieden. so sieht das mittlerweile wieder in den suchergebnissen aus.

die sitemap spiegelt jetzt auch die robots-regeln, also alles was älter als 5 jahre (oder 3, bin noch unentschieden, aber derzeit sind’s 5) ist ausgeblendet. übersichtseiten will ich nicht im index haben, weil die sich so oft ändern und ohnehin nicht zum finden geeignet sind.

und beim suchwort mediathekwebview bin ich derzeit sogar auf der ersten suchergebnisseite.

---

die seite vom heutigen morgenspaziergang zeigt exemplarisch, warum ich einerseits so begeistert von kirby bin und andererseits, auf wie viel arbeit ich mich noch freuen kann.

so habe ich das erste bild während einer kleinen pause beim spaziergang gepostet. es wurde automatisch zu bluesky und mastodon syndiziert, allerdings hat irgendwas bei der aufbereitung für den RSS-feed geklemmt, da kam der artikel zunächst ohne bild an. später hab ich einfach 6 weitere bilder vom telefon in den artikel geladen und die dem kirby starterkit mitgelieferte galerie hat out of the box funktioniert. ich musste später nur noch ein bisschen am code schrauben, damit das auch mit responsive images funktioniert.

bildserien vom telefon aus ins internet posten und teilen, vor ein paar jahren war das noch ein feuchter traum, bzw. der grund warum apps wie instagram so erfolgreich waren. ich würde gerne weiter auf instagram posten, am liebsten automatisch von hier, aber das will facebook nicht, bzw. nur für „business“ kunden. also pausier ich das jetzt erstmal und freu mich, dass ich das jetzt „zuhause“ machen kann, mit dem gleichen komfort, aber unter meiner kontrolle. einziger nachteil von sowas: der ordner mit dem artikel und den bild-rohdaten die das telefon dahin geladen hat ist 30 MB gross. zum glück kann man bei uberspace mittlerweile festplattenplatz dazukaufen, oder, wenn alle stricke reissen sollten, kann ich kirby auch ganz schnell woanders hinschieben.

ausserdem bin ich jeztzt auch in den genuss des ersten, gar nicht mal so angenehmen kirby bugs gekommen. aus mir noch nicht ganz nachvollziehbaren gründen legt kirby eine temporäre datei an, vergisst die aber zu löschen, was unangenehme folgen hat (eindeutige IDs neuer artikel sind nicht mehr eindeutig, sondern gleich). aber da mein zweiter vorname „workaround“ ist, ist das auch kein so grosses problem.

---

die ideen, was ich hier noch so alles machen könnte, fliessen momentan ganz gut. mir gefällt das ruhige, minimalistische webschaufenster derzeit ganz gut, aber weil ich schon gerne (meta-) daten und sekundär-infos zu einzelnen artikel anzeigen möchte (vor allem für mich selbst natürlich), werde ich nicht nur meine alte rückseite reaktivieren, sondern auch eine packungsbeilage zu jeden artikel anlegen, quasi artikelrückseiten. da können dann auch kommentare und webmentions und so hin.

mit anderen worten, hier könnet es in den nächsten monaten immer wieder etwas ruckeln. wenn euch was auffällt oder nervt, sagt mir bescheid.

ich hab gestern angefangen meine rückseite, also die der webseite, wieder zu rekonstruieren — oder besser wieder zu beleben. ideen/todos hab ich einige, jetzt gibt’s erstmal ne blogrolle, angelehnt an die feeds, die ich in meinem feedreader verfolge.

die liste ist einerseits länger geworden als ich dachte und doch nicht komplett. aber jeder link hat einen kurzen kommentar oder einordnung spendiert bekommen.

→ zur rückseite

das gabs seit bestimmt 15 jahren nicht auf wirres.net: eine funktionierende suche. jetzt schon.

ich staune selbst, was ich da alles finde. eigentlich will ich ja gar nicht dass man hier alles findet. nicht alle meine artikel sind gut gealtert oder auch nur im ansatz gut. aber auf ne art sind es eben auch zeitdokumente und ich stöber da gerne drin.

suchmaschinen verbiete ich schon seit langem das indexieren von übersichtseiten und artikeln die älter als 3 jahre sind. das hat damals enorm geholfen post von anwälten zu reduzieren. ausnahmen bestätigen die regel. tim mälzers gurkensalat rezept darf google gerne indexieren und verlinken. andere rezepte hab ich damals™ (wie heute) glaube ich auch entsprechend freigeschaltet.

und, den gag kollte ich mir nicht verkneifen, die such-funktion muss man natürlich auch erstmal suchen, bevor man sie verwenden kann.

eben etwas spät gemerkt, dass ich mir den RSS feed zerschossen habe. so ist das mit einem hackable cms. da hackt man auch mal was kaputt. sollte jetzt wieder funktionieren, sorry, ich lerne noch.

aber abgesehen davon heute auch gelernt:

• kirby lässt sich updaten, indem man einfach den kirby ordner im webroot austauscht und dazu soll man den media ordner löschen (in dem automatisch generierte bilder und und so liegen)
• den media ordner hab ich daraufhin gestern gelöscht, der war mittlerweile auf 6 GB angewachsen. es zeigt sich, am anfang hab ich wohl was falsch gemacht. die generierten bilder brauchen jetzt bei weitem nicht mehr so viel platz (nach 30 stunden 414 MB ) und die generierung geht verzögerungsfrei, ohne dass ich das gefühl habe, dass der server ächzt. das läuft aber alle unter dem motto: lass uns erst mal kennenlernen, liebes kirby.
• das plugin gedöns bei kirby ist weniger „it just works“ als bei wordpress. das liegt wohl auch daran, dass die freiheitsgrade beim konfigurieren von kirby sehr viel grösser sind. aber so lernt man sich eben auch immer besser kennen, kirby und ich.

und kirby kann vieles was mich begeistert:

• SVGs werden einfach wie bilder angezeigt, wenn man sie wie bilder hochlädt.
• transparente PNGs bleiben transparent, wenn sie skaliert werden
• die doku ist sensationell gut, dass die getkirby website im quelltext auf github liegt ist grossartig
• wie man core oder pluginfunktionen, templates, snippets in kirby überschreiben, bzw. erweitern kann ist fantastisch. einfach plugin snippets in den regulären snippet ordner kopieren, dann werden die benutzt. almost always fails gracefully.

ich fühle mich tatsächlich ein bisschen wie in der frühphase meines bloggens. bloggen um die technik zu testen, sachen auszuprobieren, schauen was geht und wie man es besser machen kann.

chatgpt meint ich könne cloudflare nicht mit wetterleuchten übersetzen. wolkenflakern hört sich aber doof an. aber darum geht’s eigentlich auch gar nicht. ich wollte nur bescheid sagen, dass ich cloudflare auf wirres.net abgeschaltet habe. die datenschutzerklärung habe ich entsprechend geändert.

die probleme mit langen ladezeiten und langsamen laden von bildern, die ich in den letzten tagen immer wieder beobachtet habe, sind seitdem verschwunden. ich vermute ich hätte meine cloudflare einstellungen irgendwie anpassen müssen. mit dem alten wirres.net hat cloudflare viele jahre lang wunderbar funktioniert (mein ich zumindest), aber im zusammenspiel mit kirby hat es wohl gehakt.

jedenfalls meckert jetzt auch google pagespeed/lighthouse nicht mehr und alles fühlt sich erstmal schön snappy an.

---

ausserdem bin ich spät, aber jetzt dafür mit eigenem domain-handle auf bluesky: https://bsky.app/profile/wirres.net

dieses og:image-gedöns und wesentliche suchmaschinen tags gibt der maschinenraum jetzt auch aus.

das template, bzw. der template-ordner auf dem diese website bis vor ungefähr einem jahr lief hiess wirres3. nach diese logik ist der kirby-relaunch wohl wirres version 4.

version 2 dürfte das hier gewesen sein, 2010 war ich stolz darauf von einem tabellen-basierten layout auf ein CSS basiertes layout umgestellt zu haben.

version3, bei der ich auf „responsive design“ umstellte, lief dann 12 jahre lang.

und eben, zufällig im archiv gefunden, 2015 schrieb ich über die version 0 von 1996. die lief zwar noch nicht unter wirres.net oder irgendeinem content managmente system, sondern auf blanken html-metal. in dem artikel von 2015 behaupte und belege ich, dass ich eiegentlich schon seit 30 jahren (1995) ins internet schreibe, bzw. linke.

und ich erkläre anhand eines kottke zitats, warum ich so lange auf diesem obskuren CMS geblieben bin: läuft halt, funktioniert, ist berechenbar und kenn ich.

einer der technischen gründe warum ich mit einer software aus den 90er jahren so lange gut zurecht kam, waren die html-vorlagen, also die art wie ezpublisch html aus den inhalten produzierte. jedes formatierung, bilder, links, zitate hatten ihre eignen vorlagen. statt
<a href="https://example.com>example.com</a>
schrieb ich
<link https://example.com example.com>>
bilder lagen in einer bilddatenbank und nach der verknüpfung mit einem artikel refernzierte ich sie mit
<image 1 left large>
was sich kompliziert und mühsam anhört ist technisch ein segen. so wurden bilder in den neunziger jahren vorzugsweise über tabellen-konstrukte gelayoutet. <figure> oder <figcaption> waren damals noch nicht erfunden, adaptive bilder erst recht nicht. aber mit dem template system liess sich die ausgabe von bildern jeweils an den stand der technik anpassen. so konnte ich aus einem einfachen <image 1 left large> schnell komlexes, adaptives bild-markup bauen, das optimierte bilder für alle möglichen bildschirmauflösungen ausgab.

in den neunzigern durfte man noch <b> zum fetten von text verwenden. im ezpublish backend musste ich immer <bold> verwenden, aber konnte die html-ausgabe dann eben später an das modernere <strong> anpassen.

und natürlich liess sich das auch alles erweitern. für eingebettete youtube videos hab ich mir eine ezpublish vorlage <tube hGhrJru-PQ8&t> gebaut, die dann anfangs einfach den normalen youtube embed-code ausgab und später eine datenschutzfreundlichere variante, die nur das video-poster mit einem play-button zeigte und das video und das google-tracking erst nach einem klick lud. weil kirby mit seinen block-editor ein ähnliches konzept verfolgt, liess ich das für alle meine importierten inhalte und natürlich auch neuen inhalte ruck-zuck neu bauen. im block editor gebe ich nur die video-url an, die ausgabe des blocks passe ich per template an und heraus kommt das:

diese datenschutz-freundlicheren video-embeds sind das, womit ich gestern meinen tag verbracht habe. funktioniert für youtube und vimeo.

ich weiss zwar gar nicht ob das noch irgendwer verwendet, bzw. ob ich noch jemals ein vimeo-video hier neu einbetten werde, aber weil ich in meinem archiv noch das eine oder andere vimeo-video liegen habe, soll das natürlich auch weiter so funktionieren.

ausserdem habe ich gestern noch am rss-feed geschraubt. wenn ich im kirby editor einen relativen link eingab, kam der auch im rss-feed relativ raus. which is doof. aber vielleicht isses auch doof relative links zu verwenden, wenn ich mich recht erinnere hab ich in ezpublish auch immer volle urls verwendet um auf wirres.net zu linken. ausserdem hab ich mir überlegt im feed den normalen youtube-embed code auszugeben, so dann man sich das video in seinem rss-reader eingebettet ansehen kann. ganauso gebe ich die bilder im feed nicht mehr adaptiv aus, sondern einfach, ohne gedöns auf 900px breite skaliert.

---

jedenfalls sehe ich jetzt wieder was mich über die letzten 30 jahre dazu gebracht hat ins internet zu schreiben: mein drang neue dinge auszuprobieren, zu schauen, mit welchen technischen tools man was erreichen kann um das älteste gewerbe der welt auszuüben: mit anderen kommunizieren.

in den letzten 5 jahren lag mein fokus eher auf der interspezifischen kommunikation: wie kann ich verstehen was frida will und intendiert, wie stelle ich sicher, dass frida mich versteht? das hat ganz gut geklappt und unterwegs habe ich das eine oder andere gelernt und leider eher wenig mit meiner spezi geteilt. ausser einmal letztes jahr auf der republica.

in der web-technik hat sich in den letzten jahren, so wie bei den hunde-erziehungsmethoden viel getan. lazyloading geht mittlerweile ohne jedes javascript, css kann variablen und rechnen (!), fast alle browser sind auf dem gleichen technischen stand. uberspace, wo diese seiten gehostet sind, kann http/2 und ich bin sicher an den caching-policies, cache-control headers lässt sich noch so einiges optimieren und lernen.

apropos caching und performance. nach der installation von kirby auf uberspace (piece of cake, einfach den 2,5 GB grossen kirby ordner rüberkopieren, eine kleine anpassung an der .htaccess, läuft) …

# In some environments it's necessary to
# set the RewriteBase to:
RewriteBase /

… habe ich massive performance probleme beobachtet und musste in der php.ini php mehr RAM gönnen. der grund, so erkläre ich es mir nachträglich, war cache-warming. kirby erzeugte hunderte, tausende bildvarianten für die adaptive auslieferung von bild-dateien, und das kostet RAM und CPU (sorry uberspace!). gestern habe ich die parameter der adaptiven bildauslieferung nochmal angepasst, was erneut zu merklichen performance-engpässen führte. ein blick in den media ordner, wo kirby die bildvarianten cached/ablegt, zeigt derzeit 5.8 GB. vor drei tagen waren das nur 2.4 GB, gestern 4 GB. der kirby content ordner ist 2,4 GB gross.

nach ein paar stunden bild-generierung schien die performance der seite wieder OK zu sein. wenn ihr, liebe leser, einen anderen eindruck habt, lasst es mich gerne wissen.

---

tl;dr: ins internet schreiben und eine eigene website zu betrieben ist immer noch furchtbar viel arbeit, aber allein um den stand der technik zu verfolgen, (be-)lohnt sich das. und es gibt noch viel zu tun und lernen.

(entschuldigung für die clickbait-überschrift, korrekt müsste es natürlich heissen: „30 jahre ins internet schreiben“)

vor 22 jahren hab ich auf wirres.net den ersten „artikel“ veröffentlicht. auf einem CMS namens ezpublish, damals in der version 2.2.x. später hab ich ezpublish mal auf 2.3.0 aktualisiert, danach im prinzip nicht mehr.

vor ziemlich genau vier jahren hatte ich ezpublish noch einmal geflickt, damit es es mit php 7.4 läuft. vor einem jahr war dann bei uberspace schluss mit php 7.4. wie ein alter weisser mann, kam mein CMS mit den erfordernissen der modernen zeiten (php 8.x) nicht mehr zurecht. deshalb hab ich im letzten jahr kurzfristig erstmal auf tumblr ersatz geschaffen.

ezpublish hat mir zwei jahrzehnte treu gedient. es liess sich anpassen und offensichtlich auch von jemandem mit lückenhaften programmierwissen patchen und am laufen halten, sogar mit okayer performance.

jetzt, ein jahr später wollte ich es noch einmal wissen, ob ich mit etwas geduld und vielleicht hilfe von chatgpt, dem alten CMS nochmal die moderne welt erklären kann. es zeigte sich, dass das eher schwer und uberkomplex ist. seit der php version 4.x hat sich dann doch einiges getan.

was relativ einfach ging war wirres.net lokal, bei mir zuhause, auf meinem heimserver in einem php7.4 container zum laufen zu bringen (und so im prinzip für die ewigkeit zu konservieren). mit einem eintrag in die /etc/hosts lässt sich auf meinem rechner wirres.net aufrufen, als wäre nie etwas gewesen.

beim googlen nach alternativen gefiel mir kirby von anfang an. ich mochte das konzept, dass artikel in ordnern organisiert sind und alle zugehörigen dateien mit in diesem ordner liegen. die doku gefiel mir auch und das starter kit, hatte, wie damals ezpublish, sinnvolle beispiele wie man das ding zum laufen bringt und was man damit anstellen kann. mir kamen auch schnell ideen, wie ich die inhalte aus ezpublish in kirby importieren könnte. nachdem ich mir in meiner lokalen wirres.net instanz ein export script zusammengebastelt hatte, war ich erstaunt wie schmerzfrei der import ging und wie gut kirby meine inhalte verstand. immerhin handelte es sich um über 10.000 artikel (im ø habe ich offensichtlich über die 22 jahre jeden tag etwas mehr als einen artikel geschrieben).

jedenfalls sind jetzt die artikel wieder da. auch die meisten alten urls sollten wieder funktionieren. der letzte auf der alten seite veröffentlichte artikel hätte in alter notation die url /article/articleview/11437/1/6/ und das funktioniert. die alte haupt-rss-feed-adresse sollte noch gehen, aber es dürfte auch einiges kaputt sein — also noch viel zu reparieren sein.

mal schauen wie es hier weitergeht. kirby ist toll, flexibel und auf eine angenehme weise unterkomplex, aber eben doch hochflexibel.

---

der import der inhalte hat natürlich auch dazu geführt, dass ich nochmal alte sachen die ich im laufe der zeit veröffentlicht habe gelesen oder angesehen habe. mich hat das daran erinnert, warum ich jahrelang ins internet schrieb: um sachen festzuhalten, die sonst im schaum der zeit verpuffen. es ist zwar schön im eigenen instagramm-konto ganz runter zu scrollen, aber #instagram auf der eigenen webseite ist noch schöner. und zum teil auch ein bisschen strukturierter. #schottland zum beispiel. oder die urlaubsvertretung damals (2005).

irgendwann im letzten jahr wollte ich jemandem ein bild vom pöhler zeigen, aber wirres.net war offline, auf meinem telefon finde ich eh nix und ausdrucke hab ich schon seit 40 jahren nicht mehr dabei. in der eignen unordnung lässt sich sowas ganz schnell finden.

jedenfalls bin ich froh wieder online zu sein.

wirres.net läuft ja leider auf einem etwas älteren und obskuren CMS und weil ich derzeit keine lust habe den PHP code des CMS auf die neuesten PHP versionen hoch zu hacken, funktionierte wirres.net bis heute nur so halb und seit heute gar nicht mehr. deshalb hab ich etwas brutal mal eben alles auf diese ersatz-seite umgeleitet.

wenn ich wieder ein bisschen zeit und lust habe, mach ich die alte seite wieder gängig. dass zwischendurch links brechen und feeds ins leere laufen, tut mir sehr leid, immerhin hatten die jetzt schon über 20 jahre gehalten. aber ich versuche mein bestes zu geben, das wieder zu richten.

aktuelle verlautbarungen also erst mal hier.

hier auch gleich die erste verlautbarung: am 29.05.2024 spreche ich auf der republica in berlin.

https://re-publica.com/de/session/hunde-sind-auch-nur-menschen

[nachtrag 23.03.2025]

dieser beitrag und einige andere wurden zuerst auf dem tumblr-ersatz-blog veröffentlicht. mittlerweile habe ich die beiträge wieder hierhin exportiert.

diese website läuft jetzt auf php7.4. das wurde erforderlich, weil uberspace, mein hoster, die alte plattform einstellt, auf der wirres.net viele jahre auf php5 lief. das CMS hier hinter ist bekanntlich sehr alt und lief nicht auf anhieb auf php7. nach zwei abenden fummeln und googlen lief dann aber doch alles auf der neuen plattform.

vorher hatte ich ziemlichen bammel auf irgend so einen modernen quatsch wie wordpress umsteigen zu müssen und meinem archiv „gute nacht“ sagen zu müssen. zumal ich das selbst wohl am meisten bedauert hätte, ich such ständig nach alten rezepten hier.

die nächsten 10 jahre wirres.net dürften hiermit aber erstmal (zumindest technisch) gesichert sein, php-rückwärtskompatibilität, stackoverflow, uberspace und geschicktem googeln sei dank. jetzt muss ich nur noch motivation finden mal wieder öfter was hier festzuhalten.

wer noch fehler findet, was ziemlich wahrscheinlich ist, kann mir gerne bescheid sagen.

seit diesem artikel ist die artikel-id meiner ez-publish installation auf 10.000 geklettert. das heisst nicht, dass ich 10.000 artikel auf wirres.net geschrieben habe, genaugenommen sinds 9429 veröffentlichte artikel. dazu kommen noch ein paar artikel von gastautoren. die fehlenden 513 artikel sind entweder gelöschte artikel, nie veröffentlichte entwürfe oder fehler.

seitdem ich für jedes instagram eine kopie als artikel aus der kategorie bilder anlege, ebenso für swarm-checkins, instagram-, twitter- oder youtube-favoriten — und tweets (meist) zuerst hier schreibe, bevor ich sie zu twitter oder facebook kopiere, ist die zahl der auf wirres.net veröffentlichten artikel stark gestiegen. deshalb ist auch die artikel-id im letzten jahr relativ schnell (nach 14 jahren) auf zehntausend gestiegen.

ich habe wirres.net ein bisschen schneller genmacht, zumindest laut dem google page speed tool. das scheint jetzt, nach einigen umstellen, einstellen und priorisieren, einigermassen zufrieden mit der leistung meiner seiten zu sein und zeigt die ladegeschwindigkeit meist im grünen bereich an.

die anforderungen des page speed tools zu verstehen, oder genauer, die anforderungen für schnelles seitenladen zu verstehen, ist gar nicht mal so leicht. vieles von dem was google vorschlägt hört sich für meine ohren spanisch an.

JavaScript- und CSS-Ressourcen, die das Rendering blockieren, in Inhalten „above the fold“ (ohne Scrollen sichtbar) beseitigen

woher soll ich wissen, was above the fold ist, oder welche resourcen das rendering blockieren? mit versuch und irrtum habe ich mich dem aber langsam annäheren können. entscheidend ist jedenfalls, neben den grundvoraussetzungen wie einer relativ schnellen seitenauslieferung (zum beispiel durch vorhalten fertig gerenderter seiten) und möglichst (klein) optimierter resourcen (bilder), das enthaltenen CSS- und javascript-gedöns möglichst asynchron (also irgendwann) zu laden, nachdem der hauptseiteninhalt bereits da ist.

ansatzweise hatte ich das schon vor längerer zeit gemacht, so lade ich die zahl der likes und reaktionen und die reaktionen selbst schon länger asynchron (per ajax) nach. aber noch wichtiger scheint es, möglichst viele javascripte (jquery selbst, jquery plugins und den javascript-code selbst) und stylesheets ebenfalls asynchron zu laden — eben damit sie das rendern der seite nicht blockieren.

theoretisch geht das bei javascript ganz einfach, indem man sie mit der option lädt. dann muss man aber darauf achten, dass die ladereihenfolge passt und nicht irgendein script versucht jquery zu benutzen, obwohl das noch gar nicht geladen ist. irgendwann hatte ich das aber rausgefunden, und jetzt lädt das ganze javascriptgedöns erst dann, wenn der browser es für nötig hält.

was ich seit vielen jahren für wichtig halte und was jetzt wieder sehr befriedigend läuft, ist wirres.net ohne aktiviertes javascript. alle grundsätzlichen funktionen, funktionieren auch ohne javascript. alles was per javascript nachgeladen wird, wie reaktionen oder kommentargedöns, funktioniert dann nicht, aber seitdem ich mich letzte woche von typekit verabschiedet habe und die brevia-schrift bei fontshop (werbelink) lizensiert habe, wird die brevia auch ohne aktiviertes javascript angezeigt. durch das schriftladen per CSS, sehen jetzt auch meine AMP-seiten mehr nach dem original aus (diese seite als AMP laden).

apropos CSS; komplizierter das google page speed tool zu befriedigen, wird es in sachen CSS. auch hier schlägt google vor möglichst viele resourcen asynchron oder zumindest später zu laden. leider gibt es aber keine möglichkeit einem einfach ein -attribut hinzuzufügen. den CSS-code aufzuteilen und nur das wichtigste in den seitenkopf zu packen und das weniger wichtige ans seitenende zu packen, ist schonmal ein schritt nach vorne, lässt google aber immer noch meckern. es gibt aber einen offiziellen neuen weg, das über zu machen. weil das noch nicht von allen browsern unterstützt wird, hat die filamentgroup mal wieder einen polyfill gebaut: „loadCSS, A function for loading CSS asynchronously“

der einbau dieser lösung hat mich am ende dann im google page speed tool in den grünen bereich gebracht.

---

die seitenladegeschwindigkeit auf wirres.net fühlt sich jetzt tatsächlich etwas schneller an, ein direkter vergleich mit einer AMP-seite zeigt, das die werte der regulären seiten ganz OK sind. AMP lädt diese seite in knapp einer sekunde (load), bzw. den DOM-content in 293 millisekunden. regulär lädt die seite in 1,29 sekunden (load), bzw. den DOM-content in 594 millisekunden. ich finde das sollte in sachen optimierung erstmal reichen.
 

seit der ankündigung von AMP habe ich mich, vor allem aus technologischer neugier, bemüht das format bereitzustellen. im januar begann google meine AMP-formatierten seiten in den index aufzunehmen, etwa 500 AMP seiten auf wirres.net waren am 2.2.2016 indexiert. zu diesem zeitpunkt hatte ich auch bereits die meisten fehler der seiten beseitigt, heute sind meine seiten, AMP-technisch, laut webmaster console und laut debugging tool, fehelrfrei.

aber google hat nicht nur über die letzten wochen hinweg gemerkt, dass meine AMP-seiten syntaktisch korrekt sind (die 6 monierten fehler datieren allesamt auf versionen von vor dem 2.1.2016), sondern auch nur 4 meiner AMP-seiten im index.

auch als ich noch mehr seiten im google-index hatte, hatte ich maximal 1-2 besucher pro tag auf meinen AMP-seiten, im google-index war ich, soweit ich sehen konnte, AMP-mässig unsichtbar. das heisst auch mobile suchergebnisseiten, zeigten nie meine AMP-seiten an, sondern stets die regulären seiten. das ist ja nicht weiter schlimm, aber ich habe das gefühl, dass google white oder blacklists führt und AMP-seiten nur von renomierten, reichweitenstarken webseiten in die (mobilen) suchergebnisseiten aufnimmt.

ich finde die idee und die ausführung hinter dem AMP-projekt nach wie vor faszinierend, weil es verspricht, seiten im web — und nicht etwa nur in apps — effektiv und von störendem und irritierenden müll befreit, auszuliefern, aber die implementierung und adaption von AMP scheint, selbst bei google selbst, unter aller kanone zu sein. deshalb bin ich gespannt auf den öffentlichen facebook instant articles rollout mitte april, auch wenn sich die vorteile vor allem in der app auswirken werden, aber immerhin ist die facebook-implementierung so gelöst, dass es immer einen fallback auf die webversion gibt und die instant-articles-version wie ein sahnehäubchen funktioniert.

---

apple news ist übrigens auch eine mittlere katastrophe, zumindest, wenn man ein medium mit nur um die 100tausend seitenansichten im monat (30.000 web, 60.000 RSS) betreibt. ich habe mich dort vor einem halben jahr testweise angemeldet und vorerst nur einen (englischsprachigen) RSS-kanal angemeldet, was einer mittleren katastrophe gleich kam, weil sich die apple news inhalte per RSS nicht aktualisierten und auch nicht editieren liessen. jetzt ist das apple news format teoretisch für jeden offen, aber apple lässt auch hier seinen manischen kontrollwahn walten. meine bitte um freigabe meines apple news kanals wurde bereits zweimal abgelehnt, weil die apple-türsteher zweimal meinten, dass mein kanalname ihnen nicht passt und mich zweimal zurückgewisen haben. von mir aus kann apple seinen news-format alleine nutzen, das zudem auch noch irre kompliziert und sehr proprietär ist.

heute die bild-lightbox fresco (@frescojs) mit photoswipe (@photoswipe) ersetzt. ich bin sehr begeistert von photoswipe. auf der demoseite sieht man schon ganz gut warum.

• angenehme animationen (ruckeln bei mir im firefox ein bisschen)
• flüssiges wischen/swipen auf dem desktop, aber vor allem auf mobilen geräten möglich
• vergrössern in der lightbox (kneifen/pinchen auf mobilen geräten)
• fühlt sich haptisch sehr, sehr gut an

fresco war auch sehr schön, fühlte sich aber nicht so gut an. vor ein paar versionen wurde das wischen/swipen auch zugunsten von klickgesten rausgenommen, was sich auf mobilgeräten immer ein bisschen komisch anfühlte.

ich hoffe, die änderung ist auf allen endgeräten gut angekommen, bei mir scheint alles OK.

die bildauslieferung selbst, habe ich vor ein paar tagen übrigens auch angepasst. die sollten jetzt zum grossen teil auch angepasst/responsiv ausgeliefert werden, bei kleinen bildschirmen kleinere bilder, bei grösseren und hochauflösenden bildschirmen entsprechend grösser. die grösseren bilder hatte ich früher™ per javascript nachgeladen/reingefummelt, die srcset-lösung ist aber eindeutig besser und sauberer.

vor ein paar monaten bekam ich eine interview-anfrage für einen schulfilm über das bloggen. ein paar blogger wurden dafür interviewt, ich wurde unter anderem gefragt „Was bringt einen zum Entschluss öffentlich zu werden?“ und „Was ist das tolle am Bloggen?“

heute war die die fertige DVD im briefkasten, dadrauf die interviews, ein paar intros und unterichtsmaterialen, unter anderem auch „Arbeitsblätter und Lösungen“. auf einem blatt auch unterichtsfragen zu wirres.net:

2. Lies Schwenzels Bedienungsanleitung zu wirres.net und analysiere Inhalt, Form und Aussage!

der lösungsvorschlag zur form listet trocken „Kleinschreibung, Rechtschreibfehler, Kommafehler“ auf, zur aussage lautet der lösungsvorschlag, wie ich finde, ziemlich auf den punkt:

Der Autor legt keinen Wert auf Ordnung, Sorgfalt, Regeln, Relevanz. Er sammelt und schreibt, was ihm auffällt, ihn nervt oder freut, wie es ihm gerade in den Sinn kommt. wirres.net: Der Name ist Programm.

vor ein paar tagen wollte ich mal gucken wie gut wirres.net unter https läuft. seit ner weile geht das, weil cloudflare, das wirres.net ausliefert, kunden sein SSL-zertifikat zur verfügung stellt.

das funktioniert eigentlich ganz gut: https://wirres.net (SSL-link), allerdings ganz offensichtlich nicht zu 100%. denn sowohl meine eigene fever-installation, als auch rivva.de konnten danach den RSS-feed von wirres.net nicht mehr abholen, wie ich dank frank westphals hilfe erkannte, wegen SSL-fehlern die curl unter umständen ausspuckt.

der fehler trat insbesondere auf, weil http://wirres.net/index.xml (die haupt-RSS-adresse die ich seit schon immer angebe, auch wenn es noch diverse andere gibt, siehe diese anmerkung) auf https://wirres.net/article/rssheadlines/index.xml weiterleitete (jetzt leitet die weiterleitung wieder auf ein SSL-loses http://wirres.net/article/rssheadlines/index.xml)

irgendwann werde ich mir ein richtiges zertifikat besorgen und dann wieder hoffen, dass danach weiterhin alles funktioniert. jetzt erstmal weiter ohne SSL-weiterleitung. wer https://wirres.net per SSL anfordert bekommt es auch so, es kann dann aber sein, dass man nach ein paar klicks wieder auf der http-variante landet.

ich weiss nicht ob’s am alter liegt oder am trend, aber ich hab die schriftgrössen hier ein bisschen grösser gemacht. sich am lesemodus von ios zu orientieren kann keine falsche wahl sein, hab ich mir gedacht. auch die schriftgrade für grössere darstellungen sind ein bisschen gewachsen.

ich versuche auf wirres.net so wenig tracker wie möglich einzubauen. standardmässig sollte hier beispielsweise von ghostery nur mein piwik und typekit gemeldet werden. von typekit lade ich die brevia, auf die ich nicht verzichten möchte und deren anderen lizensierungen mir zu teuer oder unbequem sind. ansonsten sollten in der regel keine tracker geladen werden. ausnahmen bestätigen die regel, wie zum beispiel dieser artikel in dem (zur demonstration der neuen twitter „kuratierungs“-funktion) javascript von twitter nachgeladen wird. damit erhält twitter theoretisch einiges an browser-informationen und setzt wohl auch cookies, die aber, sagt twitter, nach 10 tagen gelöscht oder anonymisiert werden. whatever. ich versuche diese dritt-scripte so gut es geht zu vermeiden.

wenn ich einen tweet einbette, mache ich das ohne javascript, nur mit html. das hat den vorteil, dass es auch im RSS funktioniert (allerdings lade ich eventuell im tweet eingebettete bilder nach wie vor von twitter):

#Wurstkrebs pic.twitter.com/VQUSs1fEba

myko (@mykke_) 30.10.2015 0:31

(ursprünglich veröffentlicht am 30.10.2015 08:31)

das gleiche gilt für instagram einbettungen, bei denen ich das bild durch ein bisschen zauberei allerdings selbst ausliefere:

Last night was fun!

#angeflixt #breakingbad #narcos

Maria (@mariaplays) 30.10.2015 12:02

(ursprünglich veröffentlicht am 30.10.2015 10:34)

eigentlich ist das so nicht vorgesehen. twitter (und instagram) möchten, dass man eingebettete tweets mit solchen javascripten versieht:

mit dem widget.js oder embed.js scripten werden dann aus meinen html-embeds aufgehübschte twitter-tweets (oder instgram embeds):

ok, ok, das ist jetzt nicht soo ein grosser unterschied, ausser eben, dass man mit der rechten variante ein paar kilogramm extra code lädt und sich ein bisschen mehr tracken lässt.

---

weshalb ich das alles aufschreibe; wenn einem die native, die twitter- oder instagram-javascript-variante besser gefällt, kann man sich den jeweiligen javascript-code jetzt permanent aktivieren, so dass meine twitter- und instagram-embeds so aussehen, wie sie auch überall sonst aussehen. das hier ist der schalter

(das funktioniert nur mit eingeschaltetem javascript und nicht per RSS)

:

• twitter aus
• instagram aus

das gleiche funktioniert für instagram embeds, wer die nativ, so wie instagram sich das vorstellt sehen möchte, kann sie sich hier ebenfalls aktivieren. die einstellung oben wird mit einem cookie permanent gespeichert, standardmässig sind die widgets (natürlich) weiterhin deaktiviert. die einstellung lässt sich auch in den einstellungen vornehmen.

ich hab jetzt (wieder) ne tagcloud. ich finde das bildet die themen über die ich in den letzten 13 6 jahren geschrieben habe ganz gut ab (schlagwörter setz ich erst seit ungefähr 6 jahren).

(unter anderem mit jqcloud gebaut.)

diese webseite läuft jetzt auf uberspace. meine ersten und zweiten eindrücke sind sehr gut.

der umzug meiner wordpress-webseiten und der webseiten der beifahrerin klapte sehr reibungslos, wirres.net und sein antikes CMS waren etwas fummelig, auch wenn ich es prinzipiell nach einem abend arbeit am laufen hatte. in den details steckte noch viel arbeit. sieht auf den ersten blick aus, als klappte alles, wem fehler auffallen, kann sich gerne bei mir melden.

neu ist, dass wirres.net sich jetzt per UTF-8 ausliefert. ich hoffe die RSS-feeds zicken in den readern nicht allzudoll, bisher wurden die, wie die ganze site, im alten latin1-format ausgeliefert, möglicherweise werden ein paar ältere artikel als ungelesen markiert.

sollte der uberspace-server anfangen zu zittern, schalte ich nochmal auf den alten server um, dann verschwindet dieser artikel, aber ich bin optimistisch.