DEV Community: Keyturn Kit

Seven real blog exports into Framer CMS, and the four bugs they found

Keyturn Kit — Fri, 06 Nov 2026 11:02:01 +0000

We make Blog Import, a Framer plugin that moves a blog into Framer CMS from an export file. Its test suite had 267 passing tests on the morning of 27 October. Then we imported real exports, from public repos where people had committed their own blog backups, into a Framer project, and found four bugs in one afternoon. None of them would have shown up with the hand-written fixtures.

1. `&` in image addresses

A Hashnode backup with 18 posts imported fine, but 27 of 67 images failed to copy. Most were pbs.twimg.com/media/...?format=jpg&name=medium.

The post bodies are HTML, so an & inside a src attribute is written as &. We read the attribute with a regular expression and handed ...?format=jpg&name=medium to Framer's image upload as is. Twitter's CDN doesn't know a parameter called amp;name.

The fix is one line: decode & (and &, &) before uploading, and look the decoded address up when swapping the new one back in. It affects every source, not just Hashnode. A WordPress image URL with ?w=1024&h=768 would have failed the same way; our fixtures never had one. After the fix, 2 images failed, and both were dead at the source (a 404 and a 403).

2. The old site says no, sometimes

Importing the newest 25 posts from wordpress.org/news means copying 147 images. Two runs in a row lost 2 and then 4 images, different ones each time, and the posts whose cover was among them came in without a cover. Every one of those images loaded fine with curl a minute later.

We already paced uploads in batches of 10 with a pause between them, and retried one by one when a batch failed. The one-by-one retry came right after the rate limit, so it got limited too. Now the images that still fail get one more slow pass at the end: wait 10 seconds, then one image per second. The third run lost none.

That pass can take a minute on a big blog, and the progress line used to stay on "Copying images, 45 of 45" the whole time. It now says "Trying 38 images again, 12 of 38".

3. Importing again forgot the layout

At the time, Blog Import could put everything in one collection (Framer's Basic plan allows only two) or in four linked ones, chosen with a checkbox. The checkbox always started unticked, so importing a one-collection blog a second time quietly added three new collections. The plugin now saves the layout with the collection and reads it back; for collections imported before that, it looks at which fields exist. It has since gained a third layout, Blog plus categories, which also fits on Basic.

4. A message that wasn't true

A real Ghost export from 2025 had 9 images written as __GHOST_URL__/content/images/.... Ghost exports leave out the domain, so the plugin asks for the old site's address. We gave it, and 10 images still failed: the blog has since moved to a static site, and the old image addresses now return an HTML page. The results screen said those images "still load from the old site". They didn't. It now says they still point to the old site and show only while it is online.

Re-importing got fast as a side effect

Re-importing the same posts used to copy every image again, about 30 seconds for 25 Squarespace posts. Framer's plugin API can read back the items a plugin wrote (getCollections() then getItems()), so the plugin now pairs each image in the new body with the one already in Framer, by position and the text around it, and only uploads what is new. The same re-import now takes under 2 seconds, and a cover that can't be fetched no longer replaces the one already there.

What we'd tell anyone writing an importer

Test with real exports early. GitHub has plenty: search for Squarespace-Wordpress-Export, kind#post (Blogger), __GHOST_URL__ (Ghost), or a Hashnode backup repo. Treat them as data, read only, and don't publish other people's posts.
Old sites rate-limit and die. Design the image step for partial failure, and make the message say exactly what the user's site will look like.
Our seven sources, from those runs: WordPress (live site), Substack, Medium, Ghost and Hashnode from real exports; Squarespace and Blogger from real exports too, with failures only on third-party images (a dead host and Wikimedia refusing hotlinks).

Blog Import is on the Framer Marketplace. The newest 25 posts import free; a license for the rest is $29 for one project or $59 for any number, paid once.

Moving a client's blog into Framer: a checklist for agencies

Keyturn Kit — Thu, 05 Nov 2026 11:06:46 +0000

The design is the part of a migration you quote for. The blog is the part that comes back to you a month later, when an old link from a newsletter lands on a 404 or the photos in a 2019 post stop loading. This is a checklist for that part. We make Blog Import, a Framer plugin for this job, so weigh that.

1. Get the export before anything else

Ask the client for the export file in the first week, not the last. Each platform keeps it somewhere different:

Platform	Where the export is
WordPress	Tools, Export, All content (an `.xml` file)
Squarespace	Import & export panel, Export, WordPress (an `.xml` file)
Blogger	Settings, Back up content, Download (an `.xml` file)
Medium	Settings, Security and apps, Download your information (a `.zip`)
Ghost	Settings, Migration tools, Export (a `.json` file)
Substack	Settings, Exports, Create new export (a `.zip`)
Webflow	CMS, the blog collection, Collection settings, Export (a `.csv`)

Keep a copy in the project folder. Once the client cancels, it is also the only copy of the drafts.

2. The images are not in the file

None of these exports carry the images themselves. They carry addresses on the old host: /wp-content/uploads/ on WordPress, Squarespace's image servers, Webflow's asset domain. Those addresses stop working when the client cancels, often weeks after launch. Copy the images into Framer during the import, then open a few old posts on the new site and check where each image loads from.

Our image list tool reads an export in the browser and lists which images sit on the old host.

3. Redirects need Framer Pro

Every old post address needs a redirect to its new path, or links from other sites and search results end on a 404. Framer has redirects on Pro and higher, under Site Settings, Hosting, Redirects; Basic has none. If the client is on Basic, say so in the quote. Old addresses look different on each platform, for example /2024/03/09/my-post/ on WordPress and /blog/2014/6/10/my-post on Squarespace. Redirects for a moved blog has the patterns. Addresses that were never on the client's domain can't be redirected from Framer: name.blogspot.com, name.ghost.io, name.substack.com and stories on medium.com. Leave those posts up with a link to the new site.

4. Check the CMS limits against the post count

Basic allows 1,000 CMS items and 2 collections, Pro 2,500 items and 10 collections. Authors, categories and tags count as items when they are collections of their own. On Basic, keep authors, categories and tags as fields on each post instead. Framer CMS limits for a blog works through the numbers.

5. Before the client cancels

Images load from Framer, not the old host.
Redirects are added and the site is published.
The domain points at Framer.
Five old addresses, one from the oldest year, land on the right post.
Only then cancel the old platform. Budget a month of overlap.

Doing the import

By hand is fine for ten posts. For more, Framer's CSV import brings the text in, but images inside posts stay linked to the old host and there are no redirects.

Blog Import reads every export in the table above, copies the images into Framer (for Ghost images the export writes as __GHOST_URL__, it asks for the old blog address or a zip of the images, see the Ghost guide) and, on Pro, adds one redirect per post from the old address on the client's own domain. The newest 25 posts import free, so you can run it on a real client blog before paying. A license is $29 for one Framer project or $59 for any number of projects, paid once. Other plugins do parts of this; the comparison lists them.

What six payment providers keep from a $9 Chrome extension

Keyturn Kit — Wed, 04 Nov 2026 13:03:25 +0000

Since the Chrome Web Store stopped taking payments, every paid extension needs a provider of its own, and the fee pages are hard to compare: some charge a flat cut, some add Stripe on top, some add a surcharge for cards outside the US. So we put the published rates side by side for one ordinary case: a $9 one-time purchase, 50 sales a month, 60% of buyers outside the US.

Provider	Fees a month	You keep
Dodo Payments	$42.05	$407.95 (90.7%)
Lemon Squeezy	$47.50	$402.50 (89.4%)
Polar, Starter plan	$51.55	$398.45 (88.5%)
Payhip free plan, with Stripe	$54.60	$395.40 (87.9%)
ExtensionPay, with Stripe	$54.60	$395.40 (87.9%)
Gumroad, direct sales	$70.00	$380.00 (84.4%)

The rates behind it, from each pricing page on 28 October 2026:

Lemon Squeezy: 5% + 50¢. It mentions "small additional fees" outside the US without a number, so its row has none and is a little too high.
Polar Starter: 5% + 50¢, +1.5% for cards outside the US. Its paid plans go down to 3.4% + 30¢.
Gumroad: 10% + 50¢ on direct sales, 30% on sales that come from Gumroad Discover.
Dodo Payments: 4% + 40¢, +1.5% outside the US, +0.5% for subscriptions.
Payhip free plan: 5%, plus Stripe or PayPal. Paid plans are $29 a month with a 2% fee, or $99 a month with none.
ExtensionPay: 5%, plus Stripe. Sales tax is yours.
Stripe: 2.9% + 30¢, +1.5% for international cards.

Three things the table leaves out:

Sales tax. Lemon Squeezy, Polar and Dodo Payments are merchants of record: they collect and pay the tax. With ExtensionPay, and anything else where Stripe pays you directly, filing it is your job.
Payouts and currency. Some providers pass on payout or conversion fees (Polar passes on Stripe's; Dodo's page lists a $5 fee for payouts under $1,000 in one place and "Free" in another). The real amount is a little lower for all of them.
Price changes the order. The fixed 30 to 50 cents weighs heavily on a $3 sale and barely matters on a $30 one. Try your own numbers in the calculator.

Whichever provider you pick, the extension still has to know who paid. ExtensionPay does that on its servers. With the others you check a license key from the extension. That is what we build: Keyturn Kit is a WXT + React starter that does it with no server of yours, free (MIT) for Lemon Squeezy, and $59 once for Pro, which adds Polar, Dodo Payments, Gumroad and Payhip.

Gumroad license keys in a Chrome extension, and what the API leaves to you

Keyturn Kit — Tue, 03 Nov 2026 12:28:35 +0000

We make Keyturn Kit, a starter for selling Chrome extensions with license keys, and just added Gumroad to it. Gumroad's license API is the simplest of the providers we support and also the one that leaves the most to you, so here are the details, whether you use our kit or not.

Turn license keys on

In Gumroad, open the product's content page, choose Insert and add a License key block. While you edit, the block shows the product's ID. Copy it, because every verify call needs it. Gumroad requires product_id for products created on or after 9 January 2023; the older product_permalink only works for older products.

Add https://api.gumroad.com/* to host_permissions in your manifest.

One endpoint, called two ways

There's a single public call, POST https://api.gumroad.com/v2/licenses/verify, with form fields:

const res = await fetch('https://api.gumroad.com/v2/licenses/verify', {
  method: 'POST',
  headers: { 'Content-Type': 'application/x-www-form-urlencoded' },
  body: new URLSearchParams({
    product_id: PRODUCT_ID,
    license_key: key,
    increment_uses_count: 'true', // 'false' for the daily re-check
  }),
});

A good key answers 200 with success: true, a uses count and a purchase object. A key Gumroad doesn't know for this product, a disabled key, or a purchase whose access was revoked answers 404 with success: false and a message you can show the user.

Because the key is looked up inside your product_id, a key bought for someone else's product is rejected by Gumroad itself.

No activations, only a counter

Lemon Squeezy, Polar and Dodo let a key be activated on a set number of devices. Gumroad doesn't. Every verify call adds 1 to uses unless you send increment_uses_count=false, and lowering it takes your access token, so in practice only you do it, from the sale in your Gumroad dashboard.

So count once, when the key is pasted, and compare uses with the number of browsers you allow. Re-check later with increment_uses_count=false, or a daily check would use up the key within a week. A reinstall counts as a new use, so leave some room.

Refunds and ended memberships don't disable the key

Gumroad keeps answering 200 for a refunded purchase. Its help article says the key stays enabled until you disable it. What changes is the purchase.

refunded or chargebacked is true after a refund or chargeback
disputed is true while a payment is disputed, and dispute_won tells you if you won it
for memberships, subscription_ended_at, subscription_cancelled_at and subscription_failed_at hold the date access ends, and go back to null if the membership renews

Check these on every verify and lock Pro yourself. Keyturn Kit treats refunded, charged back and lost disputes as disabled, and any of the three dates in the past as expired.

Nothing secret in the extension

Disabling a key or lowering its count goes through Gumroad's OAuth API with your access token. That token must never ship in an extension; anyone can unzip one. Keep those actions in your dashboard. In the extension, "remove key" can only forget the key in that browser.

When Gumroad can't be reached

Network errors, 429 and 5xx responses aren't an answer about the key. Keep the last good result for a while. Keyturn Kit allows 7 days after the last good check before locking Pro.

Doing it with Keyturn Kit

Keyturn Kit is a WXT + React starter that does all of the above. The free edition (MIT, on GitHub) uses Lemon Squeezy. Gumroad, Payhip, Polar and Dodo Payments come with Pro ($59 once), where switching provider is one line in lib/config.ts:

provider: 'gumroad',
gumroad: { productId: 'YOUR-GUMROAD-PRODUCT-ID', maxUses: 3 },

Pro also adds a free trial counted from install and a number of free uses per day before the paywall. The step-by-step guide for the free edition is Selling a Chrome extension with license keys, no backend. Since this post is about Gumroad, Pro is on Gumroad too.

Taking payment before the user installs your Chrome extension

Keyturn Kit — Mon, 02 Nov 2026 12:51:33 +0000

Someone asked on ExtensionPay's discussions how to charge on their own landing page before anyone installs. Setups that track paying users from inside the extension want the extension first. With license keys you can flip the order, because the key is the proof of purchase and it can arrive before the extension does. We make Keyturn Kit, a starter that works this way, so take this with that in mind.

The order of things

Buy button on your page, linking to a checkout (Lemon Squeezy here; Polar, Dodo Payments, Gumroad and Payhip work the same way).
The confirmation screen and the receipt email both point to your Chrome Web Store listing. The receipt carries the license key.
The buyer installs, and the extension opens a page that asks for the key.
The extension activates the key with the provider's license API. No accounts, no server of yours.

Point the receipt at the store

In Lemon Squeezy each product has a confirmation modal (title, message, button text, button link) and receipt settings (thank you note, button text, button link). Set both links to the store listing and say what comes next: "Install the extension, then paste the key from this email."

Ask for the key on first install

Without this, a buyer installs, sees a locked popup and has to guess where the key goes.

// entrypoints/background.ts (WXT)
export default defineBackground(() => {
  // Registered at the top level: the service worker only gets onInstalled if the listener exists on first run.
  browser.runtime.onInstalled.addListener(({ reason }) => {
    if (reason === 'install') void browser.runtime.openOptionsPage();
  });
});

The options page needs one field and an Activate button:

const r = await license.activate(key, 'Chrome');
if (!r.ok) showError(r.error);

Say on that page that people who haven't paid can use the free part and buy later, so one page serves both.

Three decisions

Set an activation limit in the provider, for example 3, so a key covers one person's browsers without spreading.
When you refund, disable the key; the extension notices on its next daily check.
For Firefox and Edge the key flow is the same, but the receipt needs a link per store, so a small "get the extension" page beats one store link.

The full guide has the same steps with links to Lemon Squeezy's docs, and the free MIT edition of Keyturn Kit ships the options page, the activation and the first-install snippet.

Moving Chrome extension license keys off Lemon Squeezy

Keyturn Kit — Sun, 01 Nov 2026 12:57:06 +0000

If your Chrome extension unlocks Pro with a Lemon Squeezy license key, you've probably seen the Stripe news. We make Keyturn Kit, a starter for selling extensions with license keys, and its free edition is built on Lemon Squeezy, so we looked at what a move would take. Short answer: nothing forces one today, but Stripe Managed Payments has no license keys, so it's worth knowing where you'd go.

Lemon Squeezy still sells and still answers its license API. Its site now carries a "2026 Update: Lemon Squeezy + Stripe Managed Payments" banner, and write-ups of that update say the goal is to make moving to Stripe Managed Payments easy. Stripe has no license keys of its own, so an extension that unlocks Pro with a Lemon Squeezy key has no direct equivalent to move to. Nothing forces a move today; this post is for planning one. Read on 27 October 2026.

What the extension needs from a provider

A paid extension without a server needs three things from a license API:

Calls the extension can make with nothing secret in its code.
A way to limit how many browsers use one key.
A key that stops working after a refund.

Four providers, side by side

Each row comes from our guide for that provider, checked against its docs on 27 October 2026.

Provider	Secret in the extension	Browser limit	After a refund
Polar	None, customer-portal endpoints need no token	Activations, if turned on in the license key benefit	Revoke or disable the key; the next check fails
Dodo Payments	None, license endpoints are public	Activations per key	Disable the key; validate then returns `valid: false`
Gumroad	None, verify needs no token	No activations, only a `uses` counter you check yourself	The key stays enabled; check the `refunded` and `chargebacked` fields yourself
Payhip	A per-product secret Payhip says is meant for public apps	A `uses` count you raise and lower with that secret (a soft limit)	Payhip disables the key by itself

Two catches worth knowing before you pick. On Dodo, a key bought from any other Dodo seller activates too, so compare business_id with yours. On Gumroad, a refunded purchase still verifies, so the extension has to look at the purchase fields.

Moving existing customers

Keys from one provider don't work at another, so plan for the people who already paid:

Send new buyers to the new store, and keep checking old keys with Lemon Squeezy: when the new provider doesn't recognise a pasted key, try it against Lemon Squeezy before saying no. Both checks can live side by side while Lemon Squeezy's license API answers.
Or give existing buyers a key from the new provider, if your new provider lets you issue one without a new purchase. Check that before you announce the move.

In Keyturn Kit

Keyturn Kit is a WXT + React starter for paid extensions. The free edition (MIT, on GitHub) uses Lemon Squeezy. Pro ($59 once) adds Polar, Dodo Payments, Gumroad and Payhip, and switching is one line in lib/config.ts:

provider: 'polar', // or 'dodo', 'gumroad', 'payhip', 'lemonsqueezy'

The free edition's walkthrough is Selling a Chrome extension with license keys, no backend.

Payhip license keys in a Chrome extension, with a secret that's allowed to ship

Keyturn Kit — Sat, 31 Oct 2026 12:58:18 +0000

Most license APIs give you one account key that must never leave a server, which is awkward when your product is a Chrome extension with no server at all. Payhip's v2 license API is different. Each product has its own secret key, and Payhip's help center says that one is meant for public apps. We just added Payhip to Keyturn Kit, our starter for selling extensions, so here is how the endpoints behave and where the limits are. The details come from Payhip's help article on software license keys, read on 27 October 2026.

Turn license keys on

In Payhip, turn on license keys for the product. Its license settings show the product secret key, and that's the value the extension sends. Your account API key stays out of it.

Add https://payhip.com/* to host_permissions in your manifest.

Checking a key

GET https://payhip.com/api/v2/license/verify?license_key=..., with the secret in a product-secret-key header:

const res = await fetch(
  `https://payhip.com/api/v2/license/verify?license_key=${encodeURIComponent(key)}`,
  { headers: { 'product-secret-key': PRODUCT_SECRET } },
);
const text = await res.text();
const license = text ? JSON.parse(text).data : null; // empty response = no such key

A good key comes back as data with enabled, license_key, buyer_email, uses and date. An unknown key gives an empty response rather than an error, so the check has to treat "nothing came back" as "not a key" instead of trying to parse it.

Counting browsers with uses

There are no activations as such, but every key has a uses number you can move up and down with the same secret.

PUT /api/v2/license/usage adds one. Call it once when the key is pasted, after checking that uses is below the number of browsers you allow.
PUT /api/v2/license/decrease takes one off. Call it when someone removes the key, so moving to a new laptop frees a slot.
The daily re-check only calls verify, which leaves the count alone.

Refunds

Payhip disables the key by itself when an order is refunded. The next verify returns enabled: false and the extension can lock the paid features. Nothing to do in the dashboard.

How far the secret reaches

The secret ships inside the extension, and anyone can unzip an extension. With it, someone who already holds a key can call decrease on that key and reset their own count, so the browser limit is soft. They can't create keys or unlock keys they don't have. That's the trade Payhip made by letting public apps call these endpoints. If a hard limit matters to you, the check belongs on a server.

In Keyturn Kit

Keyturn Kit is a WXT + React starter that does the above. The free edition (MIT, on GitHub) uses Lemon Squeezy. Payhip, Gumroad, Polar and Dodo Payments come with Pro ($59 once), where switching provider is one line in lib/config.ts:

provider: 'payhip',
payhip: { productSecretKey: 'YOUR-PAYHIP-PRODUCT-SECRET-KEY', maxUses: 3 },

The full guide, with the same code, is on our site.

Moving a photo-heavy WordPress blog into Framer CMS: what happened to 50 images and their captions

Keyturn Kit — Fri, 30 Oct 2026 12:56:47 +0000

We make Blog Import, a Framer plugin that moves old blogs into Framer CMS. Photographers' blogs are the hard case: one post per wedding or place, 30 to 80 photos each, usually with a caption under every photo. So we built a test post with 50 captioned photos and pushed it through a real Framer project. Three things came out of it that apply whether you use our plugin or write your own import.

1. Where the images live decides whether they copy

Framer's CMS can take an image by URL and store its own copy. Our first run pointed at public domain photos on Wikimedia's thumbnail server. From a laptop every one of those URLs answered 200. From Framer's side, all 64 failed, retries included.

We then hosted resized copies (1600 px, under 400 KB each, about 20 MB in total) on a plain static site and ran the same import. All 64 copied, in under 20 seconds.

A real blog hosts its own images, so this mostly matters for tests and demos. But if your old site sits behind hotlink protection or a bot filter, expect the same failure, and keep the old site online until the copy is done.

2. Static hosting caches longer than you think

Between the two runs we changed the sample JSON and ran the import again a few minutes later. It still read the old URLs. GitHub Pages serves files with cache-control: max-age=600, and the browser running the plugin kept the copy from the first run. After ten minutes the new file came through. If you iterate on fixture data served from a static host, change the path or wait out the cache.

3. Framer's rich text drops `<figure>` and `<figcaption>`

WordPress writes a captioned photo like this:

<figure class="wp-block-image">
  <img src="/uploads/2025/06/harbour.jpg" alt="Harbour at dusk">
  <figcaption>The harbour an hour after the ceremony</figcaption>
</figure>

Sent to a Framer CMS formatted text field as is, the image arrived, but the caption text was gone and the image lost its alt. What survived was a bare image.

What works is turning each captioned figure into plain tags the field keeps: the image, then a paragraph with the caption in italics, and the caption as alt when the image has none.

<img src="/uploads/2025/06/harbour.jpg" alt="Harbour at dusk">
<p><em>The harbour an hour after the ceremony</em></p>

With that change the same post came through with 50 images, 50 captions in order and 50 alts. The same shape covers Ghost's image cards and Medium's figures, which use the same tags.

The short version

Copy images from where the old blog hosts them, while it is still online.
Don't trust a fixture you changed less than ten minutes ago on a static host.
Flatten <figure> and <figcaption> into <img> plus <p><em> before writing to Framer's formatted text.

The caption change is in the current version of Blog Import on the Framer Marketplace. The Showit guide has the steps for photographers whose blog runs on Showit's WordPress, and Blog Import is free. We also made Second Shooter, a Framer template for wedding and portrait photographers built around posts like this one, with every photo large in the text column. If you have moved a big photo blog another way, I'd like to hear what broke.

What's inside a Ghost export, and what it takes to move it into Framer CMS

Keyturn Kit — Thu, 29 Oct 2026 12:57:54 +0000

We make Blog Import, a Framer plugin that reads blog exports, and Ghost was the last format we added. Ghost's export looks simple at first, a single JSON file. A few details in it decide what you can rebuild somewhere else, so here they are, whether you use our plugin or write your own script.

Getting the file

In Ghost admin, open Settings, find Migration tools and choose Export. You get a .json file with posts, pages, tags, users and settings. Images and the theme are not in it.

Two shapes of the same file

Ghost's exporter writes { meta, data }. The admin download wraps that once more, as { db: [ { meta, data } ] }. Files from older tools and Ghost's own import docs use the bare shape, so a reader should accept both.

Everything useful is in data. data.posts holds posts and pages together; type tells them apart (post or page), and status is published, draft or scheduled.

Authors and tags live in link tables

A post row has no author name or tag list. Ghost keeps them the way a database would.

data.users and data.tags hold the people and the tags
data.posts_authors and data.posts_tags connect them to posts by id, each row with a sort_order

The first author by sort_order is the primary one. Tags whose name starts with # are internal tags, used for routing and theme logic rather than as topics, so they usually shouldn't become categories on the new site.

Dates come in three formats

Depending on the Ghost version that wrote the file, published_at is an ISO string, "2024-01-10 09:30:00" (UTC, with a space instead of the T), or epoch milliseconds. new Date() handles the first and the last; the middle one needs the space replaced and a Z added, or one browser reads it as local time and another rejects it.

The image problem

This is the part that matters most before you cancel Ghost. Recent exports write the site's own address as a placeholder.

<img src="__GHOST_URL__/content/images/2024/01/photo.jpg">

Older exports write /content/images/... with no domain at all. The settings in the export don't hold the site URL either, so the file alone can't tell you where those images were. Images with a full address, on a CDN or another host, are fine.

In practice, if your Ghost site is still online, you can rebuild the addresses by putting your domain in front, and copy the images while the site is up. Once the site is gone, the only copies are the ones you downloaded yourself.

Links between posts use the same placeholder (<a href="__GHOST_URL__/second-post/">), and those are easier. Dropping the placeholder leaves a path that works on the new site if the slugs stay the same.

Old addresses

Ghost's default post address is /your-post-slug/. Sites that changed routes.yaml (dated paths, tag-based collections) use other addresses, and the export doesn't say which routes were active. Redirects built from the export assume the default, so check a few after moving.

What we do with it in Framer

Blog Import reads that file inside Framer and creates CMS collections for posts, authors and tags, linked to each other, with drafts kept as drafts and a redirect per post on Framer Pro or higher. Pages, co-authors beyond the first, members and newsletter settings don't come across. For images it does what's described above. Full addresses are copied into Framer. For __GHOST_URL__ ones you type the old blog address and they are copied too while the site is up; if it's already gone, you choose a zip of the content/images folder and the plugin matches the files (including Ghost's resized copies under size/w600/) and uploads them from there. Self-hosted sites have that folder on the server; on Ghost(Pro) you have to ask Ghost's support for it.

The newest 25 posts import free, and there's a step-by-step guide with the same details for non-developers. If your export has something odd in it that this doesn't cover, I'd like to see it in the comments.

Polar 403 "This license key does not support activations" in a Chrome extension

Keyturn Kit — Wed, 28 Oct 2026 15:34:16 +0000

If your Chrome extension checks Polar license keys and every real key fails, look at the response of the activate call. When the license key benefit in your Polar dashboard has no activation limit, Polar answers with:

403 {"detail": "This license key does not support activations. Use the /validate endpoint instead to check license validity."}

Nothing is wrong with the key. The benefit simply has nothing to count, so Polar refuses to create an activation. Most examples call activate first and treat any non-200 as "invalid key", so the buyer sees an error with a key they just paid for.

There are two ways out.

1. Turn activations on. In Polar, open the product, edit the License Keys benefit and set an activation limit (for example 3 browsers). Now activate returns an activation id, and you validate later with that id. This is the only mode where Polar enforces a browser limit.

2. Fall back to validate. If you want unlimited use, keep the benefit as it is and handle exactly that 403:

const API = "https://api.polar.sh/v1/customer-portal/license-keys";

async function post(path, body) {
  const res = await fetch(`${API}/${path}`, {
    method: "POST",
    headers: { "Content-Type": "application/json", Accept: "application/json" },
    body: JSON.stringify({ organization_id: ORG_ID, ...body }),
  });
  return { status: res.status, json: res.status === 204 ? null : await res.json() };
}

export async function activateKey(key, label) {
  const r = await post("activate", { key, label });
  const noActivations =
    r.status === 403 &&
    typeof r.json?.detail === "string" &&
    /does not support activations/i.test(r.json.detail);

  if (noActivations) {
    const v = await post("validate", { key });
    if (v.status !== 200) return { ok: false };
    return { ok: v.json.status === "granted", activationId: "" };
  }
  if (r.status !== 200) return { ok: false };
  return { ok: r.json.license_key.status === "granted", activationId: r.json.id };
}

Three details that matter:

Match that one 403 only. Any other 403 means something else and should still fail.
Store an empty activation id, and on later checks call validate with no activation_id field at all.
Skip deactivate when there is no activation id, since there is nothing to release.

These endpoints are the customer-portal ones, so they need only your organization id, no access token. Nothing secret ships in the extension.

We hit this while building Keyturn Kit, a WXT + React starter for paid Chrome extensions. Version 1.2.3 of its Polar provider (in Pro) handles both modes, with tests for the fallback. The free MIT edition on GitHub uses Lemon Squeezy.

Selling a Chrome extension with license keys, no backend

Keyturn Kit — Sun, 25 Oct 2026 14:32:13 +0000

Google wound down Chrome Web Store payments between 2020 and early 2021. To charge for an extension now, you need a checkout and a way to know who paid, and you want to make sharing one key with everyone at least inconvenient.

This post walks through a small setup that covers that without running a server: Lemon Squeezy for the checkout, its License API for the "who paid" part, and about 80 lines of TypeScript in the extension.

We make Keyturn Kit, a starter built on this approach (more at the end). Everything below works on its own without it.

Why license keys and not accounts

The usual SaaS answer is user accounts: the user logs in and your server knows their plan. That means a backend, a database and auth to look after. For an extension that sells for $5 to $30 it is a lot to run.

A license key turns this around. The payment provider generates the key and emails it to the buyer, the buyer pastes it into the extension once, and the extension asks the provider whether the key is valid and caches the answer. You don't keep a user table anywhere.

The trade-off is that anything checked on the client can be patched out by someone determined. An activation limit stops casual sharing, and you can disable a key yourself in the dashboard, for example after a refund. Neither stops a person who edits your minified JS. For many small extensions that's an acceptable line.

Step 1: the product

In Lemon Squeezy, create a product and open its settings:

turn on Generate license keys
set an activation limit, for example 3. Each browser that activates the key uses one slot.
for a one-time purchase, set the license length to unlimited

Note your store id from the store settings. You'll need it in a minute.

Step 2: the manifest

The License API is called straight from the extension, so it needs host permission:

{
  "permissions": ["storage", "alarms"],
  "host_permissions": ["https://api.lemonsqueezy.com/*"]
}

The License API docs examples send no API key: the license key itself is the credential. Never put your Lemon Squeezy API key in an extension.

Step 3: activate

When the user pastes a key, first check that it belongs to your store, then activate it with a name for this install. Lemon Squeezy returns an instance id; keep it, because you need it to validate and deactivate later.

const API = 'https://api.lemonsqueezy.com/v1/licenses';
const STORE_ID = 12345; // yours

async function post(path: string, body: Record<string, string>) {
  const res = await fetch(`${API}/${path}`, {
    method: 'POST',
    headers: { Accept: 'application/json' },
    body: new URLSearchParams(body),
  });
  // Rate limits and server errors are temporary. Don't treat them as "key rejected".
  if (res.status === 429 || res.status >= 500) throw new Error('temporary');
  return res.json();
}

async function activate(key: string) {
  key = key.trim();

  // Any Lemon Squeezy store's key is a real key. Check it's yours before using an activation slot.
  const check = await post('validate', { license_key: key });
  if (!check.valid) throw new Error(check.error ?? 'Key not accepted');
  if (check.meta?.store_id !== STORE_ID) throw new Error('This key is from a different store');

  const data = await post('activate', {
    license_key: key,
    instance_name: `Chrome ${crypto.randomUUID().slice(0, 8)}`,
  });
  if (!data.activated) throw new Error(data.error ?? 'Key not accepted');
  if (data.meta?.store_id !== STORE_ID) {
    await post('deactivate', { license_key: key, instance_id: data.instance.id });
    throw new Error('This key is from a different store');
  }

  const now = Date.now();
  await chrome.storage.local.set({
    license: { key, instanceId: data.instance.id, lastCheckedAt: now, lastOkAt: now, valid: true },
  });
}

The store_id check is easy to leave out. Without it, a key bought for any product in any Lemon Squeezy store turns on your Pro features, because the License API tells you the key is real, not that it is yours.

The random suffix on instance_name gives each install its own entry in your dashboard. Without it, a customer with three laptops shows up as three identical "Chrome" rows.

Step 4: re-check once a day

Validate once a day rather than on every popup open, so a user on a plane doesn't lose what they paid for and you aren't calling the API on every click.

const HOUR = 3_600_000;
const DAY = 24 * HOUR;
const GRACE = 7 * DAY;

// Write only if the same license is still stored. The network call takes time, and the
// user may have removed or replaced their key meanwhile.
async function saveIfSame(l: any, changes: object) {
  const { license: current } = await chrome.storage.local.get('license');
  if (current?.instanceId !== l.instanceId) return;
  await chrome.storage.local.set({ license: { ...current, ...changes } });
}

async function isPro(): Promise<boolean> {
  const { license: l } = await chrome.storage.local.get('license');
  if (!l) return false;

  if (Date.now() - l.lastCheckedAt > DAY) {
    try {
      const data = await post('validate', { license_key: l.key, instance_id: l.instanceId });
      const valid = data.valid === true && data.meta?.store_id === STORE_ID;
      await saveIfSame(l, { valid, lastCheckedAt: Date.now(), lastOkAt: valid ? Date.now() : l.lastOkAt });
    } catch {
      // No answer: keep the last known state and try again in an hour.
      await saveIfSame(l, { lastCheckedAt: Date.now() - DAY + HOUR });
    }
  }

  const { license: now } = await chrome.storage.local.get('license');
  return !!now?.valid && Date.now() - now.lastOkAt < GRACE;
}

"The server said no" and "the server didn't answer" need different handling. A key you've disabled gets valid: false and locks at the next check, so within about a day. A network error or a rate limit keeps the previous answer, for up to a week since the last good check. If you treat the two the same, either users get locked out on bad Wi-Fi or disabled keys keep working.

valid is false for disabled and expired keys, so there's no need to inspect license_key.status as well.

saveIfSame matters more than it looks. Without it, a check that started before the user clicked "move my key" can finish afterwards and write the removed key back.

Step 5: check without the popup

If you only check when the popup opens, a user who never opens it keeps Pro after you disable their key. An alarm in the service worker covers that:

// Create the alarm only if it's missing. Calling create() on every service worker start
// resets its timer, and alarms aren't guaranteed to survive a browser restart.
chrome.alarms.get('license').then((a) => {
  if (!a) chrome.alarms.create('license', { periodInMinutes: 60 });
});

chrome.alarms.onAlarm.addListener((a) => {
  if (a.name === 'license') isPro();
});

isPro() only calls the API once a day, so an hourly alarm is cheap.

Step 6: let people move their key

With an activation limit, someone who switches laptops will hit the cap eventually. Give them a button that frees the slot:

// Returns false if the slot could not be freed on the server, so the UI can say "try again online".
async function deactivate(): Promise<boolean> {
  const { license: l } = await chrome.storage.local.get('license');
  if (!l) return true;
  const freed = await post('deactivate', { license_key: l.key, instance_id: l.instanceId })
    .then((d) => d.deactivated === true)
    .catch(() => false);
  await chrome.storage.local.remove('license');
  return freed;
}

Remove the local copy even if the request fails, otherwise an offline user can't move their key at all. But tell them when the server slot wasn't freed, or they'll hit the activation limit later with no idea why.

Testing it

Lemon Squeezy has a test mode with test cards. Buy your own product in test mode and paste the key. Disable the key in the dashboard, then force a re-check by setting license.lastCheckedAt to 0 in the extension's storage (DevTools, Application, Extension storage). Pro should switch off. Then go offline and check that Pro stays on.

If you plan to refund customers, try a refund in test mode as well and see what it does to the key. Don't assume a refund disables it.

The longer version

Keyturn Kit's free edition (MIT) is this same approach with React components, a settings page and tests with a mocked fetch: https://github.com/keyturnkit/keyturn-kit

There's also a paid edition that adds Polar, Dodo Payments, Gumroad and Payhip, a free trial and per-day free usage. You don't need it to follow this post. The code above covers the basic flow.

DEV Community: Keyturn Kit

Seven real blog exports into Framer CMS, and the four bugs they found

1. &amp; in image addresses

2. The old site says no, sometimes

3. Importing again forgot the layout

4. A message that wasn't true

Re-importing got fast as a side effect

What we'd tell anyone writing an importer

Moving a client's blog into Framer: a checklist for agencies

1. Get the export before anything else

2. The images are not in the file

3. Redirects need Framer Pro

4. Check the CMS limits against the post count

5. Before the client cancels

Doing the import

What six payment providers keep from a $9 Chrome extension

Gumroad license keys in a Chrome extension, and what the API leaves to you

Turn license keys on

One endpoint, called two ways

No activations, only a counter

Refunds and ended memberships don't disable the key

Nothing secret in the extension

When Gumroad can't be reached

Doing it with Keyturn Kit

Taking payment before the user installs your Chrome extension

The order of things

Point the receipt at the store

Ask for the key on first install

Three decisions

Moving Chrome extension license keys off Lemon Squeezy

What the extension needs from a provider

Four providers, side by side

Moving existing customers

In Keyturn Kit

Payhip license keys in a Chrome extension, with a secret that's allowed to ship

Turn license keys on

Checking a key

Counting browsers with uses

Refunds

How far the secret reaches

In Keyturn Kit

Moving a photo-heavy WordPress blog into Framer CMS: what happened to 50 images and their captions

1. Where the images live decides whether they copy

2. Static hosting caches longer than you think

3. Framer's rich text drops <figure> and <figcaption>

The short version

What's inside a Ghost export, and what it takes to move it into Framer CMS

Getting the file

Two shapes of the same file

Authors and tags live in link tables

Dates come in three formats

The image problem

Old addresses

What we do with it in Framer

Polar 403 "This license key does not support activations" in a Chrome extension

Selling a Chrome extension with license keys, no backend

Why license keys and not accounts

Step 1: the product

Step 2: the manifest

Step 3: activate

Step 4: re-check once a day

Step 5: check without the popup

Step 6: let people move their key

Testing it

The longer version

1. `&` in image addresses

3. Framer's rich text drops `<figure>` and `<figcaption>`