From Gallery Hierarchies to Entity-Oriented Design: Rethinking Cheddarmongers and Contraptions

Introduction

What began as a discussion about migrating old Gallery2 and Drupal sites evolved into a broader conversation about information architecture, data modeling, and the long-term sustainability of hobby websites.

The key realization was that both Cheddarmongers and Contraptions are not fundamentally photo galleries. They are collections of interconnected knowledge. Photos matter, but they represent only one aspect of the underlying content.

Rather than organizing content primarily through folders, albums, pages, and manually assembled galleries, a modern Drupal implementation should organize content around entities and their relationships.

In short:

Cheddarmongers and Contraptions should function more like digital museums or knowledge systems than traditional photo galleries.

The Problem with Page-Oriented and Gallery-Oriented Thinking

Traditional websites often start with a page structure:

Gallery2 used a similar hierarchy:

This structure works reasonably well when each item belongs in exactly one place. However, it becomes restrictive when one object belongs in several categories at the same time.

For example, a miniature such as Village Idiot might be:

A folder hierarchy forces that miniature into one primary location. An entity-oriented model allows all of those facts to exist simultaneously.

Likewise, a contraption such as Topsy Street Organ might be:

Again, the object has many relationships. It does not naturally belong in one folder.

Core Principle: Entity-Oriented Design

A content-oriented website asks:

What kinds of content do I have?

Examples:

That approach improves on simple page design, but it still treats content as the main object.

An entity-oriented website asks a better question:

What real-world things am I describing?

For Cheddarmongers, the primary entities might include:

For Contraptions, the primary entities might include:

Then Drupal stores relationships between those entities:

Content becomes discoverable through metadata and relationships rather than folder placement.

The Museum Catalog Analogy

A useful way to think about this model is to imagine a museum catalog.

A museum would not primarily catalog:

Web Page #12

It would catalog an object:

Then it would attach supporting material:

Drupal can work the same way.

The entity is the durable object. Articles, photos, videos, and documents provide evidence, history, and context around that object.

Lessons Learned from Gallery2

Gallery2 Was Secretly a Database

The original Gallery2 installation contained much more than photos. It held structured metadata such as:

That reveals something important: the old site was already functioning less like a simple photo gallery and more like a structured catalog.

The photos themselves are relatively easy to preserve. The more valuable asset is the metadata.

In a Drupal migration, the goal should not simply be:

Move the galleries into Drupal.

The better goal is:

Preserve and improve the underlying knowledge model.

Static Albums vs. Dynamic Collections

A static Gallery2 structure might look like this:

The problem is that a miniature can belong to several of those collections at once.

Instead of assigning an item to one album, Drupal can store structured facts:

Drupal Views can then generate dynamic collections:

No duplicate images or duplicate content are required.

The same principle applies to Contraptions:

Drupal Views can generate:

Proposed Cheddarmongers Data Model

User

A User represents an actual site member.

Examples:

Potential fields:

Users can own miniatures, paint miniatures, write articles, and create characters.

Miniature

A Miniature represents a physical miniature figure.

Suggested fields:

A miniature may depict a character, but it does not have to. Some miniatures are generic figures, monsters, scenery, or prototypes.

Character

A Character represents a fictional person, creature, or persona.

Examples:

Suggested fields:

A character can exist with or without a miniature.

Relationship pattern:

This allows:

Person

A Person represents an individual who may not be a site user.

Examples:

A person may serve as:

This separates site accounts from real-world people. A famous sculptor should not need a Drupal login to exist as a referenced person.

Replacing “Race” With a Better Model

The term “race” has become increasingly awkward in fantasy gaming and often fails to describe creatures accurately.

A better model separates broad biological or mythological classification from specific lineage.

Creature Type

Broad classification.

Examples:

Ancestry

Specific lineage.

Examples:

Examples:

This structure is more expressive, more flexible, and more future-proof.

Role Versus Class

Not all miniatures represent adventurers. A miniature site needs broader language than traditional role-playing game classes.

Instead of using only:

a broader Role taxonomy can support both adventurers and ordinary figures.

Examples:

Examples:

The same taxonomy can apply to characters, miniatures, and even people when useful.

D&D Beyond Integration

Characters should exist as first-class Drupal entities.

D&D Beyond can serve as an optional external reference, but Drupal should remain the authoritative source for the site’s content model.

Potential Character fields:

Recommended relationship model:

Benefits include:

1. Characters with no miniatures
2. Multiple miniatures representing one character
3. Campaign tracking
4. Future integration opportunities
5. Independence from an external platform

Proposed Contraptions Data Model

The same principles apply to Contraptions.

Rather than structuring the site as:

the site can model a broader ecosystem of instruments, components, technologies, articles, media, and people.

User

A User represents a site participant.

Examples:

Users may create articles, document projects, build instruments, or contribute media.

Contraption

A Contraption represents a physical or conceptual object.

Examples:

Suggested fields:

The Contraption should serve as the center of the content model.

Example:

Component

A Component represents a physical part, subsystem, mechanism, or module.

Examples:

Relationships:

However, components may have flexible boundaries. A component may become complex enough to qualify as a contraption. Likewise, a contraption may become a component of a larger contraption.

For that reason, Drupal should support related contraptions and component relationships rather than force a rigid hierarchy.

Example:

Technology

A Technology represents a reusable technical concept, mechanism, or method.

Examples:

Technologies should usually be taxonomy terms or reference entities, depending on how much detail each technology requires.

If the site only needs to tag content, taxonomy works well.

If each technology needs its own description, photos, articles, and history, then Technology may deserve its own content type.

Contraption Relationships

Potential relationship types include:

Example:

This structure allows Drupal to reveal relationships automatically instead of requiring every page to be manually assembled.

Media Management Lessons

One challenge involved image organization.

The original goal was complete normalization:

That approach is technically clean because it prevents duplicate files. However, it can become cumbersome if every relationship requires manual Media references.

A more practical model is:

Then the article can display:

This keeps the file storage normalized while reducing manual relationship maintenance.

For build logs, images may also live naturally inside the article body through media embeds or paragraphs. The Media entity still stores the actual file once, but the editor can place the image where it makes sense narratively.

Dynamic Views Instead of Manual Galleries

Entity-oriented design shifts much of the organizational burden from the editor to Drupal.

Instead of manually creating:

Topsy Photo Gallery

Drupal can generate:

All media where Related Contraption = Topsy

Instead of manually creating:

Kevin White Sculpt Gallery

Drupal can generate:

All miniatures where Sculptor = Kevin White

Instead of manually maintaining:

MIDI Projects Page

Drupal can generate:

All contraptions where Technology = MIDI

In this model:

Content Type Consolidation

A related design lesson involves content type granularity.

If content frequently needs to move between types, such as:

that may indicate too many content types.

In many cases, it may be better to use one flexible content type:

Article

with taxonomy terms such as:

Content types should represent genuinely different entities, not merely different presentation styles.

For Contraptions, the durable content types may be:

with Media and Taxonomy supporting them.

For Cheddarmongers, the durable content types may be:

with Media and Taxonomy supporting them.

Shared Architecture Between Cheddarmongers and Contraptions

Although Cheddarmongers and Contraptions appear to cover very different subjects, they share the same underlying model.

Both sites include:

The domain-specific entities differ.

Cheddarmongers:

Contraptions:

But the pattern remains the same:

That shared structure means the two sites can use similar Drupal patterns even when their subject matter differs.

Practical Drupal Implementation Philosophy

When designing the Drupal content model, ask:

What real-world thing am I describing?

Better questions:

Less useful starting questions:

Menus, landing pages, galleries, and indexes can come later. Drupal Views can generate them from the underlying relationships.

The hard part is getting the entities and relationships right.

Recommended High-Level Architecture

A combined entity-oriented architecture for both sites might look like this:

Final Conclusion

The major takeaway is that both Cheddarmongers and Contraptions should be designed as knowledge systems rather than galleries.

Photos remain important, but they become attributes of richer entities. Articles remain important, but they become documentation about people, objects, technologies, and creative work.

The modern Drupal architecture should focus on:

This approach provides several advantages:

1. It preserves metadata as a first-class asset.
2. It avoids duplicate images and duplicate content.
3. It allows one object to appear in many dynamic collections.
4. It supports long-term growth.
5. It allows Drupal Views to generate galleries, timelines, indexes, and related-content sections automatically.
6. It treats both sites as living archives rather than static albums.
7. It remains understandable even after the original folder structures and legacy gallery software have been forgotten.

In short:

The folder is not the truth. The entity is the truth.

A successful Drupal 11 rebuild should not merely recreate the old Gallery2 hierarchy. It should preserve the knowledge that hierarchy was trying to express and then make that knowledge easier to maintain, discover, and extend.