Als ik een website maak op basis van WordPress probeer ik zoveel mogelijk binnen de grenzen van het platform te blijven. Soms kan dat niet en is het nodig dat ik mijn toevlucht zoek tot een hack.

Menu-editor
De ingebouwde menu-editor van WordPress 3.0 is een grote vooruitgang ten opzichte van eerdere versies. Toen zat er namelijk geen menubuilder in de WP core en was je altijd aangewezen op plugins of wazige zelf geknutselde oplossingen. Toch heeft de menu-editor van WordPress 3.0 een paar flinke tekortkomingen. Zo zijn de ID’s die aan de menu-items worden toegekend nogal onhandig. WordPress gebruikt hiervoor het database-id van het menu-item. Aaargh!

Mijn koninkrijk voor een logisch ID
Mijn koninkrijk voor een logisch ID! Met een hack van één van de bestanden in de include directory is het wel mogelijk om de items in het WordPress menu een wat logischer ID te geven. In regel 79 van nav-menu-template.php wordt het ID aan het menu-item gekoppeld. Door

$id = apply_filters( ‘nav_menu_item_id’, ‘menu-item-’. $item->ID, $item, $args );

te vervangen door iets als

$menu_item_met_een_logisch_id = strtolower(str_replace(” “,”-”,$item->attr_title));
$id = apply_filters( ‘nav_menu_item_id’, ‘mnu-’. $menu_item_met_een_logisch_id, $item, $args );

Hierin gebruik ik het title attribuut van het menu in het ID, in plaats van een lullige nummering. Dit attribuut kun je zelf toekennen in de menu-editor.

Controle over de styling
Da’s vervolgens toch wat lekkerder declareren in je stijlblad. Bijvoorbeeld:

#mnu-nieuws.current-menu-item { doe: iets; }

De combinatie van een stijlbladdeclaratie op basis van ID én class zorgt ervoor dat je volledige controle hebt over de look and feel van het actieve menu-item.

Lelijk maar acceptabel
Ugly hack? Absoluut. De core files van WordPress moet je eigenlijk met rust laten, want je loopt het risico dat jouw wijzigingen worden overschreven bij een versie-upgrade. Als tijdelijke maatregel, in de hoop dat het in de toekomst beter geregeld wordt? Acceptabel.

Gerelateerde link
WordPress codex over wp_nav_menu

Je bouwt een kekse website. Trots leun je achterover.

Midden in de nacht schrik je wakker. Wat nou als je bezoekers jouw goed geschreven artikeltjes lang niet allemaal lezen? Er staat zoveel content op je site dat mensen misschien lastig kunnen vinden wat ze zoeken.

Zoekfunctie
Je piekert en ineens weet je het: wat je nodig hebt is een zoekfunctie. Reuze handig, want bezoekers typen een trefwoord in en komen je artikelen als vanzelf tegen in de zoekresulaten. Jammer genoeg is het met de kwaliteit van de zoekresultaten niet altijd even goed gesteld, want de motor van je website wordt gevormd door WordPress. Er zijn wel plugins die de kwaliteit van de zoekresultaten wat verbeteren. Maar toch … de zoekfunctie werkt niet optimaal.

Custom Search
Online kom je een interessante Google service tegen: Custom Search Engines. Met een CSE integreer je pijlsnel een ijzersterke zoekmachine op je eigen website. De  look-and-feel van de zoekresultaten is nog redelijk te tunen ook. En de advertenties die je er extragratis bij krijgt — tenzij je een zakelijke zoekmachine afneemt? Geen probleem, daar knoop je je eigen Google Adsense publisher’s ID aan vast. Verdien je misschien ook nog een paar stuivers als er per ongeluk iemand op een Adsense-linkje klikt.

Je implementeert dus een Custom Search Engine. Je bezoekers zijn enthousiast over de goede en gebruiksvriendelijke zoekmogelijkheid op je site. Trots leun je achterover.

Nul resultaten
Midden in de nacht schrik je wakker. Een zoekfunctie is allemaal leuk en aardig, maar wat nou als er niks gevonden wordt? Nul resultaten gevonden. Misschien mis je een enorme kans voor extra content op je website, omdat je niet in de gaten had dat bezoekers op zoek waren naar “bla bla bla” maar nul op rekest kregen. Je piekert en ineens weet je het. Wat je nodig hebt is inzicht in zoekopdrachten die geen resultaat opleverden.

In het Control Panel van je CSE zie je het hoopgevende menu-item Statistics. Het valt tegen dat de achterliggende pagina nogal karig is qua info. Maar wacht, zou de link achter If you are hosting your search results on your site, you can get enhanced reporting through Google Analytics site search reporting uitkomst bieden. Je doet klik!

Site Search analytics
Hiep hiep hoera. Je hart maakt alvast een sprongetje. In Google Analytics kun je aangeven dat je interne zoekopdrachten wilt tracken. In de rapportage vind je site-zoekopdrachten terug onder het kopje Site Search. Een zee aan informatie. Maar jammer genoeg houdt Google Analytics niet bij welke zoekopdrachten geen resultaten retourneerden.

Aaargh
Wanhopen doe je niet. Op webanalisten.nl staat beschreven hoe je Google Analytics wel zover kunt krijgen. En anders kun je altijd nog een stukje javascript toevoegen om tevergeefse zoektochten in kaart te brengen.

Het duurt even voordat je doorkrijgt dat geen van deze methoden werkt in samenhang met een Custom Search Engine. Aargh!

Niet gevonden
Onderhand ben je aan het einde van je creatieve Latijn. Je weet het even niet meer en kan niet kiezen tussen twee halve oplossingen:

• een Google Custom Search Engine wegzetten. Met goede zoekresultaten, maar wellicht kansen missen
• kiezen voor een wat brakke interne zoekmachine. Met behoud van inzicht in verbeterpunten voor je website

Je hebt gezocht, maar de oplossing nog niet gevonden.

Tot voor kort besteedde ik er eigenlijk weinig aandacht aan: de manier waarop een webpagina wordt gerenderd op een mobiele telefoon. Het enige waar ik rekening mee hield waren webstandaarden.

Sinds ik zelf in het bezit ben van een goeie smartphone — HTC Desire — ben ik een stuk meer geïnteresseerd geraakt in dit onderwerp. Hey, maar dan nog, waar zou ik me druk om maken? Een eigentijdse mobiele webbrowser beschikt over een prima zoomfunctie. Een webpagina die volgens webstandaards is gecodeerd kun je prima bekijken.

Dat kan zijn. Maar daarmee stel ik me niet tevreden. Ik wil meer. Ik wil een snelle website die ook zonder inzoomen leesbaar is op een relatief klein scherm. Met andere woorden, ik wil een echt mobiele versie van mijn website, niet alleen een miniatuurversie.

Snel klaar. Toch?
Da’s toch appeltje · eitje? Ik bedoel, how hard can it be? Plaatjes eruit slopen. Floats weg. Geen in pixels gedefinieerde breedtes.

Onderschat
Da’s te kort door de bocht. Met andere woorden, het is een schromelijk onderschatte kunst: het knutselen van een stijlblad voor mobiele apparaten. Nogmaals, het lijkt zo eenvoudig, gewoon eventjes een css-bestandje maken voor smartphones en gadgets als  de iPad, het resultaat van je ‘niet zo noeste arbeid’ linken in de html-code van je site en klaar is Kees:

<link rel=”stylesheet” href=”/pad/naar/het/stijlblad” type=”text/css” media=”handheld” />

Helaas – hoe kon het ook anders – zo simpel zit het web-leven niet in elkaar. Ik beperk me tot smartphones, maar dan nog, er zijn nogal wat verschillende mobiele telefoons op de markt. Elk met hun eigen operating system  — Windows Mobile, iOS, Android — om er een paar te noemen. Over de webbrowsers die je op deze telefoons tegenkomt zal ik maar zwijgen.

Mijn punt: je hebt bijzonder weinig zicht op de manier waarop webpagina’s gerenderd worden op een mobieltje. Opera Mini is een toonbeeld van hoe webstandaards geïmplementeerd kunnen worden, maar verder … ben je aan de goden overgeleverd.

Media query
Op A List Apart staat een bijzonder informatieve tekst over web voor mobile: Return of the Mobile Stylesheet. Hierin wordt bevestigd dat mobile browsers nogal eigenzinnig omgaan met een ‘handheld’ stijlblad. Da’s goed om te weten als webbouwer. Je weet dan in elk geval dat het niet persé aan jouw code ligt.

Jammer genoeg biedt de in het artikel genoemde ontsnappingsroute, het gebruik van media queries in de stijlbladdeclaratie, ook niet echt uitkomst. Tenminste niet cross-platform. Ik heb hiermee getest op turboslak.nl en loop tegen problemen aan met de Android browser op mijn HTC. Die snapt de media="only screen and (max-device width: 480px)" stuff blijkbaar niet. De dombo.

Sad but true
Het is best triest, maar het enige wat op het moment van schrijven vrij aardig lijkt te werken is een serverside browser detectiescript. Je kijkt in de code naar de user agent die de pagina opvraagt en op basis daarvan biedt je een stijlblad aan. Op Detect Mobile Browser download je een stukje code dat de user agent uitfiltert.

Ik ben toe aan nieuwe hardware. De HP Pavilion DV 8625 laptop waarop ik dit stukje zit te typen heeft de pensioengerechtigde leeftijd bereikt. Dat vind ik tenminste. Of de boekhouder — lees Mrs Nullbeta — er ook zo over denkt valt nog te betwijfelen. Sluw als een vos kies ik voor de tactiek van de geleidelijke introductie — in de week leggen en langzaam laten wennen aan het idee. Die strategie kost tijd, maar daarmee moet het lukken om de budgethouder over de streep te krijgen.

Eén van de redenen dat ik in 2008 voor de relatief goedkope DV6825 koos was om hem al na twee jaar te kunnen afschrijven. In technisch opzicht is-ie trouwens nog niet aan het eind van zijn latijn. Behalve een rotte batterij en dito adapter heeft het HP machien weinig last van ouderdomskwalen en er valt nog aardig op te werken.

Sinds ik in het bezit ben van een iMac komt de laptop niet meer zo vaak in actie. Desondanks, als webwerker wil ik toch graag een appetijtelijk stuk mobiel ijzer tot mijn beschikking hebben. De hoogste tijd om me te oriënteren op de aanschaf. Maar da’s gemakkelijker gezegd dan gedaan. Ik heb nogal wat wensen.

Geen Windows
Op mijn nieuwe laptop hoeft eigenlijk geen Windows te draaien, tenminste niet als standaard operating system. Als ik Windows nodig heb, dan start ik wel een VMWare Fusion sessie onder Mac OSX.

Een MacBook Pro?
Browsend door de online winkel van Apple … de 13″ MacBook Pro spreekt me wel aan. Die heeft geen al te lomp grote display — nou heb ik niks tegen een groot scherm, maar in de trein is een bescheiden formaat wel zo lekker — en is nog enigszins redelijk geprijsd ook. Voor een Mac dan, want voor 1150 euro kun je natuurlijk een bovenmaats uitgeruste laptop-pc aanschaffen.

Of een iPad?
De laatste tijd heb ik me verdiept in de mogelijkheden van de nieuwste Apple telg: de iPad. De versie met 32GB en WiFi is een gadget dat ik graag in mijn bezit zou hebben:

• handzaam als mobile device in de trein
• leuk om thuis op de bank een filmpje op te kijken
• relaxt in de tuin wat te Twitteren of rond te klikken op internet

Maar heeft de iPad voldoende in zijn mars om als laptopvervanger te dienen? Daarvan ben ik nog lang niet overtuigd. Sowieso moet ik de virtualisatiemogelijkheden van VMWare of Parallels missen — komt toch dat Windows weer om de hoek kijken — en qua productiviteitstools heeft de iPad me niet zoveel te bieden. Het apparaat heeft toch meer het imago van een fun gadget dan een onmisbaar werkgerelateerd device. Desondanks lijkt het me reuze interessant om de multitouch functionaliteit van de iPad onder de loep te nemen.

Lastig kiezen
Aaargh, moeilijk om te kiezen! Wat wordt het? Ga ik voor de functionaliteit van een Apple Macbook? Of kies ik voor de frivoliteit van een iPad? Ik ben er nog niet uit.

Gelukkig heb ik nog even tijd om alle voors en tegens tegen elkaar af te wegen. Tenslotte is de Apple iPad op het moment van schrijven nog niet in de Nederlandse winkels te koop.

Het is weekend. Ik verveel me lichtelijk en besluit tot het maken van een vectortekening. Een badge voor mijn hardloopwebsite Turboslak. Niet direct een nuttig tijdverdrijf. Wel errug leuk om te doen.

Beer burning
Het concept: ik ben ooit begonnen met hardlopen om wat overtollig gewicht te verliezen. Denk hierbij onder andere aan een fikse bierbuik — in de vorm van een onderhuids geïmplanteerde opblaaseend. Tijd voor actie. Bewegen met dat rolmopsenlijf.

Hardlopen als antidote tegen de calorietjes van het gerstenat. Bierverbranding. Da’s behoorlijk effectief moet ik zeggen.

verder lezen »