Originally posted at my blog www.laurarocks.fi

So, this is a rant about the day I had yesterday. Or about the weeks I had before today. Or the 3 years I’ve spent with Drupal. Don’t get me wrong, I love Drupal. Today I moved to the other side and love it again but right now, but when I started writing this I just HATED IT SO MUCH!

A have to confess that even though I’ve been doing web developing a *long* time (mainly with PHP & mysql & javascript) I don’t see myself as a real Drupal (8) developer. Maybe with Drupal 7 I still could manage relatively complex problems and projects with custom code but even then I did a lot with just site building. But now with Drupal 8 I’m still at the early stages in the learning curve and just trying to hang on. So my projects so far has mostly been about site architecture, site building, front-end stuff and so on. And so was this project supposed to be. I didn’t have the time or the budget for custom code.

Drupal for ambitious (and small)

I wrote in my earlier post about Drupal being good for ambitious project. Well you know what. We’ve always had ambition, even for the smaller client projects. We still sometimes choose Drupal for the “too small” projects if we see something that we could learn or something valuable extra that Drupal could bring to that client.

What ends up being the most important things for almost all of our clients

  • Multilingual stuff everywhere. And it has to be easy
  • Content being used differently throughout the site. Save in one place, use differently all over
  • Categorizing content
  • Permissions to edit content only tagged to specific category and/or to add content to that category.
  • Microsites
  • Media handling

Yeah, a lot of stuff. Almost all where pretty much tackled with D7, but D8… Some of these seem to be easier, like multilingual, but then when it comes to contrib modules, it can be a real hassle. Some of these are the essence of Drupal for me, like views & taxonomies. Some are hard on both, like media handling. And then the permissions and microsites. And the last one is what bit me hard this time.

I know there has to be an easier way to do these things, but what I ended up doing was basically going with one solution for 3–4 whole days in a period of three weeks and then thinking again and redoing everything in 3 hours. And that has been the story of my whole Drupal journey. Everyone who knows Drupal, knows that there is always at least ten ways of doing things. And many of us go through every alternative of those when we learn Drupal and then (maybe) choose one. Unless maybe if you are in a bigger company and someone tells you what and how you should do things (which would of course save a lot of time…). But I wouldn’t know about that, this has been the “Drupal way” for me.

Microsites with taxonomies

So I needed a super light-weight microsite solution with permissions to people to edit only their microsite and tag some other content to belong to that microsite (but appear also elsewhere). I know that there are cool modules like Groups and Organic Groups and in D7 I have used the Workbench module succesfully, but even that needed some custom code to be able to edit both content and the terms. So everything seemed like an overkill for this project. Moreover, I usually like to know a little bit more about the code of modules I use, and unfortunately I still haven’t had the time to check Groups thoroughly, it seems awesome.

The struggles I confront with microsites and permissions usually are

  • More than 1 person needs to edit the microsite (so no “own” content shortcut)
  • Someone with higher permissions needs to easily make a new microsite (from client’s side)
  • Microsites need a menu and someone needs to edit it
  • There are usually over 50 microsites in one site (so maybe not a menu per microsite)

So what is a microsite then? For our cases it usually is 3–4 nodes grouped together with their own menu. Something has to glue them together. And there my thinking started; so why not taxonomy term? Let’s reference everything with a taxonomy term and then get some permissions in. Next reaction: Oh, cool, taxonomy menu is ported (actually re-written), so basically we could get the terms to the menu without giving editors too much power? With one patch it is actually pretty multilingual, even more cool. But wait, we need permissions, and specifically edit permissions per taxonomy term. Oh, there is Taxonomy Access Control Lite (Tac Lite) already for D8, cool, that should be enough. And the journey went on, I picked few modules here and there, until I realised that getting the taxonomy term page actually to work as a main page for the microsite, getting the taxonomy term references actually working in multilingual site (also as contextual filters in views, that was a pain), working with block visibility in this scenario was just too much complicated. So, I took a step back and decided to think this over one more time.

This was the time when I realised that maybe I’ve been too ambitious from the start. And made a new, much simpler solution. Sometimes it’s just better to make it again. And again. And again.

One entity as a microsite

So here we are. All good ideas abandoned and feeling the project slipping a little bit to the wrong direction. During the site building I’ve learned a lot, mostly how complex things can get when talking about permissions, menus, multilingual, taxonomies etc.

So what did I realise? Only the fact that like in Drupal 7, you can actually do a lot with just one entity and the amazing Inline Entity Reference. What if we could make the whole microsite only one entity, make the “menu” a little fake by using for example tabs that work with Ajax and comes from jQuery UI, already in the core. We just make one small custom javascript and use the jQuery UI as a dependency in the theme’s libraries.yml file. Now that’s an idea to look into. So I started to build the entity and theme it to look like a small microsite in it self. And the other content that the same user can add, but reference only this microsite? Well, you can use inline entity reference for that!

It gets a little bit tricky when using the entity reference as a relationship in views, (see this). And I always get double content when using entity reference as relationship, but changing query settings fixes that. But besides those, even the multilingual content seems to be in place. And big hurray for entity reference being multilingual!


So, what did a learn. A lot. But mostly that you always have more than one option and usually the most simple or obvious one isn’t the one you start with.

Oh, and one other thing, it’s important. USE Twig Tweak module! Seriously. Even just for drupal_dump(). Or better yet, drupal_view() or drupal_block(). I’m twigging it!