Drupal, maybe we should just be friends

Recent­ly I fin­ished read­ing a book and went to put the book in my blog. I don’t have the book report writ­ten but want­ed to at least get a place­hold­er in the data­base with the vital sta­tis­tics: title, author, word count, my rat­ing, and so on. After enter­ing the infor­ma­tion, I hit sub­mit and was greet­ed with the less-than-use­ful mes­sage, The web­site encoun­tered an unex­pect­ed error. Please try again later.

Frankly, this sort of thing is the rea­son I don’t write. I used to joke that main­tain­ing a blog was more work than writ­ing it. The joke has stopped being funny.

At this writ­ing, Mono­chro­mat­ic Out­look is run­ning on Dru­pal. Dru­pal is a pow­er­ful pub­lish­ing plat­form that I’ve praised high­ly in the past and which I’m like­ly to praise again. I’ve set up Dru­pal sites for clients, used it for many of my own projects, worked on con­tributed mod­ules, and for a while tried my hand at being a mod­ule maintainer/developer.

Why Drupal?

As a devel­op­er, Dru­pal is very attrac­tive. There is a lot of pow­er that Dru­pal pro­vides. Dru­pal’s Con­tent Cre­ation Kit, now part of Core, was the essen­tial rea­son I adopt­ed Dru­pal as a plat­form. Though at its heart Mono­chro­mat­ic Out­look is just a blog, I’ve enjoyed the abil­i­ty to cre­ate con­tent types which con­tain com­mon ele­ment which can be sliced and diced. I’ve tracked my run­ning with a con­tent type which con­tains the length and dura­tion of the day’s run, what shoes I wore, and the map of the run. My vocab entries have sep­a­rate fields for the def­i­n­i­tion and my com­ments about it.

There’s great poten­tial util­i­ty in this. I ought to be able to search for books I’ve read by author, add up the num­ber of pages I’ve read in a giv­en year, or dis­play the title of the book I’m cur­rent­ly read­ing.¹ Per­haps I’ve been work­ing with com­put­ers for too long, but I’ve become a bit of a suck­er for meta­da­ta.

With com­plex­i­ty comes… complexity.

After a long peri­od of antic­i­pa­tion, Dru­pal 8 has been released. Frankly, I’d been dread­ing the release for some time, as new Dru­pal ver­sions tend not to play well with oth­er ver­sions. Dru­pal has nev­er sup­port­ed mod­ules from old­er ver­sions. Mak­ing the tran­si­tion from Dru­pal 5 to Dru­pal 6 was­n’t fun, and nei­ther was the upgrade from ver­sion 6 to ver­sion 7. Unless a site uses no con­tributed mod­ules, an upgrade has to be very care­ful­ly planned and researched. The best way to do it requires a team of coders and enough time allo­cat­ed for the task to rewrite each mod­ule the site uses.

The draw­backs asso­ci­at­ed with back­ward com­pat­i­bil­i­ty are of course numer­ous; the deci­sion to define whole-num­ber ver­sions as the thresh­old beyond which old code will break isn’t nec­es­sar­i­ly wrong.

The eternal dilemma: upgrade, migrate, or deteriorate?

The big ques­tion seems to be: is it eas­i­er to upgrade an exist­ing site to Dru­pal 8, or just build every fea­ture from scratch?

This is not a prob­lem unique to Dru­pal, of course. With many soft­ware pack­ages you have the pro­mot­ers hyp­ing all the great fea­tures, and some­times the ones that are most appeal­ing are the ones that are actu­al­ly still in devel­op­ment. «Well,» one might think, «the fea­ture is already there, and maybe it will work well enough.»

Eigh­teen months down the line when some­thing goes wrong and it is nec­es­sary to get some answers about the pack­age in ques­tion, we may find that there’s no help. The pack­age might be aban­doned or replaced by a sim­i­lar but incom­pat­i­ble pack­age. Or a per­fect­ly good mod­ule might have been replaced in core when you’re try­ing to do an upgrade, with no path to get con­tent from the per­fect­ly good (but unavail­able in the new revi­sion) old mod­ule to the the also per­fect­ly good and standard

Dru­pal’s strength is its exten­si­bil­i­ty. If you don’t use con­tributed mod­ules Dru­pal is spec­tac­u­lar­ly unsuit­ed to any pur­pose. Using it for a blog? Fine but if you want to upload images, some­thing like Word­Press² or Ghost³ will do it with seem­ing­ly mag­i­cal ease out of the box. With Dru­pal, pre­pare to spend the next week tweak­ing and patch­ing and debug­ging to get a solu­tion that comes halfway to the effec­tive­ness of one of those ded­i­cat­ed blog­ging platforms.

Complexity as the enemy of content creation

Anoth­er exam­ple: there oth­er CMSes have tags and cat­e­gories built in, Dru­pal has tax­on­o­my. Tax­on­o­my is much more pow­er­ful and allows you to build all sorts of things includ­ing tags and cat­e­gories. You’re still going to have to build those tag­ging and cat­e­go­ry fea­tures. That means think­ing about the under­ly­ing log­ic of what makes a tag and what makes a cat­e­go­ry, and now you’re on your way to being a devel­op­er. There’s noth­ing wrong with being a devel­op­er, but at some point in the past you want­ed to actu­al­ly put con­tent on your site, right?

Well, I want­ed to. I still want to. I’m tired of frakking around with soft­ware to make it do the stuff I want it to do.

Dru­pal 8 is the best ver­sion of Dru­pal so far. The team made some excel­lent choic­es about the tech­nolo­gies used in the tem­plat­ing. It’s tempt­ing to think that an upgrade to Dru­pal 8 would fix every­thing. Of course it would­n’t but it might well make it eas­i­er and more pleas­ant to fix every­thing. Unfor­tu­nate­ly so much of Dru­pal 7 has no migra­tion path to Dru­pal 8 that Mono­chro­mat­ic Out­look’s instal­la­tion sim­ply can’t be migrat­ed to Dru­pal 8. It would like­ly be eas­i­er to migrate to some CMS oth­er than Dru­pal 8.

Not real­ly. Mono­chro­mat­ic Out­look can’t be migrat­ed to any oth­er plat­form eas­i­ly with­out drop­ping some of the cus­tom con­tent. The maps on the posts of my runs would have to be rebuilt from scratch, the book reviews would lose the author names and titles of the books with­out some care­ful work, and the vocab­u­lary posts would lose their structure.

I like hav­ing struc­tured con­tent. In some ways, it’s the easy part. I keep the list of books I’ve read — with word counts, ISBN num­bers, start dates and com­ple­tion dates, and so on — in a Post­greSQL data­base on my lap­top. It’s a sim­ple schema. There are four tables: one for the gen­er­al book data, one for the authors, one for pub­lish­ers, and a pure­ly rela­tion­al table link­ing the authors with the books in a many-to-many relationship.

Did I say that was sim­ple? Well, it’s real­ly not as com­plex as it might have sound­ed. You cer­tain­ly don’t need Post­greSQL to do it. Heck, you don’t need to do it at all. I’m the one who wants to keep track of the books he’s read in nice, nor­mal­ized tables.

But this is my point: when I gave up on mak­ing my con­tent man­age­ment sys­tem store the infor­ma­tion I want­ed and start­ed writ­ing data­base queries, that was (or should have been) a sign that Dru­pal isn’t work­ing for me.

The appeal of Dru­pal for these past ten years has been that it’s a plat­form I could do every­thing with. But it isn’t liv­ing up to that. Maybe it’s time to stop try­ing to keep every­thing in one place and either build tools or use the tools oth­er peo­ple have built which have spe­cif­ic pur­pos­es, which do just one thing and do that thing well. There are sites that will track my runs for me. I even use them to trans­fer the track maps from the phone so I can put them on this site. Except I don’t post them here because that fix­ing that fea­ture would take work and I already seem to have plen­ty to do.

I don’t like using web­sites I don’t run myself. That’s the rea­son I moved Mono­chro­mat­ic Out­look off of Live­Jour­nal. The IndieWeb folks and the Home­brew Web­site Club have it right. Always own your own data. Always con­trol your own content.

Before Mono­chro­mat­ic Out­look was on Live­Jour­nal, I wrote my own con­tent man­age­ment sys­tem to merge con­tent with page tem­plates.⁴ Mov­ing to some­thing that was already built and worked right made the dif­fer­ence between writ­ing once or twice a year and writ­ing once or twice a day.

There are ways to con­trol one’s own con­tent while let­ting the con­tent man­age­ment part get out of the way. After ten years I think that it’s clear that Dru­pal isn’t that for me. I still think Dru­pal is a good plat­form; I have Dru­pal run­ning on oth­er project sites. If you don’t have an exist­ing Dru­pal 7 or ear­li­er site Dru­pal 8 is a great option for a wide vari­ety of projects. The White House Web­site runs Dru­pal⁵. Dru­pal will still be a part of my web pub­lish­ing portfolio.

But frankly Dru­pal, I think it’s time I start­ed see­ing oth­er CMSs. You’re just too high maintenance.