Documentation

Content types don't have to stand alone. A Services type and an FAQ type can be linked so each service shows its own FAQs — while the site still has a top-level FAQ list too. WebProCMS lets you build those connections, create the related items right where you need them, and decide whether a related item is shared across the site or belongs to just one parent.

What it gives you

• Link one type to another with a Relationship field (e.g. a Service field that points at FAQs).
• Create related items inline — a "+ New" button on the relationship field opens a quick form, so you can add an FAQ while editing the Service without leaving the page.
• Shared vs. owned items — choose whether a new related item joins the global list (reusable everywhere) or belongs only to the parent you're editing (kept out of the global list, deleted with its parent).
• A "Used by" panel on each item showing every parent that references it, so you always know where a shared item appears before you change or delete it.

Setting up a relationship

1. Edit the parent content type (e.g. Services) under Dashboard → Content Types.
2. Add a field of type Relationship.
3. Pick the Related Content Type it links to (e.g. FAQs) and choose Allow multiple items if a parent can reference more than one.
4. For a multi-item field, pick How items are chosen — the sharing mode (next section).

Now, when you edit a Service, you'll see a manager listing the FAQs on that service.

Sharing modes — hand-picked, opt-out, opt-in

A multi-item Relationship field runs in one of three modes. The shared pool the two opt modes work from is every published item of the related type — or, when the related type declares a Show On field, only the items marked for this type (see below).

• Hand-picked (the plain default) — each record lists exactly what you pick. No pool involved.
• Show all, opt out — every pool entry shows on every record automatically. On a record's edit form the entries appear in one merged list: click the eye to hide one on that record only (it grays out and stops rendering there, while every other record keeps it); click the eye again to bring it back. You can also add the record's own items — one-offs or attached extras — and drag them anywhere in the list, including between pool entries. This is the demo default for a location's Services, Reviews, and FAQs.
• Opt in — nothing shows automatically. The record's edit form lists the pool grayed out under "Sitewide … — attach one to show it here"; attach the entries that apply, and add one-offs as usual. This is the demo default for a location's Team — a location lists the people who actually work there.

Switching a field's mode

Changing the mode never changes what your pages show. Because the modes resolve differently, a naive flip would empty every record's list (going to Opt in) or surface items a record had deliberately narrowed away (going from an older field to Show all, opt out). So when you change the mode and save, WebProCMS first writes down what each record renders right now and keeps it that way:

• → Opt in — each record gets its current list attached directly, in the same order. Nothing goes blank; you can then trim each record down.
• older fields → Show all, opt out — a record that had picked a specific subset keeps exactly that subset, with the rest of the pool marked hidden on it.

A toast tells you how many records were adjusted. Picks, exclusions, and placements are all kept in storage regardless, so flipping back and forth is safe.

A field saved before modes existed keeps its old behavior ("show everything unless the record picks a subset") until you open the content type and save — saving stamps the equivalent explicit mode, with the same preservation applied.

If you need to pin a list down without changing the mode — say, before reorganizing a shared pool — run php artisan content:attach-relation-pool {type} {field} (add --dry-run to preview). It attaches each record's currently-shown items as explicit picks and is safe to re-run.

Creating related items inline

Next to the relationship picker is a "+ New {type}" button. Click it to open a quick-create form with that type's fields, fill it in, and click Create — the new item is made and attached to the parent in one step.

The quick form covers text, rich text, dates, dropdowns, toggles, and similar fields. If the related type has a required field that needs richer input (an image, a gallery, a file, or its own relationships), the "+ New" button is hidden for that type — create those items from their own page instead, then attach them with the picker.

Newly created items default to Published so they appear on the parent's page right away; switch the quick form to Draft if you're not ready.

Shared vs. "only on this item"

When you create an item inline, you choose its Visibility:

• Shared (shows in the main list) — a normal item. It appears in its type's global list (e.g. /faqs), can be attached to several parents, and is reusable across the site.
• Only on this item — an owned item. It belongs to the single parent you're editing. It's hidden from the global list, can't be picked by another parent, and is deleted automatically when its parent is deleted.

Use "Only on this item" for content that genuinely belongs to one place — an FAQ written for one service, a staff member who works at one location — so your global lists stay clean.

Owned items are managed through their parent, not the top-level list. To edit one, open the parent and use the relationship field; to see where any item is used, check the Used by panel on the item's own edit screen.

"Show On" — scoping the shared pool per type

By default the shared pool is every published item of the related type. Adding a Show On field to the related type (e.g. FAQs) narrows it per consumer:

• Every item of that type gets checkboxes — one per content type that links to it through a relationship field (All Locations, All Services, …).
• An item is only in the pool of the types it's checked for. An unchecked item stays out of everything unless a record picks it explicitly.
• The type's dashboard section gains a tab per pool (e.g. a FAQs tab on Locations) that opens the related list pre-scoped, with New pre-checking the right Show On box.

This is the shape for "some FAQs belong on every location page, some belong to one service": mark the general ones All Locations (they show everywhere via the opt-out mode, minus any per-location opt-outs), attach the specific ones (picked or owned) per record. The demo FAQs type ships with a Show On field, its starter FAQs checked for All Locations, and the FAQs — This Item design-library row renders the combined list (with FAQPage structured data) on any detail page whose type declares a relationship field named faqs targeting FAQs. The demo Reviews type ships one too — reviews are consumed by both Locations and Services, so the checkboxes route each review to the right pages.

Adding a Show On field to a type that already has items is safe. Because the field's existence redefines the pool as "marked items only", saving the type first marks every existing shared item for all the types that currently link to it — so nothing disappears from any page, and the checkboxes start out describing where each item already shows. Renaming the field carries the marks over the same way.

"New items start checked" — a switch on the Show On field. On, a freshly created item starts checked for every linked type, so it shows everywhere by default and scoping is an act of unchecking (the right default for reviews, where most entries are company-wide). Off — the default — a new item starts unchecked and shows nowhere until routed (the right default for deliberately curated pools like FAQs).

The quick-create ("+ New") form doesn't include the Show On checkboxes; open the item from its type's list to set them.

What happens to an owned item's own page?

Because an owned item has no independent place on the site, you decide what its detail URL does. On the content type's settings, Owned item detail pages offers:

• Redirect to the owner (default) — visitors are sent to the parent's page (a permanent 301 redirect). Best for inbound links and SEO.
• Show a 404 — the item has no standalone page at all.
• Keep the page (no index) — the page still renders, but is marked "no index" so search engines don't list it separately.

Owned items are also kept out of the sitemap and on-site search, so they never lead visitors to a dead end.

The "Used by" panel

Open any item's edit screen and, if other items reference it, a Used by card lists each parent and links straight to it. If a parent owns this item, that parent is flagged Owner. This makes it easy to see the impact before editing or deleting a shared item.

Editing relations from the other side

A relationship is normally managed from the parent — you pick a service's team members on the service. Sometimes the natural place to edit it is the other end: you add a new team member and choose which services list them, right from the member's page, instead of opening every service.

Turn this on per field. In the content type's field settings for a Relationship field, switch on Editable from the other side, and optionally set a Label on the other side — the heading shown on the related type's editor (e.g. "Services"). Leave the label blank to fall back to the type's name.

Once enabled, open an item of the target type and you'll find a manager listing which owner items currently reference it, with:

• Add to … — pick an owner item to link this one into.
• Remove — unlink it. This only breaks the connection; neither item is deleted.

A few things to know:

• Changes apply immediately. Adding or removing here saves the link right away — you don't need to press Save on the item.
• It's the editable twin of "Used by." The Used by panel still shows every connection (read-only, across all fields); this manager is the editable view for the one field that opted in.
• Single vs. multiple. If the parent's relationship allows only one item, adding from this side reassigns it — replacing the parent's previous pick. If it allows several, your item is appended to the list.
• Save the item first. A brand-new item that hasn't been saved yet can't be linked from this side until it exists.

Notes & limits

• Relationships are many-to-many: a shared item can belong to several parents at once.
• Editing the link is done from the parent side. The child's "Used by" panel is read-only — it shows the connections but doesn't change them.
• This connects one custom content type to another. Linking first-class areas like Locations is on the roadmap.