@ebitex/content-mcp 0.3.93 → 0.4.95
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.
|
@@ -56,7 +56,7 @@ export const HELP_TOPICS = [
|
|
|
56
56
|
{
|
|
57
57
|
"slug": "content-streams",
|
|
58
58
|
"title": "Streams: saved queries as delivery sources",
|
|
59
|
-
"body": "# Streams: saved queries as delivery sources\n\nA **stream** is a named, saved query over your published content that any site or app can consume\nthrough the Delivery API at a stable address — `…/streams/<key>`. Instead of a consuming page\nhard-coding *which* content it lists and *how*, the stream's definition carries those decisions:\nwhich Contracts it draws from, how items are ordered, what's excluded, how items are shaped, and\nwhich filters callers may use. Editors then re-scope what a listing shows without any deploy —\nedits to a stream apply to the very next request.\n\nFind them under **Configure → Streams**.\n\n## What a stream defines\n\n- **Source Contracts** — one or more Contracts whose published Components the stream returns.\n Matching includes descendants: choosing an abstract ancestor (say, `web-page`) matches every\n published Component of every Contract built on it.\n- **Order** — a top-level field (like `publish-date`) and a direction. Items without the field\n always sort last.\n- **Projection** — optionally, a named Adapter applied to every item. The consumer then receives\n the Adapter's *output* shape (a flattened \"card\", say) instead of each item's full document,\n which keeps list payloads small. Every source Contract must satisfy the Adapter's input\n Contract; the editor checks this when you save.\n- **Resolve depth** — how deeply each item's own references are expanded, decided here rather\n than by the caller.\n- **Exclusions** — specific Components the stream never returns, whatever the query says.\n- **Declared filters** — the *only* query parameters the delivery endpoint accepts, each with a\n key you choose:\n - a **string** filter matches a top-level field's value exactly (e.g. `filter.author=ada`);\n - a **category** filter matches classified content, including everything under the given\n category (e.g. `filter.topic=topics/tech`);\n - a **fullText** filter (at most one per stream) searches all the text of each published item\n (e.g. `filter.q=postgres search`) — this is what powers a site-wide search box.\n\n## Things to know\n\n- Streams read **published** content only, always live — publishing or unpublishing something\n changes stream results immediately, and so does editing the stream or its Adapter's rules.\n- A stream itself is never published or promoted with content; it's configuration, like\n environments or delivery keys. It can be promoted between environments from its row's Promote\n button.\n- Deleting a stream is never blocked — a consumer still calling it simply gets a \"not found\"\n answer. Deleting a *Contract or Adapter a stream uses* is blocked until the stream stops using\n it.\n- Use **Preview** on a stream you're editing to run the real query against a delivery\n environment's published content and see exactly what consumers get.\n"
|
|
59
|
+
"body": "# Streams: saved queries as delivery sources\n\nA **stream** is a named, saved query over your published content that any site or app can consume\nthrough the Delivery API at a stable address — `…/streams/<key>`. Instead of a consuming page\nhard-coding *which* content it lists and *how*, the stream's definition carries those decisions:\nwhich Contracts it draws from, how items are ordered, what's excluded, how items are shaped, and\nwhich filters callers may use. Editors then re-scope what a listing shows without any deploy —\nedits to a stream apply to the very next request.\n\nFind them under **Configure → Streams**.\n\n## What a stream defines\n\n- **Source Contracts** — one or more Contracts whose published Components the stream returns.\n Matching includes descendants: choosing an abstract ancestor (say, `web-page`) matches every\n published Component of every Contract built on it.\n- **Order** — a top-level field (like `publish-date`) and a direction. Items without the field\n always sort last.\n- **Projection** — optionally, a named Adapter applied to every item. The consumer then receives\n the Adapter's *output* shape (a flattened \"card\", say) instead of each item's full document,\n which keeps list payloads small. Every source Contract must satisfy the Adapter's input\n Contract; the editor checks this when you save.\n- **Resolve depth** — how deeply each item's own references are expanded, decided here rather\n than by the caller.\n- **Exclusions** — specific Components the stream never returns, whatever the query says.\n- **Declared filters** — the *only* query parameters the delivery endpoint accepts, each with a\n key you choose:\n - a **string** filter matches a top-level field's value exactly (e.g. `filter.author=ada`);\n - a **reference** filter matches items whose field points at a particular Component, given that\n Component's key (e.g. `filter.author=<key>`) — it can also name a field path on the target to\n use as a readable label, so a facet lists author *names* rather than keys;\n - a **date** filter matches a date field by UTC month (e.g. `filter.month=2026-09`), which is\n what a \"browse by month\" archive list is built from;\n - a **category** filter matches classified content, including everything under the given\n category (e.g. `filter.topic=topics/tech`). Scope it to one category group if the Contract has\n more than one category field, or a single facet mixes values from both;\n - a **fullText** filter (at most one per stream) searches all the text of each published item\n (e.g. `filter.q=postgres search`) — this is what powers a site-wide search box.\n\n## Things to know\n\n- Streams read **published** content only, always live — publishing or unpublishing something\n changes stream results immediately, and so does editing the stream or its Adapter's rules.\n- A stream itself is never published or promoted with content; it's configuration, like\n environments or delivery keys. It can be promoted between environments from its row's Promote\n button.\n- Deleting a stream is never blocked — a consumer still calling it simply gets a \"not found\"\n answer. Deleting a *Contract or Adapter a stream uses* is blocked until the stream stops using\n it.\n- Use **Preview** on a stream you're editing to run the real query against a delivery\n environment's published content and see exactly what consumers get.\n"
|
|
60
60
|
},
|
|
61
61
|
{
|
|
62
62
|
"slug": "content-taxonomy",
|
|
@@ -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## 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.\n5. Switch to the **Fields** tab (the default tab) and select **Add field**\n to add a field. The Fields list is a set of collapsible rows —\n selecting a row's name expands it to fill in its Name/Id, pick a\n **Field type**, and set its modifiers (see below), and collapses\n whichever row was open before it, so only one field's details are ever\n in view at once. Repeat for every field the Contract needs; drag a row\n by its handle to reorder it (or, from the keyboard, focus the handle,\n press Space to pick it up, use the arrow keys to move it, and Space\n again to drop it), or select the trash icon to remove one. A row with\n an unresolved error shows a warning icon even while collapsed, and a\n failed save automatically expands the first field that needs\n attention — or, for an error on the General tab (Name, Id, Parent\n Contract), switches you back to that tab.\n6. Select **Save** (visible from either tab). Before anything is saved, you'll see a banner telling\n you whether this is a brand-new Contract, an in-place update, or a\n change that creates a new *version* (see \"Versions\" below) — confirm to\n go ahead, or cancel to keep editing.\n\n## Field types and modifiers\n\nEvery field has a **Field type** (Short Text, Number, Boolean, URL, Date,\nComponent, Blob, Presentation, Rich Text, or Category — Long Text,\nReference, and Nested are deprecated and no longer offered for new\nfields, though any field already using one keeps working unchanged; see\n\"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, Short Text, Long Text, and Rich Text all 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, Short Text and Long Text share 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### Restricting a field to a fixed list of values\n\nShort Text, Long Text, 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 Short 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 — leave it empty to allow any\nContract (including descendants of one you do list).\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## 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## 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.\n5. Switch to the **Fields** tab (the default tab) and select **Add field**\n to add a field. The Fields list is a set of collapsible rows —\n selecting a row's name expands it to fill in its Name/Id, pick a\n **Field type**, and set its modifiers (see below), and collapses\n whichever row was open before it, so only one field's details are ever\n in view at once. Repeat for every field the Contract needs; drag a row\n by its handle to reorder it (or, from the keyboard, focus the handle,\n press Space to pick it up, use the arrow keys to move it, and Space\n again to drop it), or select the trash icon to remove one. A row with\n an unresolved error shows a warning icon even while collapsed, and a\n failed save automatically expands the first field that needs\n attention — or, for an error on the General tab (Name, Id, Parent\n Contract), switches you back to that tab.\n6. Select **Save** (visible from either tab). Before anything is saved, you'll see a banner telling\n you whether this is a brand-new Contract, an in-place update, or a\n change that creates a new *version* (see \"Versions\" below) — confirm to\n go ahead, or cancel to keep editing.\n\n## Field types and modifiers\n\nEvery field has a **Field type** (Short Text, Number, Boolean, Date, Link,\nComponent, Blob, Presentation, Rich Text, or Category — Long Text, URL,\nReference, Nested, and Experience Reference are deprecated and no longer\noffered for new fields, though any field already using one keeps working\nunchanged; see \"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, Short Text, Long Text, and Rich Text all 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, Short Text and Long Text share 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### Restricting a field to a fixed list of values\n\nShort Text, Long Text, 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 Short 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 — leave it empty to allow any\nContract (including descendants of one you do list).\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## 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": "environment-refresh",
|
|
@@ -81,7 +81,7 @@ export const HELP_TOPICS = [
|
|
|
81
81
|
{
|
|
82
82
|
"slug": "export-import",
|
|
83
83
|
"title": "Export and import",
|
|
84
|
-
"body": "# Export and import\n\nPromotion (see [Content environments](content-environments.md)) moves content one direction along\na configured pipeline. Export and import is the general-purpose alternative: take a portable copy\nof something and bring it into any authoring environment — the same organization or a different\none, with or without a promotion pipeline set up between them.\n\nUse this for:\n\n- **Moving content backward** (\"demote\") — content edited in a downstream environment, brought\n back to where it came from.\n- **Copying between environments with no pipeline configured**, or **between organizations**.\n- **Backing up** a Contract, Template, page, or Component, or **seeding** a fresh environment with\n a starting set of content.\n\n## Exporting\n\nOn a Contract, Template, page, Component, Audience, or Adapter's own editor, look for the\n**Export…** button (next to Promote, where that's also available).\n\nExporting shows you everything that will be included — the item itself plus everything it depends\non (its Contract, any Templates it uses, referenced Audiences, and so on) — before you commit to\nanything. Check **Portable** if you're exporting to a different organization and the content\nincludes images or other files; this packages those files' bytes along with the content so they\ndon't arrive broken. Leave it unchecked for a same-organization export — the files are already\nvisible everywhere in your organization regardless of environment.\n\nClick **Export** to produce a bundle file, then **Download bundle file** to save it.\n\n## Importing\n\nOpen **Transfer** under **Tools** in the app navigation, then **Upload bundle file…** to stage a\nbundle you've downloaded (or received from someone else). Once staged, click **Import…** next to\nit.\n\nYou'll be asked to choose:\n\n- **Preserve identity** — items keep the same identity they had when exported. Use this for a\n same-organization import; it's also what makes a \"demote\" work cleanly, since the item you bring\n back is recognized as the same one you'll later send forward again.\n- **Fresh identity** — every item gets a brand-new identity, guaranteed not to collide with\n anything. Required when importing into a different organization than the one the bundle came\n from.\n\nThe import plan then shows each item's state:\n\n- **New** — doesn't exist here yet, will be created.\n- **Identical** — already here, exactly matching — nothing changes.\n- **Conflict** — already exists here with *different* content. You'll need to check a box\n confirming you want the bundle's version to replace what's here. (The version being replaced is\n saved first, so it isn't lost — see the item's own version history afterward if you need it\n back.)\n\nA bundle imports as a whole — you can't pick and choose individual items partway through (do that\nat export time instead, by choosing a narrower starting point). Click **Import** to apply it.\n\n## Staged bundles\n\nThe Transfer page lists every bundle you've exported or uploaded. From there you can download a\nbundle again, re-run its import, or delete it once you're done with it. An ordinary export expires\nautomatically after 30 days; delete it sooner if you're finished with it.\n\n## What travels in a bundle, and what doesn't\n\nA bundle carries the *current* state of what you selected — the live content, not its full edit\nhistory. It does **not** carry: published copies (the destination publishes on its own schedule),\nin-progress workflow reviews, delivery keys or host mappings (those belong to the environment\nitself, not its content), or activity history.\n"
|
|
84
|
+
"body": "# Export and import\n\nPromotion (see [Content environments](content-environments.md)) moves content one direction along\na configured pipeline. Export and import is the general-purpose alternative: take a portable copy\nof something and bring it into any authoring environment — the same organization or a different\none, with or without a promotion pipeline set up between them.\n\nUse this for:\n\n- **Moving content backward** (\"demote\") — content edited in a downstream environment, brought\n back to where it came from.\n- **Copying between environments with no pipeline configured**, or **between organizations**.\n- **Backing up** a Contract, Template, page, or Component, or **seeding** a fresh environment with\n a starting set of content.\n\n## Exporting\n\nOn a Contract, Template, page, Component, Audience, or Adapter's own editor, look for the\n**Export…** button (next to Promote, where that's also available).\n\nExporting shows you everything that will be included — the item itself plus everything it depends\non (its Contract, any Templates it uses, referenced Audiences, and so on) — before you commit to\nanything. Check **Portable** if you're exporting to a different organization and the content\nincludes images or other files; this packages those files' bytes along with the content so they\ndon't arrive broken. Leave it unchecked for a same-organization export — the files are already\nvisible everywhere in your organization regardless of environment.\n\nClick **Export** to produce a bundle file, then **Download bundle file** to save it.\n\n## Importing\n\nOpen **Transfer** under **Tools** in the app navigation, then **Upload bundle file…** to stage a\nbundle you've downloaded (or received from someone else). Once staged, click **Import…** next to\nit.\n\nYou'll be asked to choose:\n\n- **Preserve identity** — items keep the same identity they had when exported. Use this for a\n same-organization import; it's also what makes a \"demote\" work cleanly, since the item you bring\n back is recognized as the same one you'll later send forward again.\n- **Fresh identity** — every item gets a brand-new identity, guaranteed not to collide with\n anything. Required when importing into a different organization than the one the bundle came\n from.\n\nThe import plan then shows each item's state:\n\n- **New** — doesn't exist here yet, will be created.\n- **Identical** — already here, exactly matching — nothing changes.\n- **Conflict** — already exists here with *different* content. You'll need to check a box\n confirming you want the bundle's version to replace what's here. (The version being replaced is\n saved first, so it isn't lost — see the item's own version history afterward if you need it\n back.)\n\nA bundle imports as a whole — you can't pick and choose individual items partway through (do that\nat export time instead, by choosing a narrower starting point). Click **Import** to apply it.\n\nA large bundle can take a while, and the button counts items off as they're applied. The import runs\non the server rather than in this browser tab, so it keeps going if you close the dialog or reload\nthe page — reopening it picks the same import back up and carries on showing progress. If something\ndoes go wrong, nothing is left half-applied: the whole import is undone, and the reason appears next\nto the **Import** button.\n\n## Staged bundles\n\nThe Transfer page lists every bundle you've exported or uploaded. From there you can download a\nbundle again, re-run its import, or delete it once you're done with it. An ordinary export expires\nautomatically after 30 days; delete it sooner if you're finished with it.\n\n## What travels in a bundle, and what doesn't\n\nA bundle carries the *current* state of what you selected — the live content, not its full edit\nhistory. It does **not** carry: published copies (the destination publishes on its own schedule),\nin-progress workflow reviews, delivery keys or host mappings (those belong to the environment\nitself, not its content), or activity history.\n"
|
|
85
85
|
},
|
|
86
86
|
{
|
|
87
87
|
"slug": "locale-addressing",
|
|
@@ -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,4qUAA4qU;KACrrU;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,igVAAigV;KAC1gV;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,kCAAkC;QAC3C,MAAM,EAAE,6okBAA6okB;KACtpkB;IACD;QACE,MAAM,EAAE,mBAAmB;QAC3B,OAAO,EAAE,0BAA0B;QACnC,MAAM,EAAE,6oLAA6oL;KACtpL;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,gCAAgC;QACzC,MAAM,EAAE,sxeAAsxe;KAC/xe;IACD;QACE,MAAM,EAAE,sBAAsB;QAC9B,OAAO,EAAE,sBAAsB;QAC/B,MAAM,EAAE,m8hBAAm8hB;KAC58hB;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,2jRAA2jR;KACpkR;IACD;QACE,MAAM,EAAE,mBAAmB;QAC3B,OAAO,EAAE,mBAAmB;QAC5B,MAAM,EAAE,6/HAA6/H;KACtgI;IACD;QACE,MAAM,EAAE,iBAAiB;QACzB,OAAO,EAAE,4CAA4C;QACrD,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,4qUAA4qU;KACrrU;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,igVAAigV;KAC1gV;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,kCAAkC;QAC3C,MAAM,EAAE,6okBAA6okB;KACtpkB;IACD;QACE,MAAM,EAAE,mBAAmB;QAC3B,OAAO,EAAE,0BAA0B;QACnC,MAAM,EAAE,6oLAA6oL;KACtpL;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,gCAAgC;QACzC,MAAM,EAAE,sxeAAsxe;KAC/xe;IACD;QACE,MAAM,EAAE,sBAAsB;QAC9B,OAAO,EAAE,sBAAsB;QAC/B,MAAM,EAAE,m8hBAAm8hB;KAC58hB;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,2jRAA2jR;KACpkR;IACD;QACE,MAAM,EAAE,mBAAmB;QAC3B,OAAO,EAAE,mBAAmB;QAC5B,MAAM,EAAE,6/HAA6/H;KACtgI;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,wvJAAwvJ;KACjwJ;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,oBAAoB;QAC7B,MAAM,EAAE,4mPAA4mP;KACrnP;IACD;QACE,MAAM,EAAE,WAAW;QACnB,OAAO,EAAE,iCAAiC;QAC1C,MAAM,EAAE,s2XAAs2X;KAC/2X;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,6+HAA6+H;KACt/H;IACD;QACE,MAAM,EAAE,mBAAmB;QAC3B,OAAO,EAAE,mBAAmB;QAC5B,MAAM,EAAE,upIAAupI;KAChqI;IACD;QACE,MAAM,EAAE,iBAAiB;QACzB,OAAO,EAAE,iBAAiB;QAC1B,MAAM,EAAE,2rLAA2rL;KACpsL;IACD;QACE,MAAM,EAAE,YAAY;QACpB,OAAO,EAAE,oBAAoB;QAC7B,MAAM,EAAE,2hVAA2hV;KACpiV;IACD;QACE,MAAM,EAAE,mBAAmB;QAC3B,OAAO,EAAE,+BAA+B;QACxC,MAAM,EAAE,g2EAAg2E;KACz2E;IACD;QACE,MAAM,EAAE,WAAW;QACnB,OAAO,EAAE,mCAAmC;QAC5C,MAAM,EAAE,8vKAA8vK;KACvwK;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,kBAAkB;QAC3B,MAAM,EAAE,itIAAitI;KAC1tI;CACF,CAAA"}
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@ebitex/content-mcp",
|
|
3
|
-
"version": "0.
|
|
3
|
+
"version": "0.4.95",
|
|
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/",
|