create-nextblock 0.17.1 → 0.17.2

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "create-nextblock",
-  "version": "0.17.1",
+  "version": "0.17.2",
   "description": "Scaffold a production-ready NextBlock CMS project — the open-source, full-stack AI-native CMS for Next.js 16, Supabase, and Tailwind CSS.",
   "main": "index.js",
   "bin": {

package/templates/nextblock-template/app/api/cron/reset-sandbox/sandboxResetSql.ts

@@ -12064,6 +12064,62 @@ END
 $nb_baseline_seed$;
 
 
+-- >>> FROM: 02005_home_live_demo_promo_cadence_15min.sql <<<
+-- 02005: home "Live Demo" promo copy -- reset cadence "daily" -> "every 15 minutes".
+--
+-- cms.nextblock.dev now runs on Vercel Pro and its reset cron in vercel.json is
+-- */15 * * * * (was 0 3 * * *, daily). The promo section on the EN ('home') and FR
+-- ('accueil') home pages still advertises a daily reset; it already shipped through
+-- 02000 (catch-up) / 02004 (baseline) and lives on real installs, so per the append-only
+-- rule this is a forward-only data fix instead of an edit to those files.
+--
+-- Targets the promo by its nb-sandbox-promo sentinel + parent page (never blocks.id:
+-- ids drift on every install) and rewrites only the six cadence phrases (EN + FR) with
+-- replace(), leaving the rest of the block untouched. page_revisions rows carrying the
+-- sentinel get the same rewrite so restoring a seeded revision cannot bring the "daily"
+-- copy back. Idempotent: a second run matches zero rows (content already equals the
+-- rewritten text). On the sandbox the promo is still stripped afterward by
+-- removeSandboxPromoSections in the reset-sandbox route.
+--
+-- NOTE: keep the word "sandbox" OUT of this filename -- generate-sandbox-reset.ts
+-- excludes any migration whose filename contains "sandbox" from the reset bundle.
+
+CREATE OR REPLACE FUNCTION pg_temp.nb_promo_cadence_15min(src text)
+RETURNS text
+LANGUAGE sql
+IMMUTABLE
+AS $fn$
+  SELECT replace(replace(replace(replace(replace(replace(src,
+    'It resets daily, so explore',
+    'It resets every 15 minutes, so explore'),
+    '&middot; Resets daily</p>',
+    '&middot; Resets every 15 minutes</p>'),
+    'Wipes clean daily</strong>',
+    'Wipes clean every 15 minutes</strong>'),
+    'Il se r&eacute;initialise chaque jour :',
+    'Il se r&eacute;initialise toutes les 15 minutes :'),
+    'R&eacute;initialis&eacute; chaque jour</p>',
+    'R&eacute;initialis&eacute; toutes les 15 minutes</p>'),
+    'Remis &agrave; z&eacute;ro chaque jour</strong>',
+    'Remis &agrave; z&eacute;ro toutes les 15 minutes</strong>')
+$fn$;
+
+UPDATE public.blocks
+   SET content = pg_temp.nb_promo_cadence_15min(content::text)::jsonb,
+       updated_at = now()
+ WHERE block_type = 'section'
+   AND page_id IS NOT NULL
+   AND content::text LIKE '%nb-sandbox-promo%'
+   AND content::text <> pg_temp.nb_promo_cadence_15min(content::text);
+
+UPDATE public.page_revisions
+   SET content = pg_temp.nb_promo_cadence_15min(content::text)::jsonb
+ WHERE content::text LIKE '%nb-sandbox-promo%'
+   AND content::text <> pg_temp.nb_promo_cadence_15min(content::text);
+
+DROP FUNCTION IF EXISTS pg_temp.nb_promo_cadence_15min(text);
+
+
   -- Step D: Record the applied migrations in history (truncated in Step B) so
   -- \`npm run db:migrate:check\` reports up to date instead of listing every file as pending.
   INSERT INTO supabase_migrations.schema_migrations (version, name) VALUES
@@ -12071,7 +12127,8 @@ $nb_baseline_seed$;
     ('02001', 'baseline_schema'),
     ('02002', 'baseline_constraints_and_indexes'),
     ('02003', 'baseline_security_and_grants'),
-    ('02004', 'baseline_seed')
+    ('02004', 'baseline_seed'),
+    ('02005', 'home_live_demo_promo_cadence_15min')
   ON CONFLICT (version) DO NOTHING;
 
   -- Step E: Anchor preserved profiles

package/templates/nextblock-template/app/cms/settings/security/page.tsx

@@ -14,7 +14,7 @@ export default async function SecuritySettingsPage() {
             <CardTitle>Security &amp; 2FA</CardTitle>
             <CardDescription>
               Security settings are disabled in the sandbox/demo environment, which runs on a
-              shared account and resets daily. They are available in a real installation.
+              shared account and resets every 15 minutes. They are available in a real installation.
             </CardDescription>
           </CardHeader>
           <CardContent />

package/templates/nextblock-template/docs/12-VERCEL-DEPLOYMENT.md

@@ -167,15 +167,18 @@ the question entirely by resolving everything in-app, so the button prompts for
 
 ## Cron jobs and the Hobby plan
 
-`vercel.json` declares two crons (`/api/cron/reset-sandbox` at 03:00 and
-`/api/cron/sync-currencies` at 18:00). Vercel's **Hobby (free) tier allows up to 100
-cron jobs, each running at most once per day** — both jobs are daily, so they deploy
-fine on the free tier. (Hobby timing is approximate, ±59 min, which is irrelevant for
-daily jobs; only sub-daily schedules like `0 * * * *` are rejected on Hobby.)
-
-`reset-sandbox` only does work in sandbox mode — it returns 404 otherwise — so on a
-normal deploy it is a harmless no-op. Delete it from `vercel.json` if you'd rather not
-see it scheduled.
+`vercel.json` declares two crons: `/api/cron/reset-sandbox` **every 15 minutes**
+(`*/15 * * * *`) and `/api/cron/sync-currencies` daily at 18:00 UTC. The 15-minute
+schedule is what keeps the public sandbox at `cms.nextblock.dev` fresh; that project
+runs on **Vercel Pro**, which allows cron schedules down to once per minute with
+per-minute precision.
+
+Vercel’s **Hobby (free) tier only allows cron jobs that run at most once per day**
+(timing is approximate, ±59 min), and **a sub-daily schedule fails the deployment**
+outright. So on a Hobby project you must **delete the `reset-sandbox` entry from
+`vercel.json`** before deploying. Nothing is lost: `reset-sandbox` only does work in
+sandbox mode — it returns 404 otherwise — so on a normal deploy it is a harmless
+no-op anyway. `sync-currencies` is daily and deploys fine on Hobby.
 
 ## After deploy