strataDocs

Project Compare

Diff two content models side by side to see what changed, what was added, and what was removed across every entity type in your architecture.

What project compare does

Project Compare takes two projects within the same organization and produces a structured diff of their content models. It walks every entity type — content types, taxonomy vocabularies, media types, paragraph types, and all other tab types — and reports which entries are identical, which have been modified, and which exist in only one of the two projects.

The comparison includes child entries such as fields and display modes, so you can drill into a content type to see exactly which fields differ and how their configuration changed.

How to access it

Navigate to your organization's Projects list. When the organization has at least two active projects, a Compare button appears in the top-right corner of the page. Click it to open the comparison view.

The URL follows the pattern /{orgSlug}/projects/compare. Any organization member with access to both projects can run a comparison — no special permission is required beyond standard project read access.

On the comparison page, select a Left project and a Right project from the dropdowns, then click Compare. You can swap the two sides at any time with the swap button between the dropdowns.

What gets compared

The comparison covers every entity type that appears as a tab in your projects. Typical sections include:

  • Content Types — labels, descriptions, settings, and all child entries (fields, form displays, view displays)
  • Taxonomy Vocabularies — vocabulary configuration and their fields
  • Media Types — media type definitions and source field configuration
  • Paragraph Types — paragraph bundles and their fields
  • Block Types, Views, Menus, User Roles — and every other entity type your projects define

Certain computed or metadata properties are excluded from the diff to reduce noise:

machine_nameUsed for matching, not compared as a value
field_countDerived count, not a configured property
display_countDerived count
field_config_countDerived count
child_countDerived count
notesPer-entry notes are excluded from the structural diff

How entries are matched

Entries in the left and right projects are paired by machine name. The comparison logic reads the machine_name property from each entry's data. For display modes and similar entries that use a different key, it falls back to mode or role_ref.

When two entries share the same machine name within the same entity type, they are treated as counterparts and their properties are diffed. Entries with no match on the other side are reported as existing in only one project.

Child entries (fields within a content type, for example) follow the same machine-name matching within their parent. A field with machine name field_summary on the left is compared against a field with the same machine name on the right, regardless of sort order.

Reading the diff

After running a comparison, a summary bar shows aggregate counts across all entity types:

  • Identical — entries present in both projects with no property differences
  • Modified (amber) — entries present in both projects but with at least one property that differs, or with child entries that differ
  • Only in left (red) — entries that exist in the left project but not the right
  • Only in right (green) — entries that exist in the right project but not the left

Filtering

Use the filter buttons in the top-right corner to narrow the view. Choose All to see everything, or filter to only Modified, Only left, or Only right entries. Sections with no matching entries under the current filter are hidden automatically.

Expanding entries

Each entity type is shown as a collapsible section with its own per-section summary. Click a section header to expand or collapse it. Within a section, entries that have property-level differences or child diffs can be expanded to reveal the details.

For a modified entry, expanding it shows a three-column table for each changed property: the property name, the left value (shown in red), and the right value (shown in green). If the entry has child entries with differences (such as fields within a content type), those appear nested below the property diff and can be expanded further.

Sort order

Within each section, entries are sorted by status: entries only in the left project appear first, then entries only in the right, then modified entries, and finally identical entries. This puts the most interesting differences at the top.

Use cases

  • Auditing clones — after cloning a project, compare the clone against the original to verify that the copy is faithful, or to see what has diverged as the clone evolves independently.
  • Comparing before and after — if you duplicate a project before a large refactor, compare the two afterward to get a clear summary of every structural change you made.
  • Verifying template application — after applying a template to a new project, compare against another project built from the same template to ensure consistency.
  • Cross-project alignment — when multiple projects within an organization should share the same content model (e.g. regional sites), compare them periodically to catch unintended drift.
  • Code review preparation — before exporting a manifest for deployment, compare your working project against a known-good baseline project to review exactly what will change in the Drupal site.