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

Make your mockup in markup

Meagan Fisher pleit ervoor om mockup ontwerpen in markup te maken, in plaats van een grafisch programma. Want

The idea of rewarding users who choose modern browsers is not a new concept; Dan covers it thoroughly in Handcrafted CSS, and it’s been written about in the past by Aaron Gustafson and Andy Clarke on several occasions. I believe we shouldn’t have to design for the lowest common denominator (cough, IE6 users, cough); instead we should create designs that are beautiful in modern browsers, but still degrade nicely for the other guy. However, some clients just aren’t that progressive, and in that case you can always use background images for drop shadows and rounded corners, as you have in the past.

Progressive enhancement, dat snijdt hout. Maar toch is dit nou net het punt waarop ik denk dat het meestal spaak loopt. Ik ben bang dat een klant vrijwel altijd de “mooie versie” van de website wil zien. Dus ben je alsnog veroordeeld om je state-of-the-art ontwerp te verarmen met allerlei kunstgrepen.

iPhone Apps Need Low Starting Hurdles

Most mobile applications are used only intermittently, so they must be especially easy during initial use. In particular, upfront registration shouldn’t be required before users experience an app’s benefits.

Een verhaal over webobstakels van usability goeroe Jakob Nielsen. Stuff die we allemaal — allang horen te — weten. Maar nooit genoeg ingeprent kunnen krijgen.

WordPress podcast

Joost and Frederick discuss the WordPress Advanced Ticket System, plus how WordPress and WordPress MU have merged and multi-site functionality will be included in the upcoming WordPress 3.0.

Een tikkeltje nerdy, maar toch een interessante discussie over WordPress op Webmaster Radio. Zelf ben ik vooral erg benieuwd naar het in elkaar schuiven van de codebase van WordPress en WordPress MU (MultiUser).

The customer CAN handle the truth

I saw an example of this one day when I visited a house for sale that was advertised as: “Fantastic and rare opportunity to acquire this beautiful 7 bedroom detached home. This property has got it all!” As the sales agent quietly said to me, “The only thing you could do with this house is knock it down and start again.”

Altijd met humor geschreven, de stukjes van Gerry McGovern. Maar behalve dat ze licht komisch van toon zijn, valt er veel wijsheid uit te halen.

Veel plezier beleefd aan

• WordPress CMS
• jQuery javascript framework
• Mac OS X

Ernstig teleurgesteld in

• Microsoft Office Sharepoint Server
• mijn Google Adsense inkomsten

Aangenaam verrast door

• Pods WordPress plugin
• Windows 7

Vlekken in m’n nek van

• sociale netwerken in het algemeen en Hyves in het bijzonder
• slap ICT geklets over Enterprise Service Bussen, Service Oriented Architecture en OTAP straten

Uitdagingen voor 2010

• schonere code schrijven
• websites bouwen op basis van een fluid grid
• meer creatief bezig zijn, minder techno-nerdish

Na een weekend stoeien ben ik NOG LANG NIET KLAAR. Zowel inhoudelijk, functioneel als opmaaktechnisch mankeert er nog van alles aan, maar het begin is er.

Geen echt CMS
Een veelgehoord punt van kritiek op WordPress: het is geen echt content management systeem. In beginsel is WordPress een blogging platform. Het keurslijf van posts en pages maakt het al snel ontoereikend voor websites die meer functionaliteit nodig hebben. Voor je het weet loop je vast. Of ben je druk bezig WordPress te hacken. In een poging om het platform dingen te laten doen die het eigenlijk niet kan.

Die kritiek is in grote lijnen terecht, vind ik. Tenminste, zo dacht ik erover voordat ik de Pods CMS plugin ontdekte. Pods maakt het mogelijk om in WordPress je eigen content types aan te maken. Met andere woorden, je ontwerpt je eigen tabellen en plakt die tegen WordPress aan. Hierbij heb je de beschikking over alle handige datatypen die je nodig hebt: getallen, tekstvelden, datums en bolean logic.

Pods is WordPress evolved. Pods is a CMS framework for WordPress. It’s a plugin that sits on top of WordPress, allowing you to add and display your own content types.
These content types, or “pods”, are totally separate from Posts, Pages, or Custom Fields. The Pods plugin uses its own database structure for maximum efficiency, and for relationships among items.

Krachtige plugin
Pods belooft niet alleen veel, het maakt die belofte mijns inziens ook helemaal waar. Iemand op z’n mooie blauwe ogen geloven doe ik niet. Vanzelfsprekend wil ik in de praktijk zien of het werkt. Dus heb ik de afgelopen tijd wat gestoeid met Pods. Van de functionaliteit die ik tot nu toe in actie heb gezien is dit een uiterst krachtige plugin.

Relationele database
Concreet: voor mijn Turboslak hardloopblog wil ik  niet alleen over mijn hardloopervaringen schrijven. Ook wil een logboek bijhouden met gegevens van mijn loopjes. MyAsics-achtige informatie:

• afstand
• gelopen tijd in minuten
• soort training
• gemiddelde hartslag
• etc

Zuchtend had ik al een beginnetje gemaakt met het aanmaken van tabellen. Buiten WordPress. Want ik had niet het gevoel dat ik dit soort informatie op een elegante manier via WordPress kon realiseren. Wel dus. Met Pods bouw je in no-time een relationele database. Relationeel, want door middel van het PICKs datatype (da’s de Pods benaming voor een relatie — door middel van een dropdownlijst) kun je koppelen aan velden uit een andere Pods tabel. Maar ook een verbinding met de coretabellen van WordPress zelf kun je tot stand brengen. Sweeeettt!

Presentatie
Geloof me, een datamodel implementeer je reuzesnel met Pods. Maar ook aan de voorkant ben je goed voorzien van gereedschap. Voor de presentatie van informatie maak je gebruik van Pods sjablonen en pagina’s. Met Pods snelcodes pluk je de data uit de Pods-tabellen en zet je ze op het scherm. Op de manier waarop jij wilt. Want Pods hanteert een vrij behoorlijke scheiding tussen inhoud, functie en presentatie. Onaangename verrassingen met rare code in de html blijven je bespaard.

Voor de presentatie heb je bovendien zogenaamde helper-functies tot je beschikking. Dat zijn stukjes php-code die je bij het renderen van de pagina kunt gebruiken. Bijvoorbeeld voor het format van de inhoud van een datumveld.

Ter illustratie, de Pods templatecode van mijn turboslakkenoverzicht met loopjes ziet er zo uit:

<li>{@loop_datum,format_date}: <a href="/loopjes/{@loop_slug}">{@name}</a> &mdash; {@loop_afstand,format_getal_integer} km in {@loop_tijd_in_minuten,format_getal_integer} minuten</li>


Minpuntjes?
Zijn er dan geen minpunten aan Pods? Ik heb ze zo snel niet kunnen vinden? Als ik dan toch moet mierenneuken — een enkele suggestie voor verbetering kan ik wel bedenken. De integratie van Pods met de WordPress administrator’s GUI kan naar mijn mening net ietsje consistenter. Al is het alleen maar de iconset van Pods. Het is net geen WordPress.

Het gemak van een coole plugin wordt soms overschaduwd door de problemen die je tegenkomt bij de release van een nieuwe versie. In het verleden heb ik meermaals in een spagaat moeten vliegen om problemen te fixen, nadat ik geconfronteerd werd met een niet werkende website na een NextGen upgrade.

Vandaag was het de beurt aan de Shadowbox plugin om dwars te liggen. Na een upgrade van WordPress naar versie 2.8.4 en een update van m’n plugins doet de Shadowbox functionaliteit het opeens niet meer. Shadowbox versie 3.0.0.1 geeft niet thuis. Een downgrade van de plugin naar een 2+ versie werkt trouwens ook niet meer. Blijkbaar is er een afhankelijkheid met één van de andere plugins die ik gebruik. De Shadowboxcode die WordPress moet toevoegen aan de header van de pagina zie ik na het renderen van de pagina niet terug. Aargh!

Ik heb vandaag geen zin om eindeloos te gaan debuggen — alle plugins de-activeren en ze één voor één weer aanzetten totdat de boel omvalt — daar heb ik geen tijd voor. Ik kies voor een quick fix en ga buiten het WordPress CMS om.

En voilà, de Shadowbox functionaliteit  is weer terug!

Bij deze is mijn voornemen een feit geworden: het domein turboslak.nl is geregistreerd, de afgelopen week besteedde ik wat tijd aan de realisatie van de website en de site is inmiddels gevuld met een aantal hardloop-gerelateerde posts van nullbeta.net. Over duplicate content maak ik me verder eventjes niet al te druk. Dus geen nette 301′s voor de posts die vanaf nu op turboslak.nl thuishoren, maar gewoon quick and dirty kopiëren die handel.

Turboslak.nl is een door WordPress aangedreven weblog — mijn CMS of choice. De motor wordt dan wel gevormd door WordPress, aan de voorkant heb ik zo min mogelijk gebruik gemaakt van voorgekookte WP functionaliteit. In elk geval ben ik allergisch voor de thema’s van anderen en ook de look and feel van plugins zoals CF forms en Event Calendar probeer ik zoveel mogelijk te customizen. De website is dan ook niet direct meer als WP-powered website te herkennen.

Check turboslak — over de slak die ervan droomt een haas te worden

Nullbeta.net is online sinds 2001. Waar ik in het verleden veel plezier heb beleefd aan het bouwen van een eigen *** kuch *** CMS-je, had ik de laatste tijd steeds minder zin om zelf het wiel uit te (hoeven) vinden, elke keer als ik aanvullende functionaliteit nodig had. Vandaar m’n besluit om te kiezen voor een open source content management systeem in plaats van zelfbouw.

WordPress is mijn favoriete CMS. WordPress is gemakkelijk te installeren, flexibel in het gebruik, volledig te customizen en er zijn – door een levendige community van ontwikkelaars – een heleboel nuttige plugins voorhanden.

Mijn website was dan ook vrij snel overgezet. Het lastigste aan de migratie naar WordPress is eigenlijk dat de urls van de blogposts zijn veranderd. Vanzelfsprekend wil ik ervoor waken dat de oude links resulteren in een 404 – pagina niet gevonden melding. Isapi rewrite (mod rewrite voor Internet Information Server) komt dan goed van pas om de url’s te herschrijven en de zoekmachines met een 301 – Moved Permanently te laten weten dat de link gewijzigd is.

Wat rest is het handmatig overpompen van de indivuele posts naar WordPress. Da’s nog een aardig tijdrovend klusje