Soms leert een mens nog het meest bij van de dingen die niet meteen helemaal helder zijn. Een stom, klein, en uiteindelijk —zo bleek— eenvoudig op te lossen voorbeeld: iets dat compleet voor de hand liggend is in WordPress, het klaarzetten van een artikel om op latere datum gepubliceerd te worden, is blijkbaar niet zo voor de hand liggend in Drupal.

In WordPress ziet het er standaard zo uit:

Als ik niet direct wil publiceren, klik ik op “Bewerk” naast “Direct publiceren” en krijg ik dit:

Duw ik op “OK” of op “Publish”, ziet het er zo uit:

Dat wordt dan automagisch gepubliceerd op die dag en dat uur.

Niets van dat in Drupal. Er is per node een “created” datum (die in Drupal moet ingegeven worden in een zeer welbepaald formaat, en dan nog eens in UTC ook: “2009-06-04 07:45:00 +0200” om iets op 4 juni 2009 om 9u45 te laten “gemaakt” zijn).

…maar die “gemaakt op”-datum is dus niet de datum waarop iets zal gepubliceerd worden.

Dat concept bestaat niet in standaard Drupal, en daar moet een module voor geïnstalleerd worden.

Scheduler is de module waar zowat alles en iedereen naar verwijst. Installatie: downloaden en op juiste plaats zetten, zeggen welke gebruikers mogen schedulen, zeggen welke content types mogen gescheduled worden, en dat zou het moeten zijn.

Ik wou meteen al wat aanpassen, en ik was er al meteen mee in de problemen geraakt. Standaard install en een aanpassing van het datumformaat, dat geeft me onderaan mijn invoerformulier inderdaad twee velden:

Het formaat dat ik moet gebruiken (dag/maand/jaar uur:minuten) staat erbij, voor het gemak: “Format: 4/6/2009 3:58”. Helaas: als ik “4/6/2009 4:58” ingeef, krijg ik dit te zien:

Fantastisch. Terug naar de opties voor Scheduler, en daar de standaardwaarden terugzetten dan maar (Y-m-d H:i:s in plaats van wat ik gezet had)?

Inderdaad, dat was het.

Een manier vinden om de input een beetje gebruiksvriendelijker te laten verlopen dan met de hand in te typen? Kijk nu, er is een patch die de datumpopup en het tijdveld van de nieuwe Date erin smurft..

Installeren, en dat werkt, hoera! Geen enkele garantie dat die patch er bij de volgende release in zal zitten, en als hij er niet in zit, dat de mens die die patch heeft verzorgd, er zal voor zorgen dat hij hem opnieuw maakt voor de nieuwe release, maar bon.

Scheduler zorgt er ook voor dat de datum van het artikel zelf goed komt: nu heb ik misschien wel de publicatie laten gebeuren 4 juni 2009 om 9u45, maar standaard blijft de datum van het artikel (“created”) gewoon staan waar hij op stond. Drupal heeft geen concept van “published on date”, maar als ik de optie “Alter published on time” in Scheduler aanklik, wordt het wel relatief proper omzeild.

Oh. Juist, ja: er moet wel een cron draaien. Op mijn ontwikkeltoestel is dat niet het geval. Niet dat dat zo erg is, ik ben niet van plan machtig veel te publiceren alhier.

*
*    *

Was dit de enige optie om het aan te pakken? Nee, natuurlijk niet.

Ik heb minstens één meer complexe workflowmodule zien voorbijflitsen, maar terwijl ik dit schreef, bedacht ik dat ik ook gewoon een “publish on”-veld zou kunnen gemaakt hebben, en dat aan die content types toegevoegd hebben.

En dan een bijkomende filter bij alle mogelijk displays: published=“yes” staat er al, het zou een kwestie zijn van er “publish on<now()” bij te zetten. Of zo. Als heeft dat misschien wel andere nadelen — snelheid, misschien? Dat die nodes alsnog zouden teuggevonden worden links en rechts, nog voor ze “gepubliceerd” zouden geraken?

Ah well.

Het werkt zoals het nu werkt. Ik was er heel even wat bang voor, maar ik heb weer iets bijgeleerd.