@nextblock-cms/db 0.15.10 → 0.16.2
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.
- package/lib/supabase/server.d.ts +31 -1
- package/lib/supabase/types.d.ts +41 -11
- package/package.json +1 -1
- package/supabase/migrations/00000000000003_baseline_seed.sql +468 -468
- package/supabase/migrations/00000000000006_home_live_demo_promo.sql +67 -67
- package/supabase/migrations/00000000000007_home_live_demo_promo_copy_fix.sql +49 -49
- package/supabase/migrations/00000000000009_home_live_demo_promo_contrast.sql +52 -52
- package/supabase/migrations/00000000000014_site_themes.sql +254 -254
- package/supabase/migrations/00000000000015_scheduled_publishing.sql +43 -43
- package/supabase/migrations/00000000000016_product_revisions_and_revision_baseline.sql +310 -310
- package/supabase/migrations/00000000000017_cortex_ai_mcp_server.sql +91 -91
- package/supabase/migrations/00000000000018_site_scripts.sql +96 -96
- package/supabase/migrations/00000000000019_site_script_revisions.sql +85 -85
- package/supabase/migrations/00000000000020_updating_article.sql +162 -162
- package/supabase/migrations/00000000000021_updating_article_git_merge.sql +91 -91
- package/supabase/migrations/00000000000022_updating_article_accuracy.sql +94 -94
- package/supabase/migrations/00000000000023_updating_article_layout_not_host.sql +87 -87
- package/supabase/migrations/00000000000024_updating_article_newline_fix.sql +70 -70
- package/supabase/migrations/00000000000025_rebrand_nextblock_dev.sql +53 -53
- package/supabase/migrations/00000000000026_product_inquiries.sql +118 -118
- package/supabase/migrations/00000000000027_message_threads.sql +391 -391
- package/supabase/migrations/00000000000028_interaction_replies.sql +86 -86
- package/supabase/migrations/00000000000029_form_endpoints_default_empty.sql +52 -52
- package/supabase/migrations/00000000000030_seo_redirects_and_robots.sql +149 -0
- package/supabase/migrations/00000000000031_seo_robots_settings_admin_only.sql +35 -0
|
@@ -1,91 +1,91 @@
|
|
|
1
|
-
-- 00000000000021_updating_article_git_merge.sql
|
|
2
|
-
-- Corrects the "How Updating NextBlock Works" article seeded in 00000000000020.
|
|
3
|
-
--
|
|
4
|
-
-- That version described the standalone update as "replace the files and keep a backup
|
|
5
|
-
-- under .nextblock-backup/". The updater now performs a real git 3-way merge instead:
|
|
6
|
-
-- both template versions are committed into the project's own object database under
|
|
7
|
-
-- refs/nextblock/{base,head}, and the diff between them is applied with `git apply --3way`.
|
|
8
|
-
-- A developer's edits to framework files are preserved and only genuine overlaps conflict.
|
|
9
|
-
-- The copy-and-back-up path survives only as the fallback for a project with no git repo,
|
|
10
|
-
-- no commits, or a dirty tree.
|
|
11
|
-
--
|
|
12
|
-
-- 020 is already applied everywhere and never replays, so the copy is corrected here as
|
|
13
|
-
-- targeted, idempotent string replacements rather than a full re-write of the body: each
|
|
14
|
-
-- replace() is a no-op once the old sentence is gone, so re-running changes nothing.
|
|
15
|
-
-- Data-only; no schema change.
|
|
16
|
-
|
|
17
|
-
DO $body$
|
|
18
|
-
DECLARE
|
|
19
|
-
v_en_post integer;
|
|
20
|
-
v_fr_post integer;
|
|
21
|
-
BEGIN
|
|
22
|
-
SELECT id INTO v_en_post
|
|
23
|
-
FROM public.posts WHERE language_id = 1 AND slug = 'how-updating-works'
|
|
24
|
-
ORDER BY id LIMIT 1;
|
|
25
|
-
|
|
26
|
-
SELECT id INTO v_fr_post
|
|
27
|
-
FROM public.posts WHERE language_id = 2 AND slug = 'comment-fonctionnent-les-mises-a-jour'
|
|
28
|
-
ORDER BY id LIMIT 1;
|
|
29
|
-
|
|
30
|
-
---------------------------------------------------------------------------
|
|
31
|
-
-- English
|
|
32
|
-
---------------------------------------------------------------------------
|
|
33
|
-
IF v_en_post IS NOT NULL THEN
|
|
34
|
-
UPDATE public.blocks
|
|
35
|
-
SET content = jsonb_set(
|
|
36
|
-
content,
|
|
37
|
-
'{html_content}',
|
|
38
|
-
to_jsonb(
|
|
39
|
-
replace(
|
|
40
|
-
replace(
|
|
41
|
-
replace(
|
|
42
|
-
content->>'html_content',
|
|
43
|
-
-- 1. the "if something goes wrong" bullet
|
|
44
|
-
'<li><strong>Standalone projects:</strong> every framework file the update replaces is copied first into a timestamped folder under <code>.nextblock-backup/</code> in your project. Nothing is deleted, so files you added yourself are never removed.</li>',
|
|
45
|
-
'<li><strong>Standalone projects:</strong> the update is applied as a <strong>git 3-way merge</strong> into your working tree — nothing is committed for you. Review it with <code>git diff</code>, and undo the whole thing with <code>git reset --hard HEAD</code>. Nothing is ever deleted, so files you added yourself are never removed.</li>'
|
|
46
|
-
),
|
|
47
|
-
-- 2. the "you customised a framework file" paragraph
|
|
48
|
-
'<p>If you have customised a file that NextBlock owns — something under <code>app/</code>, <code>components/</code> or <code>lib/</code> — the update will replace it and back up your version. Diff the backup afterwards to bring your change forward. Customisations that live in your own new files, in the CMS, or in <code>.env</code> are never affected.</p>',
|
|
49
|
-
'<p>If you have customised a file that NextBlock owns — something under <code>app/</code>, <code>components/</code> or <code>lib/</code> — <strong>your edit is kept</strong>. The update merges the upstream change into your version, and only a change that genuinely overlaps yours conflicts, with ordinary <code><<<<<<< ours</code> / <code>>>>>>>> theirs</code> markers. List them with <code>git diff --name-only --diff-filter=U</code> and resolve with <code>git checkout --theirs</code> or <code>--ours</code>. Customisations in your own files, in the CMS, or in <code>.env</code> are never touched at all.</p>'
|
|
50
|
-
),
|
|
51
|
-
-- 3. the managed-cloud section
|
|
52
|
-
'<p>Your project is a standalone Next.js app, so new framework code is fetched from the published <code>create-nextblock</code> package on npm — the exact artifact your project was scaffolded from, versioned in lockstep with the release. NextBlock refreshes the files it owns, merges the new dependency versions into your <code>package.json</code>, runs <code>npm install</code>, and then applies migrations.</p>',
|
|
53
|
-
'<p>Your project is a standalone Next.js app with no upstream to pull from, so new framework code comes from the published <code>create-nextblock</code> package on npm — the exact artifact your project was scaffolded from, versioned in lockstep with the release. NextBlock fetches both your current version and the new one, and applies the difference between them as a <strong>git 3-way merge</strong>, so the update behaves exactly like a <code>git pull</code>: files you never touched update silently, files you customised keep your changes. It then merges the new dependency versions into your <code>package.json</code>, runs <code>npm install</code>, and applies migrations.</p><p>This needs a git repository with at least one commit and a clean working tree — commit your work before updating. Without that there is nothing to merge against, so the files are copied instead and anything replaced is kept under <code>.nextblock-backup/</code>.</p>'
|
|
54
|
-
)
|
|
55
|
-
)
|
|
56
|
-
),
|
|
57
|
-
updated_at = now()
|
|
58
|
-
WHERE post_id = v_en_post
|
|
59
|
-
AND block_type = 'text';
|
|
60
|
-
END IF;
|
|
61
|
-
|
|
62
|
-
---------------------------------------------------------------------------
|
|
63
|
-
-- French
|
|
64
|
-
---------------------------------------------------------------------------
|
|
65
|
-
IF v_fr_post IS NOT NULL THEN
|
|
66
|
-
UPDATE public.blocks
|
|
67
|
-
SET content = jsonb_set(
|
|
68
|
-
content,
|
|
69
|
-
'{html_content}',
|
|
70
|
-
to_jsonb(
|
|
71
|
-
replace(
|
|
72
|
-
replace(
|
|
73
|
-
replace(
|
|
74
|
-
content->>'html_content',
|
|
75
|
-
'<li><strong>Projets autonomes :</strong> chaque fichier remplacé est d''abord copié dans un dossier horodaté sous <code>.nextblock-backup/</code> dans votre projet. Rien n''est supprimé : les fichiers que vous avez ajoutés ne disparaissent jamais.</li>',
|
|
76
|
-
'<li><strong>Projets autonomes :</strong> la mise à jour est appliquée comme une <strong>fusion git à trois voies</strong> dans votre copie de travail — rien n''est validé à votre place. Examinez-la avec <code>git diff</code>, et annulez tout avec <code>git reset --hard HEAD</code>. Rien n''est jamais supprimé : les fichiers que vous avez ajoutés ne disparaissent jamais.</li>'
|
|
77
|
-
),
|
|
78
|
-
'<p>Si vous avez personnalisé un fichier appartenant à NextBlock — sous <code>app/</code>, <code>components/</code> ou <code>lib/</code> — la mise à jour le remplacera en sauvegardant votre version. Comparez ensuite la sauvegarde pour reporter votre modification. Les personnalisations qui vivent dans vos propres fichiers, dans le CMS ou dans <code>.env</code> ne sont jamais affectées.</p>',
|
|
79
|
-
'<p>Si vous avez personnalisé un fichier appartenant à NextBlock — sous <code>app/</code>, <code>components/</code> ou <code>lib/</code> — <strong>votre modification est conservée</strong>. La mise à jour fusionne le changement amont dans votre version, et seul un changement qui chevauche réellement le vôtre entre en conflit, avec les marqueurs habituels <code><<<<<<< ours</code> / <code>>>>>>>> theirs</code>. Listez-les avec <code>git diff --name-only --diff-filter=U</code> et résolvez avec <code>git checkout --theirs</code> ou <code>--ours</code>. Les personnalisations dans vos propres fichiers, dans le CMS ou dans <code>.env</code> ne sont jamais touchées.</p>'
|
|
80
|
-
),
|
|
81
|
-
'<p>Votre projet est une application Next.js autonome : le nouveau code provient donc du paquet <code>create-nextblock</code> publié sur npm — exactement l''artefact à partir duquel votre projet a été généré, versionné en phase avec la release. NextBlock rafraîchit les fichiers qui lui appartiennent, fusionne les nouvelles versions de dépendances dans votre <code>package.json</code>, lance <code>npm install</code>, puis applique les migrations.</p>',
|
|
82
|
-
'<p>Votre projet est une application Next.js autonome sans dépôt amont à tirer : le nouveau code provient donc du paquet <code>create-nextblock</code> publié sur npm — exactement l''artefact à partir duquel votre projet a été généré, versionné en phase avec la release. NextBlock récupère votre version actuelle et la nouvelle, puis applique la différence entre les deux comme une <strong>fusion git à trois voies</strong> : la mise à jour se comporte donc exactement comme un <code>git pull</code> — les fichiers que vous n''avez jamais touchés se mettent à jour silencieusement, ceux que vous avez personnalisés conservent vos changements. Elle fusionne ensuite les nouvelles versions de dépendances dans votre <code>package.json</code>, lance <code>npm install</code> et applique les migrations.</p><p>Cela nécessite un dépôt git avec au moins un commit et une copie de travail propre — validez votre travail avant de mettre à jour. Sans cela il n''y a rien contre quoi fusionner : les fichiers sont alors copiés et tout ce qui est remplacé est conservé sous <code>.nextblock-backup/</code>.</p>'
|
|
83
|
-
)
|
|
84
|
-
)
|
|
85
|
-
),
|
|
86
|
-
updated_at = now()
|
|
87
|
-
WHERE post_id = v_fr_post
|
|
88
|
-
AND block_type = 'text';
|
|
89
|
-
END IF;
|
|
90
|
-
END
|
|
91
|
-
$body$;
|
|
1
|
+
-- 00000000000021_updating_article_git_merge.sql
|
|
2
|
+
-- Corrects the "How Updating NextBlock Works" article seeded in 00000000000020.
|
|
3
|
+
--
|
|
4
|
+
-- That version described the standalone update as "replace the files and keep a backup
|
|
5
|
+
-- under .nextblock-backup/". The updater now performs a real git 3-way merge instead:
|
|
6
|
+
-- both template versions are committed into the project's own object database under
|
|
7
|
+
-- refs/nextblock/{base,head}, and the diff between them is applied with `git apply --3way`.
|
|
8
|
+
-- A developer's edits to framework files are preserved and only genuine overlaps conflict.
|
|
9
|
+
-- The copy-and-back-up path survives only as the fallback for a project with no git repo,
|
|
10
|
+
-- no commits, or a dirty tree.
|
|
11
|
+
--
|
|
12
|
+
-- 020 is already applied everywhere and never replays, so the copy is corrected here as
|
|
13
|
+
-- targeted, idempotent string replacements rather than a full re-write of the body: each
|
|
14
|
+
-- replace() is a no-op once the old sentence is gone, so re-running changes nothing.
|
|
15
|
+
-- Data-only; no schema change.
|
|
16
|
+
|
|
17
|
+
DO $body$
|
|
18
|
+
DECLARE
|
|
19
|
+
v_en_post integer;
|
|
20
|
+
v_fr_post integer;
|
|
21
|
+
BEGIN
|
|
22
|
+
SELECT id INTO v_en_post
|
|
23
|
+
FROM public.posts WHERE language_id = 1 AND slug = 'how-updating-works'
|
|
24
|
+
ORDER BY id LIMIT 1;
|
|
25
|
+
|
|
26
|
+
SELECT id INTO v_fr_post
|
|
27
|
+
FROM public.posts WHERE language_id = 2 AND slug = 'comment-fonctionnent-les-mises-a-jour'
|
|
28
|
+
ORDER BY id LIMIT 1;
|
|
29
|
+
|
|
30
|
+
---------------------------------------------------------------------------
|
|
31
|
+
-- English
|
|
32
|
+
---------------------------------------------------------------------------
|
|
33
|
+
IF v_en_post IS NOT NULL THEN
|
|
34
|
+
UPDATE public.blocks
|
|
35
|
+
SET content = jsonb_set(
|
|
36
|
+
content,
|
|
37
|
+
'{html_content}',
|
|
38
|
+
to_jsonb(
|
|
39
|
+
replace(
|
|
40
|
+
replace(
|
|
41
|
+
replace(
|
|
42
|
+
content->>'html_content',
|
|
43
|
+
-- 1. the "if something goes wrong" bullet
|
|
44
|
+
'<li><strong>Standalone projects:</strong> every framework file the update replaces is copied first into a timestamped folder under <code>.nextblock-backup/</code> in your project. Nothing is deleted, so files you added yourself are never removed.</li>',
|
|
45
|
+
'<li><strong>Standalone projects:</strong> the update is applied as a <strong>git 3-way merge</strong> into your working tree — nothing is committed for you. Review it with <code>git diff</code>, and undo the whole thing with <code>git reset --hard HEAD</code>. Nothing is ever deleted, so files you added yourself are never removed.</li>'
|
|
46
|
+
),
|
|
47
|
+
-- 2. the "you customised a framework file" paragraph
|
|
48
|
+
'<p>If you have customised a file that NextBlock owns — something under <code>app/</code>, <code>components/</code> or <code>lib/</code> — the update will replace it and back up your version. Diff the backup afterwards to bring your change forward. Customisations that live in your own new files, in the CMS, or in <code>.env</code> are never affected.</p>',
|
|
49
|
+
'<p>If you have customised a file that NextBlock owns — something under <code>app/</code>, <code>components/</code> or <code>lib/</code> — <strong>your edit is kept</strong>. The update merges the upstream change into your version, and only a change that genuinely overlaps yours conflicts, with ordinary <code><<<<<<< ours</code> / <code>>>>>>>> theirs</code> markers. List them with <code>git diff --name-only --diff-filter=U</code> and resolve with <code>git checkout --theirs</code> or <code>--ours</code>. Customisations in your own files, in the CMS, or in <code>.env</code> are never touched at all.</p>'
|
|
50
|
+
),
|
|
51
|
+
-- 3. the managed-cloud section
|
|
52
|
+
'<p>Your project is a standalone Next.js app, so new framework code is fetched from the published <code>create-nextblock</code> package on npm — the exact artifact your project was scaffolded from, versioned in lockstep with the release. NextBlock refreshes the files it owns, merges the new dependency versions into your <code>package.json</code>, runs <code>npm install</code>, and then applies migrations.</p>',
|
|
53
|
+
'<p>Your project is a standalone Next.js app with no upstream to pull from, so new framework code comes from the published <code>create-nextblock</code> package on npm — the exact artifact your project was scaffolded from, versioned in lockstep with the release. NextBlock fetches both your current version and the new one, and applies the difference between them as a <strong>git 3-way merge</strong>, so the update behaves exactly like a <code>git pull</code>: files you never touched update silently, files you customised keep your changes. It then merges the new dependency versions into your <code>package.json</code>, runs <code>npm install</code>, and applies migrations.</p><p>This needs a git repository with at least one commit and a clean working tree — commit your work before updating. Without that there is nothing to merge against, so the files are copied instead and anything replaced is kept under <code>.nextblock-backup/</code>.</p>'
|
|
54
|
+
)
|
|
55
|
+
)
|
|
56
|
+
),
|
|
57
|
+
updated_at = now()
|
|
58
|
+
WHERE post_id = v_en_post
|
|
59
|
+
AND block_type = 'text';
|
|
60
|
+
END IF;
|
|
61
|
+
|
|
62
|
+
---------------------------------------------------------------------------
|
|
63
|
+
-- French
|
|
64
|
+
---------------------------------------------------------------------------
|
|
65
|
+
IF v_fr_post IS NOT NULL THEN
|
|
66
|
+
UPDATE public.blocks
|
|
67
|
+
SET content = jsonb_set(
|
|
68
|
+
content,
|
|
69
|
+
'{html_content}',
|
|
70
|
+
to_jsonb(
|
|
71
|
+
replace(
|
|
72
|
+
replace(
|
|
73
|
+
replace(
|
|
74
|
+
content->>'html_content',
|
|
75
|
+
'<li><strong>Projets autonomes :</strong> chaque fichier remplacé est d''abord copié dans un dossier horodaté sous <code>.nextblock-backup/</code> dans votre projet. Rien n''est supprimé : les fichiers que vous avez ajoutés ne disparaissent jamais.</li>',
|
|
76
|
+
'<li><strong>Projets autonomes :</strong> la mise à jour est appliquée comme une <strong>fusion git à trois voies</strong> dans votre copie de travail — rien n''est validé à votre place. Examinez-la avec <code>git diff</code>, et annulez tout avec <code>git reset --hard HEAD</code>. Rien n''est jamais supprimé : les fichiers que vous avez ajoutés ne disparaissent jamais.</li>'
|
|
77
|
+
),
|
|
78
|
+
'<p>Si vous avez personnalisé un fichier appartenant à NextBlock — sous <code>app/</code>, <code>components/</code> ou <code>lib/</code> — la mise à jour le remplacera en sauvegardant votre version. Comparez ensuite la sauvegarde pour reporter votre modification. Les personnalisations qui vivent dans vos propres fichiers, dans le CMS ou dans <code>.env</code> ne sont jamais affectées.</p>',
|
|
79
|
+
'<p>Si vous avez personnalisé un fichier appartenant à NextBlock — sous <code>app/</code>, <code>components/</code> ou <code>lib/</code> — <strong>votre modification est conservée</strong>. La mise à jour fusionne le changement amont dans votre version, et seul un changement qui chevauche réellement le vôtre entre en conflit, avec les marqueurs habituels <code><<<<<<< ours</code> / <code>>>>>>>> theirs</code>. Listez-les avec <code>git diff --name-only --diff-filter=U</code> et résolvez avec <code>git checkout --theirs</code> ou <code>--ours</code>. Les personnalisations dans vos propres fichiers, dans le CMS ou dans <code>.env</code> ne sont jamais touchées.</p>'
|
|
80
|
+
),
|
|
81
|
+
'<p>Votre projet est une application Next.js autonome : le nouveau code provient donc du paquet <code>create-nextblock</code> publié sur npm — exactement l''artefact à partir duquel votre projet a été généré, versionné en phase avec la release. NextBlock rafraîchit les fichiers qui lui appartiennent, fusionne les nouvelles versions de dépendances dans votre <code>package.json</code>, lance <code>npm install</code>, puis applique les migrations.</p>',
|
|
82
|
+
'<p>Votre projet est une application Next.js autonome sans dépôt amont à tirer : le nouveau code provient donc du paquet <code>create-nextblock</code> publié sur npm — exactement l''artefact à partir duquel votre projet a été généré, versionné en phase avec la release. NextBlock récupère votre version actuelle et la nouvelle, puis applique la différence entre les deux comme une <strong>fusion git à trois voies</strong> : la mise à jour se comporte donc exactement comme un <code>git pull</code> — les fichiers que vous n''avez jamais touchés se mettent à jour silencieusement, ceux que vous avez personnalisés conservent vos changements. Elle fusionne ensuite les nouvelles versions de dépendances dans votre <code>package.json</code>, lance <code>npm install</code> et applique les migrations.</p><p>Cela nécessite un dépôt git avec au moins un commit et une copie de travail propre — validez votre travail avant de mettre à jour. Sans cela il n''y a rien contre quoi fusionner : les fichiers sont alors copiés et tout ce qui est remplacé est conservé sous <code>.nextblock-backup/</code>.</p>'
|
|
83
|
+
)
|
|
84
|
+
)
|
|
85
|
+
),
|
|
86
|
+
updated_at = now()
|
|
87
|
+
WHERE post_id = v_fr_post
|
|
88
|
+
AND block_type = 'text';
|
|
89
|
+
END IF;
|
|
90
|
+
END
|
|
91
|
+
$body$;
|
|
@@ -1,94 +1,94 @@
|
|
|
1
|
-
-- 00000000000022_updating_article_accuracy.sql
|
|
2
|
-
-- Three accuracy fixes to the "How Updating NextBlock Works" article
|
|
3
|
-
-- (seeded in 00000000000020, first corrected in 00000000000021).
|
|
4
|
-
--
|
|
5
|
-
-- 0. The merge is performed with `git merge-file`, not `git apply --3way`. The latter
|
|
6
|
-
-- implies --index: it stages its result (so `git diff` shows the developer nothing),
|
|
7
|
-
-- requires every path to be tracked (one gitignored framework path aborted the whole
|
|
8
|
-
-- update), and requires the worktree to match the index. merge-file touches no git
|
|
9
|
-
-- state at all. Consequently the resolution commands 021 shipped are wrong: there are
|
|
10
|
-
-- no index stages, so `git checkout --theirs/--ours` does not apply. The conflict
|
|
11
|
-
-- markers are ordinary text; `git checkout -- <file>` discards one file's merge.
|
|
12
|
-
--
|
|
13
|
-
-- 1. "A conflicted merge is aborted automatically" was true of only ONE path. The
|
|
14
|
-
-- monorepo/fork path does abort and restore the tree, because the merge belongs to
|
|
15
|
-
-- upstream. The standalone path deliberately LEAVES the conflict in the working tree,
|
|
16
|
-
-- because it is the developer's own repository and resolving it is the whole point.
|
|
17
|
-
-- The bullet now states both.
|
|
18
|
-
-- 2. The Docker section claimed `npm run update` refreshes the schema. It does not, by
|
|
19
|
-
-- design: the self-hosted stack ships its own migration runner (the `migrate` service
|
|
20
|
-
-- in docker-compose.yml, which tracks applied versions in a different table), so the
|
|
21
|
-
-- updater stages the SQL and hands off to `npm run docker:up` rather than applying it
|
|
22
|
-
-- twice through two different trackers.
|
|
23
|
-
--
|
|
24
|
-
-- Same targeted, idempotent replace() approach as 021 — a no-op once the old sentence is
|
|
25
|
-
-- gone. Data-only; no schema change.
|
|
26
|
-
|
|
27
|
-
DO $body$
|
|
28
|
-
DECLARE
|
|
29
|
-
v_en_post integer;
|
|
30
|
-
v_fr_post integer;
|
|
31
|
-
BEGIN
|
|
32
|
-
SELECT id INTO v_en_post
|
|
33
|
-
FROM public.posts WHERE language_id = 1 AND slug = 'how-updating-works'
|
|
34
|
-
ORDER BY id LIMIT 1;
|
|
35
|
-
|
|
36
|
-
SELECT id INTO v_fr_post
|
|
37
|
-
FROM public.posts WHERE language_id = 2 AND slug = 'comment-fonctionnent-les-mises-a-jour'
|
|
38
|
-
ORDER BY id LIMIT 1;
|
|
39
|
-
|
|
40
|
-
IF v_en_post IS NOT NULL THEN
|
|
41
|
-
UPDATE public.blocks
|
|
42
|
-
SET content = jsonb_set(
|
|
43
|
-
content,
|
|
44
|
-
'{html_content}',
|
|
45
|
-
to_jsonb(
|
|
46
|
-
replace(
|
|
47
|
-
replace(
|
|
48
|
-
replace(
|
|
49
|
-
content->>'html_content',
|
|
50
|
-
-- 021 shipped index-based resolution commands; the merge no longer
|
|
51
|
-
-- uses the git index, so they do not apply.
|
|
52
|
-
'<strong>your edit is kept</strong>. The update merges the upstream change into your version, and only a change that genuinely overlaps yours conflicts, with ordinary <code><<<<<<< ours</code> / <code>>>>>>>> theirs</code> markers. List them with <code>git diff --name-only --diff-filter=U</code> and resolve with <code>git checkout --theirs</code> or <code>--ours</code>.',
|
|
53
|
-
'<strong>your edit is kept</strong>. The update merges the upstream change into your version, and only a change that genuinely overlaps yours conflicts — the updater lists those files, and each one carries ordinary <code><<<<<<< your version</code> / <code>>>>>>>> NextBlock</code> markers. Edit them as you would any conflict, or run <code>git checkout -- <file></code> to discard the merge for that one file.'
|
|
54
|
-
),
|
|
55
|
-
'<li><strong>A conflicted merge</strong> is aborted automatically — your working tree is left exactly as it was, with instructions printed for resolving it by hand.</li>',
|
|
56
|
-
'<li><strong>A conflict</strong> behaves differently by install, on purpose. On a fork or clone the upstream merge is <em>aborted</em> and your working tree is left exactly as it was. On a standalone project the conflict is <em>left in place</em> for you to resolve — it is your own repository, and that is the point — and <code>git reset --hard HEAD</code> backs the whole update out.</li>'
|
|
57
|
-
),
|
|
58
|
-
'<p>The first command refreshes the application, its dependencies and the schema; the second rebuilds and restarts the containers. Your database and media live in Docker volumes and are never touched by either step — <code>docker:up</code> rebuilds images, not data.</p>',
|
|
59
|
-
'<p>The first command updates the application and its dependencies and stages the new migrations; the second rebuilds the containers <em>and applies those migrations</em>. The self-hosted stack runs its own migration service, so the updater hands the schema step to it rather than applying the same SQL through two different trackers. Your database and media live in Docker volumes and are never touched by either command — <code>docker:up</code> rebuilds images, not data.</p>'
|
|
60
|
-
)
|
|
61
|
-
)
|
|
62
|
-
),
|
|
63
|
-
updated_at = now()
|
|
64
|
-
WHERE post_id = v_en_post
|
|
65
|
-
AND block_type = 'text';
|
|
66
|
-
END IF;
|
|
67
|
-
|
|
68
|
-
IF v_fr_post IS NOT NULL THEN
|
|
69
|
-
UPDATE public.blocks
|
|
70
|
-
SET content = jsonb_set(
|
|
71
|
-
content,
|
|
72
|
-
'{html_content}',
|
|
73
|
-
to_jsonb(
|
|
74
|
-
replace(
|
|
75
|
-
replace(
|
|
76
|
-
replace(
|
|
77
|
-
content->>'html_content',
|
|
78
|
-
'<strong>votre modification est conservée</strong>. La mise à jour fusionne le changement amont dans votre version, et seul un changement qui chevauche réellement le vôtre entre en conflit, avec les marqueurs habituels <code><<<<<<< ours</code> / <code>>>>>>>> theirs</code>. Listez-les avec <code>git diff --name-only --diff-filter=U</code> et résolvez avec <code>git checkout --theirs</code> ou <code>--ours</code>.',
|
|
79
|
-
'<strong>votre modification est conservée</strong>. La mise à jour fusionne le changement amont dans votre version, et seul un changement qui chevauche réellement le vôtre entre en conflit — la commande liste ces fichiers, et chacun porte les marqueurs habituels <code><<<<<<< your version</code> / <code>>>>>>>> NextBlock</code>. Modifiez-les comme n''importe quel conflit, ou lancez <code>git checkout -- <fichier></code> pour abandonner la fusion sur ce seul fichier.'
|
|
80
|
-
),
|
|
81
|
-
'<li><strong>Une fusion en conflit</strong> est annulée automatiquement — votre copie de travail reste intacte, avec les instructions pour résoudre à la main.</li>',
|
|
82
|
-
'<li><strong>Un conflit</strong> se comporte différemment selon l''installation, volontairement. Sur un fork ou un clone, la fusion amont est <em>annulée</em> et votre copie de travail reste intacte. Sur un projet autonome, le conflit est <em>laissé en place</em> pour que vous le résolviez — c''est votre dépôt, et c''est tout l''intérêt — et <code>git reset --hard HEAD</code> annule toute la mise à jour.</li>'
|
|
83
|
-
),
|
|
84
|
-
'<p>La première commande met à jour l''application, ses dépendances et le schéma ; la seconde reconstruit et redémarre les conteneurs. Votre base de données et vos médias vivent dans des volumes Docker et ne sont touchés ni par l''une ni par l''autre — <code>docker:up</code> reconstruit des images, pas des données.</p>',
|
|
85
|
-
'<p>La première commande met à jour l''application et ses dépendances et prépare les nouvelles migrations ; la seconde reconstruit les conteneurs <em>et applique ces migrations</em>. La pile auto-hébergée dispose de son propre service de migration : la mise à jour lui confie donc l''étape schéma plutôt que d''appliquer le même SQL via deux suivis différents. Votre base de données et vos médias vivent dans des volumes Docker et ne sont touchés par aucune des deux commandes — <code>docker:up</code> reconstruit des images, pas des données.</p>'
|
|
86
|
-
)
|
|
87
|
-
)
|
|
88
|
-
),
|
|
89
|
-
updated_at = now()
|
|
90
|
-
WHERE post_id = v_fr_post
|
|
91
|
-
AND block_type = 'text';
|
|
92
|
-
END IF;
|
|
93
|
-
END
|
|
94
|
-
$body$;
|
|
1
|
+
-- 00000000000022_updating_article_accuracy.sql
|
|
2
|
+
-- Three accuracy fixes to the "How Updating NextBlock Works" article
|
|
3
|
+
-- (seeded in 00000000000020, first corrected in 00000000000021).
|
|
4
|
+
--
|
|
5
|
+
-- 0. The merge is performed with `git merge-file`, not `git apply --3way`. The latter
|
|
6
|
+
-- implies --index: it stages its result (so `git diff` shows the developer nothing),
|
|
7
|
+
-- requires every path to be tracked (one gitignored framework path aborted the whole
|
|
8
|
+
-- update), and requires the worktree to match the index. merge-file touches no git
|
|
9
|
+
-- state at all. Consequently the resolution commands 021 shipped are wrong: there are
|
|
10
|
+
-- no index stages, so `git checkout --theirs/--ours` does not apply. The conflict
|
|
11
|
+
-- markers are ordinary text; `git checkout -- <file>` discards one file's merge.
|
|
12
|
+
--
|
|
13
|
+
-- 1. "A conflicted merge is aborted automatically" was true of only ONE path. The
|
|
14
|
+
-- monorepo/fork path does abort and restore the tree, because the merge belongs to
|
|
15
|
+
-- upstream. The standalone path deliberately LEAVES the conflict in the working tree,
|
|
16
|
+
-- because it is the developer's own repository and resolving it is the whole point.
|
|
17
|
+
-- The bullet now states both.
|
|
18
|
+
-- 2. The Docker section claimed `npm run update` refreshes the schema. It does not, by
|
|
19
|
+
-- design: the self-hosted stack ships its own migration runner (the `migrate` service
|
|
20
|
+
-- in docker-compose.yml, which tracks applied versions in a different table), so the
|
|
21
|
+
-- updater stages the SQL and hands off to `npm run docker:up` rather than applying it
|
|
22
|
+
-- twice through two different trackers.
|
|
23
|
+
--
|
|
24
|
+
-- Same targeted, idempotent replace() approach as 021 — a no-op once the old sentence is
|
|
25
|
+
-- gone. Data-only; no schema change.
|
|
26
|
+
|
|
27
|
+
DO $body$
|
|
28
|
+
DECLARE
|
|
29
|
+
v_en_post integer;
|
|
30
|
+
v_fr_post integer;
|
|
31
|
+
BEGIN
|
|
32
|
+
SELECT id INTO v_en_post
|
|
33
|
+
FROM public.posts WHERE language_id = 1 AND slug = 'how-updating-works'
|
|
34
|
+
ORDER BY id LIMIT 1;
|
|
35
|
+
|
|
36
|
+
SELECT id INTO v_fr_post
|
|
37
|
+
FROM public.posts WHERE language_id = 2 AND slug = 'comment-fonctionnent-les-mises-a-jour'
|
|
38
|
+
ORDER BY id LIMIT 1;
|
|
39
|
+
|
|
40
|
+
IF v_en_post IS NOT NULL THEN
|
|
41
|
+
UPDATE public.blocks
|
|
42
|
+
SET content = jsonb_set(
|
|
43
|
+
content,
|
|
44
|
+
'{html_content}',
|
|
45
|
+
to_jsonb(
|
|
46
|
+
replace(
|
|
47
|
+
replace(
|
|
48
|
+
replace(
|
|
49
|
+
content->>'html_content',
|
|
50
|
+
-- 021 shipped index-based resolution commands; the merge no longer
|
|
51
|
+
-- uses the git index, so they do not apply.
|
|
52
|
+
'<strong>your edit is kept</strong>. The update merges the upstream change into your version, and only a change that genuinely overlaps yours conflicts, with ordinary <code><<<<<<< ours</code> / <code>>>>>>>> theirs</code> markers. List them with <code>git diff --name-only --diff-filter=U</code> and resolve with <code>git checkout --theirs</code> or <code>--ours</code>.',
|
|
53
|
+
'<strong>your edit is kept</strong>. The update merges the upstream change into your version, and only a change that genuinely overlaps yours conflicts — the updater lists those files, and each one carries ordinary <code><<<<<<< your version</code> / <code>>>>>>>> NextBlock</code> markers. Edit them as you would any conflict, or run <code>git checkout -- <file></code> to discard the merge for that one file.'
|
|
54
|
+
),
|
|
55
|
+
'<li><strong>A conflicted merge</strong> is aborted automatically — your working tree is left exactly as it was, with instructions printed for resolving it by hand.</li>',
|
|
56
|
+
'<li><strong>A conflict</strong> behaves differently by install, on purpose. On a fork or clone the upstream merge is <em>aborted</em> and your working tree is left exactly as it was. On a standalone project the conflict is <em>left in place</em> for you to resolve — it is your own repository, and that is the point — and <code>git reset --hard HEAD</code> backs the whole update out.</li>'
|
|
57
|
+
),
|
|
58
|
+
'<p>The first command refreshes the application, its dependencies and the schema; the second rebuilds and restarts the containers. Your database and media live in Docker volumes and are never touched by either step — <code>docker:up</code> rebuilds images, not data.</p>',
|
|
59
|
+
'<p>The first command updates the application and its dependencies and stages the new migrations; the second rebuilds the containers <em>and applies those migrations</em>. The self-hosted stack runs its own migration service, so the updater hands the schema step to it rather than applying the same SQL through two different trackers. Your database and media live in Docker volumes and are never touched by either command — <code>docker:up</code> rebuilds images, not data.</p>'
|
|
60
|
+
)
|
|
61
|
+
)
|
|
62
|
+
),
|
|
63
|
+
updated_at = now()
|
|
64
|
+
WHERE post_id = v_en_post
|
|
65
|
+
AND block_type = 'text';
|
|
66
|
+
END IF;
|
|
67
|
+
|
|
68
|
+
IF v_fr_post IS NOT NULL THEN
|
|
69
|
+
UPDATE public.blocks
|
|
70
|
+
SET content = jsonb_set(
|
|
71
|
+
content,
|
|
72
|
+
'{html_content}',
|
|
73
|
+
to_jsonb(
|
|
74
|
+
replace(
|
|
75
|
+
replace(
|
|
76
|
+
replace(
|
|
77
|
+
content->>'html_content',
|
|
78
|
+
'<strong>votre modification est conservée</strong>. La mise à jour fusionne le changement amont dans votre version, et seul un changement qui chevauche réellement le vôtre entre en conflit, avec les marqueurs habituels <code><<<<<<< ours</code> / <code>>>>>>>> theirs</code>. Listez-les avec <code>git diff --name-only --diff-filter=U</code> et résolvez avec <code>git checkout --theirs</code> ou <code>--ours</code>.',
|
|
79
|
+
'<strong>votre modification est conservée</strong>. La mise à jour fusionne le changement amont dans votre version, et seul un changement qui chevauche réellement le vôtre entre en conflit — la commande liste ces fichiers, et chacun porte les marqueurs habituels <code><<<<<<< your version</code> / <code>>>>>>>> NextBlock</code>. Modifiez-les comme n''importe quel conflit, ou lancez <code>git checkout -- <fichier></code> pour abandonner la fusion sur ce seul fichier.'
|
|
80
|
+
),
|
|
81
|
+
'<li><strong>Une fusion en conflit</strong> est annulée automatiquement — votre copie de travail reste intacte, avec les instructions pour résoudre à la main.</li>',
|
|
82
|
+
'<li><strong>Un conflit</strong> se comporte différemment selon l''installation, volontairement. Sur un fork ou un clone, la fusion amont est <em>annulée</em> et votre copie de travail reste intacte. Sur un projet autonome, le conflit est <em>laissé en place</em> pour que vous le résolviez — c''est votre dépôt, et c''est tout l''intérêt — et <code>git reset --hard HEAD</code> annule toute la mise à jour.</li>'
|
|
83
|
+
),
|
|
84
|
+
'<p>La première commande met à jour l''application, ses dépendances et le schéma ; la seconde reconstruit et redémarre les conteneurs. Votre base de données et vos médias vivent dans des volumes Docker et ne sont touchés ni par l''une ni par l''autre — <code>docker:up</code> reconstruit des images, pas des données.</p>',
|
|
85
|
+
'<p>La première commande met à jour l''application et ses dépendances et prépare les nouvelles migrations ; la seconde reconstruit les conteneurs <em>et applique ces migrations</em>. La pile auto-hébergée dispose de son propre service de migration : la mise à jour lui confie donc l''étape schéma plutôt que d''appliquer le même SQL via deux suivis différents. Votre base de données et vos médias vivent dans des volumes Docker et ne sont touchés par aucune des deux commandes — <code>docker:up</code> reconstruit des images, pas des données.</p>'
|
|
86
|
+
)
|
|
87
|
+
)
|
|
88
|
+
),
|
|
89
|
+
updated_at = now()
|
|
90
|
+
WHERE post_id = v_fr_post
|
|
91
|
+
AND block_type = 'text';
|
|
92
|
+
END IF;
|
|
93
|
+
END
|
|
94
|
+
$body$;
|