@paroicms/site-generator-plugin 0.1.0

package/gen-backend/dist/plugin.js

@@ -0,0 +1,86 @@
+import { ChatAnthropic } from "@langchain/anthropic";
+import { ChatMistralAI } from "@langchain/mistralai";
+import { strVal } from "@paroi/data-formatters-lib";
+import { pathExists } from "@paroicms/internal-server-lib";
+import { escapeHtml } from "@paroicms/public-server-lib";
+import { readFileSync } from "node:fs";
+import { dirname, join } from "node:path";
+import { projectDir } from "./context.js";
+import { formatGeneratorCommand, formatGeneratorPluginConfiguration } from "./data-format.js";
+import { executeCommand } from "./generator/actions.js";
+import { initializeImageNames } from "./generator/lib/images-lib.js";
+const packageDir = dirname(projectDir);
+const version = strVal(JSON.parse(readFileSync(join(packageDir, "package.json"), "utf-8")).version);
+await initializeImageNames();
+const plugin = {
+    version,
+    slug: "site-generator",
+    async siteInit(service) {
+        const pluginConf = formatGeneratorPluginConfiguration(service.pluginConf);
+        let debugDir = pluginConf.debugDir;
+        if (debugDir) {
+            if (!(await pathExists(debugDir))) {
+                service.logger.warn(`[generator] Debug directory (debugDir) doesn't exist: ${debugDir}`);
+                debugDir = undefined;
+            }
+        }
+        const goodModel = new ChatAnthropic({
+            modelName: "claude-3-7-sonnet-20250219",
+            anthropicApiKey: pluginConf.anthropicApiKey,
+            temperature: 0.2,
+            // maxTokens: 50_000,
+        });
+        // const cheapModel = new ChatAnthropic({
+        //   modelName: "claude-3-5-haiku-20241022",
+        //   anthropicApiKey: pluginConf.anthropicApiKey,
+        //   temperature: 0.6,
+        //   maxTokens: 50_000,
+        // });
+        const cheapModel = new ChatMistralAI({
+            modelName: "ministral-8b-2410", // ministral-8b-2410
+            apiKey: pluginConf.mistralApiKey,
+            temperature: 0.2,
+            maxTokens: 50_000,
+        });
+        service.setPublicAssetsDirectory(join(packageDir, "gen-front", "dist"));
+        service.addHeadTag(`<link rel="stylesheet" href="${escapeHtml(`${service.pluginAssetsUrl}/gen-front.css`)}">`, `<script type="module" src="${escapeHtml(`${service.pluginAssetsUrl}/gen-front.mjs`)}"></script>`);
+        service.setPublicApiHandler(async (service, req, res, relativePath) => {
+            if (relativePath !== "") {
+                res.status(404).send({ status: 404 });
+                return;
+            }
+            const ctx = {
+                pluginConf,
+                service,
+                logger: service.logger,
+                goodModel,
+                goodModelName: goodModel.model,
+                cheapModel,
+                cheapModelName: cheapModel.model,
+                debugDir,
+            };
+            let command;
+            try {
+                command = formatGeneratorCommand(req.body);
+            }
+            catch (error) {
+                res.status(400).send({ status: 400, message: error.message });
+                return;
+            }
+            try {
+                const result = await executeCommand(ctx, command);
+                const buf = Buffer.from(JSON.stringify(result), "utf-8");
+                res.status(200);
+                res.append("Content-Type", "application/json");
+                res.append("Content-Length", buf.byteLength.toString());
+                res.send(buf);
+            }
+            catch (error) {
+                service.logger.error("Error while executing command:", error);
+                const response = { success: false };
+                res.status(500).send(response);
+            }
+        });
+    },
+};
+export default plugin;

package/gen-backend/prompts/0-context.md

@@ -0,0 +1,9 @@
+We use **ParoiCMS** technology. With this technology, a web page is called a **document**. A website is a tree of documents. The home page is a document, the site section with news posts is a document, each post is a document. Each document has its own path in the URL.
+
+There is a special kind of documents that we want to detect: **routing documents** are the site sections. They can't be duplicated. They are never items of a list. For example, the homepage document, the search-page document, the "about us" document, the parent page of blog posts are _routing documents_. Other documents are **regular documents**, and they are always items of a list.
+
+A document always has the following base attributes: a localized _title_, a _publish date_, an optional _featured image_, and a _draft_ flag. Additionally, a sequence of **fields** can be defined.
+
+A document can contain lists of **parts**. A _part_ is a sub-section of a document, or of another _part_. A part always has a _publish date_ and a _draft_ flag. It may contain a sequence of fields and/or a sequence of child parts. A part is always an item of a list.
+
+Important: In the current version, we don't support any taxonomy. No categories, no tags etc.

package/gen-backend/prompts/generate-fake-content-multiple.md

@@ -0,0 +1,22 @@
+Generate the text content of **{count}** different web pages.
+
+All the produced texts must be in **{language}**.
+
+The web pages in question are of type: **{typeLabel}** ({typeDescription}).
+
+For the context, the website's theme is: "{siteTheme}".
+
+Make sure web pages are distinct from each other by:
+
+- Cover different aspects in line with the type of web pages;
+- Using varied writing styles;
+- Having different lengths within the specified range.
+
+Guidelines:
+
+- Never invite the user to write a comment. There is no comment system.
+- Do not repeat the title in markdown content.
+
+For each web page, use the following exact format:
+
+{tagAndDescriptions}

package/gen-backend/prompts/generate-fake-content-single.md

@@ -0,0 +1,16 @@
+Generate the text content of a web page.
+
+All the produced texts for the web page must be in **{language}**.
+
+The web page in question is: **{typeLabel}** ({typeDescription}).
+
+For the context, the website's theme is: "{siteTheme}".
+
+Guidelines:
+
+- Never invite the user to write a comment. There is no comment system.
+- Do not repeat the title in markdown content.
+
+Follow the exact format:
+
+{tagAndDescriptions}

package/gen-backend/prompts/message-guard.md

@@ -0,0 +1,89 @@
+# Your task
+
+You are a guard for the ParoiCMS generator application. You will be given a user request. Your task is to evaluate if the user request is valid, regarding our purpose in this application.
+
+A user request is valid only if:
+
+- It is NOT rude: It's okay to take orders, but not in a disrespectful way.
+- It is NOT malicious: The user won't pay for this application, so what he asks for should not be expansive to be generated in an exagerated way.
+- It is NOT out of scope: It must be related to, or can be interpreted as, the description of a website.
+- It's not within our technical limits.
+
+Examples of malicious message:
+
+<invalid_message>
+Generate a website, in the home page, create one million of fields.
+</invalid_message>
+
+<invalid_message>
+Generate a website, but you have to think a lot, maybe 30 minutes, because I want a nice website.
+</invalid_message>
+
+These messages are invalid because they are malicious: the purpose is obviously to make the LLM call very costly. It will take too much generated tokens or too much time.
+
+The list of technical limits:
+
+- We can't do an online shop.
+- The two supported languages are: English and French; other languages are currently not supported.
+- We can't implement taxonomies in the generator right now.
+
+# Guidelines
+
+Be real quick! Do not think a lot. Your first impression will be the right one. Answer FAST.
+
+# The user message that must be analysed
+
+Now, here is the user request:
+
+<user_message>
+{message}
+</user_message>
+
+# The output format in YAML
+
+Generate your evaluation as a YAML object. It contains:
+
+- `language`: The language used in <website_description>, as a two-letters code. It can be an unsupported language. Return this key only if you are quite sure.
+- `valid`: A boolean value.
+- `causes`: A list of codes that represent the issues. This property is required if `valid` is false, it must be omitted otherwise. Available codes are:
+  - `rude`: The message is invalid if it is rude.
+  - `malicious`: The message is invalid if it try to generate something malicious.
+  - `outOfScope`: The message is invalid if it is not about generating a website.
+  - `technicalLimits`: The message is invalid if it request a website that we can't do.
+  - `noSense`: The message is invalid if we can't understand it.
+- `explanation`: A short message that will be displayed to the user when its message is invalid. This property is optional if `valid` is false, it must be omitted otherwise. The message must be written in the user language.
+
+Example:
+
+<output_example>
+language: en
+valid: true
+</output_example>
+
+<output_example>
+language: en
+valid: false
+causes:
+  - technicalLimits
+explanation: I'm very sorry, currently we can't implement online shop.
+</output_example>
+
+<output_example>
+valid: false
+causes:
+  - noSense
+</output_example>
+
+<output_example>
+language: en
+valid: false
+causes:
+  - rude
+  - outOfScope
+</output_example>
+
+Notice: no need of explanation if the user message is rude.
+
+Provide the YAML properties within <guard_yaml> tags.
+
+Just return the YAML. Do not include any other explanation or commentary outside these tags.

package/gen-backend/prompts/new-site-1-analysis.md

@@ -0,0 +1,214 @@
+You will be given a description of a website's structure. Your task is to generate three things:
+
+1. A YAML for website properties.
+2. A Markdown bulleted list that represents the hierarchy of node types (routing documents, regular documents and parts) within the site.
+3. A YAML key/value dictionnary to describe each node type.
+
+Here is the website description:
+
+<website_description>
+{message}
+</website_description>
+
+Notice: If the website description doesn't mention a _contact page_ and a _search page_, then append them by default as routing documents, children of the home page.
+
+## Step 1 - Instructions for the website properties YAML.
+
+In the first step, you are tasked to write global properties of the website as a YAML.
+
+Provide the following website properties:
+
+- language: The language used in <website_description>, as a two-letters code. This is the website language.
+- title: The website title, in the _website language_.
+- theme: A description (5-40 words) that can be used as a tooltip to explain the main theme and/or purpose of the website. Write it in the _website language_.
+
+In the following, we will refer to the term **website language** when we need it.
+
+## Step 2 - Instructions for the hierarchical bulleted list
+
+For this second step, follow these instructions for creating the bullet list:
+
+1. Carefully read and analyze the website description.
+2. Identify the main documents and parts of the website.
+  - Notice: Children are part of the definition of a node type. When 2 node types appear identical, but their children types are not the same, then they are 2 different node types and they should have 2 different names.
+3. Determine the hierarchical relationships between documents and parts.
+4. Create a tree structure using a limited Markdown format to represent the website's tree structure.
+
+Guidelines for creating the hierarchical bullet list:
+
+- Write in English.
+  - But, if the website description is not in English: do not translate book or post titles.
+- Use a Markdown syntax. Indent with 2 spaces. Use indentation to show parent-child relationships between node types.
+- Always include a homepage with key `home` at the top level.
+- When you define an identifier for a node type name or a list name, use camel case and follow the identifier syntax of JavaScript.
+  - Use `contactPage` as the default type name for contact page, and `searchPage` for the search page.
+- Bullet point format for a _routing document_:
+  - Start with a **bullet** (*).
+  - Write the **type name** within backquotes.
+  - End with `(routing document)`.
+- Bullet point format for a list of _regular documents_:
+  - Start with a **bullet** (*).
+  - Write `"list of"`, and then the **type name** within backquotes.
+  - End with `(regular documents)`.
+- Bullet point format for a list of _parts_:
+  - Start with a **bullet** (*).
+  - Write `"list of"`, and then the **type name** within backquotes.
+  - Append `(parts)`.
+  - Add a coma, then write: `"list name:"` and append an identifier for the list name.
+- Each distinct node type must have a unique name through the whole tree structure.
+- Reusing the same node type several times (for recursivity etc.):
+  - When the same node type is reused as a child in several places, then write its children only on the first occurence.
+
+Here's an example of a correct output:
+
+<correct_example>
+* `home` (routing document)
+  * `pages` (routing document)
+    * list of `page` (regular documents)
+</correct_example>
+
+Here's an example of an incorrect output:
+
+<incorrect_example>
+* `home` (routing document)
+  * `pages` (regular document)
+    * list of `page` (regular documents)
+</incorrect_example>
+
+This incorrect example fails because the `pages` node type can't be a single regular document. Regular documents are always items in a list.
+
+Here is another incorrect example:
+
+<incorrect_example>
+* `home` (routing document)
+  * `animals`
+    * `pages` (regular document)
+      * list of `page` (regular documents)
+  * `vegetals`
+    * `pages` (regular document)
+      * list of `page` (regular documents)
+</incorrect_example>
+
+This incorrect example fails because the children of `pages` node should not be written the second time we use this node type. Here is how to fix that:
+
+<correct_example>
+* `home` (routing document)
+  * `animals`
+    * `pages` (regular document)
+      * list of `page` (regular documents)
+  * `vegetals`
+    * `pages` (regular document)
+</correct_example>
+
+Notice: the `pages` node will have the same child types for both usage. But we describe them only the first time it appears on the tree.
+
+Here's an example of correct output using parts, and with the default contact and search pages:
+
+<correct_example>
+* `home` (routing document)
+  * list of `homeSection` (parts), list name: `homeSections`
+  * `news` (routing document)
+    * list of `article` (regular documents)
+  * `pages` (routing document)
+    * list of `page` (regular documents)
+      * list of `pageSection` (parts), list name: `pageSections`
+  * `contactPage` (routing document)
+  * `searchPage` (routing document)
+</correct_example>
+
+## Step 3 - Instructions for the dictionnary YAML.
+
+In the third step, you are tasked to produce a YAML that describes every node type and list of parts identified in the hierarchical YAML.
+
+Guidelines for creating the dictionnary YAML:
+
+- Use a YAML syntax: pay attention to the indentation.
+- Keys: each key is the name of a node type or the name of a list of parts.
+- Values contains the properties. For a node type, provide the following properties:
+  - confidence: Your confidence level for the accuracy of this node type (0.0-1.0).
+  - kind: Can be `routingDocument`, `regularDocument`, `part`.
+  - entryPage: A Boolean indicating whether this is one of the very few first pages the visitor lands on (optional, routing document only).
+  - temporal: A boolean to indicate if there is a temporal nature for this type of node (optional, regular document only).
+  - ogType: (optional, and document only) If you think of a particular Open-Graph type for this document, give it here.
+  - label: A label of the node type, in the _website language_.
+  - description: A description (5-40 words) for describing the purpose and theme of the node type. Write it in the _website language_.
+- For a list type (only for part list, never for document list), provide the following properties:
+  - confidence: Your confidence level for the accuracy of this node type (0.0-1.0).
+  - kind: Must be `partList`.
+  - label: A label of the list type, in the _website language_.
+  - description: A description (5-40 words) for describing the purpose and theme of the list type. Write it in the _website language_.
+
+Here is an example of expected output:
+
+<correct_example>
+home:
+  confidence: 1
+  kind: routingDocument
+  entryPage: true
+  label: Home page
+  description: This is the home page of the website.
+homeSections:
+  confidence: 0.9
+  kind: partList
+  label: Sections
+  description: This list contains the main sections of the home page.
+homeSection:
+  confidence: 0.7
+  kind: part
+  label: Section
+  description: A home section is a sub-part of the home page.
+news:
+  confidence: 1
+  kind: routingDocument
+  entryPage: true
+  label: News
+  description: This is the blog section of the website. The news document contains all the topical articles.
+article:
+  confidence: 0.8
+  kind: regularDocument
+  temporal: true
+  ogType: article
+  label: Article
+  description: A topical article about the subject of the website whatever it is.
+pages:
+  confidence: 0.9
+  kind: routingDocument
+  label: Pages
+  description: This is the document for grouping all pages.
+page:
+  confidence: 0.9
+  kind: regularDocument
+  temporal: false
+  label: Page
+  description: ...
+pageSections:
+  confidence: 0.9
+  kind: partList
+  label: Sections
+  description: ...
+pageSection:
+  confidence: 0.8
+  kind: part
+  label: Section
+  description: ...
+</correct_example>
+
+# Producing outputs
+
+Before providing your final answer, use the scratchpad to organize your thoughts and plan the structure:
+
+<scratchpad>
+[Use this space to analyze the website description, identify node types, and plan the hierarchy]
+</scratchpad>
+
+Once you have organized your thoughts, provide the first YAML for website properties (step 1) within <website_properties_yaml> tags.
+
+Then, provide the mardown representing the website tree structure (step 2) within <hierarchical_md> tags.
+
+Provide the node types properties (step 3) within <dictionary_yaml> tags.
+
+Also, write a short explanation of your choices regarding the 3 steps, within <explanation_md> tags. Write the explanation in markdown and in the website description language. Your explanation message will be shown to the end-user.
+
+Finally, extract and rephrase within <unused_information_md> tags the information from the site description that you weren't able to use in the previous elements, in the form of a short prompt, in markdown format. Do not invent anything. Do not imagine anything. If you used every valuable information, then let this tag empty.
+
+Do not include any other explanation or commentary outside these tags.

package/gen-backend/prompts/new-site-2-fields.md

@@ -0,0 +1,50 @@
+You are tasked of assigning predefined fields for each node type (routing document, regular document, or part).
+
+1. Look at the list of available predefined fields (in JSON format):
+
+<predefined_fields_json>
+{predefinedFields}
+</predefined_fields_json>
+
+2. Examine the current site schema, which conforms to the `JtSiteSchema` type:
+
+<site_schema_json>
+{siteSchemaJson}
+</site_schema_json>
+
+3. Check if there are instructions about fields in these user instructions:
+
+<user_request>
+{message}
+</user_request>
+
+4. Now, here is what to do:
+
+Create a key/value dictionnary. Keys are the node type names of the provided site schema. Value are arrays of field names.
+
+Guidelines for creating the dictionnary YAML:
+
+- Use a YAML syntax.
+- All the node types must have a key in your result.
+- If there is no need of a field for a node type, then leave an empty array.
+- Documents and parts already contains a _publish date_ and a _draft_ flag.
+- A document already contains a _title_ and a _featured image_, but a part doesn't. That's why the predefined `title` field can be used on part types when needed.
+- Default values:
+  - By default, for most of node types, if you are not sure about what could be the best fields, then remember that a document is a webpage and just use a `[htmlContent]`.
+  - Except if there are specific instructions in the website description, here is the default value for the `_site` node type: `["logo", "footerMention"]`.
+
+Here is an example of expected output:
+
+<correct_example>
+_site: [logo, footerMention]
+home: [htmlContent]
+searchPage: []
+contactPage: ["introduction"]
+regularDocumentExemple1: [gallery, htmlContent]
+partExemple2: [title, image, htmlContent]
+aBlogPostExample: [leadParagraph, htmlContent]
+</correct_example>
+
+Provide the YAML result within <yaml_result> tags. Do not write any explanation or commentary outside the tags.
+
+Additionally, write within <unused_information_md> tags the information from the user instructions that you weren't able to use here, in the form of a short prompt, in markdown format. Do not invent anything. Do not imagine anything. If there is no remaining information, then let this tag empty.

package/gen-backend/prompts/predefined-fields.json

@@ -0,0 +1,110 @@
+[
+  {
+    "fieldName": "leadParagraph",
+    "dataType": "quillDelta",
+    "localized": true,
+    "description": "Lead paragraph, or \"chapo\", of a post (HTML)"
+  },
+  {
+    "fieldName": "htmlContent",
+    "dataType": "quillDelta",
+    "localized": true,
+    "description": "HTML Content"
+  },
+  {
+    "fieldName": "introduction",
+    "dataType": "quillDelta",
+    "localized": true,
+    "description": "A short introduction (HTML)"
+  },
+  {
+    "fieldName": "footerMention",
+    "dataType": "quillDelta",
+    "localized": true,
+    "description": "The footer mention is used to display a legal notice or a disclaimer (HTML). Usually included as a site field."
+  },
+  {
+    "fieldName": "logo",
+    "dataType": "media",
+    "localized": false,
+    "description": "A logo is an image that represents a brand"
+  },
+  {
+    "fieldName": "slogan",
+    "dataType": "string",
+    "localized": true,
+    "description": "A slogan is a memorable motto or phrase as a repetitive expression of an idea or purpose"
+  },
+  {
+    "fieldName": "phone",
+    "dataType": "string",
+    "localized": false,
+    "description": "Phone number"
+  },
+  {
+    "fieldName": "phone2",
+    "dataType": "string",
+    "localized": false,
+    "description": "Secondary phone number"
+  },
+  {
+    "fieldName": "title",
+    "dataType": "string",
+    "localized": true,
+    "description": "Store a title"
+  },
+  {
+    "fieldName": "shortTitle",
+    "dataType": "string",
+    "localized": true,
+    "description": "A short title can be useful for buttons or menu items"
+  },
+  {
+    "fieldName": "gallery",
+    "dataType": "gallery",
+    "localized": false,
+    "description": "A collection of images. It can be used to create a gallery, a slider or a carousel."
+  },
+  {
+    "fieldName": "image",
+    "dataType": "media",
+    "localized": false,
+    "description": "An image"
+  },
+  {
+    "fieldName": "backgroundImage",
+    "dataType": "media",
+    "localized": false,
+    "description": "A background image"
+  },
+  {
+    "fieldName": "translatedImage",
+    "dataType": "media",
+    "localized": true,
+    "description": "Image that will be different depending on the language (localized)"
+  },
+  {
+    "fieldName": "featuredDocument",
+    "dataType": "string",
+    "localized": false,
+    "description": "A link to a featured document"
+  },
+  {
+    "fieldName": "phones",
+    "dataType": "json",
+    "localized": false,
+    "description": "A list of phone numbers"
+  },
+  {
+    "fieldName": "video",
+    "dataType": "string",
+    "localized": false,
+    "description": "A Youtube video"
+  },
+  {
+    "fieldName": "translatedVideo",
+    "dataType": "string",
+    "localized": true,
+    "description": "A Youtube video with translations"
+  }
+]

package/gen-backend/prompts/test-message1.txt

@@ -0,0 +1 @@
+Je souhaite créer un site web "Mon site personnel" qui contiendra une liste d'articles, ainsi qu'une section nommée "Moins Occidental", laquelle sera dédiée à un livre. Dans "Moins Occidental", il y aura les pages du livres, mais ces pages ne seront pas des pages web, elles seront plutôt des sous-sections et elles apparaîtront toutes dans la page web de "Moins Occidental". "Moins Occidental" contient aussi une liste de sous-pages web de critiques du livre.

package/gen-backend/prompts/update-site-schema-1-write-details.md

@@ -0,0 +1,57 @@
+You are tasked with modifying a JSON object of a _site schema_, based on a given TypeScript type definition and an update message, and its localized labels. Follow these steps carefully:
+
+1. Review the TypeScript type definition of the JSON structure:
+
+<site_schema_ts_defs>
+{siteSchemaTsDefs}
+</site_schema_ts_defs>
+
+2. Examine the current JSON data, which conforms to the `JtSiteSchema` type:
+
+<site_schema_json>
+{siteSchemaJson}
+</site_schema_json>
+
+Also, the attached localized labels:
+
+<localized_labels_json>
+{l10nJson}
+</localized_labels_json>
+
+3. Read the user message that describes the required changes:
+
+<user_message>
+{updateMessage}
+</user_message>
+
+4. When there is nothing to change
+
+Evaluate wether the current schema already implements the update message. If there's nothing to do, provide an empty <task_details_md> tags and you're done.
+
+5. When there are changes to do
+
+Otherwise, if there is something to change, then rewrite the user's request as a detailed sequence of operations to be carried out one after the other.
+
+Guidelines for reformulating into a detailed sequence of operations:
+
+- All operations must be written in English.
+- Write the list of operations as a bulleted list in Markdown format. Start each operation with the `*` character. And surround identifiers with backquotes.
+- Operations will be executed sequentially, so they must be written in the order of execution.
+- If the user's request is simple and doesn't need to be separated into several operations, write a list with a single operation.
+- Describe each operation concisely in a few words.
+- Make sure that the tree structure of node types is not broken. The `site` node is separate. Then, the root of the tree structure is the `home` routing document. Every other routing document type, regular document type, part type, must be the child of another node type.
+
+Be the the less creative as possible. Follow the instructions. In particular:
+
+- You are allowed to be proactive, but only when the user asks you to do something.
+- Do not invent technical "fields" like sibling previous/next links. These are managed by the theme.
+- Do not manage media policies unless the user ask specifically. There is a default one.
+- Do not assume how works the CMS if you are not sure. Just use the provided information.
+
+Provide the bullet list in Markdown within <task_details_md> tags.
+
+6. Write an explanation
+
+Also, write a short explanation of your choices, within <explanation_md> tags. Write the explanation in markdown and in the language of the update message. Your explanation message will be shown to the end-user.
+
+Do not include any other explanation or commentary outside these tags.