‘t Is toch wel wat: dan zit ik een website te maken met Drupal en lukt alles zo ongeveer zoals het zou moeten lukken. Hoera, leve vanalles, ‘t is een groot gemak, iedereen is content, en ik heb de indruk dat het mensen zijn die op dezelfde manier denken als ik die al die dingen gemaakt hebben.
En dan kom ik op een ding terecht waaruit (misschien) blijkt dat ik er, ahem, eigenlijk niets van snap.
Gegeven een organisatie die in allerlei geledingen nieuws en kalenderinfo en verslagen produceert, wil ik ergens een plaats waar alle kalenderinfo bij elkaar te vinden is. En dan bij de verschillende geledingen van die organisatie telkens menu-itempjes nieuws, kalender, verslagen, en daarin alleen wat van die ene geleding is.
Simpel, dacht ik zo.
- Ik maak een content type kalenderinfo aan, en een content type artikel (verslagen hebbben dezelfde velden als nieuws, ze komen gewoon ergens anders te staan).
- Ik maak mijn informatie over de organisatie aan in gewone basispagina’s, die ik in een structuur giet door ze een menu-entry te geven.
- Ik maak een kalenderview aan en zet dat ergens in het hoofdmenu bovenaan: dat geeft proper wat het moet doen
Enfin, ja, ik zeg: dat doet proper wat het moet doen, maar er zat toch nog wat fiedelen met Menu Blocks en met een nieuw menu bij.
Wegens dat een kalenderitem zelf geen menu-item heeft, en dat het dus wat zooien was om links toch iets degelijks te krijgen als ik een individueel kalenderitem aan het bekijken ben.
Ah, maar wacht eens, dacht ik dan plots: er is toch zoiets als de Context-module? Daarmee kan ik gewoon zeggen “ALS nodetype = artikel en taxonomie = categorie:HR>verslagen DAN toon menublok hoofdmenu (levels 2+) in de eerste zijbalk en zet menu active class op home > HR > verslagen”. Juist? Juist?
Ah ha ha. Niet juist, dus.
Het ding weigert onder alle omstandigheden dat ene menublok te tonen (okay, toegegeven, het is een menu block en geen ingebouwd Drupal-menu, maar dat zou niet mogen uitmaken), én het ding weigert onder alle omstandigheden te beseffen dat hij op een pagina zit met een bepaalde taxonomieterm (toon blok X op alle artikelpagina’s, dat doet hij, maar toon het op alles met taxonomieterm Y, doet hij niet).
En het ergste van de zaak? Zoals altijd, bij Drupal, is het mij compleet onduidelijk of ik ergens iets niet begrijp, dan wel of er ergens een bug in één van de modules zit die ik nodig heb.
Al die modules bevinden zich in verschillende stadia van development / beta / release candidate, en ze hebben allemaal, van de eerste tot de laatste, één ding gemeen (naast de onvermijdelijke bugs): de documentatie trekt op geen ouwe slets.
Als er al documentatie is, is het een amalgaam van documentatie voor verschillende versies door elkaar, met verschillende UI’s en functionaliteiten. En wordt er meer gesproken over “in vergelijking met versie 6.x-1.7.x-dev is er dit lichtjes anders” dan dat er concrete, reproduceerbare voorbeelden gegeven worden.
Maar goed, het zou mij dus niet zou verbazen dat het mijn eigen schuld is en dat ik het niet snap. Ik ben geen specialist, ik kijk maar om het jaar of zo eens naar Drupal tot ik in een situatie als deze zit, met iets dat zou moeten werken maar het niet doet.
En dan geef ik het meestal na lang prutsen en zoeken gedegouteerd op.
(Maar deze keer dus niet, het moet gewoon werken.)
Reacties
5 reacties op “Hoepels”
Ouch! Erm. Mja, kga maar zedelijk zwijgen over het beest dat Context eigenlijk is. :p Drupal ontbreekt nog altijd zelf een propere Context API. ‘t Is iets waar ik redelijk hard voor ijver want ik loop er zelf ook tegen aan bij wijlen.
Op het gevaar of je uitleg volledig verkeerd te hebben begrepen:
* Page view voor bv. /kalender/geleiding aanmaken die de term id als argument aanneemt en doorgeeft aan de query
* Met http://drupal.org/project/menu_token spelen om automatisch URL’s te genereren genre /kalender/geleiding/[term-id] of zo?
Top of my head idee eigenlijk.
Ja, frustrerende bezigheid.
Normaal gezien zou een page view waarop de lijst van verslagen van HR staat, die term id(s) gemakkelijk moeten kunnen doorgeven:
– in contextual filters voor de page view “categorie” toevoegen
– Configure contextual filter: when the filter value is not in the URL: provide default value. Type = taxonomy term ID from URL (als er geen term id meegegeven is, haal hem dan uit node id)
…maar dat doet dus niets.
En dan loop ik tegen mijn onkennis aan: geen flauw idee hoe ik die term zou moeten meegeven in de url (een naieve print str_replace(‘”>’,’#bleh”>’,$output); in views-view-field–archive–hr-news–title.tpl.php maakt properkes URLs aan met “#bleh” erachter, maar verdomme Context kan geen actie ondernemen op alles met een URL “*#bleh”).
Gnyaarh.
Die #bleh is een anker. Dat gaat dus niet doen.
Om een argument te laten werken moet je dit doen: stel dat je URL /bleh/grunt/123 is, dan is 123 je argument. Drupal splitst dat pad op in drie delen met elk een positie beginnende bij 0. 123 is dus een argument op positie 2.
De opties die je ziet zoals “node id from URL of “taxonomy term id from URL” zijn bedriegelijk. Die activeren stukjes logica om een argument op te halen ervan uitgaande dat je URL een structuur heeft zoals /node/1234 of /term/1234. Als dat toevallig iets anders is, zullen die opties niet meer werken.
Je zou met de PHP code optie is kunnen doen zoals:
return arg(2);
Maar laten we eerlijk zijn PHP code in je database is vies, vies, vies.
Wat je nog kan doen is eens kijken naar Panels en CTools. Die zijn van dezelfde maker van Views. Met de page manager kan je via de interface wel bepalen welk deel van de url als argument moet wroden doorgegeven… Maar ook hier een waarschuwing: milde frustratie zal uw deel zijn want het Panels/CTools oerwoud is bijlange na niet zonder meer toegankelijk.
Die menu items active zetten met context werkt enkel als je uw menu print via uw (jaha), althans in Drupal 6. Ik vermoed dat er niets veranderd is.
Met context menu block kan je de brug van context naar menu block maken. http://drupal.org/project/context_menu_block
Voor D6 was er ook http://drupal.org/project/menutrails.
* Printen via de theme dus.