I Own You, Drupal View!

As I tweeted about in victory a week ago, I managed to finally get my Drupal taxonomy term view(s) to do what I wanted:

I _finally_ managed to get that Drupal taxonomy term view to generate what I want, the way I want it (TL;DR: term value, content filter, and a complex relationship). Only took a few weeks of casual/off-and-on attempts to figure it out! pic.twitter.com/ks7qqZfc73

— Matt Zaske (@matt_zaske) March 3, 2019

I'd mentioned in a previous post how I was "working around" the situation of having a taxonomy term view by using a set of rewrites, manually added for each term, and pointing them at a custom view which I'd been able to make work more or less as expected. At the end of the day, I had three expectations:

• display a list (short view) of content tagged with a certain term, by name;
• display a list of content tagged with a certain term, by its ID (default behavior in Drupal is to display the details such as name and description when browsing by ID); and
• have one view to handle both situations.

At the time of that previous post, I only had the first view working (content by tag name), and was manually rewriting the ID paths to the name. I was definitely on the right track, but it was time for some contemplative/reflection time. And, as expected, a solution came to mind in the night (or in the shower). Since I already had the first view working, I needed to iron out how to make the term ID and content work out together. As speculated, it was indeed much to do with contextual filters and relationships. Specifically, finding the proper relationship combination between the tag/term (source) and content (desired output).

It turns out that it all fell together pretty quickly once I got that relationship set up. I had some fumbles with essentially "overriding" the term ID to its name value (friendly for users), but once I worked the larger problem bit by bit it buttoned up nicely.

Once I had the two options working independently and removed the manual rewrites, I merged the two views into one (with the term ID view being a contextual override of my preferred default using the term name). Whip together/merge some other Twig-related template business—how I'm handling the layout and larger visual presentation of the views—and voila!

Along the way I also conveniently discovered how I could better configure the sidebar tag (category) list to not show new tags for content which isn't available. This was a bit of a hiccup since I am queuing up posts some time in advance. As soon as I'd tag a draft or schedule content with a "new" tag it'd show up in the list of categories—not a big deal since it's just a tag in a list—but clicking through would display no available content. One of those "it's cleaner this way" sort of things. Now it's working as I want.

Other updates

Fresh off the victory, and while I was pulling together bits of the layout/template anyway, I decided to hunt down and address some of the other styling business that's been bugging me for some time...more so now that I'm actually creating content and using the system.

• Formatting bulleted (unordered) lists in a more meaningful way (for the blog posts). I'd never liked the inherited "hand pointer" and how it laid out, so that's fixed with a more simplistic solution and better margin control.
• Better link styling within blog posts. While I like the less visually intrusive link styling for other areas of the site (tags, sidebar content, etc.), and I haven't quite figured out a bigger vision for non-blog content, I wanted to draw more obvious attention to the stuff to which I'm linking. Share and share alike, right?
• Minor sidebar content formatting, namely changing the lists to use icons reflective of their content instead of the plain chevrons. A minor detail, but something that's important and provides a better finish.
• Some other text formatting miscellany, mostly with regard to font sizes and some inheritance wonkiness.

...and a failure

But it wasn't all love and happiness in the process. Along the way I decided to troubleshoot or "fix" a different problem that nobody but myself (or someone who might have hit a 404) would have even noticed. The core theme has a headline/banner image which I generally don't use as of right now, but would like to incorporate in meaningful ways sometime in the future (see above bit about "bigger vision for non-blog content"). This is a theme-level change, and something I had configured as desired.

Except something isn't quite right, and I'm unable to obviously figure out what's going on. Google isn't helping much, either, which leads me to think the theme is actually configured in a weird way. Generally speaking the most recent blog post's headline image (or gif as I like to use) overwrites the theme value, which then has a strange cascading effect across the places where this isn't quite in use yet.

So I decided to further customize the core theme for the site. Having learned from my previous mistake with reloading, I did some staging to prepare for the worst...that horrible "The website has encountered an error..." message, put the site in maintenance mode, overwrote the theme, and purged the cache. Reload:

The website has encountered an error...

Well, shit.

Tinker for a while, upload/reload, rinse, repeat. Same problem.

So I back out of the change completely (see: being prepared), and things work like expected. Good. But...why isn't the new, simple theme change/addition not working?

I skimmed around in the theme file since I still had it front-and-center in Visual Studio Code, and the problem is glaringly obvious. In my rearranging of the theme details and adding a variable (which needs to be done in a couple of places to make it configurable once applied), I'd forgotten to delete a variable I'd pasted into the hook portion of the theme file. Of course it'd barf: PHP couldn't possibly parse the theme file with an unexpected something just sitting there.

Deleted the typo, re-applied all of the changes, and it worked right out of the gate. Now to see if my change will "stick" as new content is posted/published. Time will tell.

Headline photo via Giphy