it is dochs oars, sûnt 2001

Naschriften van een nerd | ontwikkelingen

Bij het werken aan mijn websites wreekt zich dat ik zo gewend ben met bepaalde software te werken. Photoshop is al sinds versie 1.0 mijn standaardgereedschap voor het bewerken van beeld. Maar Photoshop werkt weer niet op Linux. Terwijl Linux me nu net het best in staat stelt de innerlijke mechanismen van mijn websites onder controle te houden.

Bij zulke dilemma’s is de oplossing meestal een compromis, en ik heb ervoor gekozen dan maar een Apache-webserver en MySQL-database onder Windows te draaien, als het zo uitkomt.

Dit deed ik altijd met XAMPP. Maar om een of andere reden raken de instellingen van de webserver onder XAMPP nogal eens gecorrumpeerd. Daarom vertrouw ik dit pakket niet helemaal meer.

Nieuwe versies dijden toch al te sterk uit naar mijn zin trouwens, met allemaal functies waar ik niets mee had.

Sinds enige maanden draai ik daarom een test-servertje via WOS Portable, en dan de kleine versie ook nog, zonder phpMyAdmin. Want, het nut van phpMyAdmin is sterk afgenomen, sinds ik voor de meeste taken MySQL Administrator gebruik.

MySQL Administrator laat me namelijk online dingen doen die mijn domeinhost onmogelijk heeft gemaakt in de versie van phpMyAdmin die daar draait.

Ook heb ik met MySQL Administrator nog eens een project kunnen redden van mijn harde schijf, nadat de webserver in XAMPP weer eens hopeloos corrupt was geraakt. De MySQL-server deed het namelijk nog wel. En ach ja, gereedschap dat redt, daar blijf ik een zwak voor houden.

Evenmin pruts ik vaak genoeg aan mijn websites om er ooit goed in te worden. Zoals het nu gaat, zonder fundamentele kennis over object geöriënteerd programmeren, zo kan het nog net.

Notitie aan zelf

Als de RSS-feed van boeklog ineens stopt met werken, waar die tijden probleemloos gewerkt heeft, dan staat er een karakter met een diakriet in een boektitel waarop ineens alles vastloopt.

Wel dom dat WordPress letters met diakrieten automatisch vertaalt naar een alfabetische code waar de eigen RSS-feed op vastloopt, maar à la. Verander die alfabetische code in een numerieke UTF-8 code, en alles doet het weer.

Overwegingen | 1214 technische editie

Murphy’s Law kent vele lokale varianten;
En dan zijn er nog mensen, zoals ik, die menen dat Murphy een onvergeeflijke optimist was;

Boeklog draait vanaf gisteravond op de nieuwste versie van WordPress. Joechhei. Dat vroeg een krankzinnige intellectuele inspanning, die als voornaamste resultaat heeft dat de website er precies hetzelfde uitziet als voorheen;
Het zijn dan ook slechts het hart en de longen die vervangen werden. Plus het hele geheugen, en de aansturing daarvan. Alle moeite is gedaan om een veiliger site te krijgen. En éen bovendien die zo standaard is dat de nieuwste maatregelen tegen hackers automatisch te installeren zijn;

Om zo standaard als mogelijk te worden, moest ik twaalf verschillende hacks schrijven. Vooral omdat het interne systeem dat WordPress nu heeft om met ‘tags’ om te gaan ontstellend veel primitiever is als de externe oplossing die ik gebruikte;

Voordeel is nu wel dat ik nu ook weer andermans oplossingen gebruiken kan om de functionaliteit van de website te vergroten;

Zo had ik binnen een half uur ook een versie van boeklog gereed die geoptimaliseerd was voor kleine schermen, zoals een telefoon;
Enige nadeel van die oplossing: als een pagina al eens opgevraagd was door een bezoeker van de gewone website, kreeg de mobiele beller die ook te zien, inclusief de bijhorend lange laadtijd — omdat caching van opdrachten voor alles blijft gaan;
En mijn idee was nu net om makkelijk de lijst met auteurs of boektitels bij de hand te hebben, als ik weer eens in een boekwinkel stond;
Dat zijn twee van de meest opgevraagde pagina’s, die altijd in cache staan;

Dus nu moet ik onderzoeken wat prettiger werkt: een mobiele versie van boeklog op een apart adres; met mogelijk het probleem dat Google het vervelend vindt dat dezelfde teksten twee keer online staan;
En Google brengt haast alle bezoek binnen — daar moet ik vriendelijk voor blijven;
Of dat de standaard-installatie van boeklog volstaat, als daar enkel die twee indexpagina’s aan worden toegevoegd speciaal voor mobiele bezoekers;

Enfin. Wordt het eindelijk weer eens interessant om aan uiterlijke veranderingen van de website te denken;
En zo gaat het leven voorbij;

Onder vuur | 5

Twee keer in twee maanden is mijn boeklog nu gehackt. En het maakt nederig om te bedenken dat het de snoodaards beide keren slechts te doen was om niet meteen ontdekt te worden. Met eenzelfde gemak had de website zijn gehele gezicht kunnen verliezen.

Nu zagen sommige bezoekers alleen wat extra reclame. Bestaande uit een op het oog simpel GIF-je, aangeroepen door een javascript; dat toch ook weer een cookie plaatste, zodat niemand áltijd een advertentie tegenkwam.

Dank aan degenen die mij hun ongenoegen over de reclame meldde. Voor mij was deze inbreuk onzichtbaar. Maakte niet uit in welke browser ik keek, onder welk OS ik ook werkte.

Uiteindelijk bleken er twee dingen te zijn gebeurd. Er was een directory met javascripts — /js/ — aangemaakt in de map met de sjablonen die boeklog zijn uiterlijk geven. En dat is heel verneukeratief. Want bij alle eerdere layouts was er gewoon altijd zo’n zelfde javascript directory; om de problemen op te lossen die de bezoekers met Internet Explorer 6 geven.

En behalve die directory waren er twee regels code in de header van de pagina aangebracht, die de scriptjes aanriepen.

Hoe dit kan, weet ik niet. Behalve dan omdat WordPress vele veiligheidsrisico’s schijnt te kennen, waar niemand het ooit over heeft, en mijn host in dit opzicht er op de internetfora ook niet best vanaf komt.

Dus sukkelen we door. In het deemoedig makende besef altijd backups paraat te moeten houden.

Enfin. Éen ding houd ik dan toch weer aan deze episode over. En dit is dat er gereedschappen bestaan om in elk geval te begrijpen waar de hackers mee bezig zijn.

Eén zo’n plek is:
http://www.businessinfo.co.uk/labs/hackvertor/hackvertor.php

De illegale javascriptjes waren deels versleuteld, zodat onduidelijk was wat ze precies uitvoerden. Via bovengenoemde site is die code terug te vertalen naar begrijpelijker instructies.

• kies daartoe ‘script’ uit het menu rechtsboven;
• click daarna op js2str. Er verschenen dan ‘tags’ in het linker tekstveld;
• click tussen deze tags, en kopieer de inhoud van het verdachte javascript daar naartoe;
• click op ‘convert’;
• beaam toch echt dit script te willen uitvoeren;
• en wat in dit geval volgde was dat een overlay zichtbaar werd, waarin een advertentie kon worden aangeroepen;

gehackt

normaal

Notitie aan zelf

Creating custom taxonomies in WordPress.

Taxonomieën en ander gedoe

Weblogs hebben inmiddels prachtige mogelijkheden om eenvoudig en snel tekst online te zetten. Maar weblogs zijn er aanzienlijk minder goed in om bezoekers te tonen wat eerder al eens werd geplaatst.

Vanouds waren geschreven weblogjes al in te delen naar categorie. Dat werkt heel aardig, tot er een paar honderd postjes zijn of meer, en het archief van zo’n categorie een lange onoverzichtelijke lijst wordt.

Daarop is uitgevonden om categorieën hiërarchisch te maken. En daar maak ik bijvoorbeeld op boeklog ook gebruik van. De categorie met boeken over politiek, valt daar, net als de boeken over economie, onder de moedercategorie ‘maatschappij’.

Nog weer later wordt bedacht dat weblogjes handig van trefwoorden zijn te voorzien; de zogeheten ‘tags’. Ook dit werkt goed, zolang het aantal tags beperkt blijft, en daar enige structuur in blijft. Het systeem werkt bijvoorbeeld al niet als meer dan éen iemand een weblog bijhoudt, en iedereen zijn eigen tags verzint.

Op boeklog zijn alleen de schrijversnamen ‘tags’, wat het mogelijk maakt om eenvoudig een alfabetische lijst met opgenomen auteurs te genereren.

Alleen wilde ik mijn boeklogjes ook kunnen ‘taggen’ met andere trefwoorden dan de schrijversnaam alleen. En daartoe heb ik me moeten verdiepen in de mogelijkheden die WordPress verder biedt tot ‘taxonomy’.

Op zich is de inzet daarvan niet heel moeilijk. Al geldt die eenvoud vooral het gemak waarmee metadata aan postje is toe te voegen. Punt is alleen dat, anders dan bij het gebruik van categorieën of tags, je alle code zelf moet schrijven om de opgeslagen informatie weer elegant uit de database te kunnen peuren. Standaard zijn er vrijwel geen functies vastgelegd.

Dus houd ik het voorlopig simpel. Boeklog krijgt nu ook een twintigtal dossiers, waarin boeklogjes zijn opgenomen die tezamen, over langere tijd, een onderwerp uitdiepen.

Al zijn er daarnaast nu al dossiers bij die niets meer doen dan zaken bij elkaar harken die bij elkaar horen.

Kan ik daarnaast later alsnog besluiten om alle boeklogjes op Dewey-code te ontsluiten. Of op uitgever, of op jaartal.

Niet dat iemand daar behoefte aan heeft. Maar het kan. En ik weet nu hoe. En dat is mooi.

Taxonomieën en ander gedoe | 2

Op verzoek wat uitleg over het gebruik van eigengemaakte taxonomieën in WordPress.

Standaard zijn er twee methoden ontstaan om metadata aan een post toe te voegen op een weblog, naast de gebruikelijk ordening op datum, dus zo ook met WordPress. Zo’n tekst kan bij een categorie worden ingedeeld, of gelabeld worden met trefwoorden, de zogeheten ‘tags’.

Dit werkt op zich best, behalve als een weblog ouder wordt, en groter, en dan blijkt dat er weinig systeem zit in de gebruikte trefwoorden; zodat het voor bezoekers bijvoorbeeld moeilijk wordt om te zien of een bepaalde tag ooit gebruikt is.

WordPress heeft sinds een paar versies van de software terug daarom het hele metadata-systeem omgegooid. Het is nu vrij eenvoudig mogelijk naast de bestaande reeksen aan categorieën en trefwoorden daar nog éen of meer naast te zetten. Een probleem is wel dat deze mogelijkheden nog vrij slecht gedocumenteerd zijn.

Het enige wat er nodig is om de extra metadata over een tekst in de database te kunnen zetten, is het toevoegen van enkele regels code, aan de functions.php die het theme gebruikt — dat is de set aan sjablonen die WordPress gebruikt voor het uiterlijk van de website.

De functie die ik op boeklog gebruik, ziet er zo uit:
add_action( 'init', 'create_my_taxonomies', 0 );
 
function create_my_taxonomies() {
register_taxonomy( 'dossier', 'post', array( 'hierarchical' => false, 'label' => 'Dossier', 'query_var' => true, 'rewrite' => true ) );
}
Daarbij verdient de register_taxonomy regel misschien enige toelichting:
register_taxonomy( 'dossier', 'post', array( 'hierarchical' => false, 'label' => 'Dossier', 'query_var' => true, 'rewrite' => true ) );
Hierbij is in het eerste woord ‘dossier’ de naam vastgelegd die in de URL gebruikt gaat worden, omdat ‘rewrite’=> true. De aanduiding ‘label’ => ‘Dossier’ legt dan weer vast hoe het extra veld in de backoffice heet, en het scherm om deze nieuwe reeks aan trefwoorden te beheren.

Want, met dat ‘dossier’ heb ik een extra stel tags toegevoegd aan de website. Dat wordt vastgelegd door de parameter: array( ‘hierarchical’ => false

Was de parameter: array( ‘hierarchical’ => true, dan had ik een nieuwe serie categorieën aangemaakt, die onafhankelijk functioneren van de bestaande categorieën.

Het is met dezelfde techniek heel eenvoudig om nieuwe reeksen aan metadata te te voegen. Stel ik zou boeklog ook per recensie willen bijhouden wie een boek heeft uitgegeven, om later met die data te kunnen spelen, dan vraagt dat slechts een regel code extra, in de functions.php
add_action( 'init', 'create_my_taxonomies', 0 );
 
function create_my_taxonomies() {
register_taxonomy( 'dossier', 'post', array( 'hierarchical' => false, 'label' => 'Dossier', 'query_var' => true, 'rewrite' => true ) );
register_taxonomy( 'uitgever', 'post', array( 'hierarchical' => false, 'label' => 'Uitgever', 'query_var' => true, 'rewrite' => true ) );
}

Maar, hoe al die metadata dan weer uit de database gepeuterd kan worden, is ingewikkelder. Ook al vanwege het gebrek aan documentatie.

[wordt daarom vervolgd]

Fatal error

Het gebruik van computertechnologie dwingt een mens tot een overgave aan schijnbaar hogere machten. Wat de ene dag nog perfect werkt, kan het volgende moment onherstelbaar kapot lijken.

Heb ik daarbij nog de fout gemaakt ook om mijn eigen code te willen kloppen. Juist omdat de scripts van anderen nooit precies de mogelijkheden boden die ik zocht, of een veel te zware belasting op de server legden.

Punt daarbij is dat ik al heel blij ben zo ongeveer te snappen welke elementen een script moet bevatten. De belangrijkste delen van de code zijn vervolgens wel bij elkaar te goochelen. Dit is het internettijdperk. Vergelijkbare problemen zijn door anderen al lang eens naar tevredenheid opgelost.

Maar gisteravond, of misschien al eerder, ik kijk niet alle dagen, hield de gesorteerde pagina met alle boektitels van boeklog er ineens mee op. Een luizige 71 bytes kon niet meer worden weggeschreven naar een cache, die het een volgende bezoeker mogelijk moet maken om dezelfde informatie zonder inspanning voorgeschoteld te krijgen.

Geen van de standaardoplossingen die Google, of de WordPress fora voorstelden, brachten soelaas.

Een grove hack uit de php-bibliotheek werkte wel. Als de algemene instellingen van de server niet toestaan dat een script wordt uitgevoerd, dan is zo’n script apart te voorzien van een uitzonderingsbepaling, waarin meer geheugenruimte wordt geëist.
ini_set('memory_limit', '96M');
En zo, uiteindelijk, kostte het me tien minuten om een oplossing te vinden voor een probleem dat onverwacht opdook; op een moment dat ik betere dingen te doen had.

En opnieuw werd mijn kennis uitgebreid door pure noodzaak. Zoals ik al te veel kennis opdeed over computertechnologie omdat het nodig bleek een probleem op te lossen.

Wie almaar struikelt, komt natuurlijk ook vooruit.

Notitie aan zelf

Geen moeite meer doen om queries voor taxonomieën uit te puzzelen. In WordPress 3.1 verandert dat allemaal.

Taxonomieën en ander gedoe | 3

Een weblog ontsluiten met ‘tags’ of trefwoorden is een leuk idee, maar werkt niet vreselijk goed op lange termijn; als er nogal wat postjes zijn.

Nu ja, op boeklog staan er ruim twaalfhonderd schrijversnamen getagd. En daar is ook een overzichtspagina van. Dus het kan wel. In uitzonderingsgevallen; als de trefwoorden een duidelijk gezamenlijk thema hebben. Maar anders wordt de ontsluiting met metadata al gauw een onoverzichtelijke bende. Die juist niet doet wat zou moeten; de rijke inhoud van de website inzichtelijker maken.

Zowel op eamelje.net als op boeklog werk ik nu met dossiers vol verwante postjes. Hoeveel dossiers dat gaan worden, is me nog niet duidelijk. Maar ik denk dat het met een honderd per site wel moet ophouden. Ook al omdat het anders een toer wordt om te onthouden of een nieuwe tekst ook in een dossier past, als ik die online zet.

Boeklog maakt voor zijn dossiers gebruik van de extra mogelijkheden die WordPress sinds versie 2.3/2.8 biedt aan taxonomie12. Punt blijft alleen dat de documentatie te wensen overlaat over welke standaardfuncties daarbij aan te roepen zijn. Wat dan weer lastig is, als ‘dossiers’ wel op dezelfde manier moeten werken als ‘tags’ — er moet simpel een alfabetisch geordende lijst van zijn — maar er heel andere code nodig is voor hetzelfde effect.

Gelukkig is er in WordPress 3.0 standaard de functie get_terms beschikbaar gekomen, die vergelijkbaar is met get_tags, en zo al twintig regels aan zelfgeklopte code vervangt.

Maar dan nog werkt get_terms niet zo als get_tags. Zo kostte het me erg veel moeite om de URL goed te krijgen, die bij een dossier hoort. Omdat boeklog al ‘tags’ gebruikt, die verwijzen naar ‘auteur’, kreeg een ‘dossier’ ineens ook het woord ‘auteur’ in de verwijzende link; wat niet goed werkte.

Dat heb ik nog niet anders kunnen oplossen dan door een deel van de URL hard in de code te zetten. Een doodzonde voor de ware programmeur. En lelijk bovendien. Maar voorlopig wel effectief.

1. zie ook hier [↩]
2. en hier [↩]

Taxonomieën en ander gedoe | 4

Merkwaardige fout in het vernieuwde dossieroverzicht op boeklog. Nog niet gepubliceerde boeklogjes tellen mee, bij het genoemde aantal; achter een dossiernaam. Terwijl die boeklogjes natuurlijk vervolgens niet getoond worden.

Bij de index met auteursnamen, die ook aantallen toont, gebeurt dit niet.
 

Dezelfde functie om de database uit te lezen wordt gebruikt.

Beheerbalkjes en ander klein onderhoud

De afgelopen jaren heb ik vooral aandacht besteed aan de technische kant van mijn weblogs. Allereerst om te voorkomen dat ze weer gehackt konden worden. Maar ook om het aantal gebruikte plug-ins te verminderen; omdat plug-ins zo’n nare afhankelijkheid opleveren. De makers daarvan houden er doorgaans zo maar mee op. Terwijl de software zich wel verder ontwikkeld waarop zo’n plug-in een aanvulling is.

En goed, dan ben ik ook maar een geïnformeerde leek, dus gaat er genoeg langs me heen. Zo blijkt telkens weer dat een oplossing waar ik met hand code voor had geklopt in een nieuwe versie van WordPress ineens een standaardfunctie is geworden.

Gisteravond lukte het me daarom in een minuut om de voorpagina van eamelje.net met nog weer minder database-queries aan te roepen. Niemand die daar verder iets van merken zal. Mij maakte het eventjes gelukkig.

Technisch is de boel nu zo op orde dat ik weer mee kan doen aan wat de echte nerds zo leuk vinden: testversies van software draaien, om daar de fouten uit te vissen. Zelfs al keek ik alleen maar of al mijn zelfgeklopte code ook in versie 3.1 van WordPress foutloos werkt.

Introduceert die nieuwe versie van de CMS-software ineens wel iets extra’s waar ik niet op te wachten zat. Ineens verschijnt er een beheerbalk, boven aan ieder scherm.

Gelukkig hebben anderen al de code gevonden om dat gedoe uit te schakelen. Voeg aan de functions.php van het theme toe:
add_filter( 'show_admin_bar', '__return_false' );

Zo’n dag

Zo’n dag waarop je ontdekt dat er al een week geen automatische backups binnenkomen van je weblogs, op het daarvoor speciaal aangemaakte GMail-adres. Waarop je ook ontdekt dat deze storing kan samenhangen met het bijwerken van WordPress naar versie 3.0.5., op 7 februari. Waarop je de internetten binnenstebuiten keert om te zien of anderen hetzelfde probleem hebben. En speurt of er andere en betere oplossingen bestaan om automatisch backups te maken. Om die dan te testen.

Om vervolgens te zien dat alle automatisch backups van de afgelopen week wel gewoon ontvangen waren. Maar dat GMail ze in een spambak had gegooid.
 

Notitie aan zelf: altijd eerst in de spambakken kijken.

Taxonomieën en ander gedoe | 6

Op mijn beide weblogs komt onderaan een logje een lijst met verwante logjes te staan — zo die er zijn.

Boeklog kijkt daarbij naar wat ik nog meer heb geschreven over de auteur, of de in het boeklogje genoemde schrijver. En in principe kan de lijst met verwante logjes eindeloos lang worden. De opsomming onderaan Machines en emoties houdt momenteel het record. Dat boeklogje gaat dan ook over drie veel door mij gelezen schrijvers.

Eamelje.net labelt logjes slechts als ze in een dossier passen. En in principe kan zo’n dossier oneindig groot worden. Maar omdat op eamelje.net de titels van de postjes niet altijd alles zeggen — anders dan de boektitels op boeklog — hebben oneindig lange lijsten met verwijzingen onderaan een logje hier niet veel nut.

Dus volsta ik met links naar de tien laatste bijdragen aan het dossier. Of de dossiers.

Inmiddels ben ik op boeklog ook begonnen om dossiers aan te maken. Om goede redenen. En toen heb ik uitgezocht of die twee taxonomieën — schrijversnaam en dossier — te mengen waren in het lijstje met verwante titels.

Daar moest ik zo veel commando’s voor wrochten dat ik nooit verder kwam dan het onderzoek in een testomgeving. Twee heel verschillende tabellen uit de database moesten dan worden samengevoegd, en dat kon het inladen van een simpel boeklogje zo maar ineens tot een heel zware klus maken voor de server.

Daarop heb ik enkele categorieën aan boeken opgeheven, en tot dossier gemaakt. Dat was al een verwatering van het ideaal om me in de dossiers tot het beste te beperken. Maar dit loste het probleem op dat een categorie als ‘humor’ nergens bij paste.

Er is niet te zeggen of een humoristisch boek onder fictie of non-fictie valt — terwijl dat wel een overweging was die de hiërarchische structuur van de categorieën aan me opdrong.

Dus kent boeklog nu ook enkel dik gevulde dossiers, zoals ‘humor’, zoals dat met de ‘Nobelprijswinnaars’, en werk dat eerder verscheen in de ‘New Yorker’.

Ondertussen is WordPress bijgewerkt tot versie 3.1, waarmee het ineens wel heel simpel mogelijk is geworden om samengestelde database queries te schrijven. Dus kan ik auteursnaam en dossier wel verwerken in de lijst verwante titels.

Behalve dan dat er nu dus onhandig grote dossiers bestaan.

En zo blijft het pielen.

Pri pra privacy

Als het om software gaat, heb ik een grote voorkeur voor programmatuur waarvan iedereen de broncode kan inzien. Die is veiliger. Omdat iedereen naar de fouten kan speuren; en zulke testen dus niet slechts gedaan worden door het stelletje programmeurs dat toevallig in dienst is van éen bedrijf.

En open source software zal vaak niets, of heel weinig kosten. Want, wat allen tezamen groot hebben gemaakt daar mag niet slechts éen iemand flink aan verdienen.

Lang geleden al weer koos ik WordPress als CMS voor mijn weblogs; en dat was toeval; want vrijwel niemand deed dit nog. Maar het gebruiksgemak had iets. En dat vonden en de jaren daarop meer mensen, waardoor WordPress zich flink ontwikkelde, en ook een goede naam kreeg1. Waarop de oorspronkelijke initiatiefnemers die naam dan weer ten gelde maakten in zakelijke projecten — wat iedereen hen gunde.

Al hebben indertijd wel degelijk ontwikkelaars de rug naar WordPress gekeerd, vanwege onethisch handelen door Matt Mullenweg; de jongen met wie alles begon.

En Mullenweg is weer niet prettig bezig. Tenminste, daar lijkt het nu op.

Eén van de zakelijke diensten die Mullenweg begon is WordPress.com; een platform waarop iedereen gratis een weblog kan beginnen; of zijn of haar weblog tegen betaling kan laten hosten. En die schaalgrootte alleen al had nut. Pas door WordPress.com werd er een effectieve oplossing gevonden tegen commentspam; want daar had ineens een partij een zakelijk belang bij.

WordPress.com maakt ook een eigen statistiekenprogramma, dat dan weer gratis te gebruiken is voor iedereen die wat voor versie van WordPress ook benut.

En in die statistieken-service blijkt ineens spyware te zijn verborgen. Code van de firma Quantserve, die extra cookies plaatste op de computers van bezoekers.

Nog verneukeratiever: die spyware wordt alleen geladen op de computers van niet ingelogde bezoekers. Ikzelf krijg die cookies niet bezorgd. Enfin. Gratis bestaat niet. Zelfs niet online. Zelfs niet met open source software dat bewijst zich maar weer eens.

Maar dit zijn dan zaken waar niemand het over heeft. Die blijkbaar kunnen. En waar Matt Mullenweg zich wel heel makkelijk van afmaakte:

1. behalve dan om de veiligheid, paradoxaal genoeg. Maar dat is een straf die bij populariteit hoort: het loont om aan te vallen waar veel van is. [↩]

Pri pra privacy | ii

Er is een oplossing om én de spyware van Quantserve uit te schakelen, én de WordPress.com Stats plugin te blijven gebruiken. Via weer een andere plugin, die tracking door derden belemmert.

Zelf een website beheren, is een voortdurende wapenwedloop.

Dat was ik al wat gewend.

Eerst was er de overlast van de commentspam, toen begonnen hackers sites aan te vallen die met WordPress werken, om zo stiekem porno en andere rotzooi bij een ander onder te brengen. Maar nu keert WordPress zich stiekem tegen de eigen gebruikers.

Zelfs al stellen ze zelf dat er niets aan de hand is.

Your WordPress.com account, is not authorized to view the stats of this blog

Klaagde ik vorige week nog over de spyware die WordPress.com in zijn statistiekenprogramma stopt, vandaag werkt die software ineens helemaal niet meer. Niet alleen bij mij overigens. Velen klagen. En WordPress.com zegt niets.

Niet dat dit me heel veel uitmaakt. Statistieken zijn me vooral handig om te zien waar mensen nieuwsgierig naar zijn; hoe ze op mijn websites komen. De andere mogelijkhedenvan de pakketten doen er niet toe. ‘Return on investment’ is een angst van heel andere mensen

En populair worden toch altijd andere postjes dan je hoopt.

Google Analytics werkt overigens altijd nog. En heeft ook nog steeds dezelfde privacy-bezwaren.

Uit Duitsland bereikten me wel ineens verhalen over Piwik. De toezichthouders daar hebben namelijk zo veel bezwaren tegen Google Analytics, dat ze daar het gebruik van deze software door Duitse bedrijven willen verbieden. Alleen zullen die dan klagen geen goed alternatief te hebben. Dus wordt ineens het open source product Piwik gepromoot [pdf], dat alleen al het voordeel heeft dat het op de eigen server draaien kan.

Mal gucken.

Gehackattack

Het is weer eens zo ver. Er wordt telkens op boeklog ingebroken, door snoodaards. Die overigens weinig meer doen dan wat scriptjes plaatsen, zonder deze al in werking te stellen.

Maar omdat mijn RSS-feed niet goed meer werkte, en ik onderzocht waarom, ontdekte ik het bestaan van de duistere bestanden als sitemap.php en wp-sitemap.php.

Erger vind ik evenwel dat de inbrekers zo veel mogelijkheden hebben, dat ze ook de datum kunnen veranderen waarop zo’n bestand op de server lijkt te zijn geplaatst. En zo’n wp-sitemap.php valt dan ineens niet op tussen alle andere wp-***.php-bestanden.

Enfin, iedereen die WordPress draait kan ik aanraden om de Exploit Scanner te installeren. Die is weliswaar te kritisch, en vindt ook vele bestanden verdacht die wel deugen. Maar files met geheimtaal, zoals in de illustratie hierboven, worden foutloos gesignaleerd.

Al stond er ook ineens een afluisterbestand op de server, ergens diepweg verstopt, tussen de standaardbestanden van het TinyMCE-pakket dat ik niet eens gebruik.

Om zulke zaken te vinden, is shell-access nodig. Standaardcommando daarbij:
find . -type f -mtime -3 | grep -v "/Maildir/" | grep -v "/logs/"
Waarbij die 3 voor het aantal dagen staat dat in de logs moet worden gekeken.

Maar na hackpogingen blijft het simpeler om alles te deleten, en veilig vanuit een back-up opnieuw op de server te zetten.

WordPress 3.2

Aantekening voor het technisch handboek. Eamelje.net vandaag probleemloos overgezet naar WordPress 3.2.

Boeklog werkte minder mee. Om de overstap te kunnen maken moest de sidebar.php herschreven worden. Waar de fout precies zat, is me niet duidelijk. Maar dat uitzoeken, is ook weer zo wat.

WordPress 3.2 iii

Gelieve, om het lettertype te veranderen in de backoffice van WordPress, de volgende code toe te voegen aan de functions.php van het actieve theme:

add_action( 'admin_head-post.php', 'devpress_fix_html_editor_font' );
add_action( 'admin_head-post-new.php', 'devpress_fix_html_editor_font' );
function devpress_fix_html_editor_font() { ?>
<style type="text/css">#editorcontainer #content, #wp_mce_fullscreen { font-family: Verdana, tahoma, Arial, "Times New Roman", "Bitstream Charter", Times, serif; }</style>
< ?php }

via

Linkdump

Creating custom taxonomies in WordPress.

Onder vuur | aflevering zoveel

Boeklog werd gehackt op dinsdagmiddag, om even voor tweeën. Een half uur later had ik alles achter de website opnieuw geïnstalleerd, en moest de overlast verdwenen zijn.

Ervaring maakt handig.

De illusie dat een website zich beschermen kan tegen hackers heb ik niet. Zelfs de domeinhost met al zijn professionals trof onlangs indringers in zijn eigenste databases aan. Daarom lijkt me het beste maar om kennis te hebben van hoe de gevolgen zo gauw mogelijk verholpen kunnen worden.

Ondertussen is het afwachten tot de golf van aanvallen overdrijft. Zaterdag werd boeklog ook al gehackt. Toch staat alles er volgens de testen potdicht.

WordPress hack prevention

Nuttige links.