@ebitex/content-mcp 1.1.251 → 1.1.253
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.
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"helpCorpus.generated.d.ts","sourceRoot":"","sources":["../../src/resources/helpCorpus.generated.ts"],"names":[],"mappings":"AAKA,MAAM,MAAM,SAAS,GAAG;IAAE,IAAI,EAAE,MAAM,CAAC;IAAC,KAAK,EAAE,MAAM,CAAC;IAAC,IAAI,EAAE,MAAM,CAAA;CAAE,CAAA;AAErE,eAAO,MAAM,WAAW,EAAE,SAAS,
|
|
1
|
+
{"version":3,"file":"helpCorpus.generated.d.ts","sourceRoot":"","sources":["../../src/resources/helpCorpus.generated.ts"],"names":[],"mappings":"AAKA,MAAM,MAAM,SAAS,GAAG;IAAE,IAAI,EAAE,MAAM,CAAC;IAAC,KAAK,EAAE,MAAM,CAAC;IAAC,IAAI,EAAE,MAAM,CAAA;CAAE,CAAA;AAErE,eAAO,MAAM,WAAW,EAAE,SAAS,EAuJlC,CAAA"}
|
|
@@ -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\
|
|
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"
|
|
55
55
|
},
|
|
56
56
|
{
|
|
57
57
|
"slug": "content-streams",
|
|
@@ -116,7 +116,7 @@ export const HELP_TOPICS = [
|
|
|
116
116
|
{
|
|
117
117
|
"slug": "realms",
|
|
118
118
|
"title": "Realms",
|
|
119
|
-
"body": "# Realms\n\nIf your organization runs one brand, one site or one team, you will never need this page: Content has a single realm, nothing about it shows, and everything works as it always has. Realms are for organizations that publish several brands or sites which should **share some content and keep the rest apart**: shared design-system blocks, legal text and media Contracts that every brand uses, with each brand's own pages kept to itself.\n\n## What a realm is\n\nA realm is a place in a tree. Your organization has one **root** realm (named *Default* until you rename it), and you can create realms below it: *Shared* at the top, *Brand A* and *Brand B* underneath, and so on.\n\n- A realm sees what it owns **and** what every realm above it owns. Brand A sees Shared's Contracts, Templates, folders and Components without copying anything and without a sync step, so nothing can be out of date.\n- A realm changes only what it owns. Brand A cannot see Brand B, and Shared cannot see inside Brand A.\n- Realms are not environments. An environment is a stage a piece of content passes through (Staging, then Live). A realm is *whose* content it is. Every realm exists in every environment, so \"Live · Brand A\" and \"Staging · Brand A\" are two views of the same brand.\n\n## Switching realm\n\nWhen your organization has more than one realm, a **realm switcher** appears in the header beside the environment switcher, and the page title shows the current cell, for example \"Live · Brand A\". You only see the realms you are allowed to enter (see **Who can do what** below). Search results, My tasks and the review queue show items from every realm you can enter and open the right one when you select a result.\n\n## Owned and inherited items\n\nIn lists, folder trees and pickers, an item that another realm owns is drawn dimmer with a dotted outline and an **Owned by {realm}** chip. A legend under the list explains it, and a filter lets you show **All**, **Owned here** or **Inherited**. Whether an item is inherited depends only on which realm you are in; nothing is stored on the item.\n\nThings you can do with an inherited item:\n\n- **Use it.** Reference an inherited Contract from a Component, put an inherited Component in a page, choose an inherited Template. This is what inheriting is for.\n- **Create under it.** You can create items inside an inherited folder. They belong to your realm and sit in the shared folder, and the folder's own access rules and Allowed contracts still apply. You cannot add to the folder itself; make a subfolder of your own for that.\n- **Edit it.** Saving a change to an inherited Component, Contract, Template, Adapter or Stream is written in the realm that owns it. Before you save, the editor says so (\"Owned by Shared. Saving here changes it for every realm that reads Shared.\") and asks you to confirm. You need permission to edit in your realm **and** in the owning realm; if you lack the second you are told which realm to ask.\n- **Not from here.** Deleting, moving, restoring an older version and changing taxonomy vocabulary are refused on an inherited item, and the message names the owner. Do those in the owning realm.\n\n## Managing realms\n\nOpen **Realms** under **Configure** (requires the \"Manage Content realms\" permission, and realms must be switched on for your organization). The page shows the tree.\n\n- **Create** a realm under any other. The name is what people see in the switcher. Your plan limits how many realms you can have; Subscriptions & Billing shows the number you use. Only creating is refused when you reach the limit: nothing you already have is locked.\n- **Rename** a realm at any time. Its key, which tools use, does not change.\n- **Re-order** realms among their siblings, or **move a realm under another realm**. Moving is refused, with a list, if content in the realm or below it uses something from a realm the new position would not see.\n- **Delete** a realm that has no realms below it. This permanently deletes everything the realm owns in **every** environment and cannot be undone; you type the realm's key to confirm. It is refused while anything still points at the realm (a key, a member's access, an environment owned by it, anything published).\n\n### Move to realm, and duplicate into this realm\n\nFrom an item's row actions:\n\n- **Move to realm…** changes which realm owns an item (or a folder with everything inside it, or a site with all its pages). It is refused, with the list of what would break, when moving would leave something unable to see an item it uses: for instance moving a Contract into Brand A while Brand B's Components use it.\n- **Duplicate into this realm…** makes a copy of an inherited item in your realm, with new ids, so you can change it without changing it for everyone. References between the copied items are re-pointed to the copies; references to anything else are kept.\n\n### When something is still in use below you\n\nDeleting or narrowing something that realms below yours depend on is refused with a count per realm, such as \"used by 3 items in Brand A\". You are never shown their content, only how many items and which realm. Change those items from inside that realm, or ask someone who can, then try again.\n\n### Environments owned by a realm\n\nAn authoring environment can be shared (the default) or **owned by one realm**, in which case it is listed and usable only inside that realm and the realms below it. Choose **Realm…** in the environment's row menu on the Environments page; it is offered once your organization has more than one realm. Your default authoring and delivery environments are always shared.\n\n## Who can do what\n\n- **Members.** On the Environments page, **Members** tab, a person's role in an environment can be limited to one realm. Someone bound to Brand A in Live can enter Brand A and the realms below it, cannot see Brand B, and cannot edit Shared unless they are also bound there. A binding with no realm applies to every realm.\n- **API keys.** A **Management** or **deployment** key acts in exactly one realm, chosen when you create it. A **delivery** key can serve every realm or be limited to one realm and the realms below it, so Brand A's key cannot be used to read Brand B's site. Keys created before realms act in the root realm.\n\n## Publishing and promoting across realms\n\n- **Publishing** a page publishes everything it needs, including items its realm inherits, once. You cannot unpublish an item that a published page still references.\n- **Promoting** works for the realm you are in. If the content needs items a realm above yours owns that the target environment lacks or has behind, promotion stops and lists them by realm. Where you are allowed to promote in that realm, choose **Include {realm}** and they go first. **Promote everything** walks the realms from the top down.\n- **Environment refresh** is not available while either environment holds content in a realm other than the root; use promotion instead.\n\n## Related\n\nSee [content-environments.md](content-environments.md) for environments and promotion, [management-keys.md](management-keys.md) and [deployment-keys.md](deployment-keys.md) for keys, and [export-import.md](export-import.md) for moving content between organizations.\n"
|
|
119
|
+
"body": "# Realms\n\nIf your organization runs one brand, one site or one team, you will never need this page: Content has a single realm, nothing about it shows, and everything works as it always has. Realms are for organizations that publish several brands or sites which should **share some content and keep the rest apart**: shared design-system blocks, legal text and media Contracts that every brand uses, with each brand's own pages kept to itself.\n\n## What a realm is\n\nA realm is a place in a tree. Your organization has one **root** realm (named *Default* until you rename it), and you can create realms below it: *Shared* at the top, *Brand A* and *Brand B* underneath, and so on.\n\n- A realm sees what it owns **and** what every realm above it owns. Brand A sees Shared's Contracts, Templates, folders and Components without copying anything and without a sync step, so nothing can be out of date.\n- A realm changes only what it owns. Brand A cannot see Brand B, and Shared cannot see inside Brand A.\n- Realms are not environments. An environment is a stage a piece of content passes through (Staging, then Live). A realm is *whose* content it is. Every realm exists in every environment, so \"Live · Brand A\" and \"Staging · Brand A\" are two views of the same brand.\n\n## Switching realm\n\nWhen your organization has more than one realm, a **realm switcher** appears in the header beside the environment switcher, and the page title shows the current cell, for example \"Live · Brand A\". You only see the realms you are allowed to enter (see **Who can do what** below). Search results, My tasks and the review queue show items from every realm you can enter and open the right one when you select a result.\n\n## Owned and inherited items\n\nIn lists, folder trees and pickers, an item that another realm owns is drawn dimmer with a dotted outline and an **Owned by {realm}** chip. A legend under the list explains it, and a filter lets you show **All**, **Owned here** or **Inherited**. Whether an item is inherited depends only on which realm you are in; nothing is stored on the item.\n\nThings you can do with an inherited item:\n\n- **Use it.** Reference an inherited Contract from a Component, put an inherited Component in a page, choose an inherited Template. This is what inheriting is for.\n- **Create under it.** You can create items inside an inherited folder. They belong to your realm and sit in the shared folder, and the folder's own access rules and Allowed contracts still apply. You cannot add to the folder itself; make a subfolder of your own for that.\n- **Edit it.** Saving a change to an inherited Component, Contract, Template, Adapter or Stream is written in the realm that owns it. Before you save, the editor says so (\"Owned by Shared. Saving here changes it for every realm that reads Shared.\") and asks you to confirm. You need permission to edit in your realm **and** in the owning realm; if you lack the second you are told which realm to ask.\n- **Not from here.** Deleting, moving, restoring an older version and changing taxonomy vocabulary are refused on an inherited item, and the message names the owner. Do those in the owning realm.\n\n## Managing realms\n\nOpen **Realms** under **Configure** (requires the \"Manage Content realms\" permission, and realms must be switched on for your organization). The page shows the tree.\n\n- **Create** a realm under any other. The name is what people see in the switcher. Your plan limits how many realms you can have; Subscriptions & Billing shows the number you use. Only creating is refused when you reach the limit: nothing you already have is locked.\n- **Rename** a realm at any time. Its key, which tools use, does not change.\n- **Re-order** realms among their siblings, or **move a realm under another realm**. Moving is refused, with a list, if content in the realm or below it uses something from a realm the new position would not see.\n- **Delete** a realm that has no realms below it. This permanently deletes everything the realm owns in **every** environment and cannot be undone; you type the realm's key to confirm. It is refused while anything still points at the realm (a key, a member's access, an environment owned by it, anything published).\n\n### Move to realm, and duplicate into this realm\n\nFrom an item's row actions:\n\n- **Move to realm…** changes which realm owns an item (or a folder with everything inside it, or a site with all its pages). It is refused, with the list of what would break, when moving would leave something unable to see an item it uses: for instance moving a Contract into Brand A while Brand B's Components use it.\n- **Duplicate into this realm…** makes a copy of an inherited item in your realm, with new ids, so you can change it without changing it for everyone. References between the copied items are re-pointed to the copies; references to anything else are kept.\n\n### When something is still in use below you\n\nDeleting or narrowing something that realms below yours depend on is refused with a count per realm, such as \"used by 3 items in Brand A\". You are never shown their content, only how many items and which realm. Change those items from inside that realm, or ask someone who can, then try again.\n\n### Environments owned by a realm\n\nAn authoring environment can be shared (the default) or **owned by one realm**, in which case it is listed and usable only inside that realm and the realms below it. Choose **Realm…** in the environment's row menu on the Environments page; it is offered once your organization has more than one realm. Your default authoring and delivery environments are always shared.\n\n## Who can do what\n\n- **Members.** On the Environments page, **Members** tab, a person's role in an environment can be limited to one realm. Someone bound to Brand A in Live can enter Brand A and the realms below it, cannot see Brand B, and cannot edit Shared unless they are also bound there. A binding with no realm applies to every realm.\n- **API keys.** A **Management** or **deployment** key acts in exactly one realm, chosen when you create it. A **delivery** key can serve every realm or be limited to one realm and the realms below it, so Brand A's key cannot be used to read Brand B's site. Keys created before realms act in the root realm.\n\n## Publishing and promoting across realms\n\n- **Publishing** a page publishes everything it needs, including items its realm inherits, once. You cannot unpublish an item that a published page still references.\n- **Promoting** works for the realm you are in. If the content needs items a realm above yours owns that the target environment lacks or has behind, promotion stops and lists them by realm. Where you are allowed to promote in that realm, choose **Include {realm}** and they go first. **Promote everything** walks the realms from the top down.\n- **Environment refresh** is not available while either environment holds content in a realm other than the root; use promotion instead.\n\n## The starter kit\n\nIf your organization uses the [starter kit](starter-kit.md), it holds one more realm: a read-only one above your root, owned by ebitex. It is not in the realm switcher, because you cannot work in it, and it does not count toward your plan's realm limit. Its items appear everywhere as **Owned by ebitex starter kit**.\n\n## Related\n\nSee [content-environments.md](content-environments.md) for environments and promotion, [management-keys.md](management-keys.md) and [deployment-keys.md](deployment-keys.md) for keys, and [export-import.md](export-import.md) for moving content between organizations.\n"
|
|
120
120
|
},
|
|
121
121
|
{
|
|
122
122
|
"slug": "rendering-your-site",
|
|
@@ -128,6 +128,11 @@ export const HELP_TOPICS = [
|
|
|
128
128
|
"title": "Linking a post to sample code",
|
|
129
129
|
"body": "# Linking a post to sample code\n\nA **Sample reference** block tells a reader where to get the code for the step a tutorial post just\nwalked through. It renders as a distinct, boxed block so someone skimming a long post can find it\nwithout reading the prose around it.\n\nUse one wherever a post reaches a point the reader could check out and run.\n\n## Adding one to a post\n\n1. Edit the post's **Body**.\n2. Insert an embed and choose the **Sample reference** Template.\n3. Create a Component for it and fill in:\n\n| Field | What to put | Required |\n|---|---|---|\n| **Repository** | The repository's home page — `https://github.com/ebitex-io/samples` | Yes |\n| **Tag** | The git tag for this step — `northwind-coffee/step-07` | Yes |\n| **Path** | A folder inside the repo to point at | No |\n| **Seed bundle** | A link to the content export for this step | No |\n| **Label** | The sample's name. Left empty, the repository name is used | No |\n| **Note** | One line on what this step adds | No |\n\nA block with just a repository and a tag is complete and looks finished — most steps have nothing\nelse to say.\n\n## Where the links go\n\n**Repository is the repo's home page, not a link to the tagged code.** The link to the code *at*\nthat tag is built for you from the repository and the tag. This is deliberate: if the tagging scheme\never changes, it's one fix rather than an edit to every post ever published.\n\nFor repositories on hosts we know how to build links for, the reader gets a direct link to the code\nat that exact tag and path. For any other host, they get the repository home page and the tag shown\nas text to check out themselves — never a broken link.\n\n## Seed bundles\n\n**Only add a Seed bundle link on steps that actually have one.** In a tutorial, code and content\nadvance together, and seed bundles are usually published at a handful of checkpoints rather than at\nevery step. A reader joining mid-series imports the nearest bundle at or before their step.\n\nLeaving it empty is the normal case, and the block simply doesn't show a download.\n\n## Using it outside a post\n\nThe same block can be added as a section on an ordinary page, not just inside a post body — useful\non a landing page for a sample.\n\n## Related\n\n- [Blog series](blog-series.md) — grouping tutorial posts in order\n- [Components](components.md) — creating and editing content\n"
|
|
130
130
|
},
|
|
131
|
+
{
|
|
132
|
+
"slug": "starter-kit",
|
|
133
|
+
"title": "The ebitex starter kit",
|
|
134
|
+
"body": "# The ebitex starter kit\n\nThe **starter kit** is a set of ready-made Contracts and Templates for building a site: a page, a hero, rich text, media, cards, features, banners, calls to action, and tabs, an accordion and a grid to arrange them. ebitex maintains it, so an improvement reaches everyone who uses it. You start a client's site from it instead of from an empty organization.\n\n## Turning it on\n\nOpen **Realms** under **Configure**, find the **ebitex starter kit** card and select **Use the starter kit**. You need the \"Manage Content realms\" permission, and the kit has to be switched on for your organization. If the card is not there, the kit is not available to you yet.\n\nTurning it on adds the kit to every environment of your organization. It appears in every one of your realms as read-only items, in the same dimmed style as anything another realm owns, with an **Owned by ebitex starter kit** chip showing its version.\n\n## What read-only means\n\nYou cannot edit, move or delete a kit item, and neither can anyone else in your organization. What you can do:\n\n- **Build on it.** Create a Component of a kit Contract, give a page a kit Template, or make your own Contract that inherits from a kit Contract. Your content belongs to your realm, and the kit's items stay as they are. When the kit is improved, everything built on it gets the improvement.\n- **Duplicate it to change it.** Choose **Duplicate into realm** on a kit item to get your own copy. A copy is yours to change, and it **stops receiving updates**, because it is no longer the kit's.\n\n## How a kit is laid out\n\nA page extends the kit's page Contract, which carries the search and sharing fields, a hero, and a list of sections. Every section is a Component of one of the kit's presentation Contracts. The choices about **how** a section looks where you place it (its layout, width, background, an item's label in a tab, a card's emphasis, a banner's tone) are set at the place you use it, not on the Component. That is what lets one Component appear in several places looking different in each.\n\nThe kit does not draw anything. Your site's front end renders it, and decides what each choice looks like.\n\n## How updates arrive\n\nWhen ebitex releases a new version of the kit, it is written into your organization for you. You do not run anything, and nothing is published for you: each environment keeps serving what it has published until you publish again.\n\nAn update that would break something you built is never applied to your organization. For example, if a field were removed and your Components hold values for it, the update is held and ebitex is told, and your organization stays on the version it had. In practice the kit only adds: a field or Contract that is no longer recommended is marked as such and left in place.\n\n## Turning it off\n\nSelect **Stop using the kit** on the same card. It is refused while anything of yours still uses a kit item, and the message names the realms that do. Move that content onto copies first.\n"
|
|
135
|
+
},
|
|
131
136
|
{
|
|
132
137
|
"slug": "tasks",
|
|
133
138
|
"title": "Tasks",
|
|
@@ -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,ooRAAooR;KAC7oR;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,8xqBAA8xqB;KACvyqB;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,6+OAA6+O;KACt/O;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,wBAAwB;QACjC,MAAM,EAAE,4+FAA4+F;KACr/F;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.253",
|
|
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/",
|