30 jahre bloggen, version 4.0.1

das tem­p­la­te, bzw. der tem­p­la­te-ord­ner auf dem die­se web­site bis vor un­ge­fähr ei­nem jahr lief hiess wir­res3. nach die­se lo­gik ist der kir­by-re­launch wohl wir­res ver­si­on 4.

ver­si­on 2 dürf­te das hier ge­we­sen sein, 2010 war ich stolz dar­auf von ei­nem ta­bel­len-ba­sier­ten lay­out auf ein CSS ba­sier­tes lay­out um­ge­stellt zu ha­ben.

ver­si­on3, bei der ich auf „re­spon­si­ve de­sign“ um­stell­te, lief dann 12 jah­re lang.

und eben, zu­fäl­lig im ar­chiv ge­fun­den, 2015 schrieb ich über die ver­si­on 0 von 1996. die lief zwar noch nicht un­ter wir­res.net oder ir­gend­ei­nem con­tent ma­nag­men­te sys­tem, son­dern auf blan­ken html-me­tal. in dem ar­ti­kel von 2015 be­haup­te und be­le­ge ich, dass ich ei­egent­lich schon seit 30 jah­ren (1995) ins in­ter­net schrei­be, bzw. lin­ke.

und ich er­klä­re an­hand ei­nes kott­ke zi­tats, war­um ich so lan­ge auf die­sem ob­sku­ren CMS ge­blie­ben bin: läuft halt, funk­tio­niert, ist be­re­chen­bar und kenn ich.

ei­ner der tech­ni­schen grün­de war­um ich mit ei­ner soft­ware aus den 90er jah­ren so lan­ge gut zu­recht kam, wa­ren die html-vor­la­gen, also die art wie ez­pu­blisch html aus den in­hal­ten pro­du­zier­te. je­des for­ma­tie­rung, bil­der, links, zi­ta­te hat­ten ihre eig­nen vor­la­gen. statt
<a href="https://ex­am­p­le.com>ex­am­p­le.com</a>
schrieb ich
<link https://ex­am­p­le.com ex­am­p­le.com>>
bil­der la­gen in ei­ner bild­da­ten­bank und nach der ver­knüp­fung mit ei­nem ar­ti­kel re­fern­zier­te ich sie mit
<image 1 left lar­ge>
was sich kom­pli­ziert und müh­sam an­hört ist tech­nisch ein se­gen. so wur­den bil­der in den neun­zi­ger jah­ren vor­zugs­wei­se über ta­bel­len-kon­struk­te ge­lay­outet. <fi­gu­re> oder <fig­cap­ti­on> wa­ren da­mals noch nicht er­fun­den, ad­ap­ti­ve bil­der erst recht nicht. aber mit dem tem­p­la­te sys­tem liess sich die aus­ga­be von bil­dern je­weils an den stand der tech­nik an­pas­sen. so konn­te ich aus ei­nem ein­fa­chen <image 1 left lar­ge> schnell kom­le­xes, ad­ap­ti­ves bild-mark­up bau­en, das op­ti­mier­te bil­der für alle mög­li­chen bild­schirm­auf­lö­sun­gen aus­gab.

in den neun­zi­gern durf­te man noch <b> zum fet­ten von text ver­wen­den. im ez­pu­blish ba­ckend muss­te ich im­mer <bold> ver­wen­den, aber konn­te die html-aus­ga­be dann eben spä­ter an das mo­der­ne­re <strong> an­pas­sen.

und na­tür­lich liess sich das auch al­les er­wei­tern. für ein­ge­bet­te­te you­tube vi­de­os hab ich mir eine ez­pu­blish vor­la­ge <tube hGhr­Jru-PQ8&t> ge­baut, die dann an­fangs ein­fach den nor­ma­len you­tube em­bed-code aus­gab und spä­ter eine da­ten­schutz­freund­li­che­re va­ri­an­te, die nur das vi­deo-pos­ter mit ei­nem play-but­ton zeig­te und das vi­deo und das goog­le-track­ing erst nach ei­nem klick lud. weil kir­by mit sei­nen block-edi­tor ein ähn­li­ches kon­zept ver­folgt, liess ich das für alle mei­ne im­por­tier­ten in­hal­te und na­tür­lich auch neu­en in­hal­te ruck-zuck neu bau­en. im block edi­tor gebe ich nur die vi­deo-url an, die aus­ga­be des blocks pas­se ich per tem­p­la­te an und her­aus kommt das:

die­se da­ten­schutz-freund­li­che­ren vi­deo-em­beds sind das, wo­mit ich ges­tern mei­nen tag ver­bracht habe. funk­tio­niert für you­tube und vi­meo.

ich weiss zwar gar nicht ob das noch ir­gend­wer ver­wen­det, bzw. ob ich noch je­mals ein vi­meo-vi­deo hier neu ein­bet­ten wer­de, aber weil ich in mei­nem ar­chiv noch das eine oder an­de­re vi­meo-vi­deo lie­gen habe, soll das na­tür­lich auch wei­ter so funk­tio­nie­ren.

aus­ser­dem habe ich ges­tern noch am rss-feed ge­schraubt. wenn ich im kir­by edi­tor ei­nen re­la­ti­ven link ein­gab, kam der auch im rss-feed re­la­tiv raus. which is doof. aber viel­leicht is­ses auch doof re­la­ti­ve links zu ver­wen­den, wenn ich mich recht er­in­ne­re hab ich in ez­pu­blish auch im­mer vol­le urls ver­wen­det um auf wir­res.net zu lin­ken. aus­ser­dem hab ich mir über­legt im feed den nor­ma­len you­tube-em­bed code aus­zu­ge­ben, so dann man sich das vi­deo in sei­nem rss-rea­der ein­ge­bet­tet an­se­hen kann. ganau­so gebe ich die bil­der im feed nicht mehr ad­ap­tiv aus, son­dern ein­fach, ohne ge­döns auf 900px brei­te ska­liert.

---

je­den­falls sehe ich jetzt wie­der was mich über die letz­ten 30 jah­re dazu ge­bracht hat ins in­ter­net zu schrei­ben: mein drang neue din­ge aus­zu­pro­bie­ren, zu schau­en, mit wel­chen tech­ni­schen tools man was er­rei­chen kann um das äl­tes­te ge­wer­be der welt aus­zu­üben: mit an­de­ren kom­mu­ni­zie­ren.

in den letz­ten 5 jah­ren lag mein fo­kus eher auf der in­ter­spe­zi­fi­schen kom­mu­ni­ka­ti­on: wie kann ich ver­ste­hen was fri­da will und in­ten­diert, wie stel­le ich si­cher, dass fri­da mich ver­steht? das hat ganz gut ge­klappt und un­ter­wegs habe ich das eine oder an­de­re ge­lernt und lei­der eher we­nig mit mei­ner spe­zi ge­teilt. aus­ser ein­mal letz­tes jahr auf der re­pu­bli­ca.

in der web-tech­nik hat sich in den letz­ten jah­ren, so wie bei den hun­de-er­zie­hungs­me­tho­den viel ge­tan. la­zy­loa­ding geht mitt­ler­wei­le ohne je­des ja­va­script, css kann va­ria­blen und rech­nen (!), fast alle brow­ser sind auf dem glei­chen tech­ni­schen stand. uber­space, wo die­se sei­ten ge­hos­tet sind, kann http/2 und ich bin si­cher an den caching-po­li­ci­es, cache-con­trol hea­ders lässt sich noch so ei­ni­ges op­ti­mie­ren und ler­nen.

apro­pos caching und per­for­mance. nach der in­stal­la­ti­on von kir­by auf uber­space (pie­ce of cake, ein­fach den 2,5 GB gros­sen kir­by ord­ner rü­ber­ko­pie­ren, eine klei­ne an­pas­sung an der .ht­ac­cess, läuft) …

# In some en­vi­ron­ments it's ne­ces­sa­ry to
# set the Re­wri­te­Ba­se to:
Re­wri­te­Ba­se /

… habe ich mas­si­ve per­for­mance pro­ble­me be­ob­ach­tet und muss­te in der php.ini php mehr RAM gön­nen. der grund, so er­klä­re ich es mir nach­träg­lich, war cache-warm­ing. kir­by er­zeug­te hun­der­te, tau­sen­de bild­va­ri­an­ten für die ad­ap­ti­ve aus­lie­fe­rung von bild-da­tei­en, und das kos­tet RAM und CPU (sor­ry uber­space!). ges­tern habe ich die pa­ra­me­ter der ad­ap­ti­ven bild­aus­lie­fe­rung noch­mal an­ge­passt, was er­neut zu merk­li­chen per­for­mance-eng­päs­sen führ­te. ein blick in den me­dia ord­ner, wo kir­by die bild­va­ri­an­ten cached/ab­legt, zeigt der­zeit 5.8 GB. vor drei ta­gen wa­ren das nur 2.4 GB, ges­tern 4 GB. der kir­by con­tent ord­ner ist 2,4 GB gross.

nach ein paar stun­den bild-ge­ne­rie­rung schien die per­for­mance der sei­te wie­der OK zu sein. wenn ihr, lie­be le­ser, ei­nen an­de­ren ein­druck habt, lasst es mich ger­ne wis­sen.

---

tl;dr: ins in­ter­net schrei­ben und eine ei­ge­ne web­site zu be­trie­ben ist im­mer noch furcht­bar viel ar­beit, aber al­lein um den stand der tech­nik zu ver­fol­gen, (be-)lohnt sich das. und es gibt noch viel zu tun und ler­nen.

(ent­schul­di­gung für die click­bait-über­schrift, kor­rekt müss­te es na­tür­lich heis­sen: „30 jah­re ins in­ter­net schrei­ben“)