@ebitex/content-mcp 1.1.258 → 1.1.264
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
|
@@ -51,7 +51,7 @@ export const HELP_TOPICS = [
|
|
|
51
51
|
{
|
|
52
52
|
"slug": "content-providers",
|
|
53
53
|
"title": "Content providers",
|
|
54
|
-
"body": "# Content providers\n\nContent providers let you bring in read-only content from an external system — a product catalog,\na digital asset manager, anything a plugin has been built for — so it sits alongside your own\nComponents everywhere you'd normally reference one: Reference fields, Presentation bindings,\npublished pages.\n\n## Registering a provider\n\nOpen **Plugins** under **Settings** in the app navigation, then select **Add plugin**. A content provider is one *type* of plugin; the **Type** list is where you choose it. Adding requires a plugin to\nalready be **activated** for your organization (an administrator does this from Hub's plugin\nsettings first — this page just registers an *instance* of an already-activated plugin).\n\n1. Choose **Content provider** as the **Type**, then the plugin from the **Plugin** dropdown.\n2. Give it a **name**, which is its **provider key** — a short, lowercase, hyphenated name (e.g. `example-products`).\n This becomes part of every reference stored against items from this provider, so **choose it\n once and don't expect to rename it later**; changing your mind means removing the plugin and\n adding it again under a new key.\n3. Fill in whatever configuration the plugin asks for — this varies per plugin, and any field\n marked sensitive (an API key, say) is write-only: once saved, you'll only ever see that it's\n set, never the value itself.\n4. Set a **cache TTL** — how long (in seconds) a fetched item is reused before Content checks the\n external system again when serving published content. Lower values mean fresher data with more\n load on the external system; higher values mean better performance but slower-to-appear\n changes.\n5. Select **Add plugin**. Content contacts the provider and pulls in the Contracts (content types)\n it describes — you'll see them show up in the Contract library, badged with the provider's\n name.\n\nIf your organization authors in more than one environment and a provider is already registered in\none of them, use **Copy from another environment** instead of registering from scratch — pick the\nsource environment and the provider key, and its full configuration (including anything sensitive)\ncomes along without you re-entering it. See [content-environments.md](content-environments.md).\n\n## Using provider content\n\nWherever you can pick a Component — a Reference field, or a Presentation's bound Component — the\npicker now shows a row of tabs: **Core** (your own content) plus one tab per registered provider.\nSwitch tabs to browse or search that provider's items; not every provider supports search, in\nwhich case the search box is disabled for that tab. Once picked, an external item behaves like any\nother reference: you can still add your own decoration on top of it (a headline, a promotional\nlabel — whatever the provider's Contract declares as an editable-here field) without touching the\nexternal system at all.\n\nIf an external item is later removed on the provider's side, or the provider becomes temporarily\nunreachable, the reference shows as unresolved rather than blocking your save — you can fix it\nwhenever the item (or the provider) is available again.\n\n## Registering your Assets library\n\n**The quick way.** If you see a **Connect Assets to Content** card at the top of this page, select\n**Connect Assets**. It turns on the Assets plugin for your organization, creates a channel named\n\"Content connection\" in Assets with a delivery key, and registers Assets in Content, in one go. The card\ntells you first what it will do and which permissions it needs, never changes anything that already\nexists, and picks up where it stopped if a step fails. The key is kept inside the registration and is\nnever shown, because nothing needs it again. The new channel hides private assets from Content, so only\npublic assets appear until you change that on the channel in Assets.\n\n**By hand.** If your organization uses Assets, register it like any other provider and pick **ebitex\nAssets** as the plugin. It asks for one thing, an **API key**. Mint that key in Assets under **Settings →\nChannels**, on the channel you want this registration to see. What the key can see is decided there,\nnot in Content: the channel's folders, its categories, and whether private assets are included. Use a\nseparate registration, with its own channel's key, for each site or audience that should see a\ndifferent slice of the library.\n\nOnce registered, a Reference field can be limited to **Image**, **Video** or **Document**, and the\npicker's Assets tab shows only those, with a thumbnail and a line such as \"Image · 1600×900 · de\nrendition\". A field that lists an Assets type must allow **Reference** (not only inline). See\n[Assets](../assets/library.md) for the library itself.\n\nA change you make in Assets reaches published pages without republishing, after a short delay: the\ncache TTL above plus the delivery cache. Deleting an asset turns every reference to it into an\nunresolved one.\n\n## Registering your Data records\n\nIf your organization uses Data, pick **ebitex Data** as the plugin. It asks for two things: a **delivery key**\nand the **partition** that key reads (its key, for example `drakeshead`). Mint the key in Data under **Settings →\nDelivery keys**, as a server key. Registering checks that the partition you typed is the one the key reads and\nrefuses it otherwise, so a typo cannot point a page at the wrong data.\n\nEach Data model appears as a read-only Contract with the same fields it has in Data: text, numbers, dates, links,\ncategories, rich text, and references to other records, each with the same \"required\" rule and the same limits on which\nmodels a reference may point at. The field that carries a record's name in Data is the Contract's title. A Reference\nfield can point at one of its records. A change you make in Data reaches published pages after a short delay (the\ncache TTL above plus the delivery cache), and a change to a model reaches Content when you refresh the plugin.\n\n### Describing a value with a Data model\n\nA Component field that allows **Inline** values can also be described by a Data model. Choose the inline option and\npick the model; Content shows its fields with their ordinary controls. The value is stored in your Content page\nand nothing is created in Data. Use this when a page needs a one-off value that has the shape of a Data model, and a\nData record when the value should be shared and managed on its own.\n\nA few things work differently from a Content Contract:\n\n- **Rich text is markdown only.** Embeds (a Component, a Presentation, a personalised variant) and token injection are not\n offered, because they need Content to supply a Template or a visitor. Write the prose and links, and leave the rest.\n- **The model decides what is valid.** If you change a model in Data and refresh, a value saved earlier is checked\n against the new fields the next time you save the page.\n- **You cannot remove a model that a page uses.** The refresh stops and lists the pages.\n- **It stays where you made it.** A page that holds one cannot be promoted or exported to another environment; remove\n the value first, or use a Data record and a reference.\n- **Only Data offers this.** A model from another provider, such as an Assets file, can still be referenced but not\n used to describe an inline value.\n\n**A record a page points at cannot be deleted in Data.** The delete is refused and the pages are listed, in every\nenvironment of your organization. Remove the reference from those pages first. If Content cannot be checked at that\nmoment the delete is refused too, with a message to try again, rather than risk leaving a page with a missing\nrecord.\n\n## Refreshing and removing\n\nProvider Contracts don't update automatically — select **Refresh Contracts** on a registration\nwhenever the external system's own content types have changed. Refreshing can add new Contracts,\nupdate existing ones, and remove ones no longer described (removal is blocked if something still\ndepends on it — a Reference field constraint or a Template's supported-Contracts list — with the\nusages listed so you can address them first).\n\n**Remove** takes a provider out entirely, along with its synced Contracts — blocked the same\nway if any content still references it. Once you confirm, existing references to that provider\nkey become permanently unresolved.\n\n## Permissions\n\nAdding, editing, refreshing, and removing providers requires its own \"Manage Content\nproviders\" permission — ask an Owner or administrator to grant it if the add/refresh/\nremove actions aren't available to you. Anyone with organization membership can view\nregistered providers and use them in a picker.\n"
|
|
54
|
+
"body": "# Content providers\n\nContent providers let you bring in read-only content from an external system — a product catalog,\na digital asset manager, anything a plugin has been built for — so it sits alongside your own\nComponents everywhere you'd normally reference one: Reference fields, Presentation bindings,\npublished pages.\n\n## Registering a provider\n\nOpen **Plugins** under **Settings** in the app navigation, then select **Add plugin**. A content provider is one *type* of plugin; the **Type** list is where you choose it. Adding requires a plugin to\nalready be **activated** for your organization (an administrator does this from Hub's plugin\nsettings first — this page just registers an *instance* of an already-activated plugin).\n\n1. Choose **Content provider** as the **Type**, then the plugin from the **Plugin** dropdown.\n2. Give it a **name**, which is its **provider key** — a short, lowercase, hyphenated name (e.g. `example-products`).\n This becomes part of every reference stored against items from this provider, so **choose it\n once and don't expect to rename it later**; changing your mind means removing the plugin and\n adding it again under a new key.\n3. Fill in whatever configuration the plugin asks for — this varies per plugin, and any field\n marked sensitive (an API key, say) is write-only: once saved, you'll only ever see that it's\n set, never the value itself.\n4. Set a **cache TTL** — how long (in seconds) a fetched item is reused before Content checks the\n external system again when serving published content. Lower values mean fresher data with more\n load on the external system; higher values mean better performance but slower-to-appear\n changes.\n5. Select **Add plugin**. Content contacts the provider and pulls in the Contracts (content types)\n it describes — you'll see them show up in the Contract library, badged with the provider's\n name.\n\nIf your organization authors in more than one environment and a provider is already registered in\none of them, use **Copy from another environment** instead of registering from scratch — pick the\nsource environment and the provider key, and its full configuration (including anything sensitive)\ncomes along without you re-entering it. See [content-environments.md](content-environments.md).\n\n## Using provider content\n\nWherever you can pick a Component — a Reference field, or a Presentation's bound Component — the\npicker now shows a row of tabs: **Core** (your own content) plus one tab per registered provider.\nSwitch tabs to browse or search that provider's items; not every provider supports search, in\nwhich case the search box is disabled for that tab. Once picked, an external item behaves like any\nother reference: you can still add your own decoration on top of it (a headline, a promotional\nlabel — whatever the provider's Contract declares as an editable-here field) without touching the\nexternal system at all.\n\nIf an external item is later removed on the provider's side, or the provider becomes temporarily\nunreachable, the reference shows as unresolved rather than blocking your save — you can fix it\nwhenever the item (or the provider) is available again.\n\n## Registering your Assets library\n\n**The quick way.** If you see a **Connect Assets to Content** card at the top of this page, select\n**Connect Assets**. It turns on the Assets plugin for your organization, creates a channel named\n\"Content connection\" in Assets with a delivery key, and registers Assets in Content, in one go. The card\ntells you first what it will do and which permissions it needs, never changes anything that already\nexists, and picks up where it stopped if a step fails. The key is kept inside the registration and is\nnever shown, because nothing needs it again. The new channel hides private assets from Content, so only\npublic assets appear until you change that on the channel in Assets. The same card appears inside an\nimage, video or document picker when Assets isn't connected yet, and the list fills in as soon as it finishes.\n\n**By hand.** If your organization uses Assets, register it like any other provider and pick **ebitex\nAssets** as the plugin. It asks for one thing, an **API key**. Mint that key in Assets under **Settings →\nChannels**, on the channel you want this registration to see. What the key can see is decided there,\nnot in Content: the channel's folders, its categories, and whether private assets are included. Use a\nseparate registration, with its own channel's key, for each site or audience that should see a\ndifferent slice of the library.\n\nOnce registered, a Reference field can be limited to **Image**, **Video** or **Document**, and the\npicker's Assets tab shows only those, with a thumbnail and a line such as \"Image · 1600×900 · de\nrendition\". A field that lists an Assets type must allow **Reference** (not only inline). See\n[Assets](../assets/library.md) for the library itself.\n\nA change you make in Assets reaches published pages without republishing, after a short delay: the\ncache TTL above plus the delivery cache. Deleting an asset turns every reference to it into an\nunresolved one.\n\n## Registering your Data records\n\nIf your organization uses Data, pick **ebitex Data** as the plugin. It asks for two things: a **delivery key**\nand the **partition** that key reads (its key, for example `drakeshead`). Mint the key in Data under **Settings →\nDelivery keys**, as a server key. Registering checks that the partition you typed is the one the key reads and\nrefuses it otherwise, so a typo cannot point a page at the wrong data.\n\nEach Data model appears as a read-only Contract with the same fields it has in Data: text, numbers, dates, links,\ncategories, rich text, and references to other records, each with the same \"required\" rule and the same limits on which\nmodels a reference may point at. The field that carries a record's name in Data is the Contract's title. A Reference\nfield can point at one of its records. A change you make in Data reaches published pages after a short delay (the\ncache TTL above plus the delivery cache), and a change to a model reaches Content when you refresh the plugin.\n\n### Describing a value with a Data model\n\nA Component field that allows **Inline** values can also be described by a Data model. Choose the inline option and\npick the model; Content shows its fields with their ordinary controls. The value is stored in your Content page\nand nothing is created in Data. Use this when a page needs a one-off value that has the shape of a Data model, and a\nData record when the value should be shared and managed on its own.\n\nA few things work differently from a Content Contract:\n\n- **Rich text is markdown only.** Embeds (a Component, a Presentation, a personalised variant) and token injection are not\n offered, because they need Content to supply a Template or a visitor. Write the prose and links, and leave the rest.\n- **The model decides what is valid.** If you change a model in Data and refresh, a value saved earlier is checked\n against the new fields the next time you save the page.\n- **You cannot remove a model that a page uses.** The refresh stops and lists the pages.\n- **It stays where you made it.** A page that holds one cannot be promoted or exported to another environment; remove\n the value first, or use a Data record and a reference.\n- **Only Data offers this.** A model from another provider, such as an Assets file, can still be referenced but not\n used to describe an inline value.\n\n**A record a page points at cannot be deleted in Data.** The delete is refused and the pages are listed, in every\nenvironment of your organization. Remove the reference from those pages first. If Content cannot be checked at that\nmoment the delete is refused too, with a message to try again, rather than risk leaving a page with a missing\nrecord.\n\n## Refreshing and removing\n\nProvider Contracts don't update automatically — select **Refresh Contracts** on a registration\nwhenever the external system's own content types have changed. Refreshing can add new Contracts,\nupdate existing ones, and remove ones no longer described (removal is blocked if something still\ndepends on it — a Reference field constraint or a Template's supported-Contracts list — with the\nusages listed so you can address them first).\n\n**Remove** takes a provider out entirely, along with its synced Contracts — blocked the same\nway if any content still references it. Once you confirm, existing references to that provider\nkey become permanently unresolved.\n\n## Permissions\n\nAdding, editing, refreshing, and removing providers requires its own \"Manage Content\nproviders\" permission — ask an Owner or administrator to grant it if the add/refresh/\nremove actions aren't available to you. Anyone with organization membership can view\nregistered providers and use them in a picker.\n"
|
|
55
55
|
},
|
|
56
56
|
{
|
|
57
57
|
"slug": "content-streams",
|
|
@@ -71,7 +71,7 @@ export const HELP_TOPICS = [
|
|
|
71
71
|
{
|
|
72
72
|
"slug": "contracts",
|
|
73
73
|
"title": "Modeling content with Contracts",
|
|
74
|
-
"body": "# Modeling content with Contracts\n\nContracts define the field structure your content adheres to — think of a\nContract as a blueprint (for example \"Article\" or \"Author\") that every\nComponent built from it must follow. You need to belong to an organization to\nuse it — see [Creating an organization and inviting\nteammates](../hub/organizations.md) if you haven't set one up yet.\n\n## The Contracts list\n\n**Modeling > Contracts** lists every Contract with its name, its id (smaller, underneath), whether it is\nconcrete or abstract, which Contract it extends, how many fields it has, what it is used as, and when it\nlast changed.\n\n**What a Contract is used for is worked out from how it is used, never set by hand.** The row of buttons above\nthe list filters by it, with a count on each, and a Contract can sit in several at once:\n\n- **Components** — Components have been created from it.\n- **Experiences** — a Component of this Contract is the content of a page in your Experience tree.\n- **Templates** — it is a Template's own settings Contract. (A Contract a Template merely *supports* is an\n ordinary content Contract, so it shows under Components, not here.)\n- **Base** — it is abstract, or other Contracts extend it.\n- **Not used yet** — nothing references it. This is the clean-up list.\n\nThe **Used as** column spells it out, for example *Components 17 · Experiences 4*. Search matches a name or an\nid, and **Kind** and **Source** narrow further (a Contract can come from a provider, or be inherited from\nanother environment; both are read-only here and say so).\n\nEach row's **⋯** menu offers **Open** (or **View**, for one you can't edit), **Where used** and **Delete…**.\nDelete is switched off while anything uses the Contract, and says how many places do. Tick several rows to\ndelete them together; it tells you how many of the selection it can actually delete.\n\n## Creating a Contract\n\n1. From the Contracts list, select **New Contract**.\n2. Switch to the **General** tab. Enter a **Name** — everything else below\n fills in from it, so filling it in first saves retyping. **Id** — a\n short, URL-safe identifier made of lowercase letters, numbers, and\n hyphens — fills in from Name automatically; you can still edit it by\n hand before saving.\n3. Turn on **Abstract** if this Contract exists only to be extended by\n other Contracts, or to constrain what a field is allowed to point at —\n an abstract Contract can't be used to create content directly.\n4. Optionally choose a **Parent Contract**. Every field the parent\n declares is inherited automatically and shown read-only under\n \"Inherited fields\" on the **Fields** tab — you can't redefine or hide an\n inherited field, only add new ones of your own.\n You can also choose **Based on a platform Contract**. A platform Contract is one the product\n provides (today, **Unlock page**) and always brings its own fields, read-only and first in the list.\n Base a Contract on **Unlock page** to make its Experiences usable as the page visitors see when they may\n not read a members-only page (see [Members-only pages](visitor-access.md)). Setting or changing it adds or removes fields,\n so it can be a breaking change, and you are asked to confirm when it is.\n5. Switch to the **Fields** tab (the default tab). The fields are a list on the left and the\n selected field's settings are on the right. Select **Add field** and choose a type from the\n searchable list (each type says what it is for); the new field opens for you to name. Then fill in\n its Name and Id, change its type with **Change…**, and turn its modifiers on or off (see below).\n Repeat for every field the Contract needs; drag a row by its handle to reorder it (or, from the\n keyboard, use the **Move up** and **Move down** buttons on the field, or focus the handle, press\n Space to pick it up, use the arrow keys to move it, and Space again to drop it), or select\n **Delete field** to remove one. Fields inherited from a parent are collected under their own\n heading, collapsed; select one to see its settings, read-only. A row with an unresolved error shows\n a warning mark, and a failed save selects the first field that needs attention — or, for an error on\n the General tab (Name, Id, Parent Contract), switches you back to that tab.\n6. A bar at the bottom counts your **unsaved changes** (select it to see each one in words: \"Added the\n field Heading\", \"Turned on Mandatory for Body\") and says how saving will land. A change that would\n make existing Components fail validation shows **Breaking change** *before* you save; saving it\n asks you to confirm and names each reason, because it creates a new *version* (see \"Versions\"\n below). **Discard** puts every edit back. Select **Save changes** (or **Create Contract** for a new\n one) — the bar is visible from every tab.\n\n### Asking the assistant to draft one\n\nIf your organization has the assistant turned on, you can describe a Contract instead of building it field\nby field. On the New Contract form, open the assistant (the magenta ebitex-mark icon in the header, beside\n**?**) and ask — for example, \"Create me a Contract for a CTA Banner\". It proposes a Contract as a\n**Suggested** card listing the name and each field with its type. Nothing is saved until you select\n**Accept**, which fills in the form and saves it the same way **Create Contract** does; **Dismiss** discards\nit. Either way you can keep editing afterwards. See [Getting help](../general/getting-help.md).\n\n## Field types and modifiers\n\nEvery field has a **Field type** (Text, Number, Boolean, Date, Link,\nComponent, Blob, Presentation, Rich Text, or Category — Short Text, Long Text,\nURL, Reference, Nested, and Experience Reference are deprecated and no longer\noffered for new fields, though any field already using one keeps working\nunchanged; see \"Text fields\" and \"Component fields\" below) plus up to five\nindependent modifiers, each shown as a toggle whose label changes with\nits state:\n\n- **Mandatory / Optional** — required, or not. For a Contextual field,\n this only applies where the field is actually used, not on the\n Component itself (see \"Contextual fields\" in\n [Authoring Components](components.md)).\n- **Multiple / Single** — a list of values instead of one.\n- **Localized / Same in every locale** — a default value plus per-locale\n overrides.\n- **Contextual / On the Component** — the value lives where the field is\n *used*, not on the Component that declares it — useful for something\n like a \"theme\" that should vary by where content is placed, not by the\n content itself.\n- **Personalized / Same for every audience** — audience-conditioned\n variant alternatives — see\n [Personalizing content by audience](content-personalization.md).\n\nSome field types add an extra toggle of their own alongside these five —\nfor example, Text and Rich Text both show an **Allow\ntoken injection** toggle, since it's specific to text-bearing fields\nrather than something every field type needs.\n\nEach field type has its own extra settings, shown once you pick a type —\nfor example, Text has an optional pattern plus\nlength limits, all grouped together under **Validation** (a label you\nselect to expand, staying expanded automatically whenever something\ninside still needs your attention), Component lets you restrict which\nContracts are allowed (and, optionally, which of the two modes below), and\nBlob lets you restrict file types and maximum size.\n\n### Date fields\n\nA **Date** field has one extra setting, **Include time** — off shows and\nedits just a calendar date; on adds a time of day too. Either way, the\ndate/time you enter is shown in your own local time zone, and switching\nthis setting on or off later is a normal (additive) change, not something\nthat requires a new version.\n\n### Text fields\n\n**Text** is the one plain-text type. Turn on **Multiple lines** in its\nsettings and the editor becomes a larger box that keeps line breaks;\nleave it off for a single line such as a title. Either way the stored\nvalue is the same plain string, so switching the setting later never\nchanges or loses anything already written.\n\n**Short Text** and **Long Text** are the two types Text replaces. A field\nthat already uses one keeps working, but a new field cannot take it. To\nmove an existing field over, open it and choose **Convert to Text**: its\nsettings carry over unchanged (a Long Text field also becomes **Multiple\nlines**), every value already written is kept as it is, and the change\ndoes not by itself create a new Contract version.\n\n### Restricting a field to a fixed list of values\n\nText, Number, and Date fields can be restricted to a\nfixed set of **Allowed values** in their settings — useful for something\nlike a status field that should only ever be \"Draft,\" \"In review,\" or\n\"Published,\" rather than any free-text string. Leave it empty to allow\nany value.\n\nHow the field is edited then depends on whether it also allows multiple\nvalues and how many options you listed: a small list of single-value\noptions shows as buttons to pick one of; a longer list shows as a\ndropdown; combined with **Multiple**, a small list shows as checkboxes and\na longer one as a searchable picker. Narrowing this list later (removing a\nvalue that was previously allowed) is a breaking change, since an\nexisting Component might already hold it; adding a new value is additive.\n\n### Picking options from another system\n\nInstead of typing a fixed list of Allowed values, a Text field can\nname a **Choice source** — an activated plugin that supplies the option\nlist live, kept automatically in sync with whatever it's connected to.\nThe first one, **ebitex Forms**, lists your organization's own published\nForms, so you can pick a form by name rather than typing its id — useful\nfor a field like \"which form should appear on this page.\" A field can use\neither Allowed values or a Choice source, never both.\n\nOnce a Choice source plugin is activated (in your organization's Settings)\nand picked in a field's settings, editing a Component with that field\nlooks exactly like a normal fixed-list field: buttons, a dropdown,\ncheckboxes, or a searchable picker, depending on how many options there\nare. If the source is temporarily unavailable — a misconfigured\nconnection, for example — you'll see a short message explaining that, and\nthe field falls back to a plain text box so you can still see and edit\nwhatever value is already saved; nothing else on the page is blocked from\nsaving while that happens.\n\n### Giving a field a default value\n\nMost field types — anything other than Component, Presentation, Rich\nText, and Category, which all point at other content rather than holding\na plain value — can be given a **Default value** in their expanded row.\nOnce set, every brand-new Component created from this Contract starts\nwith that value already filled in, instead of empty; editing or clearing\nthe default afterward never changes a Component that already exists. For a\nContextual field, its default becomes the Component's own fallback value —\nused whenever a specific placement doesn't override it.\n\n## Component fields\n\nA **Component** field holds a reference to another Component, an inline\n(embedded) value, or either — decided by whoever is *filling in* the field,\nnot fixed when you design the Contract:\n\n- **Linked** — points at another Component elsewhere in your organization;\n the two stay separate, and deleting a Component that's linked elsewhere\n is blocked until the link is removed first. Covers both picking an\n existing Component and creating a brand-new one to link to.\n- **Inline** — embeds another Component's content directly inside; there's\n no separate entity to manage, it's just part of the same document. Best\n for content that only ever makes sense as part of its parent (for\n example, an article's author details).\n\nIf you want to guarantee only one of these for a given field — say, a\n\"related articles\" field that should always link to a reusable Component,\nnever an inline one-off — the field's settings offer **Allowed value\nmodes**, a checklist of the two options above (at least one must stay\nchecked). Leaving both checked (the default) lets whoever fills in the\nfield choose either way each time. Either way, **allowedContractIds** lets\nyou restrict which Contracts are allowed. The list has three states, and the\nbuilder says which one it is in: **Any Contract** (nothing set, so any Contract,\nincluding descendants of one you do list), a list of Contracts (exactly those),\nand **Nothing allowed** (an empty list: no Contract can be chosen). **Allow any**\nclears the list back to the first state, **Allow none** empties it, and removing\nthe last Contract from a list leaves **Nothing allowed** rather than silently\nallowing everything. The same three states apply to every allow-list in a\nfield's settings (Templates, category groups, link kinds and protocols, inline\nembed kinds, markdown features and content types). Value modes are the exception:\na field must allow at least one, so that list can be left out but never emptied.\n\nExisting Contracts may still have the older, separate **Reference** and\n**Nested** field types — a Reference field is equivalent to a Component\nfield restricted to Linked only, and a Nested field to one restricted to\nInline only. They keep working exactly as before; a new field just uses\nComponent instead.\n\n## Giving a Contract a title field\n\nContent built from a Contract needs a human label — the name shown in a site's\nnavigation menu, in a breadcrumb trail, and beside each item in a listing.\n**Title field** on the **General** tab is where you choose which field that\nlabel comes from.\n\nIt is a picker, not something you type. Choose a field; if the field you chose\nholds a nested block, a second dropdown appears so you can choose the field\ninside it — up to four levels deep. Only fields a title can actually come from\nare offered: text fields as the final choice, and nested blocks as the steps in\nbetween.\n\n**Set it once, on the most general Contract that has the field.** The choice is\ninherited, so if your \"Web page\" Contract declares its `title` field, every\nContract that extends it — Article, Landing page, and so on — uses the same one\nwith nothing more to set up. A Contract that needs a different field can choose\nits own, which takes over. When a Contract inherits its title field, the picker\nshows it read-only and names the Contract it came from, with **Override** to\nchoose a different one and **Clear** to remove it.\n\nA few notes on what to expect:\n\n- **It applies from the next publish.** Choosing a title field doesn't change\n anything already published — each Component picks it up when it is next\n published.\n- **Editing the title text is a Component publish.** Change the wording and\n republish that Component, and its label updates everywhere it appears. You do\n not need to republish the pages that use it.\n- **If it can't be resolved, the page's own name is used instead** — its\n internal name from Composer. That happens when no Contract in the chain\n declares a title field, when the field named no longer exists, or when the\n content isn't published. Nothing breaks; you just see the internal name, which\n is a good hint that the title field needs attention.\n- **A localizable title field is worth choosing.** One value covers every\n locale, and each visitor sees theirs.\n\nIf the same piece of content appears in more than one place and should be named\ndifferently at each, make the title field **contextual** — then each page that\nuses it supplies its own wording. Bear in mind that a contextual title belongs to\nthe page, so changing it means republishing that page rather than the content.\n\n## Editing fields as a tree\n\nSome content refers to more of the same kind of content: a dog has a sire and a\ndam who are dogs too, a product is built from parts that are products, a person\nreports to a person. Building that with one picker per field means creating the\nfurthest ancestor first and working back towards the one you actually wanted.\n\n**Editing layout**, pinned under the fields on the **Fields** tab, changes that. Choose\n**Edit as a tree** and the Component editor draws those fields as one tree, where you fill in any\nslot directly. It only changes how the fields are edited. The fields, their validation and what is\npublished are exactly as before, and it creates no new Contract version, so a change to just the\nlayout is saved without a version bump. A preview beside the settings draws the chart or outline you\nhave chosen, using your own field names, and the fields in the tree carry an **In tree** chip.\nRenaming a field in the tree updates the layout, and removing it, or changing it to a type a tree\ncan't use, takes it out of the layout.\n\nTo set it up:\n\n1. Give the Contract the fields that point at itself: two or more single-value\n Component fields (a sire and a dam), or one list field (parts). Each should\n allow the Contract, or a Contract that extends it.\n2. On **Fields**, select **Editing layout**, then choose **Edit as a tree**.\n3. Tick the fields that make up the tree and choose how many generations (or\n levels) to show.\n4. Choose whether the same Component may appear more than once.\n\n**Repeats.** *Allow across branches* lets one Component sit in several places, as\nin line-breeding or a part used in two assemblies. *Never* means each Component\nmay appear once in the whole tree, which suits an org chart or a taxonomy. If\nyou switch to *Never* on content that already repeats, the repeats are kept and\nnothing is rewritten; only a new repeat is refused. Either way, something can\nnever contain itself.\n\n**Inheritance.** Like the title field, the choice is inherited. Set it once on the\ngeneral Contract (a \"Pedigree dog\") and every Contract that extends it, such as\n\"Dog\" and \"Bitch\", edits as a tree. A Contract can choose its own, or choose\n*Ordinary fields (do not inherit the tree)* to opt out.\n\nIf the fields you tick no longer exist or no longer fit, the editor simply shows\nthe ordinary fields, so a Contract is never left uneditable.\n\n## Links to your site\n\nA Component has no page of its own, so nothing in Content takes you from a\nComponent to the page on your site that shows it. **External links** on the\n**General** tab adds that. Each link is a button in the Component editor that\nopens the page for the Component you are looking at, for example a dog's\nprintable pedigree or a blog post on the live site.\n\nTo add one:\n\n1. On **General**, under **External links**, choose **Declare links**.\n2. Give the link a **Label**, the words on the button.\n3. Write the **URL template**. It starts with `{origin}`, `https://` or\n `http://`, and can use the Component's own details:\n - `{id}` and `{externalId}`: the Component's id and external id.\n - `{field:name}`: the value of one of its fields. A field inside an inline\n value is written with dots, such as `{field:owner.name}`.\n - `{key:sire}`: the **key** of the record a reference field points at, for\n a page that is addressed by that key. A litter can link to a pedigree\n page with `{origin}/pedigree?sire={key:sire}&dam={key:dam}`. A reference\n with nothing chosen, or a value written in by hand rather than chosen\n from the records, leaves its place empty, so a litter with an outside dam\n still links; the link is switched off only when none of the `{key:}`\n fields has a value.\n - `{origin}`: the address of the **Site** you choose, always followed by a\n `/`. It is how one Contract can point at the right host in every\n environment.\n4. Choose the **Site** (when you used `{origin}`) and whether the link is\n **Enabled** always or **Once published**.\n\nA live example under the form shows the link built from one of this Contract's\nown Components, so you can see it before you save. You can add up to five links.\n\n**What authors see.** A link that works opens in a new tab. A link that cannot\nwork is greyed and says why beside it: *Publish this Component first* for a\ndraft, *Needs a value for \"name\"* when a field it uses is empty, or that the Site\nhas no host yet. A Component with unpublished changes still has a live page, so\nits link works and says it shows the published version.\n\n**Safe by design.** A value from a field can never change where a link points:\nvalues are encoded into one part of the address, and the template's scheme and\nhost cannot use fields at all.\n\n**Nothing else changes.** Links are only shown in the editor. They create no new\nContract version, change no Component and appear in nothing your site receives.\nLike the tree, they are inherited: a Contract can declare its own, or choose\n*No links (do not inherit)*.\n\n## Versions\n\nEvery save is classified automatically:\n\n- **Additive** changes (adding an optional field, loosening a limit, …)\n update the Contract's current version in place.\n- **Breaking** changes (removing a field, adding a *mandatory* field,\n tightening a limit, …) create a new version, leaving the old one intact\n so Components already pinned to it keep working.\n\nThe **History** tab on a Contract's page lists every version and\nwhat fields it resolved to. Existing Components aren't forced to update\nwhen a Contract changes — see \"The upgrade badge\" in\n[Authoring Components](components.md) for how that friction is surfaced\nand resolved.\n"
|
|
74
|
+
"body": "# Modeling content with Contracts\n\nContracts define the field structure your content adheres to — think of a\nContract as a blueprint (for example \"Article\" or \"Author\") that every\nComponent built from it must follow. You need to belong to an organization to\nuse it — see [Creating an organization and inviting\nteammates](../hub/organizations.md) if you haven't set one up yet.\n\n## The Contracts list\n\n**Modeling > Contracts** lists every Contract with its name, its id (smaller, underneath), whether it is\nconcrete or abstract, which Contract it extends, how many fields it has, what it is used as, and when it\nlast changed.\n\n**What a Contract is used for is worked out from how it is used, never set by hand.** The row of buttons above\nthe list filters by it, with a count on each, and a Contract can sit in several at once:\n\n- **Components** — Components have been created from it.\n- **Experiences** — a Component of this Contract is the content of a page in your Experience tree.\n- **Templates** — it is a Template's own settings Contract. (A Contract a Template merely *supports* is an\n ordinary content Contract, so it shows under Components, not here.)\n- **Base** — it is abstract, or other Contracts extend it.\n- **Not used yet** — nothing references it. This is the clean-up list.\n\nThe **Used as** column spells it out, for example *Components 17 · Experiences 4*. Search matches a name or an\nid, and **Kind** and **Source** narrow further (a Contract can come from a provider, or be inherited from\nanother environment; both are read-only here and say so).\n\nEach row's **⋯** menu offers **Open** (or **View**, for one you can't edit), **Where used** and **Delete…**.\nDelete is switched off while anything uses the Contract, and says how many places do. Tick several rows to\ndelete them together; it tells you how many of the selection it can actually delete.\n\n## Creating a Contract\n\n1. From the Contracts list, select **New Contract**.\n2. Switch to the **General** tab. Enter a **Name** — everything else below\n fills in from it, so filling it in first saves retyping. **Id** — a\n short, URL-safe identifier made of lowercase letters, numbers, and\n hyphens — fills in from Name automatically; you can still edit it by\n hand before saving.\n3. Turn on **Abstract** if this Contract exists only to be extended by\n other Contracts, or to constrain what a field is allowed to point at —\n an abstract Contract can't be used to create content directly.\n4. Optionally choose a **Parent Contract**. Every field the parent\n declares is inherited automatically and shown read-only under\n \"Inherited fields\" on the **Fields** tab — you can't redefine or hide an\n inherited field, only add new ones of your own.\n You can also choose **Based on a platform Contract**. A platform Contract is one the product\n provides (today, **Unlock page**) and always brings its own fields, read-only and first in the list.\n Base a Contract on **Unlock page** to make its Experiences usable as the page visitors see when they may\n not read a members-only page (see [Members-only pages](visitor-access.md)). Setting or changing it adds or removes fields,\n so it can be a breaking change, and you are asked to confirm when it is.\n5. Switch to the **Fields** tab (the default tab). The fields are a list on the left and the\n selected field's settings are on the right. Select **Add field** and choose a type from the\n searchable list (each type says what it is for); the new field opens for you to name. Then fill in\n its Name and Id, change its type with **Change…**, and turn its modifiers on or off (see below).\n Repeat for every field the Contract needs; drag a row by its handle to reorder it (or, from the\n keyboard, use the **Move up** and **Move down** buttons on the field, or focus the handle, press\n Space to pick it up, use the arrow keys to move it, and Space again to drop it), or select\n **Delete field** to remove one. Fields inherited from a parent are collected under their own\n heading, collapsed; select one to see its settings, read-only. A row with an unresolved error shows\n a warning mark, and a failed save selects the first field that needs attention — or, for an error on\n the General tab (Name, Id, Parent Contract), switches you back to that tab.\n6. A bar at the bottom counts your **unsaved changes** (select it to see each one in words: \"Added the\n field Heading\", \"Turned on Mandatory for Body\") and says how saving will land. A change that would\n make existing Components fail validation shows **Breaking change** *before* you save; saving it\n asks you to confirm and names each reason, because it creates a new *version* (see \"Versions\"\n below). **Discard** puts every edit back. Select **Save changes** (or **Create Contract** for a new\n one) — the bar is visible from every tab.\n\n### Asking the assistant to draft one\n\nIf your organization has the assistant turned on, you can describe a Contract instead of building it field\nby field. On the New Contract form, open the assistant (the magenta ebitex-mark icon in the header, beside\n**?**) and ask — for example, \"Create me a Contract for a CTA Banner\". It proposes a Contract as a\n**Suggested** card listing the name and each field with its type. Nothing is saved until you select\n**Accept**, which fills in the form and saves it the same way **Create Contract** does; **Dismiss** discards\nit. Either way you can keep editing afterwards. See [Getting help](../general/getting-help.md).\n\n## Field types and modifiers\n\nEvery field has a **Field type** (Text, Number, Boolean, Date, Link,\nComponent, Blob, Presentation, Rich Text, or Category — Short Text, Long Text,\nURL, Reference, Nested, and Experience Reference are deprecated and no longer\noffered for new fields, though any field already using one keeps working\nunchanged; see \"Text fields\" and \"Component fields\" below) plus up to five\nindependent modifiers, each shown as a toggle whose label changes with\nits state:\n\n- **Mandatory / Optional** — required, or not. For a Contextual field,\n this only applies where the field is actually used, not on the\n Component itself (see \"Contextual fields\" in\n [Authoring Components](components.md)).\n- **Multiple / Single** — a list of values instead of one.\n- **Localized / Same in every locale** — a default value plus per-locale\n overrides.\n- **Contextual / On the Component** — the value lives where the field is\n *used*, not on the Component that declares it — useful for something\n like a \"theme\" that should vary by where content is placed, not by the\n content itself.\n- **Personalized / Same for every audience** — audience-conditioned\n variant alternatives — see\n [Personalizing content by audience](content-personalization.md).\n\nSome field types add an extra toggle of their own alongside these five —\nfor example, Text and Rich Text both show an **Allow\ntoken injection** toggle, since it's specific to text-bearing fields\nrather than something every field type needs.\n\nEach field type has its own extra settings, shown once you pick a type —\nfor example, Text has an optional pattern plus\nlength limits, all grouped together under **Validation** (a label you\nselect to expand, staying expanded automatically whenever something\ninside still needs your attention), Component lets you restrict which\nContracts are allowed (and, optionally, which of the two modes below), and\nBlob lets you restrict file types and maximum size.\n\n### Date fields\n\nA **Date** field has a **Kind of value**, which decides what it stores:\n\n- **Instant (a moment in time)** is the default. It stores one exact moment.\n Its **Include time** setting is off to show and edit just a calendar date, or\n on to add a time of day. The date or time you enter is shown in your own\n local time zone, and switching **Include time** later is a normal (additive)\n change, not something that requires a new version.\n- **Calendar date (no time zone)** stores a day such as `2026-12-25`, for a\n birthday, an anniversary or a \"valid from\" date. It means the same day\n everywhere.\n- **Time of day (no time zone)** stores a clock time such as `16:00`, for\n opening hours or a doors-open time. It means the same time wherever the\n viewer is, so keep the place's own time zone in a separate field if it\n matters. A time that is after midnight, such as closing at 2 AM, is stored as\n `02:00`; the model that uses it decides it means the next morning.\n\nThe editor shows a date picker for a calendar date and a time picker for a time\nof day. Changing the **Kind of value** of a field that already has values\nchanges the shape of what is stored, so it is a breaking change: ebitex asks you\nto save a new version, and existing values are not converted.\n\n### Text fields\n\n**Text** is the one plain-text type. Turn on **Multiple lines** in its\nsettings and the editor becomes a larger box that keeps line breaks;\nleave it off for a single line such as a title. Either way the stored\nvalue is the same plain string, so switching the setting later never\nchanges or loses anything already written.\n\n**Short Text** and **Long Text** are the two types Text replaces. A field\nthat already uses one keeps working, but a new field cannot take it. To\nmove an existing field over, open it and choose **Convert to Text**: its\nsettings carry over unchanged (a Long Text field also becomes **Multiple\nlines**), every value already written is kept as it is, and the change\ndoes not by itself create a new Contract version.\n\n### Restricting a field to a fixed list of values\n\nText, Number, and Date fields can be restricted to a\nfixed set of **Allowed values** in their settings — useful for something\nlike a status field that should only ever be \"Draft,\" \"In review,\" or\n\"Published,\" rather than any free-text string. Leave it empty to allow\nany value.\n\nHow the field is edited then depends on whether it also allows multiple\nvalues and how many options you listed: a small list of single-value\noptions shows as buttons to pick one of; a longer list shows as a\ndropdown; combined with **Multiple**, a small list shows as checkboxes and\na longer one as a searchable picker. Narrowing this list later (removing a\nvalue that was previously allowed) is a breaking change, since an\nexisting Component might already hold it; adding a new value is additive.\n\n### Picking options from another system\n\nInstead of typing a fixed list of Allowed values, a Text field can\nname a **Choice source** — an activated plugin that supplies the option\nlist live, kept automatically in sync with whatever it's connected to.\nThe first one, **ebitex Forms**, lists your organization's own published\nForms, so you can pick a form by name rather than typing its id — useful\nfor a field like \"which form should appear on this page.\" A field can use\neither Allowed values or a Choice source, never both.\n\nOnce a Choice source plugin is activated (in your organization's Settings)\nand picked in a field's settings, editing a Component with that field\nlooks exactly like a normal fixed-list field: buttons, a dropdown,\ncheckboxes, or a searchable picker, depending on how many options there\nare. If the source is temporarily unavailable — a misconfigured\nconnection, for example — you'll see a short message explaining that, and\nthe field falls back to a plain text box so you can still see and edit\nwhatever value is already saved; nothing else on the page is blocked from\nsaving while that happens.\n\n### Giving a field a default value\n\nMost field types — anything other than Component, Presentation, Rich\nText, and Category, which all point at other content rather than holding\na plain value — can be given a **Default value** in their expanded row.\nOnce set, every brand-new Component created from this Contract starts\nwith that value already filled in, instead of empty; editing or clearing\nthe default afterward never changes a Component that already exists. For a\nContextual field, its default becomes the Component's own fallback value —\nused whenever a specific placement doesn't override it.\n\n## Component fields\n\nA **Component** field holds a reference to another Component, an inline\n(embedded) value, or either — decided by whoever is *filling in* the field,\nnot fixed when you design the Contract:\n\n- **Linked** — points at another Component elsewhere in your organization;\n the two stay separate, and deleting a Component that's linked elsewhere\n is blocked until the link is removed first. Covers both picking an\n existing Component and creating a brand-new one to link to.\n- **Inline** — embeds another Component's content directly inside; there's\n no separate entity to manage, it's just part of the same document. Best\n for content that only ever makes sense as part of its parent (for\n example, an article's author details).\n\nIf you want to guarantee only one of these for a given field — say, a\n\"related articles\" field that should always link to a reusable Component,\nnever an inline one-off — the field's settings offer **Allowed value\nmodes**, a checklist of the two options above (at least one must stay\nchecked). Leaving both checked (the default) lets whoever fills in the\nfield choose either way each time. Either way, **allowedContractIds** lets\nyou restrict which Contracts are allowed. The list has three states, and the\nbuilder says which one it is in: **Any Contract** (nothing set, so any Contract,\nincluding descendants of one you do list), a list of Contracts (exactly those),\nand **Nothing allowed** (an empty list: no Contract can be chosen). **Allow any**\nclears the list back to the first state, **Allow none** empties it, and removing\nthe last Contract from a list leaves **Nothing allowed** rather than silently\nallowing everything. The same three states apply to every allow-list in a\nfield's settings (Templates, category groups, link kinds and protocols, inline\nembed kinds, markdown features and content types). Value modes are the exception:\na field must allow at least one, so that list can be left out but never emptied.\n\nExisting Contracts may still have the older, separate **Reference** and\n**Nested** field types — a Reference field is equivalent to a Component\nfield restricted to Linked only, and a Nested field to one restricted to\nInline only. They keep working exactly as before; a new field just uses\nComponent instead.\n\n## Giving a Contract a title field\n\nContent built from a Contract needs a human label — the name shown in a site's\nnavigation menu, in a breadcrumb trail, and beside each item in a listing.\n**Title field** on the **General** tab is where you choose which field that\nlabel comes from.\n\nIt is a picker, not something you type. Choose a field; if the field you chose\nholds a nested block, a second dropdown appears so you can choose the field\ninside it — up to four levels deep. Only fields a title can actually come from\nare offered: text fields as the final choice, and nested blocks as the steps in\nbetween.\n\n**Set it once, on the most general Contract that has the field.** The choice is\ninherited, so if your \"Web page\" Contract declares its `title` field, every\nContract that extends it — Article, Landing page, and so on — uses the same one\nwith nothing more to set up. A Contract that needs a different field can choose\nits own, which takes over. When a Contract inherits its title field, the picker\nshows it read-only and names the Contract it came from, with **Override** to\nchoose a different one and **Clear** to remove it.\n\nA few notes on what to expect:\n\n- **It applies from the next publish.** Choosing a title field doesn't change\n anything already published — each Component picks it up when it is next\n published.\n- **Editing the title text is a Component publish.** Change the wording and\n republish that Component, and its label updates everywhere it appears. You do\n not need to republish the pages that use it.\n- **If it can't be resolved, the page's own name is used instead** — its\n internal name from Composer. That happens when no Contract in the chain\n declares a title field, when the field named no longer exists, or when the\n content isn't published. Nothing breaks; you just see the internal name, which\n is a good hint that the title field needs attention.\n- **A localizable title field is worth choosing.** One value covers every\n locale, and each visitor sees theirs.\n\nIf the same piece of content appears in more than one place and should be named\ndifferently at each, make the title field **contextual** — then each page that\nuses it supplies its own wording. Bear in mind that a contextual title belongs to\nthe page, so changing it means republishing that page rather than the content.\n\n## Editing fields as a tree\n\nSome content refers to more of the same kind of content: a dog has a sire and a\ndam who are dogs too, a product is built from parts that are products, a person\nreports to a person. Building that with one picker per field means creating the\nfurthest ancestor first and working back towards the one you actually wanted.\n\n**Editing layout**, pinned under the fields on the **Fields** tab, changes that. Choose\n**Edit as a tree** and the Component editor draws those fields as one tree, where you fill in any\nslot directly. It only changes how the fields are edited. The fields, their validation and what is\npublished are exactly as before, and it creates no new Contract version, so a change to just the\nlayout is saved without a version bump. A preview beside the settings draws the chart or outline you\nhave chosen, using your own field names, and the fields in the tree carry an **In tree** chip.\nRenaming a field in the tree updates the layout, and removing it, or changing it to a type a tree\ncan't use, takes it out of the layout.\n\nTo set it up:\n\n1. Give the Contract the fields that point at itself: two or more single-value\n Component fields (a sire and a dam), or one list field (parts). Each should\n allow the Contract, or a Contract that extends it.\n2. On **Fields**, select **Editing layout**, then choose **Edit as a tree**.\n3. Tick the fields that make up the tree and choose how many generations (or\n levels) to show.\n4. Choose whether the same Component may appear more than once.\n\n**Repeats.** *Allow across branches* lets one Component sit in several places, as\nin line-breeding or a part used in two assemblies. *Never* means each Component\nmay appear once in the whole tree, which suits an org chart or a taxonomy. If\nyou switch to *Never* on content that already repeats, the repeats are kept and\nnothing is rewritten; only a new repeat is refused. Either way, something can\nnever contain itself.\n\n**Inheritance.** Like the title field, the choice is inherited. Set it once on the\ngeneral Contract (a \"Pedigree dog\") and every Contract that extends it, such as\n\"Dog\" and \"Bitch\", edits as a tree. A Contract can choose its own, or choose\n*Ordinary fields (do not inherit the tree)* to opt out.\n\nIf the fields you tick no longer exist or no longer fit, the editor simply shows\nthe ordinary fields, so a Contract is never left uneditable.\n\n## Links to your site\n\nA Component has no page of its own, so nothing in Content takes you from a\nComponent to the page on your site that shows it. **External links** on the\n**General** tab adds that. Each link is a button in the Component editor that\nopens the page for the Component you are looking at, for example a dog's\nprintable pedigree or a blog post on the live site.\n\nTo add one:\n\n1. On **General**, under **External links**, choose **Declare links**.\n2. Give the link a **Label**, the words on the button.\n3. Write the **URL template**. It starts with `{origin}`, `https://` or\n `http://`, and can use the Component's own details:\n - `{id}` and `{externalId}`: the Component's id and external id.\n - `{field:name}`: the value of one of its fields. A field inside an inline\n value is written with dots, such as `{field:owner.name}`.\n - `{key:sire}`: the **key** of the record a reference field points at, for\n a page that is addressed by that key. A litter can link to a pedigree\n page with `{origin}/pedigree?sire={key:sire}&dam={key:dam}`. A reference\n with nothing chosen, or a value written in by hand rather than chosen\n from the records, leaves its place empty, so a litter with an outside dam\n still links; the link is switched off only when none of the `{key:}`\n fields has a value.\n - `{origin}`: the address of the **Site** you choose, always followed by a\n `/`. It is how one Contract can point at the right host in every\n environment.\n4. Choose the **Site** (when you used `{origin}`) and whether the link is\n **Enabled** always or **Once published**.\n\nA live example under the form shows the link built from one of this Contract's\nown Components, so you can see it before you save. You can add up to five links.\n\n**What authors see.** A link that works opens in a new tab. A link that cannot\nwork is greyed and says why beside it: *Publish this Component first* for a\ndraft, *Needs a value for \"name\"* when a field it uses is empty, or that the Site\nhas no host yet. A Component with unpublished changes still has a live page, so\nits link works and says it shows the published version.\n\n**Safe by design.** A value from a field can never change where a link points:\nvalues are encoded into one part of the address, and the template's scheme and\nhost cannot use fields at all.\n\n**Nothing else changes.** Links are only shown in the editor. They create no new\nContract version, change no Component and appear in nothing your site receives.\nLike the tree, they are inherited: a Contract can declare its own, or choose\n*No links (do not inherit)*.\n\n## Versions\n\nEvery save is classified automatically:\n\n- **Additive** changes (adding an optional field, loosening a limit, …)\n update the Contract's current version in place.\n- **Breaking** changes (removing a field, adding a *mandatory* field,\n tightening a limit, …) create a new version, leaving the old one intact\n so Components already pinned to it keep working.\n\nThe **History** tab on a Contract's page lists every version and\nwhat fields it resolved to. Existing Components aren't forced to update\nwhen a Contract changes — see \"The upgrade badge\" in\n[Authoring Components](components.md) for how that friction is surfaced\nand resolved.\n"
|
|
75
75
|
},
|
|
76
76
|
{
|
|
77
77
|
"slug": "deployment-keys",
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"helpCorpus.generated.js","sourceRoot":"","sources":["../../src/resources/helpCorpus.generated.ts"],"names":[],"mappings":"AAAA,qDAAqD;AACrD,EAAE;AACF,kGAAkG;AAClG,oGAAoG;AAIpG,MAAM,CAAC,MAAM,WAAW,GAAgB;IACtC;QACE,MAAM,EAAE,iBAAiB;QACzB,OAAO,EAAE,0CAA0C;QACnD,MAAM,EAAE,2yZAA2yZ;KACpzZ;IACD;QACE,MAAM,EAAE,aAAa;QACrB,OAAO,EAAE,aAAa;QACtB,MAAM,EAAE,wnGAAwnG;KACjoG;IACD;QACE,MAAM,EAAE,YAAY;QACpB,OAAO,EAAE,sBAAsB;QAC/B,MAAM,EAAE,4s0BAA4s0B;KACrt0B;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,kCAAkC;QAC3C,MAAM,EAAE,06nBAA06nB;KACn7nB;IACD;QACE,MAAM,EAAE,mBAAmB;QAC3B,OAAO,EAAE,0BAA0B;QACnC,MAAM,EAAE,i9OAAi9O;KAC19O;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,gCAAgC;QACzC,MAAM,EAAE,60sBAA60sB;KACt1sB;IACD;QACE,MAAM,EAAE,sBAAsB;QAC9B,OAAO,EAAE,sBAAsB;QAC/B,MAAM,EAAE,o9lBAAo9lB;KAC79lB;IACD;QACE,MAAM,EAAE,eAAe;QACvB,OAAO,EAAE,qCAAqC;QAC9C,MAAM,EAAE,q3FAAq3F;KAC93F;IACD;QACE,MAAM,EAAE,yBAAyB;QACjC,OAAO,EAAE,4BAA4B;QACrC,MAAM,EAAE,ksRAAksR;KAC3sR;IACD;QACE,MAAM,EAAE,mBAAmB;QAC3B,OAAO,EAAE,mBAAmB;QAC5B,MAAM,EAAE,
|
|
1
|
+
{"version":3,"file":"helpCorpus.generated.js","sourceRoot":"","sources":["../../src/resources/helpCorpus.generated.ts"],"names":[],"mappings":"AAAA,qDAAqD;AACrD,EAAE;AACF,kGAAkG;AAClG,oGAAoG;AAIpG,MAAM,CAAC,MAAM,WAAW,GAAgB;IACtC;QACE,MAAM,EAAE,iBAAiB;QACzB,OAAO,EAAE,0CAA0C;QACnD,MAAM,EAAE,2yZAA2yZ;KACpzZ;IACD;QACE,MAAM,EAAE,aAAa;QACrB,OAAO,EAAE,aAAa;QACtB,MAAM,EAAE,wnGAAwnG;KACjoG;IACD;QACE,MAAM,EAAE,YAAY;QACpB,OAAO,EAAE,sBAAsB;QAC/B,MAAM,EAAE,4s0BAA4s0B;KACrt0B;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,kCAAkC;QAC3C,MAAM,EAAE,06nBAA06nB;KACn7nB;IACD;QACE,MAAM,EAAE,mBAAmB;QAC3B,OAAO,EAAE,0BAA0B;QACnC,MAAM,EAAE,i9OAAi9O;KAC19O;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,gCAAgC;QACzC,MAAM,EAAE,60sBAA60sB;KACt1sB;IACD;QACE,MAAM,EAAE,sBAAsB;QAC9B,OAAO,EAAE,sBAAsB;QAC/B,MAAM,EAAE,o9lBAAo9lB;KAC79lB;IACD;QACE,MAAM,EAAE,eAAe;QACvB,OAAO,EAAE,qCAAqC;QAC9C,MAAM,EAAE,q3FAAq3F;KAC93F;IACD;QACE,MAAM,EAAE,yBAAyB;QACjC,OAAO,EAAE,4BAA4B;QACrC,MAAM,EAAE,ksRAAksR;KAC3sR;IACD;QACE,MAAM,EAAE,mBAAmB;QAC3B,OAAO,EAAE,mBAAmB;QAC5B,MAAM,EAAE,oxRAAoxR;KAC7xR;IACD;QACE,MAAM,EAAE,iBAAiB;QACzB,OAAO,EAAE,4CAA4C;QACrD,MAAM,EAAE,22GAA22G;KACp3G;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,UAAU;QACnB,MAAM,EAAE,iqQAAiqQ;KAC1qQ;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,oBAAoB;QAC7B,MAAM,EAAE,okYAAokY;KAC7kY;IACD;QACE,MAAM,EAAE,WAAW;QACnB,OAAO,EAAE,iCAAiC;QAC1C,MAAM,EAAE,ousBAAousB;KAC7usB;IACD;QACE,MAAM,EAAE,iBAAiB;QACzB,OAAO,EAAE,iBAAiB;QAC1B,MAAM,EAAE,g6HAAg6H;KACz6H;IACD;QACE,MAAM,EAAE,qBAAqB;QAC7B,OAAO,EAAE,qBAAqB;QAC9B,MAAM,EAAE,+iFAA+iF;KACxjF;IACD;QACE,MAAM,EAAE,eAAe;QACvB,OAAO,EAAE,mBAAmB;QAC5B,MAAM,EAAE,u9JAAu9J;KACh+J;IACD;QACE,MAAM,EAAE,MAAM;QACd,OAAO,EAAE,MAAM;QACf,MAAM,EAAE,y9FAAy9F;KACl+F;IACD;QACE,MAAM,EAAE,mBAAmB;QAC3B,OAAO,EAAE,mBAAmB;QAC5B,MAAM,EAAE,o+LAAo+L;KAC7+L;IACD;QACE,MAAM,EAAE,iBAAiB;QACzB,OAAO,EAAE,iBAAiB;QAC1B,MAAM,EAAE,6uNAA6uN;KACtvN;IACD;QACE,MAAM,EAAE,WAAW;QACnB,OAAO,EAAE,WAAW;QACpB,MAAM,EAAE,0oSAA0oS;KACnpS;IACD;QACE,MAAM,EAAE,YAAY;QACpB,OAAO,EAAE,oBAAoB;QAC7B,MAAM,EAAE,y5YAAy5Y;KACl6Y;IACD;QACE,MAAM,EAAE,QAAQ;QAChB,OAAO,EAAE,QAAQ;QACjB,MAAM,EAAE,spOAAspO;KAC/pO;IACD;QACE,MAAM,EAAE,qBAAqB;QAC7B,OAAO,EAAE,qBAAqB;QAC9B,MAAM,EAAE,i2JAAi2J;KAC12J;IACD;QACE,MAAM,EAAE,mBAAmB;QAC3B,OAAO,EAAE,+BAA+B;QACxC,MAAM,EAAE,g2EAAg2E;KACz2E;IACD;QACE,MAAM,EAAE,aAAa;QACrB,OAAO,EAAE,cAAc;QACvB,MAAM,EAAE,qjEAAqjE;KAC9jE;IACD;QACE,MAAM,EAAE,OAAO;QACf,OAAO,EAAE,OAAO;QAChB,MAAM,EAAE,i7FAAi7F;KAC17F;IACD;QACE,MAAM,EAAE,WAAW;QACnB,OAAO,EAAE,mCAAmC;QAC5C,MAAM,EAAE,69KAA69K;KACt+K;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,kBAAkB;QAC3B,MAAM,EAAE,yvJAAyvJ;KAClwJ;IACD;QACE,MAAM,EAAE,gBAAgB;QACxB,OAAO,EAAE,qCAAqC;QAC9C,MAAM,EAAE,qiPAAqiP;KAC9iP;CACF,CAAA"}
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@ebitex/content-mcp",
|
|
3
|
-
"version": "1.1.
|
|
3
|
+
"version": "1.1.264",
|
|
4
4
|
"description": "An MCP server for ebitex Content: build and publish a content model from an AI agent.",
|
|
5
5
|
"license": "Apache-2.0",
|
|
6
6
|
"homepage": "https://developers.ebitex.io/getting-started/content-as-code/",
|