DEV Community: labyrinthlab

Exporting a Solo site: fixing fonts, image paths and forms by hand

labyrinthlab — Mon, 02 Nov 2026 14:43:09 +0000

Solo's Shutdown FAQ says the export ZIP holds "an HTML export of your website and a CSV file with links to your image assets, as well as your contact form and newsletter submissions". It also says: "Image source files are not included in the ZIP."

You can't just upload that ZIP to a static host. This post covers four problem areas: images, fonts and styles, page links, and forms. For each one, you get the code our Solo export tool uses (or what it doesn't do) and the manual steps.

A caveat first: we haven't seen a real Solo export. Solo doesn't document the file names or folder layout. Our tests run on a synthetic fixture, fixtures/solo-export-example-bakery-with-assets.zip, built by scripts/build_synthetic_export.py. It assumes a layout that matches what Solo's FAQ says the ZIP contains. The code is written to cope with a different wrapper folder.

The fixture

solo-export-example-bakery-with-assets.zip
├── website/
│   ├── index.html
│   └── about/index.html
├── image_links.csv
├── contact_form_submissions.csv
└── newsletter_submissions.csv

index.html contains the kinds of references the code has to handle:

<link rel="icon" href="/favicon/favicon.ico">
<link rel="stylesheet" href="/_next/static/css/x.css">
<script src="https://soloist.ai/_next/static/chunks/main.js"></script>
...
.hero{background-image:url(https://images.unsplash.com/photo-1542653285-7f095a1183e0?crop=entropy&amp;cs=srgb&amp;fm=jpg&amp;q=60&amp;w=1600)}
...
<a href="/example-bakery/about">About</a> · <a href="/about">About</a>
<img src="https://images.unsplash.com/photo-...?...&amp;w=1080" srcset="...w=400 400w, ...w=1080 1080w, ...w=2400 2400w">
<script id="__NEXT_DATA__" type="application/json">{... "url": "https://images.unsplash.com/photo-...?crop=entropy\u0026cs=srgb\u0026fm=jpg\u0026q=85" ...}</script>

Image URLs show up in four places: src, srcset, inline CSS url(), and JSON. The JSON copy escapes & as \u0026.

1. Image paths

What the code does

lib/localize.ts scans every text file (html, htm, css, js, mjs, cjs, json, csv, txt, xml, svg) with one regex that tolerates both escapes:

export const IMAGE_HOSTS = new Set(["cdn.soloist.ai", "images.unsplash.com"]);

/** Matches http(s) URLs, including HTML `&amp;` and JSON `\\u0026`. */
export const URL_RE = /https?:\/\/(?:[^\s"'<>()\\,]|\\u0026)+/g;

export function normalizeUrl(raw: string): string {
  return raw.replace(/&amp;/g, "&").replace(/\\u0026/g, "&");
}

Then it collapses size variants so each image is downloaded once:

if (host === "cdn.soloist.ai") {
  const m = x.pathname.match(/^(.*)_(\d+)x(\d+)(\.\w+)$/);
  if (m) {
    const fetchUrl = `https://${host}${m[1]}_2048x2048${m[4]}`;
    return { key: host + m[1], fetchUrl, original: url, fallbackUrl: url !== fetchUrl ? url : undefined };
  }
}
if (host === "images.unsplash.com") {
  return {
    key: host + x.pathname,
    fetchUrl: `https://${host}${x.pathname}?ixlib=rb-4.0.3&fm=jpg&q=85&w=2400&fit=max`,
    original: url,
    fallbackUrl: url,
  };
}

A cdn.soloist.ai URL ending in _NNNxNNN maps to its _2048x2048 variant. Unsplash URLs are keyed by pathname, so all the w=400, w=1080 and w=2400 variants count as one image. If the upgraded URL fails, downloadOne() in lib/fetch-images.ts retries with the original URL.

Each file is saved as images/<sha1-prefix>.<ext>, with the extension taken from Content-Type. Then every match in every text file gets rewritten to a path relative to that file:

export function posixRelative(fromFile: string, toFile: string): string {
  // ...
  const rel = [...Array.from({ length: fromParts.length - i }, () => ".."), ...toParts.slice(i)].join("/");
  return rel || normalizedTo;
}

A root page gets images/abc.jpg. about/index.html gets ../images/abc.jpg.

In the browser, cdn.soloist.ai images can't be fetched directly. Our README notes they "have no CORS headers", so the tool routes them through a same-origin /api/img proxy. That proxy allows only cdn.soloist.ai over HTTPS and only passes image/* responses.

By hand

CORS only applies inside browsers, so a script or curl can download the images directly.

Grep every text file for cdn.soloist.ai and images.unsplash.com URLs. Decode & and \u0026 before you dedupe.
Dedupe on path, ignoring size suffix and query string. Download the largest variant.
Replace every occurrence, including srcset entries, CSS url() and __NEXT_DATA__, with a relative path. Calculate the path from each file's own folder, not from the site root.

2. Fonts and styles

What the code does

The exported HTML links stylesheets under /_next/. lib/assets.ts only fetches static, non-JS files from that one prefix:

const JS_PATH = /\.(?:js|mjs|cjs)(?:$|[?#])/i;
const ALLOWED_STATIC_EXT =
  /\.(?:css|woff2?|ttf|otf|eot|svg|png|jpe?g|gif|webp|ico|avif)(?:$|[?#])/i;

export function isAllowedSoloStaticAsset(url: string): boolean {
  const u = new URL(url);
  if (u.protocol !== "https:") return false;
  if (u.hostname !== SOLO_ASSET_HOST) return false; // "soloist.ai"
  if (!u.pathname.startsWith(SOLO_PATH_PREFIX)) return false; // "/_next/"
  if (JS_PATH.test(u.pathname)) return false;
  return ALLOWED_STATIC_EXT.test(u.pathname);
}

captureSoloAssets() starts from each <link rel="stylesheet"> (or rel="preload" as="style"). It reads @import and url() from every CSS file it downloads and queues those references up to depth 4. Each file is saved under assets/ at its original path, so https://soloist.ai/_next/static/media/bakery.woff2 becomes assets/_next/static/media/bakery.woff2. CSS url() values are then rewritten relative to the saved CSS file. Our test asserts the result:

const css = new TextDecoder().decode(result.files["assets/_next/static/css/x.css"]);
assert.match(css, /url\(["']?\.\.\/media\/bakery\.woff2/);
assert.doesNotMatch(css, /https:\/\/soloist\.ai\/_next\/static\/media\/bakery/);

fetchAssetWithRetry() retries once on a 502 or a network error. Anything still missing gets one more sweep after a delay (ASSET_SWEEP_DELAY_MS = 2000). If it's still missing after that, it's listed as skipped in the report.

By hand

Download each /_next/static/css/*.css the pages link.
grep -o 'url([^)]*)' and @import in each file. Download those too, and repeat for any CSS they pull in.
Keep the _next/static/... folder structure under one assets/ folder. Most relative url(../media/x.woff2) references then resolve without edits. Rewrite any absolute https://soloist.ai/_next/... references.
Point the <link href> in each page at the local copy, relative to that page.

3. Scripts and page links

stripSoloNextScripts() removes <script src> tags and <link rel="preload" as="script"> tags pointing at soloist.ai. It leaves __NEXT_DATA__ alone, because that tag has no src. Once scripts are removed, the report says: "Interactive parts that relied on Solo's scripts may not work."

Links in the fixture use both /<handle>/about and /about. rootAbsoluteToRelative() maps both onto files in the flattened ZIP. These are the cases from tests/assets.test.ts:

rootAbsoluteToRelative("/example-bakery/about", "index.html", files)          // "about/index.html"
rootAbsoluteToRelative("/about", "index.html", files)                         // "about/index.html"
rootAbsoluteToRelative("/example-bakery/#menu-1", "index.html", files)        // "#menu-1"
rootAbsoluteToRelative("/example-bakery/#menu-1", "about/index.html", files)  // "../index.html#menu-1"
rootAbsoluteToRelative("/favicon/favicon.ico", "index.html", files)           // unchanged

The first path segment only counts as a handle if it isn't a known asset root (favicon, img, images, assets, static, _next, css, js, fonts), doesn't contain a dot, and doesn't match a file or folder in the ZIP.

By hand: delete the Solo <script> tags and script preloads. Then, for every root-absolute href, drop the handle segment and rewrite the rest to a relative path.

4. Forms

Our tool doesn't convert Solo forms. Our static-host guide says it plainly: "The tool strips Solo scripts, and a static host cannot send the form."

The code does handle the submissions data. lib/process-zip.ts treats every .csv (and manifest.csv / report.txt) as private and splits it into a second ZIP:

function isPrivateDataPath(path: string): boolean {
  if (path === "_rescue-data" || path.startsWith("_rescue-data/")) return true;
  const base = path.split("/").pop() ?? path;
  if (PRIVATE_DATA_BASENAMES.has(base)) return true;
  if (base.endsWith(".csv")) return true;
  return base.endsWith("_submissions.csv");
}

countFormSubmissions() in lib/solo/gaps.ts counts non-empty data rows in contact_form_submissions.csv and newsletter_submissions.csv. Its quote-aware CSV splitter keeps a multi-line message as one row.

By hand:

Move every CSV out of the folder you deploy. Those files hold your visitors' names and emails.
Replace the form markup with a mailto: link, or point it at a form backend you control. Static files can't receive a POST.

Output

From the README, the Example Bakery fixture with styles produces:

website-ready-to-host.zip
  index.html
  images/<hash>.jpg
  assets/_next/static/css/x.css
  assets/_next/static/media/...

private-form-data-do-not-upload.zip
  image_links.csv
  contact_form_submissions.csv
  newsletter_submissions.csv
  manifest.csv
  report.txt

Host only the first ZIP. If you'd rather not do this by hand, the free tool runs in the browser: https://site-export-rescue.pages.dev/?utm_source=devto&utm_medium=article&utm_campaign=solo-export-fixes

Written with AI assistance from our own source code and test exports, and checked against them.

Don't DROP COLUMN while old app code still reads it

labyrinthlab — Sun, 01 Nov 2026 14:33:20 +0000

Here is the failure.

You clean up a schema:

ALTER TABLE users DROP COLUMN legacy_status;

The migration applies. New code is fine. Mid-deploy, an old app instance (or a Sidekiq worker that hasn't restarted yet) still runs a query that selects legacy_status. Rails may also have a cached schema that still lists the column. Requests start failing with "column does not exist" until every process has the new code and a fresh schema cache.

This is not a theoretical edge case. GitLab's "Avoiding downtime in migrations" guide opens the "Dropping columns" section with the same point: running processes expect those columns to exist, ActiveRecord caches the table schema at boot, and you need a multi-release sequence: ignore the column in code first, drop it in a later release, then remove the ignore rule after that.

Postgres itself makes the DDL look cheap. Per the ALTER TABLE docs, DROP COLUMN does not rewrite the table immediately; it marks the column invisible. The lock is still real, and the application failure mode is worse than the lock: code that still references the column breaks even when the statement finishes quickly.

The pattern that works

Change the schema in steps. Do not combine them into one locking "cleanup" migration.

Ignore it (release M): remove every code reference, including model validations, and deploy code that ignores the column. GitLab's ignore_column is one form of this.
Wait: make sure every instance, worker, and job is running that code. No process still reads or validates the column.
Drop it (release M+1): only then run the drop. Remove the ignore rule in the release after that.

ALTER TABLE users DROP COLUMN legacy_status;

Same idea when you are adding shape instead of removing it: add the new column nullable, backfill in batches, then tighten constraints. Do not add NOT NULL and drop the old column in the same deploy as the code change that needs them.

When destructive SQL does show up in a migration file, read it twice: first work out exactly what gets dropped, then confirm the target names and that no app path still references them before you apply.

What reviewers should ask

Does any still-running binary select, update, or validate this column?
Are there views, triggers, or reporting queries that still name it?
Is this drop in the same release as the code that stopped using it? If yes, split the release.

If an AI agent writes your migrations, give it the same checks as a standing rule before it ever suggests applying a DROP COLUMN: confirm the column name, verify no app references, and split the change across releases instead of one combined cleanup.

A free Cursor hook that steers the agent's shell commands away from running prisma migrate reset and drizzle-kit push --force against a non-local database is here: https://site-export-rescue.pages.dev/cursor-prisma-drizzle-guard/?utm_source=devto&utm_medium=article&utm_campaign=dont-drop-column-while-old-code-still-reads-it. It doesn't touch your SQL files or block the CLI for humans; pair it with rules that make the agent flag DROP COLUMN before the migration lands.

Drafted with AI assistance from GitLab's avoiding-downtime migration guide, the PostgreSQL ALTER TABLE documentation, and our own migration review rules, and checked against them.

CREATE INDEX on a live Postgres table locks writes. CONCURRENTLY fixes that, if you keep it out of a transaction

labyrinthlab — Sat, 31 Oct 2026 13:34:40 +0000

Here is the failure.

You ship a migration that adds an index on a busy table:

CREATE INDEX idx_orders_customer_id ON orders (customer_id);

Postgres builds the index with a SHARE lock. Other sessions can still SELECT. They cannot INSERT, UPDATE, or DELETE until the build finishes. On a large table that can be minutes or hours of blocked writes. The PostgreSQL CREATE INDEX docs say so outright: a standard index build "locks out writes (but not reads) on the table until it's done."

The fix is also in those docs:

CREATE INDEX CONCURRENTLY idx_orders_customer_id ON orders (customer_id);

CONCURRENTLY builds without taking locks that block concurrent inserts, updates, or deletes. It does more work (two table scans, waiting on open transactions), and it has one hard rule that trips most migration tools:

a regular CREATE INDEX command can be performed within a transaction block, but CREATE INDEX CONCURRENTLY cannot.

If your migrator wraps the file in a transaction, you get:

ERROR: CREATE INDEX CONCURRENTLY cannot run inside a transaction block

That exact error shows up when people put CONCURRENTLY into a Flyway (or similar) migration that always runs inside a transaction. See How do I create indexes concurrently with flyway in postgres?: 25k+ views, same Postgres error message.

What to do instead

Put the concurrent index in its own migration with nothing else in it.
Tell the tool not to wrap that migration in a transaction (Flyway detects CREATE INDEX CONCURRENTLY and can run it non-transactionally; Rails has disable_ddl_transaction!; other tools have equivalent flags).
Set a short lock_timeout first so a blocked lock fails fast instead of waiting forever:

SET lock_timeout = '5s';
CREATE INDEX CONCURRENTLY idx_orders_customer_id ON orders (customer_id);

After it finishes, check the index is valid. A failed concurrent build can leave an INVALID index that still costs write overhead:

SELECT c.relname, i.indisvalid
FROM pg_index i
JOIN pg_class c ON c.oid = i.indexrelid
WHERE c.relname = 'idx_orders_customer_id';

If indisvalid is false, drop it and retry CREATE INDEX CONCURRENTLY.

Why agents make this worse

An agent writing a "quick" migration often emits plain CREATE INDEX because that form works inside a transaction and looks like every other DDL statement. Or it puts CREATE INDEX CONCURRENTLY next to an ALTER TABLE in the same file, which many tools still wrap as one transaction. So Postgres rejects the concurrent build and the agent "fixes" it by dropping CONCURRENTLY.

If you use Cursor (or another agent) on migration SQL, give it a standing rule: Postgres indexes on live tables use CREATE INDEX CONCURRENTLY alone in their own migration, with lock_timeout set first. That is exactly what the lock-safe section of Schema Migration Guard tells the agent before it writes the file.

A free, copy-paste Cursor hook that blocks remote prisma migrate reset and drizzle-kit push --force (a small subset of the same pack) is here: https://site-export-rescue.pages.dev/cursor-prisma-drizzle-guard/?utm_source=devto&utm_medium=article&utm_campaign=postgres-create-index-concurrently-outside-transaction. It does not rewrite your SQL for you; the rules side is what steers the index pattern.

Drafted with AI assistance from the PostgreSQL CREATE INDEX documentation, Stack Overflow question 20350501, and Schema Migration Guard's lock-safe-migrations rule, and checked against them.

verizon connect work to jobber or housecall pro: opening your attachment zips and importing your jobs

labyrinthlab — Wed, 28 Oct 2026 13:40:12 +0000

this is the follow up to leaving verizon connect work? how to move your clients and job history into your next tool. that one covers the export basics. this one starts after the zips land: what's in them, and how much jobber or housecall pro can actually take.

the dates to plan around

from verizon's final transition deadlines & data export cutoffs article (updated 22 oct 2026):

31 dec 2026: end of active service.
4 jan 2027: platform ui restriction. admin logins go straight to the data migration tool and the mobile app stops.
28 feb 2027: last day to start a new export. verizon says large exports "can take over a week to process".
31 mar 2027: last day to download finished zip files. after that verizon says job logs, signatures and media attachments are "irretrievably purged".

verizon's final billing cycles page says that after 31 dec 2026 "the user interface will be locked". so plan for 31 dec, and treat the later dates as a safety net for exports only.

what's in the attachment zips

honest caveat: i don't have a real work export, and verizon doesn't publish a sample, so no file names here. this is what verizon's migration tool guide (updated 21 oct 2026) says:

date range exports come as zip files grouped by month.
"jobs with attachments" gives you job and task data plus attached files like photos and documents. "attachments will be in individual folders numbered for each associated job."
you also need the plain jobs export in csv. verizon calls it "your master key": "column a in your csv contains the unique 'job id,' which corresponds exactly to the numbered folders in your downloaded zip file."
the faq on the same page says attachment file names "correlate directly" with those job ids.

so the workflow is: unzip a month, open that month's jobs csv, and use column a to go from a numbered folder to a client, address and date. if your files look different, trust your files.

same goes for column names. verizon's guide only names column a, so any work column names you see below or in a mapping are a starting point, not gospel. take the real ones from your own export. the map in the guide marks them "check your export" for exactly that reason.

opening them without making a mess

unzip each month into its own folder named for the month, like 2024-03. keep the original zips untouched somewhere else.
don't double click the csv. use your spreadsheet's import option and set id, phone and zip columns to text, so job ids and leading zeros survive.
spot check: pick a job you remember, read its column a, open that folder. if the photos match, the month is good.

if you want to keep a readable copy of the old jobs before you import, there's a free viewer that opens the zip, csv and json files from a work export as a browsable archive. the files stay in your browser, nothing gets uploaded.

what jobber can import

i read these on 23 oct 2026.

clients (import clients, updated 6 aug 2026): csv, tsv or psv. admin only, and it won't run in an incognito or private window. each file must be under 2.5mb, (about 5000 rows), so split bigger lists. it takes names, company, phones, email, addresses, notes and tags. if the street column is empty, no property gets created. only text client custom fields import, not dropdowns, and only jobber's built in lead sources.

jobs (import jobs, updated 10 sep 2026): this is a beta feature, admin only. up to 1000 jobs per import. past jobs come in as complete and archived, but only if the start date is within ten years. columns include job title, instructions, client name, notes, property address, start date and times, assigned to and total price. client name and the full property address, including country, are mandatory, and jobber warns not every export includes one. no job level custom fields. jobs attach to existing clients only on an exact name or address match, otherwise you get a new client, so import clients first and keep names identical. you get 10 minutes to revert an import.

attachments: neither import doc mentions photos or files. jobber's notes and attachments page allows 500 mb per file on notes, but that's manual upload, not an import.

what housecall pro can import

from prepare to import your data (updated 23 jan 2026):

customers: customer id, names, company, addresses, phones, emails, notes, tags and lead source. zip codes "must be a real usa zip code", phone numbers must be 10 or 11 digits, and "custom fields cannot be created". anything without a matching field goes into notes or tags first.

jobs: the jobs import takes the customer fields plus job id, invoice number, notes, subtotal, tax, payment details, scheduled, start and completion dates and job type. each row has to be one job. if your export spreads a job over several rows (say, one per line item), you have to merge them or only the first row goes in.

on the max plan, housecall pro's data import team can bring over customers, job history, equipment and price book for you.

attachments: again, no photo or file field in the import. their attachments page covers uploading files to jobs by hand, and the mobile photo page caps pdfs uploaded from a phone at 5mb. i couldn't find a documented size limit for web uploads or for the import file itself.

so what actually moves

clients: yes, both, after some column cleanup.
job records: yes, both, as csv. jobber's is beta and capped at 1000 per file.
photos, signatures, pdfs: no bulk import in either tool's docs. keep them in your archive, or re upload the few you need onto the right jobs by hand.

import clients, then a small test batch of jobs, check them, then do the rest. and keep the work zips forever.

written with ai assistance and checked against verizon's, jobber's and housecall pro's published help docs on 23 oct 2026.

the PocketOS incident: 4 guards between a coding agent and your prod database

labyrinthlab — Tue, 27 Oct 2026 13:47:12 +0000

in late april 2026, PocketOS founder Jeremy Crane posted that a Cursor agent running Claude Opus 4.6 deleted their production database on Railway. the Hacker News thread pointed at his write-up. Railway then published their own account.

this post is not a blame piece. it asks a practical question: what concrete guards stop a coding agent from wiping a prod database?

what the sources say happened

Crane wrote that the agent hit a credential mismatch while working in staging, then called Railway's GraphQL API and deleted a production volume. he said the call took nine seconds and took volume-level backups with it. Decrypt quotes him saying Cursor running Claude Opus 4.6 "deleted our production database and all volume-level backups in a single API call to Railway," and that "it took 9 seconds."

(Decrypt, quoting Crane's X post)

Railway's engineering post confirms the shape of the call. the agent found a Railway API token on disk and posted a volumeDelete mutation to backboard.railway.app/graphql/v2. Railway says the request was authenticated, so the API honored it the same way it would for a CLI or CI job. they also say the token was account-scoped, the broadest option they offer.

(Railway blog)

on recovery: Railway says they restored the database and the customer came back up with all their data. Crane, quoted by Decrypt, said the most recent recoverable backup he could find at the time was three months old, and that significant data gaps remained. Jake Cooper of Railway told Decrypt they recovered the data about thirty minutes after he connected with Crane, and that a legacy API path had lacked the delayed-delete logic the dashboard already used. Railway later said they patched that endpoint so volume deletes soft-delete for 48 hours, matching the dashboard.

the wipe path in the sources is a Railway GraphQL volumeDelete via curl. it is not a Prisma or Drizzle migration command. keep that in mind when you read guard 4.

guard 1: the agent never holds prod credentials

the cheapest control is absence. if the agent cannot see a production token or a production DATABASE_URL, it cannot use them.

Railway's own post walks through token scopes: account, workspace, project (optionally down to an environment), and OAuth with explicit grants. the token in this incident was account-scoped. narrower tokens already existed; the path of least resistance produced a wider one than the work needed.

(Railway blog)

practical version for day to day work:

keep prod URLs and cloud tokens out of the .env your editor loads
give the agent a project or environment scoped token that cannot delete prod volumes
give your local DB role no DROP rights on shared databases

rules steer an agent. missing credentials cannot be talked around.

guard 2: backups you have restored, including offsite

Railway's volume backup docs are blunt: "Wiping a volume deletes all backups." volume snapshots help after a bad migration. they do not survive deleting the volume itself.

(Railway volume backups)

their Postgres backup guide recommends three layers for production: volume backups, point-in-time recovery (WAL archiving), and logical dumps with pg_dump that live somewhere else. the guide's restore drill is the point. a backup you have never restored is unverified. Postgres's own docs describe continuous archiving and point-in-time recovery the same way: base backup plus an unbroken WAL archive, then a restore to a chosen time.

(Railway Postgres backups, Postgres PITR)

if your only copy sits next to the data, a volume delete is still a bad day. schedule an offsite dump, restore it into a scratch database, and write down how long it took.

guard 3: human approval for destructive commands

Cursor hooks can gate shell commands before they run. a beforeShellExecution hook receives the command string and can return allow, deny, or ask. exit code 2 is also deny. for security-critical hooks, set failClosed: true so a crash or timeout blocks instead of failing open.

(Cursor hooks)

use that for the verbs you care about: volume deletes, rm -rf against known data dirs, forced schema resets, cloud CLIs that destroy databases. ask puts a person in the loop. deny forces the agent to stop and explain. one catch from our own testing: with auto-review on, an ask result could just run the command, so check that in your setup or use deny for the worst verbs. do not rely on a prompt rule alone. prompts are suggestions. hooks are process checks.

guard 4: a hook that steers dangerous migration commands

a different failure mode shows up in everyday agent coding: prisma migrate reset or drizzle-kit push --force against a remote DATABASE_URL that still sits in .env from last week's debug session. Prisma's own agent consent checks help for some of those commands. they do not cover every tool, and they still depend on you reading which database the URL points at.

Cursor's beforeShellExecution hook is the place to steer those commands. one free option is the Cursor Prisma / Drizzle Guard page: a small project hook that denies prisma migrate reset and drizzle-kit push --force when the target URL is not local (localhost, 127.0.0.1, file, or sqlite). it matches the agent shell path. it does not block commands you run yourself in your own terminal.

that hook would not have matched the PocketOS call path in the sources above. the call was Railway GraphQL, not Prisma or Drizzle. put it in place for the wipe modes agents hit during schema work, and pair it with guards 1 through 3 for cloud tokens and recovery.

put them together

no prod credentials in the agent environment
backups and PITR you have actually restored, with an offsite dump
approval (or deny) hooks on destructive shell commands
a migration hook that steers remote resets and forced pushes

none of these need a new platform feature. they are ordinary engineering controls that still apply when the operator is a coding agent.

Written with AI assistance from the sources linked above, and checked against them.

tu sitio de weebly quedó fuera de línea: cómo convertir el zip del archivo en un sitio estático gratis

labyrinthlab — Mon, 26 Oct 2026 13:46:17 +0000

la respuesta corta: sí. si tenías un sitio de weebly en uno de los países afectados y ya no aparece en línea, todavía puedes descargar el archivo zip del sitio desde el editor y convertirlo en un sitio estático que funciona en un hosting gratuito. no necesitas que el sitio siga publicado, porque todo sale de los archivos del zip. lo que sí necesitas es entrar a tu cuenta antes del 26 de diciembre de 2026.

un poco de contexto, porque se está repitiendo mucho algo que no es cierto. el cambio afecta a weebly solo en 67 países, no en todo el mundo. en esos países los sitios fueron despublicados el 27 de septiembre de 2026, y el acceso a la cuenta (y con él la exportación) termina el 26 de diciembre de 2026. en la lista hay varios países de habla hispana: colombia, chile, costa rica, ecuador, perú, uruguay y paraguay, entre otros. la lista completa está en el aviso de weebly.

cómo descargar el archivo

en el editor del sitio entra a settings > general, baja hasta archive, escribe tu correo y haz clic en email archive. te llega un correo con el enlace de descarga. weebly lo explica en su página back up your site.

no lo confundas con download my data, en la configuración de la cuenta. es otro archivo con otro formato. baja los dos, pero el que se convierte en sitio web es el zip del archivo. ábrelo apenas llegue para confirmar que no está vacío.

qué trae el zip y qué no

abrí un zip real de un sitio de prueba de cuatro páginas, exportado el 8 de octubre de 2026. adentro hay una sola carpeta con un nombre largo (17027946326ac7e6d662b26/), y esa es la raíz del sitio. ahí están index.html, about.html, gallery.html y contact.html, la carpeta uploads/ con las imágenes, files/main_style.css, los scripts del tema en files/theme/files/ y un reproductor de audio flash en apps/.

un detalle: en uploads/ varias imágenes aparecen dos veces, por ejemplo berry-tart.jpg y berry-tart_orig.jpg. son dos tamaños de la misma foto, así que no borres ninguna.

lo que no viene es el blog ni la tienda. según la página de respaldo de weebly, las páginas de blog y de tienda no se incluyen en la exportación porque dependen directamente de su base de datos. la misma página avisa que el formulario de contacto y los slideshows pueden no funcionar fuera del editor, y que el zip no se puede volver a importar en weebly. si tenías blog, copia las entradas desde el editor mientras puedas entrar.

qué falla si lo subes tal cual

en el html del zip que revisé, cada página carga los estilos, las fuentes y los scripts compartidos de weebly desde cdn2.editmysite.com y cdn11.editmysite.com con http://, once veces por página. cualquier hosting estático gratuito sirve tu sitio con https, y los navegadores bloquean esos archivos por contenido mixto. el resultado es una página sin estilos.

además, las páginas piden files/theme/plugins.js y files/theme/custom.js, pero en el zip esos archivos están en files/theme/files/. el menú móvil depende de esos scripts, y en mi prueba solo abrió en el teléfono después de corregir el https y las rutas. y el formulario de contacto envía a ///weebly/apps/formSubmit.php, que solo funcionaba dentro de weebly.

dos maneras de convertirlo

a mano. trabaja sobre una copia de la carpeta. el arreglo de https es un reemplazo en todos los html:

# dentro de la carpeta del sitio. en macos usa: sed -i '' ...
sed -i 's#http://cdn#https://cdn#g' *.html

el de los scripts del tema también lo haces tú: mueves los dos archivos una carpeta arriba o corriges las rutas en cada html. el formulario lo reemplazas por un enlace mailto: o por un servicio de formularios, después de exportar las entradas viejas desde el panel.

con una herramienta gratuita. archive to static es una herramienta de navegador que lee el zip del archivo del sitio. tu exportación se queda en tu navegador. convierte los enlaces http:// a https, quita los scripts del editor y la insignia de weebly, y cambia los formularios que ya no funcionan por un aviso con un enlace de correo si le das una dirección. con el tema hace algo distinto a lo que harías a mano: no corrige las rutas de esos scripts, sino que quita los scripts del tema (plugins.js y custom.js) y agrega su propio código para el menú móvil. o sea, el menú abre, pero los scripts originales del tema ya no están. el blog y la tienda tampoco aparecen con la herramienta, porque no están en el zip; los lista en el informe como páginas que faltan.

dónde alojarlo gratis

en cloudflare pages puedes arrastrar la carpeta o el zip. el límite es de 1.000 archivos y 25 MiB por archivo. en netlify drop arrastras la carpeta, pero inicia sesión antes: si lo subes sin cuenta, el sitio queda protegido con una contraseña temporal hasta que lo reclames. sube el contenido de la carpeta de nombre largo, para que index.html quede en la raíz.

si compraste el dominio con weebly, empieza la transferencia antes del 26 de diciembre desde el panel de dominios. no cambies los datos de contacto del dominio antes de transferirlo, porque eso activa un bloqueo de 60 días.

lo honesto: no recuperas el blog, ni la tienda, ni el reproductor flash, y vas a tener un sitio sin editor, así que cambiar un teléfono significa editar html. para un sitio de presentación que casi no tocabas, igual es la forma más rápida de tenerlo de vuelta en línea, gratis y con el mismo aspecto. lo urgente es descargar el zip ahora, aunque lo conviertas el mes que viene.

Escrito con ayuda de IA y verificado contra un archivo real de un sitio de Weebly y la documentación de Weebly, Cloudflare y Netlify.

leaving solo (soloist.ai): wordpress, carrd or a static host? how to pick before 30 nov

labyrinthlab — Sat, 24 Oct 2026 13:31:15 +0000

solo, mozilla's ai site builder, deletes everything on 30 nov 2026. its shutdown faq is blunt about it: "There will be no way to recover your site, account, or data after that date."

the export steps are in my earlier post, so i won't repeat them. this one is the question people ask after they have the zip: ok, where does it go?

solo's faq suggests wix, squarespace, wordpress or ai builders. i'll compare three that fit most small solo sites: wordpress.com, carrd, and a free static host.

first, what you're actually carrying

per solo, the zip has "an HTML export of your website and a CSV file with links to your image assets," plus form and newsletter submissions. the photos aren't in it. they come from the csv links, which die with solo on 30 nov, whichever destination you pick. so grab the images first, decide later. and the submissions are customer emails, they stay on your own machine.

the real difference between the three: does it take your html as is, or do you rebuild?

wordpress.com: rebuild, but you get an editor

there's no solo importer. wordpress.com's import from other platforms guide is a copy-paste job: add your images to the media library, then copy "the main text of a single page" into a new page, since copying the whole page "may make some unwanted HTML." menus get rebuilt separately.

so your text and image files carry over. the solo look doesn't, you pick a theme. forms don't either.

cost, from the pricing page today: the free plan is a yoursite.wordpress.com subdomain with 1 gb of storage, and visitors see ads. connecting a domain you already own is a paid feature, Personal and up (connect a domain). Personal is us$4/month billed yearly, or us$9 month to month. annual plans include a free domain for the first year, monthly ones don't.

fits you if: you'll keep editing, want a blog, or someone non-technical updates it. effort: an afternoon for a few pages, more if you're picky about design.

carrd: rebuild, small and cheap

carrd builds "one-page sites," so it suits solo sites that were really one long page: a landing page, a portfolio, a link-in-bio thing. no html import here either, you rebuild with text elements and upload your images. even carrd's own downloads "cannot be uploaded back to the Carrd platform."

cost is where carrd is nice. the free plan lets you "build up to three sites per account" on a .carrd.co address (carrd.co). your own domain needs Pro Standard, $19/year (plans, custom domain). Pro Lite at $9/year has no custom domain. a contact form also needs Pro Standard (contact form).

fits you if: it's one page and you want an editor without all of wordpress. effort: the quickest rebuild, if it really is one page. five separate pages gets clunky.

a static host: keep the html, lose the editor

the only option that uses your export as is. once the html points at your local images instead of solo's links, you upload the folder and it looks basically the same.

cloudflare pages direct upload takes a folder or a zip by drag and drop, up to 1,000 files and 25 MiB per file. cloudflare says all plans come with "unlimited sites, seats, requests, and bandwidth" (pages). one gotcha: a direct upload project can't be switched to git later.

netlify drop is the same idea. log in first, or the site sits behind a temporary password until you claim it. the free plan is $0 with a 300 credit limit per month, and custom domains are included (pricing). a production deploy costs 15 credits and bandwidth is 20 credits per gb, and if you hit the limit your projects pause until the next cycle. plenty for a small brochure site, but cloudflare is safer if you're worried about a traffic spike.

what doesn't carry: anything that needed solo running, like the contact form (use an email link or a form service). and no editor, so new opening hours means editing html.

fits you if: the site is done and you just want it up, free, looking the same. effort: under an hour once the images are sorted.

i wrote a longer walkthrough with the netlify and cloudflare steps and a what-carries-over table here, and it links the wordpress and carrd versions too. it's built around the zip from our free tool, so heads up, that tool fetches your images through our server.

the domain move

if you bought the domain through solo domains (not ionos), it moves to name.com first: fill in your name.com contacts, then email solo your account code (steps in the faq linked up top). ionos or anywhere else, just log in there.

then each option wants something different:

wordpress.com: a paid plan, then their connect-a-domain flow.
carrd: Pro Standard, then the A record for @ and CNAME for www it shows you. can take up to an hour.
cloudflare pages: a bare domain like example.com must be a zone in your cloudflare account (nameservers pointed at cloudflare). a subdomain just needs a CNAME, but add it in pages first or you get a 522 (custom domains).
netlify: add it in netlify first, then a CNAME for subdomains and an ALIAS, ANAME or A record for the bare domain (external dns).

and leave the mx records alone if you get email on that domain.

so which

one page, want an editor: carrd. many pages, want to keep editing or blogging: wordpress, and treat it as a rebuild. it's finished and you just want it alive: static host, free.

none of it matters if the images are gone though. get them out of the csv links this week. the destination can wait, the export can't.

Written with AI assistance and checked against Solo's shutdown FAQ and the WordPress.com, Carrd, Cloudflare Pages and Netlify pricing and docs, all read on 23 Oct 2026.

moving off weebly: wordpress or a free static host? what the archive zip actually allows

labyrinthlab — Fri, 23 Oct 2026 13:34:53 +0000

quick context. weebly is winding down in 67 countries, not everywhere. sites there were unpublished on 27 sep 2026, and login (and with it the export) ends on 26 dec 2026. the us, uk and eu aren't on the list. details are on weebly's notice.

i already wrote up the hand-fix route for a static host. the question i keep getting after that one: should the archive go into wordpress instead? so i opened a real archive and checked what each route can do with it.

what's actually in the zip

this is a real site archive from a small 4-page test site, exported on 8 oct 2026. one top-level folder with a long id for a name (17027946326ac7e6d662b26/), and inside it:

index.html, about.html, gallery.html, contact.html
uploads/1/5/6/4/156416411/ with about 20 images, most in two sizes (berry-tart.jpg and berry-tart_orig.jpg)
files/main_style.css, plus files/theme/files/ with custom.js, plugins.js, manifest.json and a few theme images
apps/audioPlayer2.swf, a flash audio player

that's it. no favicon, no xml, no csv, no database dump. no blog or store either, and that's by design: weebly's back up your site page says blog and store pages aren't included because they rely on its database, that the contact form and slideshow may not work outside the editor, and that the zip can't be imported back into weebly.

two more things from the html itself. each page loads weebly's shared css, fonts and scripts from cdn2.editmysite.com and cdn11.editmysite.com, with 11 http://cdn references per page. and the contact form posts to ///weebly/apps/formSubmit.php, which only ever worked on weebly.

that list decides most of what follows.

the wordpress route

there's no weebly importer. the wordpress.org importing content page covers blogger, tumblr, movable type, rss, another wordpress site (via a WXR file) and plugins for a bunch of other systems. weebly isn't on it, and the archive has nothing those importers read. it's plain html files.

so moving this zip to wordpress means rebuilding. wordpress.com's own html site guide says to copy only the main text of each page, since pasting the whole page brings unwanted html along, and to add your images separately.

what comes over: the text (by copy-paste), the images (upload them from uploads/ to the media library) and your page structure. what doesn't: the look, since main_style.css is a weebly theme and not a wordpress one, the form, the flash player, and of course the blog and store that were never in the zip.

what you get back is an editor, a real blog going forward, form plugins, and woocommerce if you want to rebuild the store. if you post or edit often, that matters more than keeping the old design.

cost: the wordpress.com free plan is a wordpress.com subdomain with ads and 1 gb of storage, and connecting a domain you already own needs a paid plan (pricing, connect a domain). self-hosted wordpress is free software, but you pay for hosting and you keep it updated.

the static host route

here you upload the html you already have, so the site keeps its look. on cloudflare pages direct upload you drag in a folder or a zip. drag and drop allows 1,000 files and 25 MiB per file, and a direct upload project can't be switched to git later. on netlify drop you drag in the folder, but log in first: a drop without signing in sits behind a temporary password until you claim it. both have free plans, and my test archive (46 entries, about 4 mb) is nowhere near the limits.

"as-is" isn't quite as-is, though. on https those http://cdn links get blocked as mixed content. and the pages ask for files/theme/plugins.js and files/theme/custom.js while the files sit one folder deeper, in files/theme/files/. so on a phone the menu won't open until you deal with it. the earlier post has the find-and-replace for both.

i also ran this archive through the free browser tool i made for this. on this zip it upgraded the links to https, saved the editmysite css and fonts into assets/vendor/, stripped the theme's scripts and added its own small mobile menu (assets/ats/nav.js), left out the .swf, and swapped the contact form for a note saying it can't send. it does not fix the theme script paths. it removes those scripts instead, so if your theme leaned on them for more than the menu, check that by hand. i wrote up what to do with that output for each route, including the wordpress copy-paste steps, here.

the catch with static: there's no editor. changing a phone number means editing html, and there's no blog going forward unless you add a static site generator.

gotchas for both

blog and store. neither route recovers them, because they aren't in the zip. copy posts out of the editor while you can still log in, and export the store separately.

forms. dead either way. on wordpress add a form plugin, on a static host use a form service or a mailto: link. export your old form entries first.

domains. if you bought it through weebly, start the transfer from the weebly dashboard before 26 dec. the notice also says a domain can't be transferred within 60 days of registration. if it lives at another registrar, add it in the new host first, then change dns (cloudflare pages custom domains, netlify external dns). on wordpress.com that's the paid-plan step above.

flash. audioPlayer2.swf won't play on either. modern browsers dropped flash.

so which one

if it was a brochure site you rarely touched, a static host gets it back online today, free, looking the same. if you blog, sell, or someone non-technical edits it every week, go wordpress and treat it as a rebuild, with the zip as your source of text and images.

either way, download the archive before 26 dec. neither route works without it.

Written with AI assistance and checked against a real Weebly site archive and the Weebly, WordPress, Cloudflare and Netlify docs.

your cursor hook says ask. in auto-review, the command may just run

labyrinthlab — Sat, 17 Oct 2026 16:16:58 +0000

say you wrote a cursor hook to catch the scary database commands, like prisma migrate reset or drizzle-kit push --force. you made it answer "ask", because you want a human to look before it runs, not a hard no.

in two of cursor's run modes, that works the way you'd expect. in auto-review mode, it may not. the command can just run with no prompt.

this post covers what was reported, what cursor staff said about it, and what i'd return instead.

what was reported

the report is cursor forum topic 173694, "beforeShellExecution hook returning ask is ignored in Auto-review mode (honoured in Allowlist and Run Everything), 3.21.16", posted 4 oct 2026. the reporter was on cursor 3.21.16 on windows, with a project-level hook that always answers ask:

{"permission":"ask","user_message":"hook asked","agent_message":"hook asked"}

then they asked the agent to run echo test > t.txt in each mode. their summary:

"A project-level beforeShellExecution hook that answers {"permission":"ask"} gets the approval prompt in Allowlist mode and in Run Everything mode ("Hook requested approval: …"). In Auto-review mode the command runs without any prompt. deny is enforced in all three modes."

their table, cleaned up:

auto-run mode	hook answers ask	hook answers deny
allowlist	prompt	not tested
auto-review	no prompt, command ran (two trials)	blocked
run everything	prompt: "Hook requested approval"	not tested

they also noted that the hook payload doesn't say which auto-run mode is active, "so a hook can't detect Auto-review and compensate."

what cursor staff said

a cursor community support engineer replied in the same thread on 5 oct 2026:

"You're right: in Auto-review, when Auto-review itself decides a command is safe to run, the hook's "ask" answer currently isn't applied, so no approval prompt appears. "deny" is still enforced in every mode, as you saw. I've flagged this to the team."

and for the meantime:

"If you need to stay in Auto-review, have the hook return "deny" for the commands that must never run without review. The agent will see the hook's message and can ask you before retrying."

the other option they gave was to use allowlist or run everything, where an ask always shows the prompt.

the important bit is the qualifier: ask gets dropped when auto-review decides the command is safe. so you can't count on ask in that mode. as of 17 oct the thread doesn't say it's been fixed, but i haven't re-tested on a newer build, so check yours.

one more thing: which message reaches the agent

a different thread, cursor forum topic 174902 (reporter on cursor 3.24.18), got a staff reply on 16 oct 2026 that matters if you write deny messages:

"when a hook denies a command, only user_message reaches the agent right now (agent_message is dropped)"

and:

"Put any instructions meant for the agent in user_message"

so when you deny, put the "here's what to do instead" text in user_message. the hook below writes the same text into both fields, so it's fine either way.

so: deny, with a useful message

for commands that should never run without a person, return deny and say what the agent should do next. the cursor hooks docs also say exit code 2 counts as deny, and that crashes, timeouts and other non-zero exits fail open unless you set failClosed: true. so set it.

here's the hook. it's 27 lines of node with no dependencies, because if you're on prisma or drizzle you already have node.

.cursor/hooks/deny-db-wipes.mjs:

// beforeShellExecution hook: deny commands that can wipe a database.
// cursor sends JSON on stdin and reads JSON from stdout.
let raw = "";
process.stdin.on("data", (c) => (raw += c));
process.stdin.on("end", () => {
  let cmd = "";
  try {
    cmd = String(JSON.parse(raw).command || "");
  } catch {
    return reply("deny", "the db-wipe hook could not read the hook payload, so it blocked this command. run it yourself if you meant it.");
  }
  const rules = [
    [/\bprisma\s+migrate\s+reset\b/, "prisma migrate reset drops the database"],
    [/\bprisma\s+db\s+push\b[^;&|]*\s--(force-reset|accept-data-loss)\b/, "prisma db push with --force-reset or --accept-data-loss can drop data"],
    [/\bdrizzle-kit\s+push\b[^;&|]*\s(--force|-f)\b/, "drizzle-kit push --force auto-approves data loss statements"],
  ];
  const hit = rules.find(([re]) => re.test(cmd));
  if (!hit) return reply("allow");
  reply("deny",
    `blocked by the db-wipe hook: ${hit[1]}. do not retry with a different flag or wrapper. ` +
    `tell the user the exact command and which database it targets, and let them run it themselves.`);
});
function reply(permission, msg) {
  const out = { permission };
  if (msg) Object.assign(out, { user_message: msg, agent_message: msg });
  process.stdout.write(JSON.stringify(out) + "\n");
}

.cursor/hooks.json:

{
  "version": 1,
  "hooks": {
    "beforeShellExecution": [
      {
        "command": "node .cursor/hooks/deny-db-wipes.mjs",
        "timeout": 10,
        "failClosed": true,
        "matcher": "prisma|drizzle-kit"
      }
    ]
  }
}

the matcher means cursor only runs the hook when the command text contains prisma or drizzle-kit. per the docs, beforeShellExecution matchers are tested against the full command string. project hooks run from the project root, which is why the path is .cursor/hooks/....

the drizzle message quotes drizzle-kit's own help text for --force: "Auto-approve all data loss statements. Note: Data loss statements may truncate your tables and data" (checked in drizzle-kit 0.31.11).

test it without cursor

you don't need the agent to check the logic. pipe fake payloads in:

t() {
  printf '{"command":%s,"cwd":"","sandbox":false}' "$(node -p 'JSON.stringify(process.argv[1])' "$1")" \
    | node .cursor/hooks/deny-db-wipes.mjs
}
t "npx drizzle-kit push --force"
t "npx drizzle-kit push"

here's what i got on node 20 with a batch of commands:

npx prisma migrate reset                              -> deny
npx prisma migrate reset --force                      -> deny
pnpm exec prisma migrate reset -f                     -> deny
npx prisma migrate dev                                -> allow
npx prisma migrate deploy                             -> allow
npx prisma db push                                    -> allow
npx prisma db push --accept-data-loss                 -> deny
bunx prisma db push --force-reset                     -> deny
npx drizzle-kit push                                  -> allow
npx drizzle-kit push --force                          -> deny
npx drizzle-kit push -f                               -> deny
npx drizzle-kit push --strict --force                 -> deny
npx drizzle-kit generate && npx drizzle-kit migrate   -> allow
cd app && npx drizzle-kit push --force                -> deny
bash -c 'npx prisma migrate reset --force'            -> deny
npm run db:reset                                      -> allow   (miss)
echo prisma migrate reset                             -> deny    (false positive)
npx drizzle-kit push --forceful                       -> allow
not json                                              -> deny    (fails closed)

that's a test of the script, not of cursor. i ran these payloads through node on a linux box. i didn't run them through a live cursor agent in each mode, so check the end-to-end behavior on your own build.

the gaps, honestly

wrappers get past it. npm run db:reset doesn't contain prisma or drizzle-kit, so the matcher never even calls the hook. the same goes for a makefile target or a shell script. either add your script names to the matcher and the rules, or keep destructive scripts out of package.json.
it only sees text. the hook doesn't know which database DATABASE_URL points at. prisma migrate reset on a throwaway local db gets blocked too, and you run it yourself. that's the trade.
regex isn't a shell parser. quoting, variables ($CMD), eval and odd spacing can slip through. it also over-blocks things like echo prisma migrate reset. that's fine for a guard, just know it.
deny is blunter than ask. in allowlist and run everything mode, ask would have given you a nice prompt. with deny you copy the command and run it yourself. the reporter in 173694 asked for the auto-run mode to be added to the payload so a hook could deny only in auto-review. until something like that ships, deny is the answer that holds in every mode.
the model can still argue with a deny. a deny stops that one command. it doesn't stop the agent trying another route, like raw sql through psql. the message tells it not to, but that's an instruction, not enforcement.
behavior can change. this was reported on 3.21.16 and acknowledged on 5 oct. retest after updates.
none of this replaces the real boundary. the agent's shell shouldn't have a production database url in the first place. run prod migrations from ci, give the app a role that doesn't own the tables if you can, and turn on point-in-time restore or scheduled dumps for anything an agent can reach.

checklist

[ ] hooks that guard destructive commands return deny, not ask
[ ] instructions for the agent go in user_message
[ ] failClosed: true on the hook
[ ] matcher and rules cover your own npm scripts and wrappers
[ ] tested with piped json payloads, then once for real in your actual run mode
[ ] no prod DATABASE_URL in the agent's environment
[ ] backups or pitr on every database the agent can reach

Written with AI assistance and checked against Cursor forum topics 173694 and 174902 (including the staff replies), the Cursor hooks documentation, and the drizzle-kit 0.31.11 CLI source. The hook was tested with sample JSON payloads, not inside a live Cursor session.

three site and app shutdowns with deadlines before april. solo, weebly in 67 countries, verizon connect work

labyrinthlab — Sat, 17 Oct 2026 00:28:43 +0000

a few platforms are winding down at the same time this year, and the dates are easy to mix up. here's what each vendor actually says, pulled from their own notices, plus what you should export before the window closes.

updated 23 oct 2026: verizon posted final cutoffs for work in its final transition deadlines & data export cutoffs article (updated 22 oct 2026). the verizon section now has all four dates: on 4 jan 2027 the normal screens and the mobile app stop, 28 feb 2027 is the last day to start a new export, and 31 mar 2027 is the last day to download.

updated 18 oct 2026: added short export steps for each one, plus a fourth shutdown that came up since posting: appdrag, which closes on 1 nov 2026.

one note up front: none of these notices give a time zone. if a date matters to you, treat the day before as your real deadline.

solo (soloist.ai)

solo is mozilla's ai website builder, and it's closing for good. from solo's own shutdown faq:

"All Solo websites and data will be deleted on November 30, 2026."

so 30 nov 2026 is both the export deadline and the deletion date. there's no grace period after it. signups are already closed, and solo says refunds are calculated as of 1 oct 2026.

the export lives under account settings > download website data. you get a zip with an html export, a csv of image links, and your contact form and newsletter submissions. the catch is that the images themselves aren't in the zip, only links to them. those links die with solo, so download the actual image files before 30 nov, not after.

also keep the form submissions off any public host. that's your visitors' names and emails.

solo export steps

log in at soloist.ai. if your site isn't there, you're probably on the wrong email (i don't see my websites).
click the menu at the top right, then account settings > download website data (shutdown faq).
unzip it and open the csv. solo says "Image source files are not included in the ZIP", so download each image from the csv links before 30 nov.
move the form and newsletter submissions out of the site folder before you upload it anywhere.

weebly, but only in 67 countries

this one gets misreported a lot. weebly is not shutting down everywhere. weebly's notice, "changes to weebly global operations", covers 67 countries. if you're outside those, nothing changes for you. check the notice to see if your country is on the list.

if you are affected, here's the timeline:

new page publishing stopped on 29 jun 2026.
sites were unpublished on 27 sep 2026, so they're already offline.
login and export access ends on 26 dec 2026.

that last date is the one that matters now. your site isn't public anymore, but you can still log in and get your content out until 26 dec. after that, the account is gone. if you've been putting it off because the site "already disappeared", it hasn't fully disappeared yet, so go export it.

weebly export steps

there are two exports, and you want both.

site archive: in the site editor go to settings > general, scroll to archive, type your email and click email archive. the download link arrives by email (back up your site).
account data: account settings > my data > download my data. it's a separate file.
open both right away. blog and store pages aren't in the site archive, so copy blog posts out of the editor while you can still log in.
if you bought your domain through weebly, transfer it out before 26 dec. the steps are on weebly's notice.

verizon connect work

not a website builder, but plenty of small field service businesses run on it, so it belongs on the list. verizon's final transition deadlines & data export cutoffs article now lays out four dates:

31 dec 2026, end of active service. no more scheduling jobs, adding clients or managing active workflows, and verizon says "All end-of-year billing, invoicing, and job closures must be finalized by this date." the comprehensive faq still says: "We recommend completing all exports by December 31, 2026." that's also when they want daily operations moved somewhere else.
4 jan 2027: "Standard access to the Work platform ceases." admin logins get sent to the data migration tool, and "The Work Mobile App will also cease to function".
28 feb 2027: "The absolute final day to initiate a new data export job."
31 mar 2027: "The final day to download previously completed ZIP files." after that, verizon says the data "will be irretrievably purged".

the stretch after 4 jan is a safety net, not a plan. treat 31 dec as the deadline, 28 feb as your last chance to start an export, and 31 mar as the point of no return.

verizon connect work export steps

log in as a full account administrator. only admins get the migration tool button in the top nav (verizon's guide). if nothing opens, allow pop-ups.
export clients, then the date-range exports (jobs, invoices, quotes and the rest). pick csv if unsure, and save the view schema and er diagram too.
run jobs with attachments in monthly or quarterly chunks. don't cancel or re-request a slow one, that resets your place in the queue.
download every monthly zip from the job history page. each one is only available for three weeks.
bring the files to your next tool yourself. verizon says: "To protect your privacy, we cannot move data directly to a third party."

appdrag (added 18 oct 2026)

appdrag is a website, backend and newsletter builder. from its own sunset notice:

"we have decided to cease accepting new customers and projects with immediate effect, and to permanently shut down AppDrag on November 1st, 2026."

annual renewals are already withdrawn. the notice says you need to migrate any websites, domains or newsletters you want to keep, links its own guides for downloading your project and transferring your domain, and says support stays available until the shutdown date. that's the tightest deadline on this list, so start with this one if it's yours.

what to do this week, whichever one you're on

log in now and confirm you're on the right account. finding out your site was made under an old email is better in october than on deadline day.
run the export and open it. a zip you never unzipped isn't a backup.
check for things that live outside the export, like solo's image links.
keep customer data private and stored somewhere you control.
put the deadline in your calendar a few days early.

i keep the dates and their sources in a free tracker here: https://site-export-rescue.pages.dev/shutdown-tracker/?utm_source=devto&utm_medium=article&utm_campaign=three-site-and-app-shutdowns-with-deadlines-before-april-solo-weebly-in-67-countries-verizon-4c2j (the data behind it is a cc0 data.json, so reuse it if it helps).

Written with AI assistance and checked against Solo's Shutdown FAQ (support.soloist.ai), Weebly's "Changes to Weebly global operations" notice (updated 2026-08-13), Verizon Connect Work's Comprehensive FAQ (updated 2026-10-19) and "Final Transition Deadlines & Data Export Cutoffs" (updated 2026-10-22), plus, for the export steps and update, Solo's "I don't see my websites" page, Weebly's "Back up your site" page, Verizon's Data Export Migration Tool guide, and AppDrag's "Sunset of AppDrag" notice (checked 2026-10-17; verizon dates rechecked 2026-10-23).

solo (soloist.ai) is shutting down on 30 nov. how to get your site out, images included

labyrinthlab — Fri, 16 Oct 2026 13:40:49 +0000

if you built a site with solo, mozilla's ai website builder at soloist.ai, it's closing. the date is in solo's own shutdown faq:

"All Solo websites and data will be deleted on November 30, 2026. There will be no way to recover your site, account, or data after that date."

so that's the window. the export is quick, but it leaves out one big thing, and that's most of this post.

1. log in (the soloist ai login bit)

go to soloist.ai and click sign in. solo lets you log in with your email or your google account (solo's interface guide). you land in the designer, the editor with the toolbar across the top.

if you log in and your site isn't there, you're probably on the wrong email. solo's i don't see my websites page says to check your inbox for mail from @soloist.ai to see which address the site was made with. it also says script blockers like noscript stop solo from loading, so allow soloist.ai if you use one.

2. download your website data

the steps from the faq:

log in to solo.
click the menu at the top right and select account settings.
in the account settings popup, click download website data.

you get a zip. per solo it has "an HTML export of your website and a CSV file with links to your image assets, as well as your contact form and newsletter submissions."

unzip it right away and look inside. keep the original zip somewhere safe and work on a copy.

3. the images aren't in the zip

this is the part people miss. solo says it directly:

"Image source files are not included in the ZIP. Download each image individually from the links in the CSV file before the shutdown date on November 30, 2026."

so the csv is a list of links, not your photos. once solo deletes everything, those links stop working, and your html points at nothing.

if you have five images, just open each link and save it. if you have fifty, script it. here's a small python example, standard library only. it's an example to adapt, not a finished tool. i haven't seen every solo export, so check your csv and html before you run it.

if you'd rather not script it, i put a free browser tool for this here: site-export-rescue.pages.dev. heads up, it fetches the images through our server.

# EXAMPLE ONLY. adapt it to your export, and run it on a COPY of the unzipped folder.
# usage: python3 grab_images.py path/to/the-image-links.csv
import csv, hashlib, re, sys, urllib.request
from pathlib import Path
from urllib.parse import urlparse

csv_path = Path(sys.argv[1])
out = Path("images")
out.mkdir(exist_ok=True)

# pull every http(s) link out of the csv, whatever the column is called
urls = set()
with csv_path.open(newline="", encoding="utf-8") as f:
    for row in csv.reader(f):
        for cell in row:
            urls.update(re.findall(r"https?://[^\s\"',]+", cell))

mapping = {}
for url in sorted(urls):
    base = Path(urlparse(url).path).name or "image"
    base = re.sub(r"[^A-Za-z0-9._-]", "_", base)
    # short hash prefix so two files both called photo.jpg don't overwrite each other
    name = hashlib.sha1(url.encode()).hexdigest()[:8] + "_" + base
    dest = out / name
    if not dest.exists():
        try:
            with urllib.request.urlopen(url, timeout=30) as r:
                dest.write_bytes(r.read())
        except Exception as e:
            print("FAILED", url, e)
            continue
    mapping[url] = "images/" + name

# point the html at the local copies
for page in Path(".").rglob("*.html"):
    text = page.read_text(encoding="utf-8")
    for url, local in mapping.items():
        text = text.replace(url, local)
    page.write_text(text, encoding="utf-8")

print(len(mapping), "of", len(urls), "images saved")

a few things to watch:

the images/... paths are relative. that's fine if your html files sit next to the images folder. if some pages are in subfolders, they need ../images/ instead.
the html might reference an image slightly differently from the csv, like with size settings on the end, or & instead of &. after running it, search your html for leftover remote image links and fix those by hand.
anything that prints FAILED, open the link in your browser and save it manually.
some image files come back without an extension. if one won't display, check what it actually is and rename it.

prefer the shell? pull the links into a plain text file, one per line, and wget -i links.txt -P images downloads them all. you still have to rewrite the html references yourself though, which is the fiddly half.

then double-click index.html and click around. every image should load with your wifi off.

4. keep form submissions private

the same zip has your contact form and newsletter submissions. that's your customers' names, emails and messages. don't put them on a public host. anything you upload to a static host can be downloaded by anyone who finds the path.

before you upload anything, move the submission files out of the site folder and keep them on your own computer plus one private backup. solo's help also has a separate export contacts option in the designer settings if you want a second copy as csv.

also, the contact form itself stops working when solo closes. a static host can't receive form posts, so swap it for a mailto: link or a form service.

5. host it for free

the folder with index.html at the top is your site. upload the contents of that folder, not the folder that contains it.

netlify drop. go to app.netlify.com/drop and drag the folder in. Log in to Netlify first. Drop works without an account, but if you drop without signing in, the site is protected with a temporary password until you claim it. more in netlify's drop quickstart. they also say deploys under 50mb work best.

cloudflare pages direct upload. in the cloudflare dashboard go to workers & pages, then create application > get started > drag and drop your files. name the project, drop the folder or a zip, deploy. drag and drop allows 1,000 files and 25 mib per file. details in cloudflare's direct upload docs.

either way you get a free subdomain, and you can add your own domain after.

6. move your custom domain

if you bought your domain through solo domains (not ionos), solo is moving those to name.com. the faq steps, roughly:

create a name.com account or log in.
fill in the registrant, administrative and technical contacts on name.com's account contacts page. the transfer can't go through until these are done.
copy the account code from the top right of the name.com dashboard.
email it to support@soloist.ai. solo transfers the domain and emails you when it's done.
add billing info at name.com so it renews.

if the domain is from ionos or another registrar, those steps aren't for you. log in wherever you bought it.

once you control the dns, add the domain in your host's custom domain settings (netlify, cloudflare pages) and copy the records they show you into your dns. leave email (mx) records alone if you use email on that domain. dns changes can take a while to show up.

the other option: data liberation agent

automattic, the company behind wordpress.com, has an open source command-line tool called data liberation agent. you point it at a url and it captures the live site into plain html, css, media and fonts, with references rewritten so it works locally. its readme lists soloist as a supported platform.

the catch is in that word live. it reads your published site, so it has to run before 30 nov, and it won't get your form submissions. it's a node project that also needs playwright's chromium installed, so it's best if you're fine in a terminal. if you are, it's worth running alongside the zip export, not instead of it.

that's it

download the zip today. get the images out while the links still work. keep the form data off the internet. the hosting and domain stuff can happen any time, but the export can't happen after 30 nov.

Written with AI assistance and checked against Solo's shutdown FAQ and help pages, the Netlify and Cloudflare docs, and Automattic's Data Liberation Agent README.

leaving verizon connect work? how to move your clients and job history into your next tool

labyrinthlab — Sat, 10 Oct 2026 23:38:53 +0000

if you run a field service business on verizon connect work (it used to be called fleetmatics work), it's being retired, and the part that actually matters is getting your clients and job history out and into whatever you use next.

updated 23 oct 2026: verizon posted final cutoffs in its final transition deadlines & data export cutoffs article (updated 22 oct 2026), so i fixed the dates below. short version: on 4 jan 2027 the normal work screens and the mobile app stop, 28 feb 2027 is the last day to start a new export, and 31 mar 2027 is the last day to download finished zips.

the dates, straight from verizon's final transition deadlines & data export cutoffs page:

31 dec 2026, "End of Active Service": "You will no longer be able to schedule jobs, add new clients, or manage active workflows." verizon also says "All end-of-year billing, invoicing, and job closures must be finalized by this date."
4 jan 2027, "Platform UI Restriction": "Standard access to the Work platform ceases." admin logins get redirected to the data migration tool, and "The Work Mobile App will also cease to function".
28 feb 2027, "Data Export Initiation Cutoff": "The absolute final day to initiate a new data export job." big exports can take over a week, so don't wait for that day.
31 mar 2027, "Final Infrastructure Decommissioning": "The final day to download previously completed ZIP files." after that, verizon says your job logs, signatures and attachments "will be irretrievably purged".

the comprehensive faq still says "We recommend completing all exports by December 31, 2026." so that's still the safe target. international customers have their own faq page, so check that one if you're outside north america.

also worth knowing early: verizon won't hand your data to your next provider. their words: "To protect your privacy, we cannot move data directly to a third party." you download it, then you bring it to the new tool.

one honest caveat: i haven't seen a real export file, and there's no public sample export, so everything below about files and formats is what verizon's docs say. check it against what you actually get.

1. who can export, and where

only full account administrators can use the export. in the top nav of work there's a migration tool button, which opens in a new tab or window (verizon's guide). if you click it and nothing happens, your browser is probably blocking it as a pop-up. allow pop-ups for work2.fleetmatics.com and try again. if it loops back to the dashboard, verizon suggests firefox or a private window.

there's also the older route from before the shutdown: settings > import/export data > export data. it exports clients, suppliers, items and jobs as excel or csv, and jobs can be filtered by job start date, creation date or invoice date (2022 article, so the menu may differ now).

2. what to export

the migration tool splits things in two.

general exports (no dates): clients, and start/finish questions.

date-range exports: accounts (your inventory and purchases accounts), invoices, jobs (data only), jobs with attachments, purchase orders, quotes, suppliers. each range can be at most 2 years apart, and verizon says not to overlap ranges.

each category comes as csv or json. verizon says if you're unsure, pick csv, since excel or google sheets can open it.

two extras people skip: every category has a view schema button, and there's a show er diagram button with a download option. save both. if your next provider isn't one of verizon's partners, verizon says those providers "do not have access to our export data schemas", so the schema and diagram are the closest thing to a map of your data you can give them.

3. running it without losing your place

text exports are quick. anything with photos, signatures and pdfs can take "several days to over a week".
don't cancel or re-request a slow one. that resets your spot in the queue. closing the browser doesn't stop it.
run jobs with attachments in small chunks. verizon's own tip is monthly or quarterly.
results land on the job history page, grouped into zip files by month. each download is only available for three weeks after it finishes, so watch the "available until" column and grab every month.
work deletes job records that haven't been modified in 7 years, so anything before about september 2019 is already gone (retention policy). a range from before then, or one with no completed jobs, gives you a 0-record file.
if a file comes back blank but you can see the jobs in the jobs tab, verizon suggests smaller chunks (6 months or a year). for export trouble, their faq lists work.support@srv.verizonconnect.com.

4. check the files the same day

unzip every month and make sure each one actually has something in it.
open the clients csv and a couple of job files. do names, addresses and phone numbers look right? pick a busy month and roughly compare the row count to what the jobs tab shows.
check attachments. verizon says they come in folders numbered for each job, and file names match the job id in the job csv. pick three jobs you remember, find their files and open a photo.
keep two copies in two places, like a laptop and an external drive.

5. a browsable offline copy, by hand

after you move you'll still want to look things up ("what did we do at this address in 2022"). a plain spreadsheet does most of it:

never edit the original files. copy them into a "working" folder and edit the copies.
import the csv through the spreadsheet's import option instead of double-clicking it, and set postcode, zip and phone columns to text, otherwise leading zeros can disappear.
one workbook, one sheet each for clients, jobs and invoices. paste each month's jobs under the last, and keep only one header row.
freeze the header row and turn on filters to find jobs by client or address.
verizon says jobs link back to the client name, so a lookup (xlookup or vlookup) can pull client details into the jobs sheet.
add a column with each job's attachment folder path. in desktop excel a hyperlink to a relative folder path can open the folder, as long as the workbook sits next to the unzipped folders. test it on one row first.
save the workbook as .xlsx, but keep the original csvs and zips too. those are your real backup.

if you'd rather not build the spreadsheet, i put a free browser tool for it here: job-archive-viewer.pages.dev. it turns the export files into a browsable offline archive, and your files stay in your browser.

6. what people commonly miss

attachments. plain "jobs" is data only. photos, pdfs and signatures only come with jobs with attachments, and that's the slow one, so start it first.
notes. verizon's docs don't spell out which note fields end up in the job export. open a job you know has notes and check the export for them. if they're missing, copy the important ones while you can still log in.
invoices, quotes, purchase orders, suppliers. each is its own export. your accountant will probably want the invoices.
inventory items and price books. verizon's master data page lists them as csv exports, but the migration tool's list doesn't name inventory items, so check settings > import/export data for them.
start/finish questions. small, but export them.
client custom fields. work supports them. check they show up in the clients export.
recurring jobs. i couldn't find anything saying recurrence patterns export. write down your recurring schedules.
gps. if you use reveal, that's a separate platform and keeps running, but verizon says the work/reveal integration stops once you move off work.

7. planning the move into your next tool

before you commit, ask the new tool what it can import (clients, job history, attachments) and in what format.
give their onboarding people a small sample of your files plus the schema and er diagram from step 2.
verizon's faq says you can take your exports "to any field service provider of your choice", but mapping the files is then that provider's job.
move clients first, since jobs hang off clients. then upcoming and recurring work. job history can go in too, or stay in your offline copy if the new tool can't take it.
verizon's migration checklist says to train your team on the new tool well before december 31, 2026. run both for a bit if you can.
keep the original zips untouched after the move.

that's it

none of this is hard, just slow and easy to put off. queue the attachment exports this week, download each month inside its three-week window, check a few files, and your history goes wherever you do.

Written with AI assistance and checked against Verizon's published docs.