Edit the theme in place, and the next composer update overwrites your changes — or you stop updating, and the theme's fixes for security, speed and new browsers never reach you. Fork it, and you own every line of it from then on, merging each upstream release by hand.

WordPress solved this years ago with child themes, and most WordPress developers reach for one without thinking. kitloom now has them too, built the same way: a child theme holds only what it changes and takes everything else from its parent — including the parent's updates.

What a child theme is ​

A child theme is a theme with a parent. Where WordPress reads Template: twentytwentyfive from a child's style.css, kitloom reads the parent's name from the child's composer.json:

{
    "extra": {
        "kitloom": {
            "theme": {
                "parent": "Journal"
            }
        }
    }
}

A folder themes/Inkwell/ with that file and one changed template is a complete child theme. It needs no service provider and no package.

When a page is drawn, kitloom walks the WordPress template hierarchy as usual, but asks for each template name twice: first in the child, then in the parent, before it moves on to the next name. The same order applies to Blade views and to the Vue or React components a template imports.

First, check whether you need one at all ​

Many of the changes people make child themes for are not code. The accent colour, the logo, the line under the footer, a sidebar on the left instead of the right: in kitloom, a theme declares these as settings, and the site's owner changes them on Appearance → Customize, beside a live preview of the site.

The preview is a draft only you can see, for an hour, in any tab. It is never cached and never indexed. Publish makes it live for everyone. If that covers what you wanted, stop here: there is no child theme to maintain.

Make a child theme in one command ​

When you do need code, the theme generator writes the child for you:

php artisan kitloom:make-theme Inkwell --parent=Journal

themes/Inkwell/
├── composer.json          the parent's name, the child's card on Appearance → Themes
├── README.md              how to override, and every file of Journal you may override
└── resources/
    └── style.css          loaded after Journal's styles

To start from one of the parent's files, copy it over as you make the child, or later:

php artisan kitloom:make-theme Inkwell --parent=Journal --copy=Components/Masthead.vue,Templates/page

The command copies only the files you name, and never over one the child already has. A child meant for several sites can be a Composer package instead (--package --vendor=acme), with its own service provider and test.

Appearance → Themes then shows both themes, and tells you which is which:

Override a template, a layout or a component ​

A Blade theme. Put a view of the same path in the child, and every page uses it — also pages drawn by the parent's own templates. To wrap the parent's view instead of copying it, name it with parent:::

{{-- themes/Ledger/resources/views/layouts/app.blade.php --}}
@extends('parent::layouts.app')

A Vue or React theme. Imports through @/ look in the child first. Put resources/js/Components/Masthead.vue in the child, and every template that imports @/Components/Masthead.vue gets the child's — the parent's templates included. @parent/ always means the parent's file:

<script setup>
import ParentMasthead from '@parent/Components/Masthead.vue';
</script>

<template>
    <ParentMasthead v-bind="$attrs" />
    <p class="masthead-note">Printed in the hills</p>
</template>

The child is built on its own (APP_THEME=Inkwell npx vite build). It has no entry script of its own, so it is built from the parent's entry, with the child's style.css added after the parent's styles.

Just colours and rules. Every bundled theme keeps its colours in CSS variables, so a few lines in resources/style.css go a long way:

:root { --accent: #b45309; }

header.masthead { border-bottom: 6px solid var(--accent); }

What stays the parent's ​

While a child is active, its parent counts as active too, just as WordPress loads both themes' functions.php. Nothing the parent sets up is lost:

• its menu locations and widget zones, with the menus and widgets already in them;
• its post types, with their admin screens in Filament and Nova;
• the data its templates read, and its database tables — activating the child runs the parent's migrations first;
• its translations, which the child's lang/*.json can override line by line;
• its settings on Appearance → Customize. The first time the child is activated, it starts from the parent's values, so the colours and logo the owner picked stay. WordPress resets them instead.

And when the parent is updated with composer update, the child gets every change it did not override.

Coming from a WordPress child theme ​

If you have built WordPress child themes, you already know how this works:

Child themes and SEO ​

A theme switch is the kind of change that worries anyone responsible for search traffic. Moving from a parent theme to its child is about as safe as such a change gets, and the reasons are worth knowing.

Addresses do not change. In kitloom, a page's URL comes from its content and the site's permalink settings, not from the theme. Switching to a child theme leaves every address, every redirect and the sitemap exactly as they were.

Titles, descriptions and structured data do not come from the theme. The seo module puts the meta title, description, canonical address, Open Graph tags and schema.org markup into every page through @siteHead — with the values from Rank Math if the site came from WordPress. Every theme, parent or child, prints the same head.

No extra requests. A Blade child's styles go into the page head with the parent's. A Vue or React child is one build: the parent's code and the child's overrides in a single bundle, with no extra stylesheet or script to load. The colours from Customize are a few CSS variables in the head, not a file.

Previews stay out of the index. A Customize draft is drawn only for the person editing it, marked noindex and kept out of the page cache, so a half-finished colour scheme can never be crawled.

You keep the parent's fixes. Performance and accessibility fixes in a theme update reach a child theme automatically. A forked theme would have to merge them by hand, and in practice often never does.

Before switching a live site, it is still worth checking:

1. Compare the pages that matter. Run the child on a staging copy and compare it with the live site using compare-sites.php: status codes, titles, descriptions, canonical addresses, headings and structured data, address by address.
2. Keep one <h1> per page. If you override a template or a layout, check that you did not drop the page heading or add a second one.
3. Run Lighthouse on a phone on the home page, a post and an archive, and compare with the parent. A child that only changes templates and colours should score the same.
4. Clear the page cache after the switch, from Settings → Cache, so visitors get the new pages at once.

Let an agent do the colours ​

Settings are also open to AI agents. An agent connected to the site sees the active theme, its parent and its settings in describe_site, and changes them with theme_customize, as the user whose key it holds — "make the accent darker and put our logo in the header" without opening the admin. The values go through the same checks as the Customize screen, and the change is in the activity log.

Watch it ​

Two short lessons from the admin, narrated, about a minute and a half each:

Read more ​

• Child Themes — every detail: Blade, Vue and React, packages, what a child inherits.
• Theme Settings (Customize) — for site owners and for theme authors declaring their own settings.
• Theme Catalog — every bundled theme, each with a live demo, all of them ready to be a parent.

What each one is ​

Statamic is a Laravel CMS that has been around since 2012, now at version 6. A new site chooses at install whether content lives in flat files — Markdown and YAML that sit in git with the code — or in a database through the Eloquent Driver. It has its own control panel, the Bard editor with block sets, Live Preview, blueprints with more than 40 field types, forms, and templates in Antlers or Blade. Its addon marketplace is large: e-commerce, SEO, search and many more, some free and some paid. The Core edition is free, with one administrator and one form. Pro adds users and roles, revisions, multi-site and the REST and GraphQL APIs.

kitloom is a Laravel CMS whose storage is the WordPress database. Point it at one and the same site answers at the same URLs, with the same users and their passwords, and with the plugins' data read in the plugins' own formats. There is no WordPress code inside. The models speak Laravel ($post->title, $post->field('price'), Settings::get()), and requests are handled the way WordPress handles them: permalinks, the main query, the template hierarchy. On top of that it brings:

• an admin in Filament 5 or Laravel Nova 5;
• 43 modules, among them a shop, bookings, courses, listings, languages, SEO, redirects and forms;
• 14 themes in Blade, Vue or React;
• an MCP server, so an AI agent can run the site with the rights you give it.

Side by side ​

When Statamic is the better choice ​

• The site is new, and there is no WordPress behind it. Statamic is made for designing content from scratch: you shape blueprints around the site, not around tables someone else designed.
• You want content in git. Flat files mean content goes through the same review and deploy as the code, with no database on the server. kitloom always needs a database.
• The editor matters most. Bard, block sets and Live Preview are what Statamic is known for. kitloom has a visual editor and no block editor.
• It must be free to start. A personal site or a small one with one editor can run on Statamic Core for nothing. kitloom has no free edition: you see everything in the demos first, and there is a 14-day refund.
• You want a mature ecosystem. Fourteen years of addons, answers, tutorials and agencies that know it. kitloom is young.

When kitloom is ​

• An AI agent runs the site, under your control. kitloom ships an MCP server, not an addon. Claude, Cursor or your own agent connects to /mcp, calls describe_site first, then does the work through the same code as the admin: create_content and update_content for posts and pages, upload_media, menu_save, product_save and orders_list, and the tools of SEO, redirects, forms, bookings, courses and translations. Ask it to "draft three posts from these notes and put them in the Guides category", or to "fill in the SEO descriptions of the products that have none". It acts as the user whose key it holds: an author's key writes drafts, a read-only key only reads. The settings that decide who gets in or what code runs on every page are locked, trash_content is the only way out of a record and restore_content brings it back, every change goes into the activity log, and revoking the key stops it at once. See Run your site from Claude or Cursor.
• The site is on WordPress now. Every URL keeps working, users keep their passwords, and the plugins' data keeps working, not just reads: a Contact Form 7 form still sends, WooCommerce orders can still be refunded, Rank Math's redirects still redirect, and Redirection's rules come over with one command. With Statamic that is an import, routes and redirects to rebuild, and plugin behaviour to find addons for. See Moving a WordPress site to Laravel without moving the content.
• You build many sites. One kitloom license at $299 covers every site you own or build for clients. Statamic Pro is $349 for each site.
• The site sells, books or teaches. The shop, bookings, courses and listings are modules of the same product, tested together, with admins in Filament and Nova. In Statamic each is an addon, often from another author and with its own license.
• Your team works in Filament or Nova already. The admin is the one they know, and a module's screens are ordinary Filament resources or Nova resources they can extend.

Try both ​

Statamic's Core is free: install it with Composer from statamic.com and build a site.

For kitloom, open a sandbox in one click, no sign-up: Filament demo or Nova demo. Connect an agent to it from the dashboard and give it something to do. Then follow Migrate from WordPress on your own data, starting read-only. Prices and the refund are on Pricing.

ACF has its own way of storing all of that:

• Field groups and fields are posts of type acf-field-group and acf-field, with their settings in post_content and their location rules ("show this group on books").
• Values sit in postmeta, termmeta or usermeta under the field's name, with a reference beside each one: _{name} holds the field key.
• A repeater keeps its row count under its name, and each row's values as {repeater}_{row}_{sub}. A group's sub fields are {group}_{sub}. Flexible content keeps a list of its row layouts.
• Options pages keep their values in wp_options as options_{name}.

A usual Laravel rebuild turns this into columns or a JSON blob, so someone has to decode the repeater rows, guess the types and write an importer. The editors lose the forms they knew: field groups, location rules, conditional logic. And every template that called get_field() is rewritten against the new schema.

How kitloom reads it ​

kitloom runs on the WordPress database as it is. kitloom/custom-fields uses ACF's layout as its data model. It reads field groups and fields as the plugin stores them, with their location rules and conditional logic. It reads values under the same meta keys and writes them back in the same places. Data stored by Secure Custom Fields, the free fork, is read the same way.

All 37 field types are covered, PRO ones included:

In a theme or any Laravel code, a value is one call:

$post->field('subtitle');               // 'Under the title'
$post->field('slides');                 // [['caption' => 'One'], ['caption' => 'Two']]

use Kitloom\CustomFields\Facades\Fields;

Fields::option('footer_text');          // a value of the options screen

Values come back the way get_field($name, $post, false) returns them: ids stay ids, a repeater is a list of rows, a flexible content row carries acf_fc_layout. Writing goes through the same checks as the form. $post->setField('subtitle', 'Under the title') checks required fields, choices, ranges and conditional logic. Given a user, as in $post->setFields([...], $user), it also refuses a write that user may not make.

Post types and taxonomies made with ACF come along too. kitloom/post-types reads them from their acf-post-type and acf-taxonomy posts, so their archives and single pages answer at the same addresses.

What the admin shows ​

Both admins have a Custom Fields section with Field Groups and Add New Field Group, as in the plugin's menu. A group has its title, fields, location rules, style, label and instruction placement and order. Each field has a label, a name, a type with that type's settings, instructions, required and conditional logic.

• Filament edits a group's fields on the group's form, nested a few levels, as the plugin's editor does. A record's form shows the matching groups in a Custom Fields block on post, term and user forms. A repeater is a Repeater, flexible content a Builder with a block per layout.
• Nova edits fields one by one, because a single form holding every type's settings at every level would weigh megabytes in the browser. A Custom Fields tab on post and taxonomy forms shows the matching groups, with repeaters and flexible content as rows.

In both, image, file and gallery fields open the media library, and wysiwyg fields use the site's visual editor (TinyMCE). The screens need the manage_field_groups permission, which administrators have.

With kitloom/languages, text fields follow the page's language. With kitloom/ai, an agent reads a record's fields with their types and values (fields_get) and sets them (fields_set), checked as the form checks them and only where its user may edit the record.

What changes and what is not covered ​

• The move is one way. Lists and maps kitloom writes are JSON. What ACF serialized is read as it is, never as PHP objects, and becomes JSON on its next save. ACF on WordPress would not read those values back.
• Groups have to be in the database. kitloom reads field groups from their posts. A group that only ever lived in PHP (acf_add_local_field_group()) or in acf-json files is not there to read. GroupWriter takes the array ACF exports to JSON, so such a group can be saved once. Its values are in meta already.
• Not here yet: the options pages screen (the values are stored and read already), ACF blocks, bidirectional relationships, and fields in REST output.
• The plugin's Position setting (after the title, in the side column) has no counterpart on these forms. A group keeps the value it had.
• Plugin code does not run. Templates that call get_field() are rewritten in a kitloom theme with $post->field(). There is no Gutenberg in the admin, and ACF blocks in content are not drawn yet.

Fill and fix fields with an AI agent ​

With kitloom/ai installed, an agent connected to the site knows the field groups before it touches anything: describe_site tells it which groups show on which post types. It reads a record's fields with their types (fields_get) and writes them (fields_set), checked exactly as the edit form checks them, so a wrong value is refused rather than stored. That turns field work that took an afternoon of clicking into one request:

• "Fill the servings and preparation time fields of every recipe from its text."
• "Find the projects whose client field is empty and tell me which they are."
• "Copy the subtitle into the new summary field on every case study, shortened to one sentence."

The agent works as the user whose key it holds and may only change records that user may edit. Every change is in the activity log. How to connect one: Run your site from Claude or Cursor.

Check it on your own site ​

Create a MySQL user that can only read, point kitloom at the live database, and look at your pages. Then run compare-sites.php against both sites. It compares status codes, titles, content and lists address by address, and it flags block comments that reached kitloom's page undrawn, such as ACF blocks. How fields are laid out on a page is the theme's work, so look at your field-heavy templates yourself or let an AI agent go through them. Signing in to the admin needs a copy of the database. The steps are in Migrate from WordPress, and the details of storage are in the Custom Fields guide.

Try it ​

Open a sandbox in one click, with no sign-up: Filament or Nova. When it fits, see Pricing.

ACF rarely comes alone. The same approach covers WooCommerce, Contact Form 7 and Flamingo and Rank Math. An overview is in your plugin data after moving to Laravel.

Here is where the two plugins keep it all:

• A form is a wpcf7_contact_form post. Its template ([text* your-name] and the rest) is in the _form meta. The two mails are in _mail and _mail_2, the texts a visitor sees in _messages, the extra options in _additional_settings, and the hash a shortcode finds it by in _hash.
• A page shows a form with [contact-form-7 id="1a2b3c4"] in its content.
• A message Flamingo kept is a flamingo_inbound post, with a _field_<name> meta per field, plus _from, _subject and _meta (IP, browser, page, date). The form it came from is its flamingo_inbound_channel term.

A usual Laravel rebuild writes the forms again in code or in a form builder. Their mail templates and messages are typed in again by hand. The shortcodes in old pages show up as plain text, and the messages end up in a CSV export, or nowhere.

How kitloom reads it ​

kitloom runs on the WordPress database as it is. kitloom/forms reads forms where Contact Form 7 keeps them and messages where Flamingo keeps them, and needs no table of its own.

• Shortcodes keep working. [contact-form-7 id="…"] finds the form by the start of its hash or by its post ID, and the older [contact-form id="12"] works too. The theme gets the form's template with each form-tag as a field to draw: text, email, URL, telephone, number, date, textarea, select, checkbox, radio, acceptance and submit.
• The same submit address. The form posts to /wp-json/contact-form-7/v1/contact-forms/{id}/feedback, the plugin's own route, and gets the plugin's JSON answer: mail_sent, validation_failed, spam or mail_failed, with the invalid fields.
• Validation checks each field against its tag (required, email, URL, ranges, length, the choices the form offers) and keeps only the form's own fields.
• Messages are stored as Flamingo's, under the form they came from. Old messages are there as before.
• Mail goes out through Laravel's mailer and queue, with the mail-tags filled in: [your-name], [_site_title], [_date], [_url] and the rest.
• Additional settings that change behaviour are followed: skip_mail: on, do_not_store: true, demo_mode: on.

Spam protection is built in. A honeypot is on by default, Cloudflare Turnstile is on once its keys are set, and one address may send 10 submissions a minute by default. The same checks guard the site's comment form.

What the admin shows ​

Filament has a Contact section and Nova a Contact Forms section, each with All Forms, Add New Form, Messages and Settings. A form has Contact Form 7's tabs: Form (the template with its form-tags and the shortcode to copy), Mail and Mail (2), Messages (the texts a visitor sees) and Additional Settings. A new form starts from the plugin's default template and mail.

Messages lists what the forms received, newest first and without spam, with a filter by form. A message opens read-only, with its fields and where it was sent from. Deleting moves it to the trash. Settings holds the spam protection: the honeypot, the limit per minute and the Turnstile keys, with the secret stored encrypted.

Administrators and editors manage forms and read messages (manage_contact_forms, read_contact_messages). Only administrators open Settings.

A few modules plug in here when they are installed:

• kitloom/languages: a form follows the page's language through its Translations tab.
• kitloom/ai: an agent lists forms and messages, changes a form's template and marks a message as spam or not. It deletes nothing.
• kitloom/privacy: WordPress's Export and Erase Personal Data screens include the messages a person sent.

What changes and what is not covered ​

• The move is one way. Arrays are written as JSON and the serialized ones are read too. Contact Form 7 on WordPress would not read the JSON back.
• Some form-tags stay as text. [file] and [quiz] are not drawn, so a form that takes file uploads needs another way to do it. The same goes for tags added by other plugins.
• Spam protection is kitloom's own: the honeypot and Turnstile. Spam services set up for the plugin in WordPress are not read.
• Flamingo's address book (its list of contacts) is not read. The messages are.
• Mail needs Laravel's settings. Set MAIL_* in .env, and run a queue worker when the queue is not sync, or nothing is sent.
• Plugin code does not run. Contact Form 7's own scripts and markup are not used. The theme draws the form from its data. Of the bundled themes, Journal, Bureau, Portfolio, Pantry and Blade draw it; Marketplace and Game Reviews do not.

The complete list of what is read is in the Forms guide.

Read and answer messages with an AI agent ​

Years of Flamingo messages are only useful if someone reads them. With kitloom/ai installed, an agent connected to the site lists the forms (forms_list, form_get), reads their messages (submissions_list), marks spam (submission_spam) and changes a form's template (form_update). You ask:

• "Summarise this week's messages from the contact form and list the ones that ask for a quote."
• "Mark the obvious spam from the last month as spam."
• "Add a phone field to the quote form, optional, after the email."

The agent acts as the user whose key it holds, sees messages only if that user may, and deletes nothing. The mail settings that decide where messages go stay locked to people. How to connect one: Run your site from Claude or Cursor.

Check it on your own site ​

Create a MySQL user that can only read, point kitloom at the live database, and look at your contact pages. Then run compare-sites.php against both sites. Among its checks, it flags any [shortcode] that reached kitloom's page undrawn.

Sending a form writes to the database, so try it on a copy. Load the copy, run php artisan migrate, set the mail settings and send a test message from each form. It should show in Messages, under its form, next to the ones Flamingo kept. The steps are in Migrate from WordPress.

Try it ​

Open a sandbox in one click, with no sign-up: Filament or Nova. When it fits, see Pricing.

Forms are one plugin among several. The same approach covers WooCommerce, ACF fields and Rank Math. An overview is in your plugin data after moving to Laravel.

Every package tests itself ​

kitloom is 167 Composer packages: the core, every module with its Filament and Nova admins, and the themes. 164 of them have a test suite of their own, inside the package. A buyer who installs only some modules still gets their tests, and each package's split repository carries them too.

Together the packages hold 4,412 tests. The largest suites are where the most can go wrong:

The tests come in a few kinds:

• Tests on the WordPress tables. Rows are written exactly as WordPress leaves them, and the tests check that kitloom reads them the same way. They run in an in-memory database, so they are fast.
• Tests on real plugin data. 58 fixture files hold rows exactly as the plugins wrote them: every field type as Secure Custom Fields stores it, Rank Math's serialized redirect rules, WooCommerce's orders, and more. A module is tested against what the plugin really leaves behind, not against what we think it leaves.
• Tests of the whole application. These boot a real kitloom site and send requests to it, as a visitor and as each role.
• Tests of both admins. 102 test files drive Filament screens and 101 drive Nova screens: forms save, lists filter, a role that may not open a screen doesn't see it.
• Tests of the AI agent's tools. 21 modules test their MCP tools directly. On top of that, the agent server's own suite checks the rules every tool shares: a read-only key gets the reading tools only, the writers refuse what the key's user may not do, an author's agent sees only its own drafts, locked settings are reported as locked, and "delete" means the trash. Control over the agent is kitloom's main promise, so it is tested where it is made.
• Tests of the words. 24 packages check that their translation files match the texts in the code, so a new message never ships untranslated.
• Tests of the themes. 14 themes run their demo in a test: every widget zone is filled, every menu location has a menu, and the pages draw.

The skeletons test how it fits together ​

A package can pass on its own and still clash with another one. So the two applications kitloom is installed from, the Filament skeleton and the Nova skeleton, run every package's suite inside a real application, with all the modules installed together. They also have tests of their own: 185 in the Filament skeleton and 143 in the Nova one. Those cover the installer, the wiring between modules and the menus of the admin.

Altogether that is over 4,700 tests. A full check runs them about 7,400 times, because the domain packages run once under each admin: 3,795 test runs in the Filament skeleton and 3,648 in the Nova one. Each suite runs in parallel, a process per CPU core, and takes about a minute. The suites pass on SQLite and on MySQL with the WordPress table prefix, which is how most real sites run.

Before the tests: the repository checks ​

tools/check.sh runs before every release. Before the tests it checks:

• that every kitloom package a package uses is declared in its composer.json;
• that namespaces match file paths;
• that the skeletons' own tests import only the core, so a module's test lives in the module;
• the license fields of every package;
• that every package requires the others at the same version;
• code style with Pint;
• static analysis with PHPStan, where new code may not add a single error to the baseline.

Compared with a real WooCommerce store, on the same data ​

Some behaviour can only be judged next to the original. For the shop, a separate suite runs 29 scenarios on a real WooCommerce store and on kitloom over the same data: coupons, taxes, rounding, shipping, stock. It compares the totals and the orders written. When a number differs, kitloom is fixed, not the scenario.

For your own site, the same idea is a script you run yourself. compare-sites.php reads your WordPress and kitloom address by address and reports every difference in status, redirect, title, canonical tag and content. See Look at your WordPress site in Laravel before you move it.

Every module describes what it does ​

Each package has a README, 166 of them. A module's README is not only for developers. It is the module's How it works page in the admin, so the person who configures a site reads the same text the code was checked against: what each screen does, where the data is kept, which WordPress plugin's data it reads, and what it does not do yet. The module guides at kitloom.dev are built from the same READMEs.

The video lessons test the admin once more ​

The video lessons are not screen recordings made by hand. Each one is a script, 90 of them across 34 modules and themes. It drives the real admin in a browser, as a person would: it signs in, opens the screen, fills the fields and saves, while a voice reads the narration. Every step has to find what it clicks or types into. If a button moved or a screen broke, the lesson stops with an error before any video is made. A check mode plays the same steps without recording, in seconds.

They found real problems. The first time the lessons were written, they turned up 31 admin defects the tests had not caught, such as a date format the settings form refused to save and a counter that showed a stale number. Each one went on the fix list. The 75 videos published today are the screens as they are now, including what an AI agent does through them.

Try it ​

None of this proves kitloom fits your site, but it's why you can check that yourself without risk. Open a sandbox with every module and theme in one click, Filament or Nova. Or look at your own WordPress site through kitloom with a read-only database user, as Migrate from WordPress shows.

What each one is ​

Corcel is a collection of model classes that read the WordPress database, built on Eloquent. Its README describes the intended setup: WordPress stays the back end, the admin panel where posts are written, and you use Laravel (or any PHP project) in front to create routes, views and controllers that fetch WordPress data through Corcel. It covers posts, pages, custom post types, taxonomies, attachments, revisions, options, menus and users. Meta can be read and written (saveMeta(), createMeta()). ACF fields come through a separate corcel/acf package. Shortcodes are registered in config and parsed by a shortcode library. A corcel user provider lets Laravel's Auth validate WordPress users. It is released under the MIT license.

kitloom is a Laravel CMS whose storage is the WordPress database. It has Eloquent models over the same tables, with Laravel names ($post->title, $post->field('price'), Settings::get()), and on top of them:

• request handling the way WordPress does it: permalink settings, rewrite rules, the main query, canonical redirects and the template hierarchy;
• writers (PostWriter, TermWriter, CommentWriter) that make slugs unique, fill dates and check what the acting user may do, with events other code listens to;
• an admin in Filament 5 or Laravel Nova 5;
• about 40 modules, many of which read a plugin's data in that plugin's own format;
• themes in Blade, Vue or React, every page as JSON, and an MCP server for AI agents.

WordPress itself is retired. Its PHP does not run.

Side by side ​

When Corcel is the better choice ​

• You only need to read WordPress data inside your own app. A Laravel application that shows the latest blog posts, a dashboard over WooCommerce data, an app that signs in WordPress users. Corcel is a small dependency for that, and kitloom would be far more than you need.
• WordPress stays the CMS. If editors keep writing in wp-admin and WordPress keeps drawing most of the site, Corcel lets Laravel read alongside it. kitloom is not meant to share a database with a WordPress that keeps writing to it: kitloom writes new arrays as JSON, which WordPress does not read.
• You are not on Laravel. Corcel works in any PHP project. kitloom needs PHP 8.4 and Laravel 13.
• It has to be free and open source. Corcel is MIT. kitloom is a paid, commercial product.

When kitloom is ​

kitloom is for the case where the Laravel app is meant to become the site, and WordPress is meant to go:

• An AI agent runs the site, under your control. kitloom ships an MCP server. Claude, Cursor or your own agent connects to /mcp and does the work: posts and pages, media, menus, SEO and redirects, form messages, the shop's products, orders and sales, bookings, courses, translations. It acts as the user whose key it holds, through the same code as the admin. An author's key writes drafts, a read-only key only reads, and the settings that decide who gets in or what code runs on every page are locked. Nothing is deleted for good, every change is in the activity log, and revoking the key stops it at once. See Run your site from Claude or Cursor.
• Every URL has to keep working. Single posts, pages under pages, category and tag archives, date archives, author pages, pagination, search, the static front page, old slugs. With Corcel each of those is a route and a query you write. kitloom handles them the way WordPress does, from the site's own settings.
• Editors need an admin. Without WordPress, Corcel leaves you with no place to write posts. kitloom brings one: posts, pages, media, menus, widgets, users and roles, plus each module's screens.
• The plugins' data has to keep working, not just be readable. A Contact Form 7 form that still sends, Flamingo messages someone still reads, WooCommerce orders that can be refunded, Rank Math redirects that still redirect, LearnPress students who keep their progress. That is behaviour on top of the data, and in kitloom each of those is a module. Polylang and WPML sites are converted once. What is not read yet, such as Yoast SEO's meta (in progress), is listed on WordPress Compatibility.
• Writes have to follow the rules. Unique slugs, dates, term counts, who may publish what, events that a cache or a search index listen to. In kitloom that is the writers' job, not each controller's.

Corcel and kitloom share a view of the problem: the WordPress schema is fine, it is the code around it that teams want to replace. Corcel replaces the read side. kitloom replaces the whole application.

Rehearsing the move ​

Because kitloom reads the database as it is, you can look at your site through it before deciding anything. Give it a MySQL user that may only SELECT, point it at the live database, and run the comparison script against the WordPress site. It reports, address by address, where status codes, redirects, titles, canonical tags, content or archive lists differ, and where a shortcode reached the page as text. See Look at your WordPress site in Laravel before you move it.

Try both ​

Corcel is on GitHub and installs with Composer.

For kitloom, open a sandbox in one click, no sign-up: Filament demo or Nova demo. Then follow Migrate from WordPress on your own data, starting read-only. Prices and the refund are on Pricing.

So the question is not which one keeps your content. Both do. The question is which part of WordPress you want to leave behind.

What each one is ​

Headless WordPress means WordPress stays as the content back end, with wp-admin, the block editor and its plugins, while a separate application draws the site. That application reads content over an API:

• The WordPress REST API, part of WordPress itself. Its handbook describes it as an interface "for applications to interact with your WordPress site", sending and receiving JSON, and it is also the foundation of the block editor. Public content is available without signing in; private content, custom post types and meta are available with authentication or when they are set to be shown.
• WPGraphQL, a free, open-source plugin that adds a GraphQL schema and API to WordPress. It has a first-party extension that exposes Advanced Custom Fields to the schema.

kitloom is a Laravel CMS whose storage is the WordPress database: wp_posts, wp_postmeta, wp_terms, wp_options, wp_users and the plugins' tables. It handles a request the way WordPress does, so the same URLs answer, and it has its own admin in Filament 5 or Laravel Nova 5. WordPress's PHP no longer runs. kitloom can be headless too: every page also answers as JSON, and kitloom/api serves the basics of WordPress's wp/v2 REST API.

Side by side ​

When headless WordPress is the better choice ​

• Editors must keep wp-admin and Gutenberg. If the people who write the site depend on the block editor and its patterns, headless WordPress keeps that exactly. kitloom has no block editor; blocks already in content are drawn as WordPress draws them, and new content is written in a visual editor.
• The site depends on plugins kitloom does not cover. In headless WordPress every plugin keeps working on the back end. In kitloom a plugin without a module leaves its data in the database and its shortcodes on the page as text.
• You want a way back at any time. Nothing about headless WordPress is one way. kitloom writes new arrays as JSON, which WordPress does not read, so going back means restoring a backup.
• The front end is built on WPGraphQL. kitloom has no GraphQL. A Next.js or Nuxt front that reads WordPress's REST API works with kitloom too (see below), but one written against WPGraphQL's schema would have to move to REST or to kitloom's page JSON first.
• There is no budget for a license. WordPress and WPGraphQL are free.

When kitloom is ​

kitloom fits when the problem is WordPress itself, not only its themes:

• An AI agent runs the site, under your control. kitloom ships an MCP server. Claude, Cursor or your own agent connects to /mcp and does the work: posts and pages, media, menus, SEO and redirects, form messages, the shop's products, orders and sales, bookings, courses, translations. It acts as the user whose key it holds, through the same code as the admin. An author's key writes drafts, a read-only key only reads, and the settings that decide who gets in or what code runs on every page are locked. Nothing is deleted for good, every change is in the activity log, and revoking the key stops it at once. See Run your site from Claude or Cursor.
• You want WordPress off the server. No core and plugin updates to track, no functions.php, no hooks. The code is Laravel: Eloquent models, events, queues, Composer packages and tests. See What Is WordPress Here, What Is Laravel.
• One application instead of two. Headless WordPress means running, securing and deploying WordPress and a separate front end. kitloom is one Laravel app with the admin, the site and the API in it.
• URLs should keep working without writing a router. kitloom reads the permalink settings, category and tag bases, the static front page and the canonical redirect, as WordPress did. A headless front has to reproduce all of that itself.
• You still want a JavaScript front. kitloom's Vue and React themes run on Inertia in the same application. Or ask any address with Accept: application/json and get the page as data: its kind, its template and its parts. See Headless & APIs.
• Your Next.js or Nuxt front can stay. kitloom serves WordPress's REST API at the same address, /wp-json/wp/v2/, with the same routes, parameters and X-WP-Total headers for the core fields, so a decoupled front written against WordPress can point at kitloom instead. Fields that plugins add to the REST answers are not there, and meta is empty, so check what your front reads. See The WordPress REST API.
• The plugin data is covered. ACF and Secure Custom Fields, Contact Form 7 and Flamingo, WooCommerce with HPOS orders, Rank Math, LearnPress, Houzez and Listeo, Slide Anything, Nextend Social Login. Polylang and WPML sites are converted once. Yoast SEO's meta is not read today; support is in progress.

The move itself ​

A headless project has no migration step, which is its appeal. kitloom keeps that risk low a different way: it can draw the site from the live database with a MySQL user that may only SELECT, while WordPress goes on as it is. A script then compares the two sites address by address: status codes, redirects, titles, canonical tags, content, the lists on archives, leftover shortcodes. You switch when the report says what you want it to say. The steps are in Migrate from WordPress, and the reasoning in Moving a WordPress site to Laravel without moving the content.

Try both ​

For headless WordPress, start with the REST API Handbook or WPGraphQL, on a copy of your site.

For kitloom, open a sandbox in one click, no sign-up: Filament demo or Nova demo. Then look at your own site through kitloom with a read-only database user, as Migrate from WordPress describes. Prices and the refund are on Pricing.

• Settings are serialized arrays with on/off switches, in four options: rank-math-options-titles (title and description templates), rank-math-options-general (breadcrumbs, verification codes, robots.txt, redirect settings), rank-math-options-sitemap and rank-math-options-instant-indexing.
• Each record's own head is in meta: rank_math_title, rank_math_description, rank_math_robots, rank_math_canonical_url, rank_math_focus_keyword, rank_math_breadcrumb_title, the Facebook and Twitter fields, and rank_math_primary_category.
• Redirects and the 404 log are tables of their own: rank_math_redirections, rank_math_redirections_cache, rank_math_404_logs. The link counter has rank_math_internal_links and rank_math_internal_meta.

A usual Laravel rebuild adds an SEO package and imports what it can. The templates with their variables (%title% %sep% %sitename%) have to be written again. The sitemaps move to the package's addresses, and the redirect rules go into a new table with different matching rules. Each of those is a chance for a page to answer differently than it did.

How kitloom reads it ​

kitloom runs on the WordPress database as it is, and three modules read Rank Math's data where the plugin keeps it.

kitloom/seo draws the head of every page from the record's meta or its type's template:

• the title, description, robots and canonical, with the page number on page 2 and further;
• Open Graph and Twitter tags, and the webmaster verification codes on the front page;
• schema.org markup for the site's owner, the website with its search, the page, its breadcrumbs, and an article where the type asks for one;
• breadcrumbs with Rank Math's labels and the primary category.

It serves the sitemaps at Rank Math's addresses (/sitemap_index.xml, /{type}-sitemap.xml, /main-sitemap.xsl), robots.txt with its saved text, Google's HTML verification file, and [rank_math_html_sitemap]. Instant indexing sends new and changed addresses to IndexNow and to Google's Indexing API.

kitloom/redirects runs on the redirection tables. Every rule keeps working: exact, contains, starts with, ends with and regex; 301, 302 and 307, or a 410 or 451 status. When several rules match, the newest wins, and hits are counted. The settings are followed too: where a missing page goes, and Auto Post Redirect, which leaves a rule behind when a slug changes. The 404 monitor goes on writing to the same log, in simple or advanced mode.

kitloom/internal-links counts links the way Rank Math's Link Counter does, in the same tables, and lists orphans: published posts nothing links to.

In code, the options are read and written key by key, so the keys a screen does not own stay as they are:

use Kitloom\Seo\RankMath\Options;

app(Options::class)->get(Options::TITLES, 'title_separator', '-');
app(Options::class)->isOn(Options::SITEMAP, 'authors_sitemap');

What the admin shows ​

Both admins, Filament and Nova, have an SEO section laid out like Rank Math's menu:

• General Settings: breadcrumbs, webmaster tools, robots.txt.
• Titles & Meta: global meta, local SEO, the home page, authors, other pages, and a tab per post type and taxonomy.
• Sitemap Settings: what gets a sitemap and how many links a file holds.
• Instant Indexing: submit addresses by hand, choose what is sent on its own, and see what the services answered.

Post and taxonomy forms get an SEO block (a tab in Nova) with the title, description, focus keyword, robots, canonical, breadcrumb title, primary category and social previews. An empty field falls back to the template.

The Redirects section has Redirections (rules with several sources each, bulk activate, deactivate and trash), the 404 Monitor (make a rule from logged rows, clear the log) and Settings. Internal Links has Posts, Links and Orphans, plus a links column in the post lists.

With kitloom/ai installed, an agent reads and changes a record's head meta (seo_get, seo_update), manages redirect rules, and turns 404 log rows into a rule (redirect_from_404). It moves rules to the trash and never deletes them.

What changes and what is not covered ​

• The move is one way. Rank Math's serialized options and redirect sources are read. What kitloom saves is JSON, which Rank Math on WordPress would not read back.
• Rank Math's per-post schema from its Schema Generator is not read. kitloom builds its schema.org graph from the settings.
• Content analysis and the SEO score are not there. The focus keyword is kept and editable.
• Yoast SEO and the Redirection plugin are imported, not read in place. SEO → General → Import from Yoast SEO and Redirects → Settings → Import from Redirection take their data once into Rank Math's keys and tables; from then on the site works with those, and the report names what had no place to go.
• Feeds and WordPress's own sitemap. kitloom sites have no RSS feeds, so /feed/ answers 404. /wp-sitemap.xml is not served; /sitemap_index.xml is.
• A static file wins. A robots.txt or verification file left in public/ is served before kitloom is asked. Remove it.
• Plugin code does not run. All of this is kitloom's own code, written from Rank Math's data model.

The keys, addresses and settings are in the guides for SEO, Redirections and Internal Links.

Keep SEO in shape with an AI agent ​

SEO after a move is a long tail of small jobs, and that is what an agent does well. With kitloom/ai installed, an agent connected to the site reads and writes each record's head meta (seo_get, seo_update), manages redirect rules (redirects_list, redirects_create, redirects_update), reads the 404 log (not_found_list) and turns a missed address into a rule (redirect_from_404). You ask:

• "Which addresses gave 404 since the switch? Redirect the ones that have a new page and list the rest."
• "Write meta descriptions for the posts that have none, under 155 characters."
• "Find the pages whose SEO title is longer than 60 characters and shorten them."

It acts as the user whose key it holds, rules go to the trash rather than away, and every change is in the activity log. How to connect one: Run your site from Claude or Cursor.

Check it on your own site ​

Create a MySQL user that can only read, point kitloom at the live database, and run compare-sites.php against both sites. It takes the addresses from both sites' sitemaps, plus any list you give it. Give it your most visited pages from Search Console. For each address it compares the status code, the redirect target, robots (an error when one side says noindex), the title, description and canonical, the content, and the posts an archive lists.

The read-only look leaves the redirects module out: redirects, like the admin, need a copy of the database that php artisan migrate has run on. Test your redirects there. The steps are in Migrate from WordPress, and what to watch after the switch is in Leaving WordPress without losing your search rankings.

Try it ​

Open a sandbox in one click, with no sign-up: Filament or Nova. When it fits, see Pricing.

SEO data is one part of a site's plugin data. The same approach covers WooCommerce, ACF fields and Contact Form 7 and Flamingo. An overview is in your plugin data after moving to Laravel.

kitloom ships an MCP server for that. Turn it on and the site has an address, https://your-site/mcp. Claude Code, Cursor, Claude Desktop, claude.ai or any other MCP client connects to it with a key, and then runs the site from its chat.

Connecting takes a minute ​

1. In the admin, AI agents → Settings: turn agents on.
2. AI agents → Connect an agent makes a key and shows the settings ready to paste.
3. Paste them into the agent. For Claude Code that is one line:

claude mcp add --transport http kitloom https://your-site/mcp --header "Authorization: Bearer 12|…"

In claude.ai it's a custom connector with the same URL and header. That works on the web, on a phone and in Claude Desktop. Cursor takes the same two values in .cursor/mcp.json. The AI Agents guide has every client.

What the agent can do ​

Its first call is describe_site. It returns the post types and taxonomies, what each one supports, which fields show where, the menu places, and what the key's user may do with each type. Then it has tools for the whole site:

• Content. It can list, read, create and update posts, pages and any post type. It can move records to the trash and restore them, manage terms, upload media from a link or a file, and change settings.
• Seeing the site. resolve_url tells what lives at an address and which template draws it. render_page shows a page as a visitor sees it, as text, HTML or the page's parts as JSON, including a draft's preview.
• The modules' tools. Every installed module adds its own: SEO meta, redirects and the 404 log, menus, widgets, custom fields, forms and their messages, comments, the shop's products, orders, sales and coupons, bookings, courses, listings, translations, broken links, backups, the activity log, Site Health, webhooks and maintenance mode.

So you can ask for whole jobs, not single edits:

• "Fill in the SEO descriptions of the products that have none."
• "Which addresses gave 404 this week? Redirect the ones that have a new page."
• "Find the pages that still mention the old phone number and fix them."
• "Write a draft post about our spring collection, put it in News, and take the cover from this link."
• "How did the shop do this month, and which products sold best?"

The video lessons show a real agent doing these on a demo site. The chat is on the left, and every tool call changes the site on the right.

Exactly the access you give it ​

Handing an agent the keys to a production site is the part that worries people, and it's the part kitloom was designed around:

• The agent works as a user. The key is that user's application password. The agent sees and writes what that user may, through the same code the admin uses. An author's key writes drafts, an editor's publishes, and a read-only key gets only the reading tools.
• Nothing is deleted for good. Records go to the trash and can be restored. Permanent deletion stays with a person in the admin.
• Some settings are out of reach. Secrets and the site address are never shown. Settings that decide who gets in (registration, roles, two-factor), the doors into the site (agents, the REST API) and the code on every page (header scripts, tag manager, analytics) are locked. The agent sees them but can't change them, because a page it reads could try to talk it into it.
• Everything is written down. The activity log records each change under the key's user. Revoking the key stops the agent at once.
• Requests are limited. Each user gets 120 requests a minute by default.

When the site should ask a model itself ​

An agent is your subscription working on the site from outside. Sometimes you want the opposite: a Translate with AI button for an editor who has no AI account. AI Writer does that. You save a provider key on the site once with a monthly budget, the modules that write text get "with AI" buttons, and every question is logged with its cost. Two Ways to Use AI compares the two.

Try it ​

Every demo sandbox comes with a key ready on the dashboard, so you can connect your own Claude or Cursor to a site of your own in a couple of minutes, with no sign-up: Filament demo or Nova demo.

And if your site is on WordPress today, it can move to kitloom with its database as it is, and then an agent can run it.

A usual move to Laravel picks a shop package with its own schema and writes an importer. Each step can lose something: an attribute that does not map, the tax per rate on an order line, a coupon's usage count, a refund, a saved address. Customers reset their passwords, and the importer runs again at the switch for the orders placed meanwhile.

How kitloom reads it ​

kitloom runs on the WordPress database as it is. kitloom/shop takes WooCommerce's tables, meta keys and options as its own data model, so nothing is imported and there is nothing to lose in an importer. A live WooCommerce shop opens in kitloom as it is:

• Products: simple and variable, with categories, tags, global and custom attributes, prices, SKUs, stock, upsells and cross-sells, images and reviews (comments of type review with their rating).
• Orders: from the HPOS tables, with their lines, fees, shipping, taxes per rate, coupons, notes and refunds.
• Customers: read from the orders, one per billing email, guests included. A customer with an account signs in with their WordPress password and finds their orders and saved addresses in My account.
• Coupons, shipping zones and their methods (flat rate, free shipping, local pickup), tax classes and rates, from WooCommerce's own tables.
• Settings: the store's address, where it sells and ships, the checkout options, currency, taxes and the emails, from the woocommerce_* options.
• Offline payments: bank transfer and cash on delivery keep their titles and instructions, read from woocommerce_bacs_settings and woocommerce_cod_settings.

The addresses stay too: /product/…, /product-category/… and /product-tag/…, or the bases in woocommerce_permalinks. The Cart, Checkout and My account pages keep working, whether they hold WooCommerce's shortcodes or its Cart and Checkout blocks. The cart and checkout answer where WooCommerce's Store API lives, under /wp-json/wc/store/v1/.

In code, a product and an order are Eloquent models with plain method names:

if ($product->isVariable()) {
    $product->priceRange();              // ['min' => 18.0, 'max' => 24.0]

    foreach ($product->variations as $variation) {
        $variation->sku();
        $variation->stockQuantity();
    }
}

$order->totalRefunded();

We compare the shop with a real WooCommerce store on the same data: a suite of scenarios (coupons, taxes, shipping, stock) runs the same steps on a WooCommerce store and on kitloom over the same data and compares the totals.

What the admin shows ​

Both admins, Filament and Nova, have one Shop section: Orders, Coupons, Customers, the products with their categories, tags and attributes, Shipping, Shipping classes, Tax rates and Settings. The product form has WooCommerce's Product data tabs: General, Inventory, Shipping, Linked products, Advanced, and Variations for a variable product.

An order's page changes its status, adds notes (for the staff or for the customer), edits the addresses and, while the order is pending payment, on hold or failed, its items. Refund sends the money back through the gateway or records a refund made some other way. Add order takes an order by hand, and Send email sends one of the order's emails again.

The screens ask WooCommerce's own capabilities: edit_shop_orders, manage_woocommerce, edit_products, edit_shop_coupons. WooCommerce's Shop manager role is not created for you; make one on the roles screen if you need it.

With kitloom/ai installed, an AI agent can read and save products, list orders, move an order to another status, leave internal notes and read sales reports, each with the rights of the user it acts as.

What changes and what is not covered ​

• The move is one way. kitloom writes arrays as JSON (_product_attributes, an order line's _line_tax_data, list options), and WooCommerce cannot read those back. kitloom reads WooCommerce's serialized values.
• Orders are read from the HPOS tables only. A shop that still keeps its orders as shop_order posts shows none of them until WooCommerce has moved them to HPOS. Do that in WooCommerce before the move.
• WooCommerce's lookup and analytics tables (wc_product_meta_lookup, wc_order_stats and the rest) are not kept up to date, and the admin has no Analytics screen. An agent's sales reports read from the orders.
• Refunds are given in the admin. An agent may change an order's status, but not to refunded.
• Online payment gateways are set up again in kitloom/payments (Stripe, Paddle, LiqPay, Monobank, WayForPay, Hutko).
• Downloadable products keep their files in meta, and paid orders get their download permissions. The shop does not serve the downloads yet, and the product form does not edit the files.
• Grouped and external products keep their type but cannot go into the cart, as in WooCommerce. An external product's button leads to the site that sells it. A grouped product's page does not list its products yet.
• Shipping methods from other plugins (table rates and the like) are listed but not offered. WooCommerce's Geolocate option is not supported.
• Extensions are plugins of their own. Their data stays in the database, but without a kitloom module nothing uses it.
• Plugin code does not run. The shop is kitloom's own code, written from WooCommerce's data model. The storefront is drawn by a kitloom theme, and there is no Gutenberg.

The full list, table by table, is in the Shop guide.

Run the shop with an AI agent ​

This is where kitloom differs most from a shop you moved by hand. With kitloom/ai installed, Claude, Cursor or your own agent connects to the site and works the shop through its own tools: products and their attributes (products_list, product_save, attribute_save), orders (orders_list, order_get, order_set_status, order_add_note), customers, coupons (coupon_save), and the numbers (sales_report, top_products). You ask in plain words:

• "Which orders have been on hold for more than three days? Add a note to each and list them for me."
• "How did the shop do last month, and which five products sold best?"
• "Write descriptions for the products that have none, as drafts."
• "Make a 10% coupon for the spring collection that ends on Sunday."

You stay in control. The agent acts as the user whose key it holds, so a shop manager's key does what a shop manager may do and a read-only key only reads. A new product is a draft until a person publishes it. A completed or refunded order is not reopened, and refunds stay in the admin. Every change is in the activity log, and revoking the key stops the agent at once. How to connect one: Run your site from Claude or Cursor.

Check it on your own site ​

You can see your shop in kitloom before anything changes. Create a MySQL user that can only read, point kitloom at the live database, and run compare-sites.php against both sites. It compares status codes, titles, canonicals, content and the lists on archive pages, address by address. Products, categories and the Shop page are drawn from the same data at the same moment.

The cart, the checkout and signing in write to the database, so they need a copy of it. Load the copy, run php artisan migrate, sign in with your WordPress password and open a few orders. At the switch, the shop takes no orders until the final copy is in place. The steps are in Migrate from WordPress.

Try it ​

Open a sandbox in one click, with no sign-up: Filament or Nova. When it fits, see Pricing.

The same approach covers the rest of a WooCommerce site's plugins: ACF fields, Contact Form 7 and Flamingo and Rank Math. An overview is in your plugin data after moving to Laravel.

Why the WordPress database ​

Many Laravel teams inherit WordPress sites, and many WordPress developers would rather write Laravel. Between the two sits years of content in one well-known shape. kitloom reads and writes that shape — ACF field groups, Contact Form 7 forms and Flamingo messages, WooCommerce products and orders, Rank Math meta and redirects — in the formats those plugins use. There is no WordPress code inside: no hooks, no wp-admin, just Laravel that understands the data model.

The public site is handled the way WordPress handles it: rewrite rules from the permalink settings, the main query, canonical redirects, the template hierarchy. A theme is Blade, Vue, React — or none, and every page answers JSON.

Filament or Nova ​

The admin is yours to pick. Kitloom for Filament and Kitloom for Nova carry the same core, modules and themes; only the admin differs. Every module — custom fields, forms, the shop, SEO, redirects, languages, bookings and more — is a Composer package with an admin for each.

An agent with exactly the access you give ​

kitloom/ai puts an MCP server on the site. Claude, Cursor or your own agent works with the rights of the user it acts as — an author's agent writes drafts, an editor's publishes — and every change it makes is the one that user could make in the admin. kitloom/ai-writer goes the other way: the site asks a model itself, with your key and a monthly budget, for the "with AI" buttons in the admin.

Try it ​

Each demo gives you a site of your own for a few days — the admin, the content, an agent connected to it:

• Filament demo
• Nova demo

Then Migrate from WordPress shows how a real site comes over, and Pricing what it costs.

Search engines see a site as its addresses and what each one answers. Keep those the same and a move is a non-event for them. kitloom is built so that they stay the same.

The same URLs ​

kitloom does not invent its own routing for content. It reads WordPress's permalink settings (permalink_structure, the category and tag bases, the static front page and posts page) and handles a request the way WordPress does: rewrite rules, the main query, then the template hierarchy. A post at /2019/04/a-post/, a page at /services/web-design/, a category at /category/news/page/2/ all answer at the same address.

The canonical redirect behaves like WordPress's too: ?p=123 and ?page_id=45 lead to the pretty address, and old links to /wp-content/uploads/… get a 301 to where the file lives now.

The same head ​

kitloom/seo works on Rank Math's own data, so nothing has to be re-entered:

• Titles and descriptions: each record's own (rank_math_title, rank_math_description), and the templates for every post type, taxonomy and archive with their variables (%title% %sep% %sitename%).
• Robots and canonical per record, the primary category, breadcrumb titles, Open Graph and Twitter tags.
• schema.org markup: the organisation, the website with its search, breadcrumbs, articles.
• Webmaster verification codes for Google, Bing and the others, and Google's HTML verification file, so Search Console keeps recognising the site.

The same redirects and 404 log ​

kitloom/redirects runs on Rank Math's redirection tables. Every rule the site collected over the years (exact, contains, starts with, regex; 301, 302, 307, 410) keeps working, and the 404 monitor goes on writing to the same log. After the switch it is where you look first for addresses that people or crawlers still ask for.

Sitemaps and robots.txt ​

Sitemaps are served at Rank Math's addresses (/sitemap_index.xml and the files under it) with the same settings: which types and taxonomies are listed, how many links per file. robots.txt keeps its text. Instant indexing sends new and changed addresses to IndexNow and Google's Indexing API, as Rank Math did.

Checking it before the switch ​

The point of keeping everything is that you can verify it. kitloom can draw the site from the live database with a read-only user, and compare-sites.php compares WordPress and kitloom address by address, taking the addresses from both sites' sitemaps and any list you give it. Give it your most visited pages from Search Console. For each address it checks:

• the status code and the redirect target;
• robots, with an error when one side has noindex;
• title, description and canonical;
• the content and, on archives, the posts listed and their order.

An error on any of those is something to fix before the switch, not to discover in Search Console a month later.

Known differences ​

Some things are different on purpose, and it is better to know them up front:

• RSS feeds: kitloom sites have none, so /feed/ answers 404. Redirect it if it had subscribers.
• /wp-sitemap.xml, WordPress's own sitemap, is not served; /sitemap_index.xml is.
• Query addresses other than ?s=, ?p=, ?page_id=, ?paged= and ?cpage= (such as ?cat=3) are not read.
• Yoast SEO is imported once. SEO → General → Import from Yoast SEO (or php artisan seo:import --from=yoast --dry-run to see it first) takes the titles, descriptions, robots, canonicals and social meta of posts, terms and authors, and the templates of Titles & Meta, into Rank Math's keys. Run it before you compare the sites.
• The Redirection plugin's rules are imported once too, from Redirects → Settings → Import from Redirection, with their hits. Rules that ask more than the address (signed in, referrer, browser, cookie) stay behind, and the report lists them with the reason.

After the switch ​

Watch three things in the first days: the 404 log in the admin, Search Console's page indexing report, and the server's error log. Submit the sitemap again in Search Console so it is fetched from the new application, and keep the old WordPress on a backup for a while in case something needs comparing.

An AI agent makes this first week shorter. Connected to the site through kitloom's MCP server, it reads the 404 log (not_found_list), turns a missed address into a redirect (redirect_from_404) and fills or fixes titles and descriptions (seo_update), as the user whose key it holds, with every change in the activity log: "Which addresses gave 404 since the switch? Redirect the ones that have a new page." See Run your site from Claude or Cursor.

The full procedure is in Migrate from WordPress, and what kitloom/seo reads and writes is in its module guide.

Where WordPress migrations really go ​

A WordPress site that has been running for a few years keeps more in its database than its posts:

• Addresses. The permalink structure, category and tag bases, the static front page, pages nested under pages, attachment pages. Every one of them is a URL that search engines and other sites link to.
• Meta. wp_postmeta holds a featured image here, an ACF repeater there, SEO titles, a page template, a sort order, and a few keys from a plugin that was removed in 2017.
• Options. Settings of WordPress and every plugin, much of it as PHP serialize() output, sometimes nested three levels deep.
• Users. Accounts with WordPress's password hashes and roles. Rebuilding means either a password reset for everyone or reimplementing the hashing.
• Plugin tables. WooCommerce orders, Rank Math redirects, form submissions, social logins. Each in a format only its plugin documents.

A rewrite has to export all of that, design new tables for it, write an importer, test the importer on the real database, freeze the content for the final run, and add redirects for every URL that came out different. It is the part that is hard to estimate, and the part most likely to lose something on the way.

Same database, new application ​

kitloom removes that step. It is a Laravel CMS whose storage is the WordPress database: Eloquent models over wp_posts, wp_terms, wp_options, wp_users and the plugins' tables, reading every format WordPress and those plugins wrote, including serialized arrays.

Moving a site is pointing a kitloom application at that database:

DB_CONNECTION=mysql
DB_DATABASE=wordpress
DB_PREFIX=wp_          # $table_prefix from wp-config.php

and running php artisan migrate, which adds kitloom's own tables (sessions, queue, roles, the modules') beside WordPress's and leaves WordPress's tables and rows as they were. The site then has:

• the same posts, pages, media, menus, widgets and comments;
• the same URLs, because kitloom handles a request the way WordPress does: the permalink settings, rewrite rules, the main query, the canonical redirect and the template hierarchy;
• the same users, signing in with their WordPress passwords (both the old phpass hashes and WordPress 6.8's bcrypt);
• the same plugin data, read by modules in the plugins' own formats: custom fields, forms, the shop, SEO, redirects. More on that in a separate post.

What you write from then on is Laravel. The public API speaks Laravel names ($post->title, Settings::get(), Menus::get('main')), writes go through writers that fill slugs and dates and check permissions, and every module is a Composer package with service providers, contracts, events and tests.

What is still work ​

Pointing at the database moves the data, not the look or the custom code:

• The theme. A WordPress theme is PHP for WordPress and does not run. Start from a bundled theme, generate one with every template of the hierarchy, or turn an HTML template into one. Or go headless: every page also answers as JSON.
• Your own code. What functions.php or a site plugin did (a post type, a shortcode, an email) becomes a module. php artisan kitloom:make-module writes one, with both admins and tests, that passes every check as generated.
• Plugins without a module. Their data stays in the database, their shortcodes show as text. The comparison script below finds every page where that happens.
• Files. wp-content/uploads/ is copied to the media disk; old links to /wp-content/uploads/… get a 301 to the new address.

That is real work, but it is work you can estimate, and none of it puts content at risk.

Doing it without risk ​

Because nothing is converted, the move can be rehearsed for as long as you like. kitloom can even draw the site from the live database with a MySQL user that may only SELECT, so WordPress goes on as it is while you look at the same posts through kitloom. A script then compares the two sites address by address: status codes, redirects, titles, canonical tags, content, lists on archives, leftover shortcodes. How that works step by step is in the next post and in the full guide, Migrate from WordPress.

When everything you care about matches, the switch itself is short: freeze content, take the final copy, php artisan migrate --force, sync uploads, point the domain.

After the move: an agent on the site ​

Once the site runs on kitloom, it can be run from a chat. kitloom ships an MCP server, so Claude, Cursor or your own agent connects to the site and works with every module: it fixes the 404s the switch left behind, writes the missing meta descriptions, answers form messages, reads the day's orders. It acts as the user whose key it holds, through the same code as the admin. Locked settings stay with people, nothing is deleted for good, and every change is in the activity log. See Run your site from Claude or Cursor.

Try it ​

Open a sandbox with demo content in one click, Filament or Nova, or go straight to your own site with Migrate from WordPress. What kitloom reads from WordPress and its plugins, and what it does not, is on WordPress Compatibility.

kitloom's approach is that a plugin's data is the module's data model. A module that replaces a plugin reads the plugin's tables, options and meta keys as the plugin left them, and writes them back in the same places. Nothing is imported, so nothing is lost in an importer.

Custom fields: ACF and Secure Custom Fields ​

kitloom/custom-fields reads ACF's field groups and fields as they are stored, as acf-field-group and acf-field posts, with their location rules. Values stay under the field's meta key with ACF's _{name} reference beside it, and options pages stay options_{name}. All of ACF's field types are covered, repeaters and flexible content included.

In code a value is $post->field('price'), and a theme gets the fields with the record. Post types and taxonomies made with ACF come along too, through kitloom/post-types, so their archives and single pages answer at the same addresses.

Forms: Contact Form 7 and Flamingo ​

kitloom/forms reads each Contact Form 7 form from its wpcf7_contact_form post: the form markup, both mails, the messages and the additional settings. A [contact-form-7 id="…"] shortcode in a page keeps working. Messages Flamingo kept are there as before, filed under the form they came from, and new ones are added the same way. Spam protection (a honeypot and Cloudflare Turnstile) is built in.

The shop: WooCommerce ​

kitloom/shop reads WooCommerce's products (simple and variable, with their categories, tags, attributes, prices, SKUs and stock) and its orders from the HPOS tables (wc_orders, wc_order_addresses, woocommerce_order_items and the rest), plus the woocommerce_* settings. A customer signs in with their password and sees their order history. The cart, checkout and My account are drawn by the theme from the shop's own parts.

We compare it with a real WooCommerce store on the same data: a suite of scenarios (coupons, taxes, shipping, stock) runs the same steps on a WooCommerce store and on kitloom over the same data and compares the totals.

SEO and redirects: Rank Math ​

kitloom/seo works on Rank Math's options and meta: title and description templates with their %title% %sep% %sitename% variables, each record's own title, description, robots and canonical, the primary category, breadcrumbs, sitemap settings and the verification codes. kitloom/redirects uses Rank Math's own redirection and 404-log tables, so every rule the site had keeps redirecting. How that keeps rankings intact is in a post of its own.

And the rest ​

• Menus, widgets, page templates, synced patterns: WordPress's own storage, read by the core.
• Slide Anything sliders, with their shortcodes: kitloom/slider.
• Nextend Social Login: linked Google and GitHub accounts, kitloom/social-accounts.
• Rank Math's link counter: kitloom/internal-links.
• Analytics, tag manager, ad pixels, cookie consent (Site Kit, MonsterInsights, GTM4WP, PixelYourSite, Complianz, CookieYes and others): an Import button on the module's settings page takes their settings once.

The complete table, with every option and meta key, is on WordPress Compatibility.

Each module comes with tools for an AI agent ​

The plugins' data is not only kept, it can be worked from a chat. Every module above gives kitloom's MCP server tools of its own: custom fields (fields_get, fields_set), forms and their messages, the shop's products, orders, coupons and sales reports, SEO meta, redirects and the 404 log, sliders, menus and widgets. Claude, Cursor or your own agent uses them with the rights of the user whose key it holds, and every change is in the activity log. See Run your site from Claude or Cursor.

What a module does not cover ​

Honesty matters more here than anywhere:

• A plugin without a module keeps only its data. Its tables stay in the database, its shortcodes reach the page as text. The comparison script lists every page where that happens, so you know before the switch.
• Yoast SEO and the Redirection plugin are imported, not read in place. Rank Math's data is read as it is. Yoast's titles, descriptions, robots, canonicals and social meta, and Redirection's rules with their hits, are taken once into Rank Math's keys and tables, with a button in the admin or php artisan seo:import --from=yoast and php artisan redirects:import. The report names what had no place to go: Yoast's scores and Premium redirects, Redirection rules that ask more than the address.
• Plugin code does not run. The data is read by kitloom's own code, rewritten from the data model, not copied from the plugin.

When a plugin you depend on has no module, you can write one: WordPress Compatibility shows how to study what the plugin stores, keep its tables and keys, read both serialized and JSON values, and test against rows exactly as the plugin wrote them. php artisan kitloom:make-module gives you the package, both admins and the tests to start from.

This works because kitloom runs on WordPress's database as it is. If the new application reads the same tables, it can read them while WordPress is still the site.

1. A user that can only read ​

Create a MySQL user that may read the WordPress database and change nothing:

CREATE USER 'kitloom_read'@'%' IDENTIFIED BY 'a-long-random-password';
GRANT SELECT ON wordpress.* TO 'kitloom_read'@'%';

It is safe to hand to whoever does the work: an agency, a freelancer, an AI agent. If the host has a read replica, point it there.

2. An application that writes nothing ​

Create a kitloom application and point it at that database, with everything kitloom would normally keep in tables of its own moved off the database:

DB_CONNECTION=mysql
DB_HOST=db.example.com
DB_DATABASE=wordpress
DB_USERNAME=kitloom_read
DB_PREFIX=wp_

SESSION_DRIVER=array
CACHE_STORE=array
QUEUE_CONNECTION=sync
PULSE_ENABLED=false

# Images straight from the live site, so nothing is copied
MEDIA_UPLOADS_URL=https://example.com/wp-content/uploads

Run php artisan serve and open it. Every public address works: posts, pages, archives, search, a missing page, robots.txt, the sitemaps, the REST API under /wp-json/, drawn by the kitloom theme you picked. Change something in wp-admin and it shows in kitloom at once, because both read the same rows.

What waits for later is everything that writes (the admin, forms, the cart), since that needs kitloom's own tables. The details, including the one module to leave out in this mode, are in Migrate from WordPress.

3. Compare, address by address ​

compare-sites.php is one PHP file with no dependencies. It sends only GET requests to both sites and writes down what differs:

curl -O https://kitloom.dev/migrate/compare-sites.php
php compare-sites.php --old=https://example.com --new=http://localhost:8000 --save-html

It takes the addresses from both sites' sitemaps, a few probes and any list you give it (the most visited pages from Analytics or Search Console are a good one), and checks for each:

• the status code and where a redirect leads;
• robots (an error when one side says noindex), title, description and canonical;
• the record's content, as the words a visitor reads, from WordPress's REST API against kitloom's page JSON by the same ID;
• leftovers: [shortcodes] and block comments that reached the page undrawn, the sign of a plugin with no kitloom module;
• on archives, the blog and search, whether the same posts are listed in the same order.

The report, compare-report/report.md, groups everything by check and lists the worst addresses first. Since both sites read the same data at the same moment, every difference is kitloom's, never the content's. Fix, run again, until only what you accept is left. The exit code is 1 while there are errors, so the run can sit in CI.

4. Let an agent look at it ​

A script reads markup. A gallery that does not open, a menu in the wrong order or a price without its currency needs eyes. An agent with a browser (Claude Code, Cursor, anything with a Playwright MCP server) does that pass well. The guide has a ready prompt that keeps it read-only on the live site, makes it group findings by cause rather than by page, and asks for a report you can act on.

5. Then a copy, then the switch ​

For the admin, forms and redirects, take a copy of the database with the same read-only user (mysqldump --single-transaction), run php artisan migrate on the copy and sign in with your WordPress email and password. Rehearse the switch there: sync the uploads, save a few posts, send the contact form, place a test order, time it all. The switch itself is the same steps on the real database.

At no point before the last step does the live site change. That is the difference between a migration you rehearse and one you hope for.

The whole procedure, with every command: Migrate from WordPress.

Why we built a WordPress-shaped CMS for Laravel ​

If you write Laravel for a living, you have probably been handed a WordPress site. The client wants "the same site, but in Laravel". It has ten years of posts, an ACF setup somebody built in 2016, a WooCommerce shop, a contact form whose messages the sales team still reads, and URLs that Google has known for a decade.

The code is the easy part. The data is what eats the budget.

The itch ​

Every time, a rewrite ran into the same wall. We had to design new tables for content that already had a perfectly good shape, then write an importer for wp_postmeta and for options stored as PHP serialize(). After that came ACF's field references, WooCommerce's order tables, and the redirect rules from an SEO plugin. Then we had to test that importer on the real database, freeze the content, run it one last time, and chase the URLs that came out different.

At some point the obvious question came up: why move the data at all? WordPress's schema has held up for twenty years. What people want to leave is the code around it, not wp_posts.

What we considered ​

• Rewrite and import. The usual way. It works, but it is a project of its own, and the import is the part that loses things.
• Headless WordPress. It keeps the data and puts Laravel or a JS front in front of the REST API. But WordPress, its plugins and their updates are all still there.
• Eloquent models over the WordPress tables. There are packages that do this, and they are a good start. But a site is more than models. It also needs permalinks, the main query, canonical redirects, the template hierarchy, sign-in with WordPress passwords, roles, menus and widgets, and the plugins' data.
• An existing Laravel CMS. Statamic, Filament-based CMSs and others are good products with their own content models. For a WordPress site, that means the import again (kitloom vs Statamic goes through where each one fits).

What we built ​

kitloom is a Laravel CMS whose storage is the WordPress database. Point it at one and run php artisan migrate. That adds kitloom's own tables and leaves WordPress's rows as they are. The same site then answers at the same URLs, and users sign in with the passwords they had.

Inside, there is no WordPress code: no hooks, no wp-admin. It is ordinary Laravel:

• Eloquent models over the WordPress tables. The models speak Laravel names ($post->title, $post->field('price'), Settings::get()). Writers fill slugs and dates and check permissions, and events fire on publish, trash and delete.
• Requests handled the way WordPress handles them. Rewrite rules come from the permalink settings, then the main query and the template hierarchy. The themes are Blade, Vue or React through Inertia. Every page can also answer as JSON or Markdown.
• Modules that read plugins' data in the plugins' own formats. ACF for custom fields, Contact Form 7 and Flamingo for forms, WooCommerce for the shop, Rank Math for SEO and redirects, and others.
• Two admins, Filament or Nova, with the same core and modules. Every module is a Composer package with an admin for each.
• An MCP server, so an AI agent can work on the site. The agent has the rights of the user it acts as.

The hard parts ​

• Serialized PHP everywhere. kitloom reads it (never as objects) and writes JSON from then on. That is also why the move is one way: WordPress does not read the JSON back.
• The edges of WordPress's URL handling. Pages nested under pages, attachment pages and paged archives behave as WordPress does, and so does the canonical 301 from ?p=123. We compare kitloom with WordPress page by page on the same database, and that script is now part of the migration guide.
• Plugin formats that are documented nowhere but in the plugin's code. We rewrote each one from the data model, without copying plugin code. We studied what the plugin writes, saved those rows as fixtures, and tested against them.
• Not becoming WordPress. It is tempting to rebuild hooks. We used Laravel's own tools instead: contracts, container tags and events.

What it is not ​

• It does not run WordPress plugins or themes. A plugin's data comes along when there is a module for it.
• It has no block editor. Existing blocks are drawn, and new content is written in a visual editor.
• It is not a CMS with no WordPress in it. The tables are WordPress's, and we say so on the home page.
• It is not free. kitloom is a paid product, sold once with a year of updates and a 14-day refund. There are sandboxes to try it first. That pays for maintaining dozens of modules against plugins' data formats.

Try it, and tell us where it breaks ​

• A sandbox with demo content in one click: Filament or Nova.
• On your own WordPress database, read-only, without touching the live site: Migrate from WordPress.

We are most interested in the sites where it does not work yet, such as a plugin you depend on or a URL that answers differently. That is how the next module gets chosen.

1. An AI agent does the work, under your control ​

kitloom/ai puts an MCP server on the site. Claude, Cursor or your own agent connects to /mcp, calls describe_site, and then does the work through the same code as the admin: create_content for posts and pages, upload_media, menu_save, redirect_from_404, product_save and orders_list — every installed module brings its own tools. Ask it "which addresses gave 404 this week? Redirect the ones that have a new page", or "fill in the SEO descriptions of the products that have none".

It acts as the user whose key it holds: an author's key writes drafts, a read-only key only reads, and nothing it does is beyond what that user could do in the admin. The settings that decide who gets in or what code runs on every page are locked, nothing is deleted for good — it goes to the trash — every change is in the activity log, and revoking the key stops it at once. Run your site from Claude or Cursor shows it at work.

2. Start from your WordPress site, or a new one ​

Bring the site you have. kitloom runs on the WordPress database. Not an import, not a copy: the same wp_posts, the same options, the same users with the passwords they already have, the same plugin tables. The site answers at the same URLs, so search engines and old links don't notice the move.

You don't have to take that on faith either. kitloom can draw your live site from its database with a read-only user, and a script compares both sites page by page — the rehearsal happens before anything is switched.

Or start a new one. php artisan kitloom:install asks which modules the site needs, a theme fills it with demo content, and no WordPress is installed. The content takes WordPress's shape — posts, pages, terms, menus, users — which editors know from the first day and AI models know well, and where a client's old WordPress site fits in later.

3. It is Laravel, with nothing hidden underneath ​

There is no WordPress code inside: no hooks, no wp-admin, no globals. A post is an Eloquent model ($post->title, $post->field('price')), an option is Settings::get(), a change to content fires a Laravel event. Every module is a Composer package with its own tests.

So your team works the way it already does — Composer, PHPUnit, queues, Octane, your deploy pipeline — and the next developer who opens the project recognises what they see.

4. Fast, and clean by Google's measure ​

On the same database, kitloom serves a page faster than WordPress: 14.7 ms against 19.6 ms across thirteen pages, and 25 ms against 43 ms once WordPress carries the plugins most sites run. The benchmark shows every number and how it was taken.

Speed on the server is half of it. The other half is what a visitor's browser gets. Here is Keystone, one of the themes that come with kitloom, measured by Google Lighthouse on a public demo — as a phone on a slow connection sees it, and on a desktop:

On a phone: ninety-nine for performance and one hundred for accessibility, best practices and SEO, with the first text in about a second and nothing shifting while the page loads. On a desktop, one hundred for all four. That is the theme as it ships, not a page made for the video: canonical URLs, meta tags and structured data come from the core and the SEO module, images that will be the largest thing on screen are fetched first, a map loads only when the visitor scrolls to it, and contrast, link names and heading order are part of how a theme is checked. Open a demo, press Lighthouse in Chrome's developer tools, and see what you get. The benchmarks page has the other pages of the theme, how it was measured and how to measure it yourself.

5. Filament or Nova — your call ​

The admin is the one your team already knows. Kitloom for Filament and Kitloom for Nova carry the same core, the same modules and the same themes; only the admin differs. Every module brings a screen for each.

6. Plugins become modules, and keep their data ​

A WordPress site is as much its plugins' data as its posts. kitloom's modules read that data in the plugins' own formats: ACF fields, Contact Form 7 forms and Flamingo messages, WooCommerce products and orders, Rank Math's SEO settings and redirects. Here is what comes over and how.

Around them are the modules a Laravel site needs anyway — languages, bookings, courses, listings, backups, two-factor sign-in, webhooks, a cookie banner that holds trackers back — each installed with Composer and switched off with one setting.

7. You see all of it before you pay ​

There is no free tier and no trial clock, because there is nothing held back. One click gives you a Filament or Nova sandbox of your own with every module and theme — no sign-up, no card. The documentation is all public, with video lessons for the modules. And if kitloom doesn't fit once you have it on your own site, you get the full amount back within 14 days, no reason needed. Why it works this way.

What kitloom is not ​

To be fair about it: kitloom doesn't run WordPress plugins or themes — a plugin's data comes along when there is a module for it. It has no block editor; existing blocks are drawn, and new content is written in a visual editor. And the move is one way: kitloom writes arrays as JSON, which WordPress doesn't read back.

If that still sounds like your next site, open a demo — it takes one click.

What I don't want to do to you ​

You know how it goes. You open an app because there's something you need to get done right now. You sign up, log in, spend your time and go through step after step, and you still haven't worked out whether you need this app at all. Then, in the middle of the job, it stops and asks you to pay a large sum for a whole year up front.

And most of the time you pay. You came to finish something, you've already put the time in, so you buy it on the spot. A while later you're wondering why you needed it.

That bothers me every time it happens to me. I don't mind paying for something once I know I need it. What I mind is paying before I can tell.

So everything is visible first ​

You can see everything kitloom does before you pay anything:

• The demos. One click gives you a Filament or Nova sandbox of your own with every module and theme. You don't sign up or give an email address, and you don't need a card.
• The documentation, all of it: how the core works, every module's guide with its video lessons, and how to write a theme or a module.

And then the decision is yours ​

I could have made a free basic edition, but then I'd be deciding which parts of kitloom to hold back so you'd want the rest. I'd rather sell the whole thing and trust the person buying it.

So here's how it works. You buy kitloom, install it on your own site and your own WordPress database, read the code and build something with it. If it doesn't do what you expected, or you don't like how it's written, or it just doesn't fit how you see your application, write to us within 14 days and you get the full amount back. You don't have to give a reason, and nobody will try to argue you out of it. The terms are on the Refunds page.

I'm completely fine with refunds. I'm not hiding them in small print or hoping nobody asks.

What I'm doing is leaving the judgement with you, the developer. After you've used kitloom on your own project, ask yourself honestly whether it was worth what you paid. If it wasn't, ask for your money back, and you'll get it.

The owner of kitloom

For a five-page brochure site that is an afternoon. For a site with ten years of posts, custom fields, a shop and a contact form whose messages someone still reads, the migration is the project, and it is the reason many teams stay on WordPress longer than they want to.

kitloom takes the other road. It is a CMS on Laravel that runs on the WordPress database as it is: wp_posts, wp_postmeta, wp_options, the terms, the users, and the tables of the plugins the site already has. Nothing is exported and nothing is converted. A new application is put in front of the same tables.

Why people leave WordPress ​

Usually not because of the content model. Posts, pages, terms and meta have held up for twenty years. The reasons are more often:

• The code. Hooks reaching into hooks, a functions.php nobody wants to touch, plugins that each bring their own way of doing things. A Laravel team would rather write services, Eloquent models, queues and tests.
• The plugin count. Many business sites run on dozens of plugins, each with its own updates, its own security history and its own idea of the admin.
• Hiring and tooling. A team that already writes Laravel would rather not keep a second stack for one site, and static analysis, CI and a real test suite come naturally there.
• The front end. A Vue or React front, or a site that is also an API for an app, is first-class in Laravel and an afterthought in a WordPress theme.

None of these is a reason to throw the content away.

What stays the same ​

Point kitloom at the database and the site keeps:

• Its content: posts, pages, attachments, revisions, categories, tags, custom taxonomies, comments.
• Its addresses: kitloom reads the permalink settings and handles a request the way WordPress does: rewrite rules, the main query, the canonical redirect, the template hierarchy. /2019/04/a-post/ is still /2019/04/a-post/.
• Its people: users sign in with the password they had, because WordPress's password hashes are read as WordPress wrote them, and their roles come along.
• Its plugins' data: ACF field groups and values, Contact Form 7 forms and Flamingo messages, WooCommerce products and orders, Rank Math's titles, sitemaps and redirects, among others. Each is read by a kitloom module in the plugin's own format. The full list is on WordPress Compatibility.
• Its settings: site name, reading settings, menus and their locations, widgets.

What changes ​

Everything that is code:

• No WordPress PHP. No hooks, no wp-admin, no plugins or themes from WordPress. The admin is Filament or Laravel Nova, and every module is a Composer package with an admin for each.
• Laravel all the way down. Eloquent models over the WordPress tables ($post->title, not post_title), events, queues, Horizon, Pulse, Pint, PHPStan, PHPUnit.
• Any front end. A theme in Blade, Vue or React, or none: every page also answers as JSON, so the front can be anything. See Headless & APIs.
• An AI agent runs the site, under your control. kitloom ships an MCP server. Claude, Cursor or your own agent connects to /mcp and does the work: posts and pages, media, menus, SEO and redirects, form messages, the shop's products, orders and sales, bookings, courses, translations. It acts as the user whose key it holds, through the same code as the admin. An author's key writes drafts, a read-only key only reads, and the settings that decide who gets in or what code runs on every page are locked. Nothing is deleted for good, every change is in the activity log, and revoking the key stops it at once. See Run your site from Claude or Cursor.
• Speed. On the same database the bare core answers faster than a bare WordPress, and the whole kitloom with every module faster than WordPress running three popular plugins (SEO, forms and a shop). The setup and the numbers are on Benchmarks, including where WordPress is still ahead (search).

What you give up ​

An alternative is only useful if its trade-offs are clear:

• WordPress plugins do not run. A plugin's data comes along when kitloom has a module for it. A plugin without a module leaves its data in the database and its shortcodes on the page as text, until a module or a replacement takes over.
• Your WordPress theme does not run. It is PHP written for WordPress. You take a bundled theme, generate one, or build one from an HTML template.
• No block editor. Blocks already in content are drawn as WordPress draws them; editors write in a visual editor, not Gutenberg.
• The move is one way. kitloom writes new arrays as JSON, which WordPress does not read. Going back means restoring your backup.
• It is WordPress-shaped. The tables are WordPress's, and a type's model extends Post. If you want a Laravel CMS with no WordPress in it at all, kitloom is not it, and What Is WordPress Here says so in detail.

Who it is for ​

kitloom fits when the site's content already lives in WordPress, or in that shape, and the team wants Laravel for everything around it: an agency inheriting WordPress sites, a company whose developers moved to Laravel, a WooCommerce shop that has outgrown its plugin stack, a publisher who wants an API and a modern front without a re-platforming project.

The quickest way to judge it is on your own data. Migrate from WordPress shows how to look at your site through kitloom with a read-only database user, so the live site is not touched, and how to compare the two page by page. Or open a sandbox first: Filament demo, Nova demo.

The setup ​

A fresh WordPress filled with the Theme Unit Test data and generated content — 10,000 posts in 118 categories, 50,000 comments, 20 authors — exported as WXR and imported into an empty kitloom. Both sites read the same records from one MySQL 8 server.

Four sites took part:

• WordPress with its default theme and no plugins;
• WordPress + plugins: Yoast SEO, Contact Form 7 and WooCommerce, as many WordPress sites run;
• kitloom, lean: what a bare WordPress has — posts, pages, media, menus, widgets, comments, the REST API, a form module, the Blade theme;
• kitloom, full: the whole Filament skeleton, about a hundred packages with every module and the admin.

Each runs PHP 8.4 under PHP-FPM with OPcache, behind nginx, and each page was loaded for ten seconds over one connection and then over eight, in three rounds. No page cache on either side for the main numbers: every page is built from the database.

The numbers ​

The median time of one page over one connection, and pages per second over eight:

It ran on one laptop (an M4 Pro under Docker Desktop), so read the ratios rather than the milliseconds: the rounds were 3–9 % apart, and the ratios held across runs.

What stands out ​

Like for like, kitloom is faster. With what a bare WordPress has, kitloom answers in 14.7 ms against 19.6 ms across the thirteen pages and serves 1.2 times as many pages a second. A post runs 18 SQL queries against WordPress's 25: menus are built only for the places a page draws them, so a migrated site with a dozen forgotten menus does not pay for them.

Plugins cost WordPress more than packages cost kitloom. Three plugins more than double WordPress's time for a post, 13 → 31 ms. Everything the full kitloom skeleton adds to the lean one — about ninety packages and the admin — costs about 10 ms a page, most of it starting them. The full kitloom still comes in at 25 ms against 43 ms for WordPress with its plugins, 1.6 times as many pages a second.

WordPress still wins search. 43 ms against 54–64 ms. Both look for the words with LIKE '%…%' in every post's HTML, which no index can serve. WordPress reads the posts once and asks MySQL how many rows it found; kitloom reads them twice, once to count the results for the page links and once for the page, the way Laravel paginates on every database it supports. On ten thousand posts that is the whole difference; a site with a few thousand pays a few milliseconds, and a large one that needs fast search gives kitloom/search Meilisearch or Typesense.

Redis helps WordPress, not kitloom. WordPress keeps posts, terms and query results in its object cache, so Redis takes most of its SQL away and makes search three times faster. kitloom reads only its settings and a few small lists from the cache: with Redis its pages came out the same as with files.

With a page cache ​

Both sides can keep finished pages. WordPress with a page-cache plugin and kitloom with its stored page sent before Laravel starts come back in the same 0.2 ms — around 20,000 pages a second. Sent through Laravel instead, a stored kitloom page costs the framework's start: 1.4 ms on the lean site, 7 ms on the full skeleton. kitloom also keeps search results, which the plugin does not.

Try it on your own data ​

Numbers from someone else's laptop are a starting point. The benchmarks page has every table, the versions, the content and how each figure was taken, and the advice for a live site: php artisan optimize on every deploy, the page cache on, and the modules a site does not use left out.

Or open a Filament or Nova demo and click around a kitloom site of your own.