Kicking down doors: My Drupal Journey from Site builder to Developer
Don’t let yours take as long as mine.
I don’t like boxes. When I am in one, all I can do is look for ways to get out.
I have been in a lot of them: web designer, interaction designer, user-experience designer, production manager.
Never programmer, developer, or coder. Even as a kid, that was my brother’s world. He was the one locked in his room playing computer games with his friends. When he was gone I would sneak in and try to guess his passwords so I could play, too.
Eventually I began working on computers, first as a sound designer for multimedia on CD-ROM. When the Web took over, I wanted it to be as rich and interactive as the projects I had been working on, but it still had a long way to catch up.
It was the early days of the Web and I was working at a cool design shop making websites for Hollywood and the music industry trying to force engaging experiences through dial-up modems. I could bring a page to life with HTML and an animated image, but if I wanted something more I had to go running to the developers.
I loved having a new storytelling medium to experiment with and still love finding ways to add logic and interaction to bring content to life, but I still felt like a little brother sneaking around.
Not only did they code in languages I didn’t understand, but they seemed to speak a different language. If I could at least learn how to talk to them I could get better at asking them for help.
[This is the point where I would tell my younger self to find a class, book, or workshop. Pick a starting point and dive in for six weeks. Kick down the door!]
As a web designer I worked with HTML. Developers wrote PHP. Most of it looked the same, but with variables where the content should go, a function to connect to a database, and bits of logic to affect how it is all rendered.
I began to pick up a trick here and there, but instead of making it easier to talk to developers I just became more aware of how much I didn’t know. I would bang away for hours on my own instead of asking for help on the simplest things. I was learning, but very slowly and with no guidance.
Eventually I built a rudimentary content management system. I even had a couple of clients using it to manage their sites, but it was only a work-in-progress, and my list of things that needed fixing was always growing. I didn’t have the time or knowledge to deal with it. Once again I had made myself aware of how much I didn’t know.
Fortunately I didn’t have to. Open source communities were busy building much more robust systems and offering them for free!
Looking back, I see that this was the end of my PHP experiments for a very long time. I remember feeling relieved that I didn’t have to pretend to be a programmer any longer. There were others doing it and making it available to all. Many even came with themes so I didn’t even need to be a designer. I climbed into my sitebuilder box and shut the door.
[This is the next big fork in the road. I had just spent months thinking about and learning to put a CMS together from scratch. Instead of kicking down the door and contributing to one of projects, I ran for cover.]
The Drupal Ecosystem
The promise of every CMS is to allow a user to configure a site and manage content without touching any code. In Drupal terms this is a sitebuilder, one of several points of entry into the Drupal ecosystem. Drupal exists for this user. Drupal also exists to be infinitely customizable, so as soon as this user finds their way around the basics, they will want to start adding features.
As a site builder, when you have an idea and begin searching around you will find a wide range of suggestions. The one you are hoping for is, “Oh, there is a module for that.” Maybe it is a core module and all you have to do is turn it on. Or, it might be a contributed module that needs to be downloaded and installed. This leads us to the another door that needs kicking down because adding modules, although getting better, is still not as easy as it should be.
Who is behind that door
In my experience, Drupal is like a series of rooms. Each one unlocks a part of Drupal’s potential, and each one has its own language and rituals. As you kick down doors and poke your head into the next room you may encounter others who are unaware or unconcerned with any room but their own. It will make you want to run for the cover of your own familiar room, but you must resist. Drupal requires all of these rooms, and the best solutions are aware of all the rooms and involve all that are necessary.
How many rooms are there? I don’t know. It’s just a simile, don’t get hung up on it! All I know is that each time I enter one, there are a lot more doors leading to a lot more rooms. Everyone’s path will be different. Here is a very brief description of mine.
- I worked for a university on a very small team rebuilding Drupal sites using a theme developed by the IT department. They only allowed a very limited set of contributed modules to be installed, and the page templates were very static. Kicking down the door to the core Views module changed all that. Views turns you into a powerful database administrator, or at least helps you write complex queries and relate bits of content with one another.
- Now I had some dynamic pages, but I needed to update the templates. Time to kick down another door and learn to create a custom child theme. Now I could modify and add new Twig templates, which opened up a lot of possibilities to control how the pages were displayed. I ended up creating overrides for nearly every template in the theme. I probably should have just started from scratch, but there were also custom modules and functions in the .theme file that I didn’t understand and was afraid to touch.
- It took me a while to kick down that next door. This was not all bad news, though. I think I became really creative at solving problems in the templates and site configuration. In fact, I also began to notice that some developers were writing custom code to accomplish things that are easily done with site configuration using the administrator user interface. It turns out that many who begin their Drupal journey as PHP programmers never even poke their heads into the sitebuilder room! Honestly, this felt empowering. They had as much to learn from me as I from them!
- I left the university and started working for an agency doing the same kind of work but times ten. This has accelerated the kicking of doors by providing a library of past projects to review, colleagues to brainstorm with, and a steady stream project work. My tool box now includes custom modules, migration plugins, and pre-process functions. I still feel like a visitor in these rooms, but I am learning to speak the language feeling more welcome all the time.
Put on your boots
I hope your journey is quicker than mine. Maybe that is why I want to share this story. I spent far too long staring at the door thinking, “This is not for me, I am not a developer.” Take as long as you need, but don’t let that be the thing that stops you.
The Drupal community is very aware of the difficulty of getting started. They also know that as a user gains more experience their approval rating of Drupal goes up exponentially. My story is rather typical of Drupal users, but we don’t often discuss those first giant hurdles we had to get over.
That is why I am telling this story and why my goal is to keep it going with a series that goes into more detail about each of the doors I encountered and the basics of how you can kick it down. I’ll begin with a big one: setting up a local development environment. My palms are sweating just thinking about it.
I hope you will find this encouraging, but the truth is I need to hear it as much as you. I have many more doors to kick down. The one that I am staring at right now is contribution. The thing I love most about Drupal is that it is open-source, and the thing that makes that work is the strong community of contributors. So let’s get busy kicking down those doors and I will see you on the other side!
