This post is the expansion of a tongue-in-cheek IRC conversation I had the other day. I thought it’d be fun to blog about it because, while it’s mostly just humorous, it actually does cover some of the issues Web Developers encounter while developing in Drupal (or in many other platforms). So, walk with me if you will, into the year 2020 and how your Drupal project might unfold then…
*space-agey whooshing sound*
You’ve just aced your interview with the client – or, well, people still call them interviews, but thought transmission technology has made the process much quicker. Send them all your project-related memories (content filters will protect your private memories, of course!), let them evaluate them, and they tell you if they want to continue or not. You’ve saved hundreds on lunch meetings since this technology became generally available and affordable for business (you can pick up the device for around 150 ameros).
So you begin. Using Drush, you download and install vanilla Drupal 10. It prompts you for all the settings you’d normally have to supply in an install window, including your database credentials. You input them, it populates settings.php for you, and away you go. For your theme, you choose the Nuclear Fusion starter theme (guess which one it’s based on) and create your mcii child theme…by clicking “Create child theme” in the Nuclear Fusion UI. They’ve made it so easy! You’re going to do the theming later, so this is enough for you for now. You grab Root Candy to make administration a bit easier, and, after a moment of consideration, issue drush dl administration_tools – you sure are happy that drupal.org implemented the concept of “module bundles” back in the Drupal 9 era around 2018. With that one command, you can get Admin role, Administration menu, and other goodies to make administration easier. You install Features, as well. You smile as you see the familiar gray (F) indicator appear on Administration menu. It’s gray, of course, since you don’t have any features, but you know it will turn red once you have some and override any settings (or green if you’re all good).
4D video is big on the client’s list, so you grab the Media module right away. For the video player, you know the built-in browser video players are good enough these days. In anticipation, though, you sigh and add an ie16.css file – you just know you’ll have to make some tweaks. Anyway, the Media module makes this pretty easy, and in a short while, you’ve got the sample 4D video playing. Great! Oh, wait…what’s that message at the top of the video page?
Notice: Undefined property: item on line 317 in media.module
Notice: Undefined property: vid on line 1515 inmedia.module
Notice: Undefined variable: i on line 181 in includes/media.4dvideo.inc
Whoops! Looks like the developer didn’t have E_NOTICE turned on. No worries – you’re used to this. You quickly create an issue over on Media, check out the issue’s repository (sure is great they still have those after the great disk space scare of 2017, eh?), fix the errors (as well as a few more you encounter while testing), and ask the maintainer to pull your changes. You know you’ll be waiting for a bit, so you also merge your changes into your copy of the Media module – added automatically as a git submodule for you by Drush, of course.
The worst part seems to be behind you, so now you just need to add some Views (yay for #DC10X) to display the videos and a couple fields to your Video bundle to store some additional information. You also download the Video Reference module to get that special field type, and then you run into the issue that is the bane of every Drupal Developer in 2020: the video_reference module doesn’t fully support PHP 7.3 yet.
Sighing, you feel like this project just got a whole lot longer…