Resources outside the tree

A page that behaves like a MODX resource — its own URL, template, menu flags, publishing, blocks — but lives in pb_resources instead of site_content, and therefore never appears in the resource tree.

Why not just make a resource

The MODX tree is a manager tool. It is fine for the pages a person navigates: sections, articles, landing pages. It stops being fine when the pages are data.

Ten thousand cities, every company in a directory, every vacancy — as resources, they turn the tree into something nobody can open, slow down the manager, and bury the two dozen pages an editor actually edits.

Those pages still need everything a resource has: an address, a template, a title, meta, publishing. pb_resources gives them exactly that, in their own table.

What it can do

The columns mirror the ones you know:

Content	pagetitle, longtitle, description, introtext, content, menutitle
Address	alias, uri, uri_override, alias_visible
Behaviour	template, menuindex, hidemenu, isfolder, searchable, context_key
Lifecycle	published_at, deleted_at, timestamps

Plus the constructor pair — model_type and model_id for the owner, constructor_id, field_id and data. Which means a custom resource is an AbstractDataModel: constructor fields work on it, exactly as they do on a block.

It also has blocks(), so a page here is assembled in the builder like any other.

How the address is resolved

ResourceResolver looks in three places, in order:

1. a translation — so /de/uber-uns is the canonical German address;
2. site_content — an ordinary MODX resource;
3. pb_resources.

Both kinds render through the same templates. A template does not know, and does not need to know, which table its page came from.

A real resource wins a collision

If an address exists in both tables, site_content answers. That makes the custom table safe to fill from an import: a generated row cannot take over a page an editor made.

The URI builds itself

uri is recomputed on save from the alias and the owner's prefix, so you set alias and forget about it.

Two switches change that:

• uri_override — keep the uri exactly as written and stop recalculating it. For an address inherited from an old site that must not change.
• alias_visible on the parent — when off, the parent's alias is left out of the child's URI. That is how a grouping level exists in the data without showing up in the address.

When to use which

	Use
A page an editor writes and rearranges	A MODX resource
Many pages generated from data, each needing its own URL and meta	pb_resources
A page with logic and no stored row at all	A virtual page

The three coexist. A catalog section can be a resource, its thousands of items custom resources, and its filter a virtual page — on the same site, in the same templates.