What is sitebuilding - for me!
At this point, I don't so much want to write down a definition of terms, but rather tell you what I consider to be important and unimportant parts of the process. Everyone may define this differently for themselves and that's perfectly fine, because every site builder has a different stack of skills at their disposal or sets their priorities differently. So what I'm going to describe here is my personal approach, which I've used to successfully implement many projects so far.
So let's get started: As a site builder, with the right content management system, I can build complex website structures and, in the best case, I don't need any technical background about the system itself, the server or other third-party technologies used. So you use this system with all its possibilities as it exists at a certain point in time (that of the project implementation).
To make this clearer, you can compare it to buying a car: I configure the car for myself with all its engine options and equipment features offered by the dealer. But I don't pick up a tool and tinker with the engine, the exhaust or the windshield wiper system because they wipe at the wrong intervals. If the car manufacturer had done a good job, I could easily adjust the interval to my needs via the on-board computer.
Understanding the individual configuration options doesn't require much additional understanding when buying a car. It's different with a CMS. As of February 2023, there are a total of 49,723 additional modules on drupal.org that extend the core functionality of Drupal . Of these, 9,394 can be used for the latest Drupal version 9 and 3,912 modules have already been ported to the latest Drupal version 10. That's a lot of modules that you need to know and be able to use. In order to find the right one, you have to do a lot of research and read countless tutorials. However, I will go into this in more detail later.
One point that is just as important as it is problematic is that you also have to say "no" sometimes. To do this, it is important to work with the customer to outline a way in which the goal can be adjusted so that everyone is happy with it. Ideally, the new goal is even better than the previous one. At such moments, everyone involved is forced to think outside the box and break their own thought patterns. But of course, this can also mean that the collaboration cannot be continued. However, this has not happened to me yet. Drupal simply offers too many alternative ways to achieve a goal or to define a new, different goal.
A basic knowledge of PHP is an advantage
It also helps a lot to learn a few basics in PHP. This will definitely not solve complex problems and that is not the real reason. Sometimes, as a site builder, you reach a point where you need external help. This is usually the case when a module you are using has a bug or you want to ask the maintainer for a specific feature. Then it helps if you can roughly describe the technical requirements or have already found the point in the code that leads to an error.
With the replacement of PHP by Twig in the frontend template system in Drupal 8, you don't need to have in-depth knowledge of this nowadays. This brings me to the next point: the frontend or website theming.
Website theming
For me, being able to implement the layout of a website as a site builder is an essential part of the process. An off-the-shelf layout is simply out of the question for me. As I have a graphic design background, creating the website layout is part of my sitebuilder stack. In practice, this simplifies a lot of coordination processes, as I can think about the functionality of the website at the same time as creating the layout.
The implementation of the layout, i.e. the theming, is therefore the only point in the process where I have to deal with code in the form of HTML, CSS and Javascript.
So to summarize, with the exception of theming and Twig templating, I work almost exclusively with Drupal's user interface. And that brings us to what sitebuilding is not for me: code!
So how much do I have to do with the code?
Ideally, I have nothing to do with code. Likewise, I don't care about the technical aspects in the first step. What counts for me is that the system works and that the developers have done a good job. I don't need (and don't want) to know HOW the system is structured technically, but I do need to know WHAT I can do with it.
I would also like to add a few words about the hurdles mentioned. With the introduction of Drupal 8, a lot has unfortunately turned negative for Sitebuilder. And quite a few of us threw in the towel or stuck with Drupal 7. We were forced to deal with technologies that we had never had anything to do with before and lacked a basic technical understanding of how they worked. As a site builder, you suddenly needed a development environment. I can remember that it took me over 6 months to establish a system to work with Drupal 8 in a reasonably sensible way. A few thousand files in Drupal 7, which could be easily moved back and forth using an FTP client, became tens of thousands of files under Drupal 8. This is no longer possible using the FTP client and requires a completely different way of working.
These hurdles still exist today and represent an almost unsolvable problem for any site builder who wants to look at Drupal.
But once you have fought your way through, you will be rewarded with an impressive system!
From the idea to the finished website
I don't want to go into the basic steps of project implementation in detail here, as they work identically in many projects. I'll just pick out the site-building-relevant special paths that can differ.
It becomes particularly exciting when customer requirements cannot be implemented or cannot be implemented as desired. This can be the case, for example, if a corresponding module is not available or is available with a different range of functions. As a result, many a project is on the brink of failure or cannot actually be implemented. However, the knowledge about this must already exist in the offer phase, because as a site builder I cannot program the missing component myself. In such a case, having to commission external programming during implementation usually exceeds the time and financial framework. I therefore need to know very precisely in the quotation phase whether and how I can implement an order. And that leads directly to a central component in the work of a site builder: research, research, research!
How the research leads to the goal
As described above, the Drupal world is huge. It is therefore important to know very well how to access relevant information. Everyone has their own approach here. For me, it has proven useful to translate the requirement into various keywords and questions. You can be creative, because the big challenge here is often to think like a developer. After all, modules are programmed by developers and placed on drupal.org. That's why the description of the modules is sometimes very technical or written with a different vocabulary than you would expect as a site builder. Not to mention the naming of the modules.
My first port of call is not the module overview on drupal.org, but Google. Here I have the opportunity to find results that reproduce the module descriptions in different words than the module maintainer. This increases the chance of finding what you are looking for more quickly.
Basically, you should keep in mind that someone has almost always wanted to solve the same or a very similar requirement and has written about it. You just have to find it. It is also always worth reading results that seem to only touch on your own topic in passing. Because it is precisely here that suggestions and ideas are hidden that you have not yet thought of yourself. You also get lots of new ideas for future projects.
Sitebuilding in everyday agency life at arocom
After many years of being a lone wolf and building up my sitebuilding stack, the process of transferring this knowledge into the day-to-day work of a Drupal agency is very exciting.
It quickly became clear that developers and sitebuilders can learn a lot from each other. The open working culture that prevails at arocom makes it easy for everyone to get involved in new things.
I was quickly able to add a few new skills to my pure site-building stack. On the other hand, the developers benefit from new ideas on how to solve tasks without custom code.
It's nice to see how quickly both sides want to learn and benefit from each other. A classic win-win situation.
Conclusion
Life as a site builder is very exciting and varied. The widespread opinion that you just click around a bit is by no means true here. To be successful and have fun in the long term, it is of course important to put together your very own stack of skills and professionalize yourself.
With Drupal, you have a great system at hand to master almost any challenge.
