Core Principle

Design the website around things that exist in the subject matter, not around pages, menus, or articles.

Ask:

"What are the things I want to know about?"

not

"What pages do I want on my website?"

Step 1: Identify Core Entities

An entity is something important enough to deserve its own page.

For Contraptions, examples include:

• Contraption
• Sound
• Voice
• MIDI Map
• MIDI Map Entry
• Function
• Registration
• Effect
• Article
• Tech

The test is:

Would I ever want to browse, search, categorize, or link to this thing directly?

If yes, consider making it an entity.

Step 2: Separate Things from Stories

Distinguish between persistent objects and temporary narratives.

Objects

Things that exist over time:

• Topsy
• Glockenbox
• MIDI Interface
• Reuter 1674

Stories

Things that document activity:

• Build logs
• Progress reports
• Announcements
• Historical articles

Objects accumulate stories over time.

Step 3: Normalize Concepts

Separate different dimensions of classification.

For example:

What it IS

Instrument
Interface
Controller
Rank
Tool

This belongs in:

Contraption Type

What disciplines are involved

Electronics
Mechanical
Woodworking
Software
Physics
Music

This belongs in:

Genre

A single taxonomy should answer a single question.

Step 4: Prefer Relationships Over Hierarchies

Many systems naturally form networks rather than trees.

Avoid forcing this:

Parent
 └─ Child

when reality looks more like:

A relates to B
A uses C
A inspired D
B controls E

Use flexible relationships whenever possible.

Step 5: Model Reality, Not Implementation

Example:

Don't ask:

"Should MIDI Controller be a content type?"

Ask:

"What is a MIDI Controller in the real world?"

The answer determines the model.

A database should describe reality rather than software structure.

Step 6: Create New Entities Only When Necessary

Avoid creating content types for every idea.

Ask:

Is this fundamentally different?

If not, use an existing entity.

For example, we discovered many "components" are actually specialized contraptions:

• Pipe chest
• MIDI interface
• Bellows
• Test bench

Rather than creating a new Component entity, they can remain Contraptions.

Step 7: Use Taxonomies for Classification

Use content types for things.

Use taxonomies for categories.

Good entity

Contraption

Good taxonomy

Contraption Type

Good taxonomy

Genre

Step 8: Make Relationships Discoverable

Store the relationship once.

Examples:

Topsy
→ related contraption
→ MIDI Interface

Then use Views to discover:

What references this item?

instead of storing reciprocal links manually.

Step 9: Let Real Content Drive the Model

Avoid endless redesign.

Enter real content.

Examples:

• Topsy
• Reuter 1674
• Glockenbox
• MIDI Interface

Then observe:

• Which fields feel useful?
• Which relationships keep appearing?
• Which categories emerge naturally?

The content will reveal the proper architecture.

Step 10: Think Like a Museum Curator

The website is not a collection of pages.

The website is a collection of interconnected knowledge.

For Contraptions:

Each item can be viewed from multiple perspectives without duplicating information.

Guiding Question

Whenever you are unsure how to model something, ask:

"Is this a thing, a category, a relationship, or a story?"

Most content-modeling decisions fall naturally out of that question.

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.

Introduction

What began as a simple question about migrating a Drupal 6 website and gallery to Drupal 11 evolved into a digital archaeology project spanning more than twenty years of hobbyist history.

The subject of the investigation was Cheddarmongers.org, a community site dedicated to miniature gaming, painting, and related hobbies. Over the years, the site ran on multiple versions of Drupal and relied heavily on Gallery2 for image management. Like many hobby sites of the early internet, it accumulated thousands of photos, tutorials, blog posts, and user contributions.

The challenge was not simply upgrading software. The challenge was identifying and preserving the site's true historical and informational value.

The Original Goal

Initially, the objective was straightforward:

The site had already been resurrected in DDEV using a backup, and the question was how best to migrate it.

However, as more information surfaced, it became clear that migration was only part of the story.

Discovering the Site's History

Several clues emerged from Wayback Machine captures and old blog posts.

Welcome to Cheddarmongers! | Cheddarmongers (on Wayback)

A September 2007 Wayback capture showed a thriving hobby portal featuring:

• Gallery
• Tutorials
• Blogs
• Forums
• Contests
• User-generated content
• Recent photos and community activity

This was not just a personal website. It was a functioning hobby community.

An old homepage post from September 29, 2011 provided another important clue:

"My goal has always been to make it so that the links in the site stay so that if you ever link to a picture or page here, your link wouldn't go bad."

This concern for URL permanence became a recurring theme throughout the site's history.

Reconstructing the Technical Timeline

Based on the available evidence, the likely timeline became:

2003–2004

Cheddarmongers launches on Drupal 4.

2004–2005

Migration to Drupal 5.

2005–2011

Long and successful Drupal 5 era.

Gallery2 becomes deeply integrated into the site's identity.

Early 2011

Migration from Drupal 5 to Drupal 6.

2011–2019

Years spent evaluating:

• Drupal 7
• Gallery2
• Gallery3
• Gallery bridge modules
• Alternative gallery solutions

By January 2020

A backup restored successfully in DDEV revealed:

• Drupal 7
• Gallery2 tables
• Gallery2 data
• Gallery3 files

This proved that a Drupal 7 migration had already occurred.

2021–2022

Wayback captures indicate:

• Gallery integration struggles
• Site restructuring
• Decoupling of Gallery2 from Drupal
• Continued search for sustainable solutions

Solving the /prod Mystery

One mystery involved Wayback captures referencing:

http://www.cheddarmongers.org/prod/

At first glance, this appeared to indicate a migration problem.

Eventually the true explanation emerged.

The original plan had been to implement a small-scale SDLC structure:

The idea was surprisingly enterprise-grade for a hobby website.

In reality, only the /prod environment was ever used. Most development happened directly in production.

This discovery explained why Wayback continued referencing /prod years later.

The Most Important Discovery: g2data Survived

Among all the findings, one stood above the rest.

The original g2data directory still exists.

This is significant because Gallery2 stored its image assets there.

Even if:

• Drupal fails,
• Gallery2 fails,
• modules become unavailable,

the photographs themselves remain preserved.

For a miniature-painting community site, the images represent the most valuable and irreplaceable content.

Gallery2 Was Not Dead

Attempts were made to resurrect Gallery2 using:

• PHP 5.6
• MariaDB 5.5

Results were surprisingly positive.

Gallery2:

• authenticated users,
• displayed the gallery homepage,
• displayed user gallery thumbnails,
• initiated upgrade procedures.

Some images and links were broken, but the system clearly still recognized:

• its database,
• its users,
• its albums,
• portions of its content.

The conclusion was encouraging:

Gallery2 is not dead. It is merely wounded.

The Database Revelation

Another breakthrough came when examining the database.

Rather than using a separate Gallery2 database, the site contained:

in the same MySQL database.

This means the gallery metadata likely survives along with the images.

Potentially recoverable information includes:

• album structure
• image captions
• descriptions
• upload dates
• user relationships

Combined with the g2data directory, this dramatically improves recovery prospects.

The Shift to Entity-Oriented Design

The discussion gradually shifted away from migration and toward information architecture.

A key realization emerged:

Gallery2 organized content like this:

But hobby data doesn't naturally fit into hierarchical albums.

A miniature can simultaneously belong to:

• a manufacturer,
• a range,
• a painter,
• a sculptor,
• a game system,
• a genre.

This led to the adoption of an entity-oriented content model.

Building Cheddar2

The proposed successor, Cheddar2, would focus on relationships rather than albums.

Core entities include:

Supporting taxonomies include:

A particularly elegant concept involved the Role taxonomy:

The same Role vocabulary can apply to both:

• real people,
• fictional characters,
• miniature subjects.

People as a First-Class Entity

The first new content type created was:

Person

This allows representation of:

• painters,
• sculptors,
• photographers,
• authors,
• community members.

Rather than treating people as simple tags, they become fully referenceable entities.

Examples include:

This provides a foundation for rich relationships throughout the site.

The Core Lesson

Perhaps the most important lesson from the investigation was this:

Build the framework first. Then migrate the data.

Rather than modifying the new design to match Gallery2's historical limitations, the recommendation is:

1. Design the ideal entity model.
2. Create the entities and relationships.
3. Map the historical data into that structure.

The old data should inform the framework.

The old data should not dictate the framework.

Current Recommendation

Preservation Sources

The current recovery assets are remarkably complete:

✅ Drupal 7 backup

✅ Gallery2 tables

✅ g2data directory

✅ Gallery2 code

✅ Gallery3 test installation

✅ Wayback Machine captures

✅ Historical blog posts

✅ Original site creator available for consultation

Recovery Strategy

The goal is no longer simply upgrading Drupal.

The goal is preserving two decades of community history while creating a sustainable platform for the future.

Conclusion

What began as an upgrade project became something much larger.

The investigation revealed that Cheddarmongers is not merely a website. It is a historical archive of miniature gaming, painting, tutorials, photography, and community contributions spanning more than twenty years.

The encouraging news is that the evidence increasingly suggests the content survives:

• the databases survive,
• the images survive,
• Wayback captures survive,
• institutional knowledge survives.

The project has moved beyond recovery and into assessment and design.

The next chapter is not restoring Gallery2.

The next chapter is building Cheddar2—a modern, entity-oriented successor that preserves the past while remaining sustainable for the future.

When designing a database, one of the most important goals is to organize data in a way that minimizes redundancy, improves consistency, and makes updates easier. Database normalization is the process of structuring data according to a set of rules known as normal forms.

Normalization helps answer a simple question:

"Where should a piece of information be stored so that it exists in exactly one place?"

Without normalization, databases often suffer from duplicated data, inconsistent values, and difficult maintenance. With normalization, data becomes easier to manage and relationships between entities become clearer.

Why Normalize Data?

Consider a simple table containing information about people, organizations, and roles:

This structure looks simple at first, but problems quickly emerge:

• A person's name may be repeated dozens of times.
• An organization's name must be updated everywhere if it changes.
• Deleting the last role for an organization may accidentally remove the organization itself.
• Adding a new organization requires creating a dummy record.

Normalization addresses these problems by separating data into logical entities and defining relationships among them.

First Normal Form (1NF)

A table is in First Normal Form when:

• Every column contains a single value.
• No repeating groups exist.
• Each row can be uniquely identified.

Not 1NF

The Roles field contains multiple values.

1NF

Each field now contains only one value.

Drupal Example

A multi-value field in Drupal may appear as multiple database rows behind the scenes rather than a comma-separated list in a single column.

Second Normal Form (2NF)

A table is in Second Normal Form when:

• It is already in 1NF.
• Every non-key column depends on the entire primary key.

This issue usually appears in tables with composite keys.

Not 2NF

Organization Name depends only on Organization ID, not on the entire key.

2NF

Organizations table:

Membership table:

Organization information is stored once and referenced through keys.

Third Normal Form (3NF)

A table is in Third Normal Form when:

• It is already in 2NF.
• Non-key columns depend only on the primary key.
• No transitive dependencies exist.

A transitive dependency occurs when one non-key column determines another non-key column.

Not 3NF

City depends on Zip Code, not directly on Person ID.

3NF

People table:

Zip table:

The dependency chain has been removed.

Boyce-Codd Normal Form (BCNF)

BCNF is a stricter version of Third Normal Form.

A table satisfies BCNF when:

• Every determinant is a candidate key.

Most practical databases that reach 3NF also satisfy BCNF, though edge cases involving overlapping candidate keys can require additional decomposition.

BCNF is especially important when a business rule allows multiple candidate keys that each uniquely identify a record.

Fourth Normal Form (4NF)

A table is in Fourth Normal Form when:

• It is already in BCNF.
• Independent many-to-many relationships are stored separately.

Not 4NF

The hobbies and languages are unrelated, yet every combination must be stored.

4NF

Person Hobbies:

Person Languages:

The duplicated combinations disappear.

Fifth Normal Form (5NF)

A table is in Fifth Normal Form when:

• It is already in 4NF.
• Complex many-way relationships can be reconstructed from simpler relationships without introducing incorrect records.

5NF addresses rare situations involving three or more entities with intricate join dependencies.

Most business applications never require deliberate design beyond 4NF.

Domain-Key Normal Form (DKNF)

DKNF represents the theoretical ideal.

A database is in DKNF when every constraint is enforced entirely through:

• Domain definitions
• Key definitions

No additional business rules are required to ensure data integrity.

In practice, very few systems achieve full DKNF because business logic often extends beyond simple domains and keys.

A Practical Example

For a site such as Cheddar2, a normalized model might include separate entities for:

• People
• Organizations
• Places
• Events
• Artifacts
• Roles
• Taxonomy terms

Relationships would be stored independently:

People

• Bob Smith
• Jane Jones

Organizations

• Acme Corp
• Makers Guild

Roles

• Engineer
• Treasurer
• Manager

Memberships

In this design:

• People are stored once.
• Organizations are stored once.
• Roles are stored once.
• Relationships connect them.

This approach avoids duplication and allows a person, organization, or role to be updated in a single location.

The Trade-Off: Normalization vs. Convenience

Normalization improves:

• Data consistency
• Data integrity
• Maintainability
• Reuse of information

However, highly normalized databases can require many joins to assemble information for display.

Modern systems often use a balance:

• Normalize operational data.
• Denormalize selectively for reporting, caching, and search.

Drupal itself follows this philosophy. Content entities, taxonomy terms, users, and media are stored separately and connected through references, while search indexes and caches may contain denormalized data for performance.

Conclusion

Normalization is fundamentally about identifying entities and relationships, then storing each fact in exactly one place. First Normal Form eliminates repeating groups. Second and Third Normal Forms remove partial and transitive dependencies. Higher normal forms address increasingly specialized situations involving keys and relationships.

For most Drupal applications, designing entities and relationships thoughtfully and achieving Third Normal Form provides an excellent balance between flexibility, maintainability, and performance. When modeling a site such as Cheddar2, thinking in terms of people, places, organizations, events, and relationships naturally leads toward a well-normalized design that remains easy to extend as the content grows.