Put your WordPress-categories back in the tagcloud

When blogging, tags and/or categories allow you to classify your posts. The taxonomy you create that way, allows searchbots (and human readers) to better understand what the post is about and to find related posts.
category cloud widget config screenshotEver since the release of WordPress 2.3 (in sept. 2007), you can specify both categories and tags for your posts. More or less following the ideas put forward by Lorelle-on-WordPress, I use categories as the main classification-method (putting posts in a hierarchical, directory-like structure) and add one-off keywords as tags. The only disadvantage: as tags are one-offs, the default tagcloud-widget in WordPress generates a dense put useless heatmap.
If you’re in the same situation, you might benefit from this little WordPress-plugin I wrote (well, …copy/pasted, actually, 80% is code straight from the original WP-tagcloud widget) to solve my tagcloud-woes. Once unzipped in your plugins-folder, “category cloud” will provide you with a widget which can not only generate a “tagcloud” or a “catcloud”, but also a “cat-and-tagcloud”. And because the default “general”-category might skew your catcloud-results or because you might prefer to have that NSFW-tag not show up, you can exclude tags and categories from being shown as well by entering their ID in the appropriate input box.

“Lifestreaming, across my universe”

Lifestreaming is where it’s at, so here I am, aggregating all my stuff (Google Reader shared items, my Youtube clips and favorites, my Facebook status and my blogposts) into one place. I tried sweetcron a couple of weeks ago, but for some reason it didn’t feel “ready” yet (or maybe I didn’t want to invest to heavily in it). I recently installed a simple WordPress plugin which seems to be doing the trick very well. Sweet indeed!
Next up; something to handle multi-language blogging a bit better, but now for something completely different (The Firm, Star Trekkin’ on Youtube);

The Firm - Star Trekkin'

WordPress 2.6 svn-upgrade; ouch!

WordPress 2.6 has been pushed out the door at Automattic and it contains some exiting new goodies as usual. So I fired up my trusty upgrade script, but got an ugly php-error when accessing the database update-pages:

Parse error: syntax error, unexpected T_SL in wp-includes/widgets.php on line 464

Turns out that the wp_widget_search-function in wp-includes/widgets.php included some remnants of an SVN-merge. Don’t know if it was a sync problem at my side or if the faulty code was on the SVN-server (it isn’t now), but I ended up copy/pasting the correct function from a fresh tar-ball I downloaded.

The WordPress-on-an-intranet nightmare

[UPDATE june 2009: this is solved in WordPress 2.8]
wp for dummies book coverHaving a fair amount of experience with WordPress installations and configuration, I wanted to install trusty old WP 2.5.1 on an idle desktop (winXP+xampp) at work to do some blogging on our intranet. The installation itself went smoothly (how hard can unpacking a zip-file be) but after some time the damn thing stopped working, producing nasty timeout-errors caused by a.o. wp-includes/update.php and wp-admin/includes/update.php.
The problem is that WordPress tries to open an internet-connection (using fsockopen) to see if updates are available. Great, except when you’re trying to run WordPress on an intranet behind a proxy without a (direct) connection to the internet. After some unsuccessful fiddling in multiple WordPress php-files, I ended up disabling fsockopen in php.ini (disable_functions)!

Disabling! Fsockopen! In php.ini! Just to have a working WP?

I mean, come on guys, why doesn’t WordPress provide configuration options where you can specify if and how (what type of proxy, what address to find it on, …) it should try to connect to the internet? I even made this truly amazing UI mock-up which you guys can just like copy/paste straight into your code;

_______________________________________________________________________________
How should WordPress connect to the internet to check for updates?
(*) Direct connection to the internet (default)
( ) Use a proxy:
    Proxy type:     (*) http ( ) socks
    Proxy URL:      ___________________________________________
    Proxy User:     ___________________________________________ (optional)
    Proxy Password: ___________________________________________ (optional)
( ) No internet connection available (WordPress won't be able
    to warn you about updates!)
________________________________________________________________________________

_
😉
Pretty please?

Verhuis je blog zonder twee keer na te denken!

Het leven op de elektronische snelweg kan zwaar zijn: Koen Fillet was bijna een volledig jaar zijn kluts kwijt omdat de Leeskamer-blog van naam én URL was veranderd. Hij sprak deze ochtend zichzelf, Jan Coucke en de wereld dan ook enigszins vermanend toe;

“Verander je ouwe vertrouwde blog niet zomaar van naam en van adres. Denk twee keer na, want je lezers ben je kwijt.”

Hij heeft gelijk natuurlijk; door een ondoordachte verhuis kun je heel wat lezers rechtstreeks (rss-volgelingen of echte trouwe bezoekers) en onrechtstreeks (zoekrobotten en bezoekers die via zoekmachines op je site komen) verliezen.
Beter twee keer nadenken dus. Of gewoon verder lezen, dat zou U ook kunnen doen. Want om mijn bloggende medemens al dat dubbel gepeins te besparen, zal ik hier de truuken van de foor opsommen, zoals ik die gebruikte bij mijn verhuis van het wordpress.com-platform naar een eigen wordpress.org-installatie.
Op je oude blog zou je volgende dingen kunnen doen:

  • je verhuis ruim op voorhand aankondigen (met url natuurlijk).
  • Van de laatste blogpost maak je natuurlijk een duidelijke doorverwijzing naar je nieuwe blog, met link en al.
  • Je zorgt er dan voor dat die laatste tekst het enige zichtbare artikel is voor wie op de homepagina komt.
  • Laat je oude blog voor de rest gerust staan, maar kleed hem wel grondig uit:
    • Exporteer alle teksten (inclusief commentaar).
    • Laat in je (populaire) posts enkel de eerste paar zinnetjes staan en link voor het vervolg door naar je nieuwe blog.
    • Verwijder commentaren en zet de commentaar-optie uit.
    • Laat zoveel mogelijk interne links direct naar je nieuwe blog verwijzen.
  • Publiceer de rss-feed van je nieuwe blog op je oude blog.

Op je nieuwe blog ga je dan bijvoorbeeld op deze manier aan de slag:

  • Importeer alle blogposts (inclusief comments) van de oude versie.
  • Pas interne links in die geïmporteerde tekstjes aan om te voorkomen dat je lezers terug naar het verleden worden gekatapulteerd.
  • Publiceer de eerste dagen gerust een artikeltje meer, zodat je lezers zich direct thuis voelen.

Vraag voor de rest aan de eigenaars van sites waar je blog vermeld wordt om dat adres aan te passen. En niet onbelangrijk voor je rss-lezers tenslotte: gebruik feedburner om je feed te publiceren. Nu, direct, weken, maanden en jaren voordat je verhuist al. Het is een fantastische gratis dienst en op het moment van de waarheid moet je dan enkel je feedburner-instellingen aanpassen en al je rss-volgelingen verhuizen mee zonder dat ze daar zelf iets voor moeten doen.
Misschien een beetje neurotisch allemaal en “your mileage may vary“, maar in mijn geval werkte dat wel goed. Regelmatige lezers verhuisden dankzij de aangepaste feedburner-feed automatisch mee. Wie m’n blog op de gewone manier bezocht, ziet op m’n uitgeklede wordpress.com-blog dat ik verhuisd ben èn direct ook links naar mijn laatste posts op mijn nieuwe stek. Zoekrobotten worden via m’n oude site op allerlei manieren doorverwezen naar m’n nieuwe onderkomen en vinden daar direct ook inhoud om te indexeren. Zolang Google nog resultaten uit de oude blog toont (en dat zal nog een tijdje zo zijn), kunnen toevallige bezoekers daar nog proper landen om daar dan naar m’n nieuwe site doorverwezen te worden.
Dat was het zo ongeveer denk ik, veel meer valt daar niet over te vertellen. Succes met je verhuis!

Ssst, hier verhuist men!

Het is hier even net iets stiller, niet alleen omdat het op het werk momenteel druk is, maar ook omdat ik op mijn eigen VPS-serverken WordPress 2.3 aan het installeren ben. Alles draait ondertussen betrekkelijk vlot, heb een paar plugins geïnstalleerd, content overpompen is een stukje taart, maar ik vind “het perfecte theme” niet. Indigo staat hoog op mijn lijstje wegens mooi minimalistisch, maar die heeft het nog even moeilijk met de wordpress widgets in de sidebar.

indigo screenshot

Eerst de rest nog wat tweaken en dan zullen maar eens in de Indigo-code (meer bepaald sidebar.php) duiken zekerst?

WordPress automagisch upgraden (nu met nog slimmer hondje)

labrador puppyDe meeste nerds/ bloggers weten het ongetwijfeld al; wordpress.org bracht eergisteren versie 2.3 van de gelijknamige open source blogsoftware uit. Wat die nieuwe versie allemaal kan, hebben anderen al beschreven, ga gerust daar even lezen indien ge op zo’n dingen kickt. Via-via kwam ik echter op een pagina van wordpress zelf waarin werd beschreven hoe ge via subversion (ofte svn) bijna automatisch kon updaten. Omdat ik wel van een potje shell-scripten hou en omdat “bijna automatisch” net niet automatisch genoeg is, heb ik WPuppy.sh bij elkaar gekliederd.
Het beestje probeert samengevat het volgende te doen:

  • het haalt van de wordpress svn de pagina waar alle versies opgelijst staan en distilleert daaruit de laatste versie
  • het vergelijkt die versie met de versie die in een config-bestandje opgeslagen zit en vraagt of ge wilt upgraden
  • het upgrade via svn en opent de update.php van uw blog in lynx, zodat wordpress de laatste aanpassingen kan doen
  • het past de versie in het config-bestandje aan

WPuppy.sh hoort vanzelfsprekend in een linux-hok met shell-access en heeft naast bash oa ook lynx en svn nodig om te kunnen spelen. Bij testen heeft WPuppy.sh oa. succesvol een upgrade van WP 2.2 naar 2.3 op mijn Debian Etch machine gedaan, maar ik kan vanzelfsprekend geen garanties geven dat het jonge beest altijd en overal even zindelijk zal zijn 😉
Wie denkt iets met mijn nieuwe speelkameraadje te kunnen doen, moet:

  • WordPress een eerste keer manueel installeren met svn (zoals beschreven op de WP-pagina over svn)
  • WPuppy.sh afhalen in mijn kennel en in een mandje op zijn/ haar linux-gebaseerde server zetten
  • in dat bestand de waarde van variabelen blogdir en blogurl aanpassen
  • in hetzelfde directory een bestand aanmaken met de naam “wp-installedversion” en daarin de huidige versie opslaan in de juiste vorm (bv. “2.2”).

Als ge dat gedaan hebt, zout ge in principe elke upgrade moeten kunnen doen door WPuppy.sh er gewoon op los te laten. Kleine hondjes zijn leuk, toch?
Update: ik heb één en ander aangepast voor eigen gemak en zielerust en WPuppy.sh maakt nu eerst een backup van database en filesysteem en deactiveert daarna ook alle WP-plugins. Fouten allerhande zouden verder iets properder moeten worden opgevangen en gemeld. Maar van de weeromstuit heeft WPuppy.sh nu natuurlijk ook mysql, mysqldump, tar en gzip nodig om te kunnen blaffen. En dat het nu nog meer dan voordien spaghetti-code is, dat spreekt voor zich toch?

Stoute wordpress upgrade maakt posts van pages?

Outro_Spective had gisteren een probleempje met zijn upgrade naar de laatste versie van WordPress op animobrugge.be; alle pages waren plots posts.


De oplossing bleek gelukkig betrekkelijk eenvoudig: posts en pages worden beiden in de ‘wp_post’ tabel bijgehouden in de wordpress database. Als je van de verdwenen pages in kwestie het ‘post_type’ van ‘post’ naar ‘page’ verandert, is alles terug in orde. Volgend sql-statement doet dat in 1 klap:

UPDATE wp_posts SET post_type = ‘page’ WHERE ID IN (x,y,z)

met in de plaats van x,y en z de id`s (het nummer na p= of page_id= parameter in de url van je posts/ pages) van de posts die terug page moeten worden

Waarmee dat Jong Links Brugs geweld terug foutloos online staat en ze zich nu terug volop met de politiek kunnen bezighouden 🙂