Three ways to curate posts in Drupal 8
Lately, I've been writing things in series. Even for what I thought would be a small post, it ends up as two or three parts just so I can get it out of the proverbial door in time. I usually try to link the content together within the body of the posts, but this can make the posts hard to find collectively.
If I wanted to share with someone the Cardboard Pi project, I would need to dig up the exact URL for the first post in the series. It's almost too long if I wanted to write it on a whiteboard or share it in slide for a presentation:
https://deninet.com/blog/2019/06/30/handheld-raspberry-pi-part-1-if-first-you-dont-succeed
While I could use a short link, this introduces a third party to the web interaction. That third party could try to use the information gathered in the redirect to advertising or tracking. Needless to say, I'd rather not introduce such a thing if I had alternatives.
So what are they? How can we curate series of posts in Drupal 8 site like mine?
The easiest method is to use tags. Users are free to create whatever tags they want for their posts on my site, and use as many tags as they like. Drupal has excellent support for tagging out of the box going back as far as I've ever used it, so I have no issues with it be deprecated or removed in the future.
Each post in the series would be assigned the same series specific tag. All the posts related to that series would then instantly get their own easily linked page:
https://deninet.com/tag/handheld-pi
This is *really* easy and short to share. As a bonus, this only requires minimal configuration on Drupal 8, plus the addition of the Pathauto module to override the default tag URL with something more human readable and shorter.
While the URL was easy to share, the user experience (UX) left a lot to be desired. On my site, the tag title didn't appear due to the title block being hidden. None of the tags were curated or had a description. Posts were shown in a list of linked titles. Technically, summaries of each post were displayed, but aren't in use on deninet. The net result was that tag pages were rather embarrassingly cryptic.
Fortunately, the tag page in Drupal 8 is a view instead of something defined by code alone. This allows us to override the page display and format it to be more pleasing. After some work last weekend, the site now displays posts as a grid using user-assigned teaser images. This grid was created using CSS grids instead of the grid view display plugin so that the markup was cleaner and responsive to smaller screen sizes.
That's better, but is it really enough?
An alternative is to leverage the tagging mechanism of Drupal, but to do so it a more deliberate fashion.
When I was building deninet 8 a few years ago, I spent a lot of time thinking about this problem. Tags excel at creating associations between posts. While easy, tags can also become a kind of dumping ground. A post may have tags like "meanderings", "daily life", "electronics"; again, all associations. Occasionally, I also created a project or series specific tag such as "handheld pi". We could keep doing that, but it effectively makes the reader do more work. Now, they need to read through a sizable list of tags in order to find the one that only corresponds to this series.
Fortunately, Drupal allows us to create multiple types of tags, or taxonomies. We can still keep tags, but we can create another taxonomy specifically for series and projects.
On deninet, I call them topics. The topic taxonomy is intended to be used for categorization of content, rather than association. Unlike tags, you may only assign one topic to a post. That topic would then be made more visible to end users by displaying them on the content thumbnail on the main page and any content lists:
Topics were originally also supposed to be hierarchical, but I ended up dropping this feature about a year into the site's operation. I've had bad experiences with hierarchical taxonomies on other Drupal projects, and they simply don't live up to their advantages given their numerous disadvantages in practice. As a result, I have topics configured using the same "auto-tagging" UI I use for tags, although you may only select (or create) a single topic term for a post.
Topics are intended to be more intentional than tags, and are required for use on each post. In retrospect, this might have also been a mistake. Making it required encourages content creators on the site -- myself included -- to treat it as an annoying tag field, rather than something to curate a series of posts. To change that, I would need to make modifications to the site theme and to the content types, as well as clean out the topics taxonomy. Drudgery, but doable.
In addition to the separate taxonomy, topics also had a different configuration for how they are displayed. Rather than just being a description and a series of posts, I also included a Paragraphs field so that additional content stripes may be displayed. This allows topic pages to be richer. Furthermore, content creators were granted the ability to edit topic pages to add these content stripes as they see fit. The goal is to encourage content creators to treat topic pages as a valuable means of curation, rather than Just Another Tag Field. Admittedly, opening topic editing to an entire user role works well for deninet as we have a small number of users and a high degree of trust between them. On a larger site, additional functionality may be necessary to ensure that tags cannot be maliciously overwritten.
But then I ran into a snag; a story idea came to me. While I could keep it all to myself during the course of writing, I've had previous experiences with that which...weren't encouraging. Instead, it would probably be more successful if I were to stick to the model with which I was most familiar, blogging. I could post each chapter as a separate post to my Patreon page, but that would also give Patreon de facto ownership over the content.
Yeah. No. I'm not doing that.
The only alternative then, would be to post it to deninet in some fashion. I could use topics, I thought, but what happens if I need to reorder posts? The topic page currently displays posts first according to if they are marked as "sticky", then by post date. This multi-method sorting may be a small detail, but it'll be important later. Even if I planned to post each chapter in a linear fashion, no doubt they'll be some situation where an older post would need to be before a newer one.
I could edit the post, use my admin powers to change the post date to get the correct sort order, but that also creates another problem. Remember the blog post URL pattern? The date is part of the URL. Changing the date could break shared links and damage SEO.
So then I thought, What if I created a new content type to curate series? It seemed like a good idea. At any point, I could create a -- let's call them a collection -- and add posts to it. Drupal's entity reference field makes this easy, since you can specify the order of items linked therein when creating or editing the collection:
I threw together the functionality an deployed it out the same day. Then, I started to regret it.
The more I thought about it, the more collections seemed to simply muddy the waters of how to curate series and projects on deninet. Weren't topics supposed to do that? And then I thought about another bit of functionality on deninet and I really started to get confused.
In addition to blog posts, deninet has one more major content type: creations. Creations have all the same fields as blog posts, but are meant to show off a completed project. This could be a game, a piece of artwork, a product of making, a story, and so on. The idea was to have blog posts for more informal content or thought-pieces, while creations would be used for most of everything else. Ideally, the Cardboard Pi, the toolbox build, all of that should have been done as creations. Yet, those have all been posted as a series of blog posts.
Why? For the most part, blog posts lend themselves to incomplete, and on-going projects. For the moment, that's exactly what those projects are -- incomplete and on-going. The idea of going back to post a creation on the conclusion of a project series just seemed like duplicating content unnecessarily. Instead, wouldn't it be better to fit creations into my writing pattern as it evolves?
To do so would require a few changes to how creations work. An entity reference field could be added, or a reference paragraph type created, so that creations could reference existing content. The URL component could be removed from the URLs for creations, since creations are more "timeless" anyways. But hang on...isn't that just...collections with another name? That's exactly the problem.
Collections and fitting creations to my current writing patter is like using two stones against one bird. Sure, you may hit the bird with the first or second stone, rarely even both, but it's equally likely that the stones will strike each other allowing the metaphorical avian to escape with it's allegorical life intact.
Worse, this doesn't really solve the problem of releasing a story chapter by chapter. A chapter of writing isn't really a blog post, no matter what popular CMSs say otherwise. In deninet's present model, each chapter should be a creation in it's own right, but then curated under something that can provide a summary page, a short URL, and a list of posts. You know...like a topic.
Dammit.
One possible solution out of this mess might be to make topics orderable. In theory, this could be done by updating the taxonomy display view for topics to enable posts to be reordered. I turned this question out to Twitter last week and was presented with two possible solutions:
- Implement Draggable Views.
- Add a weight or delta field to posts that can be included in topics to act as a sorting method.
I spent a good portion of a half week trying to get Draggable Views to work for my site. For the most part, this did work. I can create a view that will allow items to be resorted by user preference. The problem with this method is that I can't seem to find an easy way to attach the view providing the ordering UI to the topic term pages. No matter what I do, I can't seem to get the tab to show up. I suspect it's because the term page isn't really the term page, but overridden by the taxonomy view instead, and that is fouling up the ability to display a tab.
Adding a weight or delta field to posts that can be included in topics isn't difficult. A default value of 0 could be added so that posts sort as expected unless something exceptional needs to be done. The downside is that this must be done on each individual post, or a special admin display drawn up. This might still be acceptable given the limited number of users on the site, and the fact that ordering outside of sticky/post-date is unlikely.
Another solution I keep forgetting about is the Book module. It's been around in Drupal since the earliest days, and remains in core today. I've had a fraught relationship with it however, which is only why I'm reluctantly considering it here. The biggest advantage it has is it's ability to organize posts into...well...books. Each page has a next page and previous page link, as well as the ability to go up to the parent page.
The book module allows you to designate one or more content types to act as a book. The problem comes when you start adding child pages. Book module only allows you to select one child page type no matter the book content type:
This limitation makes it pretty much useless for my case. I would prefer to be able to set one or more content types to use as individual "pages", by book type. Since I don't need deep hierarchies, books offer me little advantage over the collection route.
Merging the content referencing ability of collections into creations doesn't really solve the original problem, it only reuses the same content with a different name. It might be more efficacious as we're also reusing an existing content type and all it's associated menu structure, but it's still the same thing with a different name.
More damningly, it sounds an awful lot like....topics. Adding a reference field and de-dating the URL transforms creations into a summary page for a project and series with a specific order. Topics already have a summary section, and can be associated with one or more posts. Granted, topics can't really order the posts, but that could be potentially solvable using something like the Draggableviews module. Furthermore, topics already have their own RSS fields, but creations do not.
The result of all of this is a messy feature matrix where no one is a clear winner:
Topics | Collections | Books | |
---|---|---|---|
Created | Implicitly when assigned to a post. | Explicitly as separate process. | Explicitly to create the book. Pages added on node edit page. |
Scalable | Yes. | Clumsy if referencing a large number of posts. | Yes. |
Reference method | Reverse, field on post | Forward, field on collection | Third party (database table) |
Who can edit? | Admin by default. User role if so configured. |
Original poster only preferred. | Book admins. |
Referenced items can be user-ordered? | Sort of. See Draggable Views. | Yes, core functionality. | Yes, core functionality. |
Multiple orders allowed? | Yes, via views. | No, user-ordered only. | No, user-ordered only. |
Works as standalone content? | No. | Yes. | Sort of. A book doesn't need "pages". |
Easy to display with post? | Yes. Topic is just a field. | No. Requires custom code or use of a views block. | Yes, since the page switcher is displayed automatically. |
Required for all posts? | Yes, but should it? | No. Opt-in. | No. Opt-in. |
Has its own RSS feed? | Yes. | No. | No. |
Book-like next post links? | No. | No. | Yes. |
Show block of related posts? | Yes, via views. | Requires custom code. | Might be possible with views |
While it's possible to order posts within a topic, it's clumsy and I've had some difficulty making it work as seamlessly as I'd prefer. Likewise, it's no easy task to add RSS feeds and implicit creation to collections/creations. Even if I merge all collection functionality into creations, that still doesn't resolve the problem.
The larger question really boils down to "What is a topic?" "What is a creation?" Is a physical project like the Cardboard Pi a creation or a topic? Is my series on automated testing in Drupal a creation, or a topic? If I were to write a series of fiction posts, is each post a blog post? Or are they creations in their own right part of a larger topic which is the entire story? Does treating creations as part of a date-series have value?
At the moment, I have more questions than answers. Trying to derive a solution from first principles seems more an exercise in hair-pulling than solving a problem productively. The temptation is to try to use structure to solve this, whereas it may be the content itself which is the best determining factor despite functional overlaps.
This post was created with the support of my wonderful supporters on Patreon.
If you like this post, consider becoming a supporter at:
Thank you!!!