I’m using tome for two sites because I’m very lazy and should not be trusted with running databases and real live Drupals in production. Security updates are a hassle for this designerd so they tend not to happen soon enough. Which is less of a problem when that insecure site is only sometimes running locally on just my laptop.

So, yay for Tome, which lets me keep using Drupal for its powerful content modeling and clicky tools for site building. Then export to flat html and upload that as the live site.

Even between content updates months may pass. Which introduces other types of insecurites:

1. Do I still know how to run, update, export the thing?
2. In the mean time, did I not break something in the required tooling?

Point 1 is fixed by keeping notes with my own step by step how-to instructions based on the tome documentation.

Point 2 though is more tricky. For as much as possible I keep using the MAMP Pro application to keep the basic LAMPP stack up and running. Sometimes that clashes with some of the commands that want to run their own webserver, but I can work around that.

Composer, Drush, Git, Tome itself are tools that are primarily operated through the command line. I’ve become accustomed to (I'm not scared anymore of) using basic commands to make simple things work. But that doesn’t mean I actually know what’s happening. So when for example Drush throws error because database not found, I have very little knowledge on how to fix. It’s tricky business trying out possible solutions found on stackexchange and the like. I can’t always tell how applicable a proposed fix is to my specific situation and it may even further break things?

I guess my main worry is that running Tome and it’s underlying tools directly on my laptop potentially makes things brittle.

I think that’s where things like Docker come in? So that, among other things, a working version of all the required tooling is bundled up and kept somewhat immune from changes outside it’s container?

Yet more terminal commands to explore!

#drupal #tome

This is somewhat Drupal specific, but the graph view in Obsidian is a fun and flexible way to visualize a content model.

Assuming you want to document these different kinds of things and see how they relate:

• Content types (news, product, person, form, event, …)
• Vocabularies (event types, colors, sizes, materials, …)
• Media types (image, video, audio, document, …)

Steps:

1. Create a separate vault for the content model
2. Create a note for each content type
3. Use wikilinks to relate different content types
4. Use tags to indicate vocabularies
5. Create and insert image, video, etc. placeholders
6. Look at the pretty graph!

Create a separate vault

This is just a folder somewhere on your computer. Store it in your dropbox, google drive, nextcloud or similar to access from other computer machines, but you knew that already.

From the bottom-left sidebar in Obsidian click the thingy which wants to look like a vault. From there, you can name your new vault and point to the folder you want to use.

Create a note per content type

Start creating a note for each content type that is in your model. Use the name of the content type as the file name. So create a “product.md” for your product content type, “news.md” for your… you get the point.

Use links to connect the content types

Create links between related content types. In Drupal content type speak, these would be reference fields. A reference field lives on the content type that does the pointing to the other content type. The direction matters so it's meaningful to create the link in the file for the content type that will have the reference.

Use tags for vocabularies

Obsidian understands hashtags (“#somelabel”).

Now here we need to make a mental leap. In regular use, hashtags are often used as quite specific labels, e.g. “yellow”, “banana”, “merino wool”, etc.

Not here. For your content model you're not primarily concerned with the specifics of wether a content item is tagged with “blue”, “apple”, or “denim”. What you want to document is that your content types want to use tags from (in this exampe) these collections of terms: “colours”, “fruit” and “textiles”. In Drupal speak: use hashtags to indicate which vocabularies the content type will be able to use.

Create and insert media placeholders

Images, videos, documents and the like are considered media types in Drupal. Similar to content types, but media objects are treated as a separate type of content types, because technical reasons, mostly.

A similar leap as we did with tags for vocabularies above with an additional simplification. Instead of using placeholder audio and video files, we'll use images for each media type. Use the name of each file and a bit of iconography to make them distinct. Create these images and add them to the vault:

• image.png
• video.png
• audio.png
• document.png

(audio icon via https://freesvg.org/volume-icon)

For each content type that uses one or more of these media types, embed the corresponding image in the body of the note.

Here's an example of a testimonial content type note that contains a video and uses the fruit and colours vocabularies. The file would be called “testimonial.md” and the minimal contents would be:

# Testimonial ![[video.png]] #fruit #colours

Look at the pretty graph!

Got your content type notes in place and linked, hashtags for vocabularies added and media items embedded? Great, now switch to the graph view.

By default you'll probably only see the content type notes. Expand the “Filters” section in the little box top left of the graph and toggle the switches to also show tags and attachments. You may also want to toggle the “Arrows” switch that is in the “Display” section. The arrows will show the direction of your references, or, which note is doing the pointing to another note.

Here's the content model of the Umami food magazine demo that ships with Drupal core:

(download these umami content model files here: https://github.com/yoroy/purple-maze)

What I think works well

• The very explicit network-like presentation, which is very much not looking like a sitemap.
• For a more complex content model like the one in the picture at the top of this post it clearly shows which content types are the workhorse hubs in the collection, connecting to many other pieces.
• Extending, changing the model is very easy to do, it's all just simple markdown text files and a few image attachments.

Further explorations and limitations

• Content types, vocabularies and media types are the three essential building Drupal content modeling building blocks. The Obsidian concepts of notes, tags and image embeds are the three availabe kinds of things to map to. Should you need a fourth type of building block like e.g. a custom entity type, I don't know how to introduce a fourth type of thing in Obsidian. It's scriptable so there's probably a way around this?
• You could add the other fields a content type uses (body, summary, duration, etc) as a list to the content of the corresponding note. I don't think this simple markdown format is the best way to specify the configuration details for each field.
• Maybe there's a more fine-grained way to do this, using a note for each field instead of for each content type. Would probably need to use folders for each content type then.

#contentmodeling #drupal

The CMS_ui project dedicated some posts of the Drupal views module user interface from 2006, 2008 and 2011.

I was heavily involved in these efforts (1, 2 ), it was one of my first substantial contributions to the project as a designer. Still proud of this concept model.

#drupal #design

Written in response to

This set of really good questions by @jjosephmiller gets at the heart of what the CMS's job is. Do its "content types" (or templates, or post types, or entity types, etc) necessarily map to the conceptual "kinds of content" that exist in the high level map of an org's content? https://t.co/6z2fWtN0qm

— Actually, (@eaton) October 28, 2020

The most obvious reason to create separate content types is because different content structure, different fields.

Other reasons to define a separate content type can go beyond differences in the needed field structure:

• Different editorial workflows.
• Governance: difference in content life cycles.
• A simple(?) way to segment who can access what

Yes, there are other tools available to achieve the above (i.e. taxonomy, roles, groups in Drupal parlance), but at a certain point, the maintenace and complexity cost of DRY (don't repeat yourself) can become too high.

The definition of the function of a content type is a wider consideration than its functional-structural definition on field level alone.

(I suspect there's an analogy to be made here with object oriented code. Not all giraffes, kangaroos, wolves, mice, cows, lemurs should be instances of the same mammal class?)

An example of “all in one”: in one case we pushed really hard on gathering wildly variable service-related content into a single content type for:

• future extensibility. Much of the service was info at first. Actual handling of service requests (order this, request that, subscribe to) will be added over time and can be made available across the whole set.
• governance: tighter control of who can create these items to reduce the chance of duplication, which was a problem

At the same time we created different versions of a training because even if most fields were shared, which ones were required varied greatly. No meaningful (predictable) shared set of what we could assume to be available. Hard to create view modes for that.

#contentmodeling #drupal