Okay, dan hebt ge dus zo’n website draaien met Drupal, zonder noemenswaardige problemen.
Om de zoveel tijd een update, dat gaat allemaal relatief pijnloos, iedereen content, iedereen tevreden.
En dan ineens: de kalender werkt niet meer. Hoe, de kalender werkt niet meer? Eén van de kalenders werkt niet meer, blijkbaar.
Naar http://website.domein/admin/structure/views, klik op “edit” naast de view die het probleem geeft: ERROR 500 INTERNAL SERVER ERROR UW WEBSITE IS NAAR DE KLOTEN MBWAHAHAHAHA.
Bon, error logs van de server nagekeken:
[Mon Sep 24 17:39:13 2012] [warn] [client 1.2.3.4] mod_fcgid: stderr: PHP Fatal error: Call to a member function summary_title() on a non-object in /home/website.domein/sites/all/modules/views/plugins/views_plugin_display.inc on line 1192, referer: http://website.domein/admin/structure/views
Gaan kijken in de code, wat staat daar?
$row_summary = empty($row_plugin[’title’]) ? t(‘Missing style plugin’) : $row_plugin_instance->summary_title();
$row_title = empty($row_plugin[’title’]) ? t(‘Missing style plugin’) : $row_plugin_instance->plugin_title();
Euh ja. Uitcommentariëren, zien wat dat geeft? Ha kijk, ik kan op de pagina waar die view geëditeerd kan worden. Dikke rode foutboodschappen bovenaan:
Notice: Undefined variable: row_title in views_plugin_display->options_summary() (regel 1198 van /home/website.domein/sites/all/modules/views/plugins/views_plugin_display.inc).
Notice: Undefined variable: row_summary in views_plugin_display->options_summary() (regel 1199 van /home/website.domein/sites/all/modules/views/plugins/views_plugin_display.inc).
I’m so happy. En wat ik ook doe, er is geen manier om het op te lossen: onder het kopte “format” blijft bij “display” een waarde van “Broken Field |” staan.
Zoeken op het internet: honderden websites die dezelfde foutboodschap geven, dus het komt wel meer voor. En nergens een duidelijke uitleg wat of hoe.
Tot ik toevallig op deze terechtkom: Calendar Block View Broken. Precies de symptomen die ik heb, hierrrrr brandt de lamp, denk ik dus.
En inderdaad. Na een paar mensen die zeggen dat ze het probleem weg krijgen door hun view te verwijderen en een nieuwe aan te maken, sluit Karen Stevenson het ticket en schrijft ze lakoniek:
I had to create some new calendar components that work better than the old ones did and it resulted in deprecating some old ones. Creating a new view will make everything work.
What the actual fucking fuck? Sinds wanneer worden er stilzwijgend zonder ook maar een vermelding in de release notes dingen kapot gemaakt?
Bon okay, ik sleur mezelf dan maar weer in “kak, wéér van dat”-modus en ik maak een nieuwe kalenderview aan.
Die mij prompt een leeg scherm geeft. Géén mogelijkheid om wat dan ook te doen. Hm. Misschien eens die nieuwe view deleten en nog eens alle refreshen en herbeginnen?
Ah, péch. Dikke rode letters:
Notice: Undefined property: view::$export_type in ctools_export_ui->access() (regel 128 van /home/webste.domein/all/modules/ctools/plugins/export_ui/ctools_export_ui.class.php).
U heeft niet voldoende toegangsrechten voor deze pagina.
De mengeling van Nederlands en Engels is altijd een beetje lachen, maar bon. Een probleem met Chaos Tools? Ja, manifest wel, maar wat? Niemand heeft een idee: niet hier, niet hier, niet hier, niet nergens.
Fuck, dus. Trekt uw plan, dus. Bakt u een ei, dus.
En zo gaat dat maar door. Hier iets veranderen is daar iets kapot maken, en omgekeerd. Om dit probleem op te lossen heb ik moeten zitten prutsen in een database, server logs moeten bekijken en stukken code in de kalendermodule moeten veranderen, alleen maar om een diagnose te stellen.
De site waar het over gaat, zou eigenlijk moeten kunnen onderhouden worden door mensen die nog net met Office kunnen werken. Ik kan die mensen toegang geven tot veel zaken, maar van zodra het om Views of andere zaken gaat, kunnen het ze met één verkeerde knop compleet kapot maken.
Drupal is vele keren beter dan veel andere dingen, maar zeg nu eens ernstig: wie wordt verondersteld zo’n net iets meer complexe site te administreren? Zonder tegelijk kennis van Drupal, php, jquery, html, css, (my)sql en godweetwatnog, is dat toch onmogelijk?
Een uur later is het oorspronkelijke probleem helemaal opgelost, maar heb ik ondertussen gemerkt dat die kalendermodule nóg dingen veranderd heeft. Gratuit. In de gegenereerde html. Waardoor er overal nog dingen mogen veranderd worden in de css, en god weet wat daar dan de gevolgen van zullen zijn elders.
Zucht.
Ik heb soms de indruk dat elke keer als Drupal een béétje krediet opgebouwd heeft, ze erin slagen om een stunt uit te halen zoals die “oh ja, ’t is kapot, ja”-boodschap over de kalender, en dan is het voor mij weer allemaal naar de kloten.
Reacties
10 reacties op “For fuck’s sake, Drupal!”
Één woord: WordPress! Zei de advocaat van de duivel.
Veel meer foolproof en laten we eerlijk zijn, met de juiste plugins heeft dat toch ondertussen al grosso modo dezelfde mogelijkheden. Ik heb er al meerdere verenigingen een plezier mee gedaan 🙂
In de overgrote meerderheid van de gevallen ja, maar dan blijft er nog altijd een kleine minderheid over, waar robuuste taxonomieën nodig zijn, meer granulaire gebruikersrechten, en ingewikkelder kalender-dinges.
WordPress heeft een enorme stap vooruit gezet toen er min of meer proper content types konden aangemaakt worden, maar toch.
Drupalmiserie oplossen is niet voor niets de core business van Acquia. Ik vind Drupal een mooi voorbeeld van hoe open source-idealisme stopt waar customer support en SLA’s beginnen.
En soms krijg ik het gevoel dat er een en ander expres gedaan wordt: die documentatie, dat is toch om bij te bleiten?
Geloof me vrij. Daar wordt écht niet om gedaan. Het ding groeit & verandert zo hard dat het nauwelijks bij te houden is. De meeste developers zijn ook niet de mensen die meteen hun eigen code zouden documenteren. Nochtans wordt er wel werk van gemaakt om mensen te sensibiliseren.
Het lijkt er gewoon soms op. En ja, ik zie ook elk jaar in de roadmaps en de presentaties en de intention statements en watnog passeren dat ze dit jaar, echt waar dit jaar werk gaan maken van documentatie.
Maar het is gewoon bijna ondoenbaar: al die verschillende versies door elkaar, en 90% van de mensen die ermee werken zijn ontwikkelaars die geen enkele nood hebben aan documentatie, en van wie wel documentatie nodig heeft, is twee derden op zoek naar informatie over “wat is er veranderd sinds vorige keer”… bleh.
Mja, het wil nu wel lukken dat je daar extreem vieze dingen te zien krijgt die je niet zou mogen zien.
We doen ons best om er echt wel het beste van te maken. De Calendar module wordt op dit moment door 88.000+ sites actief gebruikt en de meeste developers proberen er écht wel voor te zorgen dat hun modules bij upgrades niet breken. Karen is daar geen uitzondering op.
Nu, ik kan mij niet voorstellen dat de Calendar module “zomaar” kapot gaat. Out of the blue. Dan moet dat toch wel bij een upgrade gebeurd zijn.
Ik neem aan dat je dan eerst de zaak hebt uitgeprobeerd op een lokale versie vooraleer je de upgrade ook op de productie versie uitvoert? Of je nu met WordPress, Drupal of een ander systeem werkt: bij een upgrade ga je toch eerst even testen? Of niet?
Overigens: je hebt waarschijnlijk een view die met de calendar module en code meekomt en wordt geïmporteerd proberen aanpassen en daarna verwijderen. De view leeft nog altijd in code en zat waarschijnlijk half gecached in je Drupal. Anders zou CTools zo geen fout geven. Misschien volstond het gewoon om je Drupal cache te legen? Zodra je code begint te veranderen of aanpassen van veel gebruikte contrib modules, zit het probleem meestal eerder in jouw specifiek project dan in de module zelve.
Soit, neemt niet weg dat je weer eens een slechte ervaring hebt gehad met het ding. Echt wel jammer…
Normaal gezien test ik dat allemaal, maar niet als er in de release notes niets echt noemenswaardig staat.
En neen, ik had geen dingen geprutst in de modules zelf of onorthodoxe dingen gedaan. Alle respect voor KarenS, maar zoals ze zelf zegt: “ah ja, juist, ik heb het kapotgemaakt, ge moet al uw views verwijderen en opnieuw maken”.
En ja, cache was geleegd, het gaf in eerste instantie geen problemen, en ik ben niet de enige, neen.
Dat van CTools is nog iets anders: om de één of andere reden (ik had noch tijd noch zin om te zoeken wat of waarom) kon ik de view enkel verwijderen als ik als administrator ingelogd was. Niet als een user die alle rechten van de superuser-of-hoe-heet-het-ook had, maar als user 0, de eerste user.
(Die 88.000, da’s natuurlijk ook relatief: de versie van mei 2012 wordt maar door 24.000 mensen gebruikt, en ik zie nog wel eens graag hoeveel procent daarvan ook maar iéts aangepast heeft. :))
Zeer herkenbaar allemaal … ook bij WordPress al tegengekomen (incompatibele plugins, verouderde of ontbrekende doc, geen of slechte support…)
Maken we dagelijks mee bij een van de grotere organisaties van het land. Reactie van ict’ers gewoonlijk beperkt tot “er is een ticket aangemaakt” maar dan in ’t frenglish. En dan moet ik naar hier komen om te weten wat dàt betekent. En is mijn probleem nog steeds niet opgelost. Je bent dus niet alleen, Michel. Dat zou een troost zijn als het niet zo triestig was.