TMS Component System

Documentation

TMS Component System is a plugin that adds a master–instance workflow on top of the WordPress block editor. It lets you define a layout once as a component master, drop reusable instances of it across your site, and update every instance from one place.

The plugin focuses on maintaining reusable layouts rather than rebuilding them. When the master changes, every instance can follow — automatically on the front end, and with one click in the editor.

TMS Component System currently supports:

component masters (a dedicated Components screen)
page instances inserted from the block inserter
per-property overrides on individual instances
content areas for freely editable sections
front-end sync with no publish step
staleness and drift detection
nested components, up to 20 levels deep
structure locking to keep instances intact

It works best with TMS Blocks. Core WordPress blocks can also live inside a component instance, but per-property style overrides only apply to TMS blocks — core blocks can be overridden as whole blocks, but individual properties inside them cannot.

If you are already comfortable with the WordPress block editor, TMS Component System should feel familiar. It builds on the normal editing flow and adds a reusable-layout layer on top.

Getting started

After activating the plugin, you’ll see a new Components screen in the WordPress admin (under Components in the sidebar). That’s where component masters live.

A simple way to begin is:

open a post or page and build the layout you want to reuse
select the block (or block group) you want to turn into a component
choose Convert Current Block to Component from the settings sidebar
open the new master from the Components screen to rename it and refine the layout
insert instances of the component anywhere using the block inserter’s Components category

Component masters

A component master is a saved layout that acts as the single source of truth for every instance. It is stored as a special post type, so it has its own editor, title, and categories — but it never appears on the site by itself. It only exists to drive the instances you place elsewhere.

Creating a master

There are two ways to create a master:

Convert an existing block — Select any block or group of blocks in a post or page and click Convert Current Block to Component in the sidebar. The block becomes an instance, and a new master is created automatically (named after the block type, e.g. “TMS Heading”).
Create one from scratch — Go to Components → Add New in the admin and build the layout directly in the component editor.

Note: After converting a block, reload the editor once so the new component shows up in the block inserter’s Components category.

Editing a master

Open a master from the Components screen and edit it like any post. Every time you save, the master’s version increments. That version bump is what tells every instance on the site that something changed.

Changes you make to a master fall into two categories:

Attribute-only changes — style or content values that don’t change the block structure (e.g. a color or a heading text). Instances update with a simple, fast sync.
Structural changes — adding, removing, or reordering blocks. These change the master’s structure and are detected as drift on affected instances (see Nested components and drift).

Page instances

An instance is a live copy of a master placed inside a post, page, or template.

Inserting an instance

Open the block inserter and go to the Components category. It lists the published masters (the 200 most recent). Click one to insert it.

Each inserted instance inherits the master’s structure and content. In the editor, the instance is shown as a block tree — a root block with its child blocks locked inside it.

Important: Only published masters appear in the inserter. If you just created or edited a master, publish it first.

The inspector panel

When you select a component instance (or one of its child blocks), the settings sidebar shows the component panel. This is where you identify, update, and manage the instance.

[SCREENSHOT: Component inspector panel]

Component picker

At the top is a Component search field. It shows which master the selected block belongs to. For a root instance you can search and switch the instance to a different master; child blocks show their master but cannot be reassigned.

Master information

Below the picker, a card shows the master the instance follows:

Master: the master’s title
Version — the master’s current version
Status — Up to date, Update available, or Inherited staleness (a nested master changed, see below)

Actions

The Actions section contains the buttons you’ll use day to day:

Button	What it does
Convert Current Block to Component	Turns the selected block into a new master and links it as an instance (shown only when the block isn’t already part of a component).
Edit Master	Opens the instance’s master in the component editor. Turns red and reads Edit Master — Nested Instance Outdated when a nested master inside it is stale.
Update Component Instance	Rebuilds the selected instance from the current master, preserving your local overrides and content areas.
Reset Component Instance	Rebuilds the instance and clears all local overrides back to the master’s values.
Reset This Block Overrides	Clears overrides on a single child block.
Sync All Instances In Post	Updates every component instance in the current post or page.
Sync Same Master Instances	Updates every instance in the current post that follows the same master as the selected block.
Solve Drift Chain	Resolves nested drift through the master’s full dependency chain (see Nested components and drift).
Check Instance Integrity	Runs a read-only integrity report on the selected instance (see Structure integrity).
Detach From Component	Unlinks the instance from its master, turning it into ordinary blocks.

Orphaned instances: if an instance’s master has been deleted or trashed, all actions except Check Instance Integrity and Detach From Component are disabled (see Deleted masters (orphaned instances)).

Content Area toggle

While editing a master, selecting one of the master’s own blocks shows a Content Area toggle. Turn it on to mark that block (and everything inside it) as freely editable in every instance. See Content areas.

When a selected instance has local overrides, a small orange dot appears in the block toolbar. Hovering it shows Content overridden — click to reset all overrides; clicking it clears every override on the instance.

Per-property overrides

An override is a single value that a specific instance changes away from the master. You don’t configure overrides directly — you just edit the instance.

For example, if the master’s heading is black, and you set one instance’s heading to red, only that color becomes an override. The instance keeps following the master for everything else, so a later change to the master’s heading text still reaches this instance — only the color stays red.

Overrides are per property. Change spacing, color, typography, or any other style property without touching the master or other instances.
TMS blocks only. Only TMS blocks support per-property overrides. Core WordPress blocks inside an instance can be overridden as whole blocks, but individual properties inside them cannot.
The orange toolbar dot tells you an instance has overrides and lets you clear them all in one click.
Reset buttons. Use Reset This Block Overrides for a single block or Reset Component Instance to clear every override on an instance.

Note: Non-TMS blocks can be overridden as whole blocks, but you can’t override individual style properties on them. You can still place them inside an instance.

Content areas

A content area is a region inside a master that stays locked in position but is free-form in content. Mark a block as a content area, and every instance can add, remove, or edit whatever is inside it.

Setting up a content area

Open the master in the component editor.
Select the block that should act as the boundary.
Turn on the Content Area toggle in the sidebar.

How it behaves

Inside the content area — content is instance-owned. Each instance can have completely different text, images, or blocks.
Outside the content area — the instance structure remains locked and follows the master.
In the list view — a content-area boundary gets a distinct grid badge, and blocks inside it get no lock badge.

Content areas are the exception to structure locking: they are the one place where users are meant to edit freely inside an otherwise locked instance.

Syncing and staleness

When a master changes, its instances become stale until they catch up. The plugin surfaces this clearly and gives you several ways to bring instances current.

Front-end sync

The front end always renders the current master. There is no manual publish step — when a page loads, any stale instance resolves automatically against the latest master. Editor-side updates are only needed if you want to see the new values in the editor or to persist them to the saved content.

Editor sync

The buttons under Actions are the editor-side controls:

Update Component Instance — update one instance, keeping overrides.
Reset Component Instance — update one instance and drop overrides.
Sync All Instances In Post — update everything in the current post.
Sync Same Master Instances — update all instances of the same master in the current post.

Staleness detection

The editor checks for stale instances automatically on a polling interval (configurable in Settings). When an instance is behind its master, the list view shows an amber badge and the inspector’s master card shows Update available.

Staleness has two levels:

Stale — the master changed in a way that doesn’t affect structure (version/attribute-only). A simple update resolves it.
Drift — the structure changed. See the next section.

Nested components and drift

Nested components

Components can contain other components. A master can embed an instance of another master, which can embed another, and so on — up to 20 levels deep. Each level is tracked independently, so a change deep in the chain propagates up to every instance that contains it.

Drift

Drift means an instance’s structure no longer matches its master’s structure. It happens in two ways:

Own drift — someone manually modified the instance’s structure (added, removed, or reordered blocks inside it).
Nested drift — a component inside the instance changed structurally, but the outer master hasn’t been re-saved, so it still embeds the old nested structure.

A drifted instance can’t be updated with a simple sync — it needs a rebuild. The editor shows a red badge and a warning before you publish.

Solve Drift Chain

When an instance (or a master) shows nested drift, use Solve Drift Chain. It resolves the whole dependency chain in the correct order — deepest nested master first, then each parent up to the selected master — and then rebuilds the instance.

This is the fastest way to repair inherited drift without manually editing each master in turn.

Structure integrity

Inside a component instance, the structure is protected. Users cannot add, remove, or reorder blocks — the editor enforces this automatically.

Locked instance children cannot be moved, removed, or have blocks added inside them.
Content areas are the exception — everything inside one is freely editable.
Copied orphans auto-detach. If you copy a block out of an instance and paste it somewhere else, the component attributes are stripped automatically so the orphan behaves as an ordinary block.

Check Instance Integrity

The Check Instance Integrity button runs a read-only report on the selected instance. It looks for duplicate IDs, stale scoped IDs, dangling master references, and version/hash mismatches, and shows the results in the sidebar. It never writes or changes anything — it’s a diagnostic aid for troubleshooting.

List view badges

Every component block gets a badge in the Gutenberg list view. The color tells you its state at a glance.

Badge	Meaning
🔗 Component (purple)	Component root — up to date
🔒 Instance child (purple)	Part of a component instance
🔗 Stale (amber)	Newer master available, or a nested master is outdated
⚠️ Drift (red)	Structure changed — own drift or a drifted nested instance
🔄 Syncing (blue)	Update in progress
⚠️ Orphan (gray)	The instance’s master cannot be found (deleted or trashed) — see Deleted masters
▦ Content area (grid icon)	Free-form content zone inside an instance

Priority: Syncing beats Drift beats Stale. All blocks in the same instance show the same badge, except content-area boundaries (grid icon) and their contents (no badge).

Deleted masters (orphaned instances)

If you delete a component master (or move it to the trash), its instances are not deleted — they stay in your posts as orphaned instances. The content is intact, but there is no master to sync from.

An orphaned instance looks like this in the editor:

List view: a gray warning badge instead of the purple component badge.
Inspector: a red callout explains the master no longer exists, and most actions are disabled — only Check Instance Integrity and Detach From Component remain available.
Editing still works. You can change properties on the instance; the edits are saved as overrides and survive if the master is restored later. Because there is no master to compare against, modified properties show the default blue dot (standalone) instead of purple/orange.

To resolve an orphan:

Detach From Component — unlinks the instance and turns it into ordinary blocks, keeping all the content.
Restore the master — if you restore the original master with the same ID (e.g. from the trash or a backup), instances automatically re-link and your orphan-era edits are kept as overrides. If the restored master gets a new ID, select it again from the Component picker to re-link.

Tip: WordPress Tools → Export includes component masters, so it’s a convenient way to back them up.

The Components screen

The Components admin screen (Components in the sidebar) lists all component masters, published or not.

Columns

The list includes several component-specific columns:

ID — the master’s post ID
Version — the master’s current version
Indexed Posts / Indexed Instances — how many posts contain instances of this master, and how many individual instances that is
Stale Posts / Stale Instances — how many posts/instances are behind the master’s version
Drift Posts / Drift Instances — how many posts/instances have a structural mismatch

Stale cells show an amber dot, drift cells a red dot.

Maintenance actions

Two buttons sit above the list (and repeat at the bottom in the Instance Tools section):

Reindex All Instances — rebuilds the instance lookup table from scratch by scanning every post. Use this if the counts look wrong or after migrating data.
Update All Stale Instances — the site-wide equivalent of “Update Component Instance”: it resyncs every stale master and updates every stale instance across the whole site.

Note: Both actions run in the background and may continue via scheduled jobs on large sites. Masters currently being edited are skipped.

All Instance Rows

The Instance Tools section also shows an All Instance Rows table — a flat view of every indexed instance with its master ID, post, block UID, version, structure hash, and status. It’s useful for spotting a single misbehaving instance.

Settings

Settings live under Components → Settings.

Setting	Description
Stale Polling Interval (seconds)	How often the editor checks for stale instances. Range 5–300, default 30.
Show Stale Notice	When on, the editor shows a notice when instances are stale. Default on.
Delete All Data on Uninstall	When on, deleting the plugin also removes all saved components from the library (masters, their metadata, and categories). Instances inside your posts/pages are always left untouched. Default off.

Strip Matching Overrides is no longer configurable — overrides that match the master value are always removed during sync/rebuild (hard-coded on).

Next steps

This documentation covers the core Component System workflow — masters, instances, overrides, content areas, sync, and the admin tools. It can be expanded later with step-by-step walkthroughs, troubleshooting guides, and worked examples for common reusable-layout patterns.