Download the PHP package shipfast/live-edit without Composer

ShipFast Live Edit

In-place editing for sites that are already built. Tag the elements, and the people who own the site edit text, images, links, icons, styles and lists on the page itself. There are no admin screens for content, because the page is the admin screen.

It runs on five kinds of site, through adapters over one engine:

What has actually been driven through a browser on a real site, adapter by adapter, is in ADAPTERS.md. What does not work yet, and whether it is being fixed or lived with, is in LIMITATIONS.md.

The rest of this file is the Laravel adapter. The others have their own instructions in the console when a site is registered.

What the Laravel package provides

• Endpoints (ShipFast\LiveEdit\Http\Controllers\LiveEditController) for settings, records (create / update / move / delete), images (replace / alt / title / remove), styles and undo — all whitelist-validated from your config.
• Models ElementStyle (per-element visual overrides) and EditRevision (undo history), with migrations.
• RichText — XSS-safe markdown-lite (**bold**, *italic*, [text](url)).
• live-edit:prune-orphans — deletes uploaded images nothing references.
• The editor itself — drawer, toolbar, live preview as you type, undo and redo, the image picker, publish review and preview mode. Served by the package at /live-edit/runtime.js and loaded by @liveEdit; you never import or build it.

Install

Two steps.

Then one line in your layout's <head>:

That is the whole integration. The directive serves the editor from this package, so there is nothing to import, nothing to publish, and nothing to add to your asset build.

Do not import the editor in app.js. Bundling it compiles a copy of the engine into your site's assets, which means an engine fix reaches you only when you rebuild and redeploy — and until you do, the copy in your bundle and the one composer installed are different versions of the same thing, with nothing to say so. @liveEdit loads the installed package, so updating it is composer update.

Signing in

The package serves its own sign-in at /live-edit/sign-in. Link to it from wherever suits the site — a footer link is usual:

It authenticates against your users, with your guard and your password hashes. The package stores no credential, issues none, and has no user of its own to reset or recover. Its one requirement of a host is a users table and an auth provider, which a Laravel application has whether or not it has ever had a login screen.

That matters because most sites this is installed on have no admin panel. Requiring one would make "install it and add a line" untrue for exactly the sites it is for.

Signing out is POST /live-edit/sign-out.

The three values a site is given

APP_KEY is public. It is printed into the source of every page it edits, so it is not a secret and its name should not suggest one. A site whose own server talks to the service, to let its people in or to publish, also sets LIVE_EDIT_SECRET_KEY; a Laravel or WordPress install that keeps its own content never calls that API and never needs one.

These were LIVE_EDIT_SITE and LIVE_EDIT_KEY, and before that the LIVE_EDIT_LICENCE_* and LIVE_EDIT_CLOUD_* pairs. Every one of them is still read, so an upgrade changes nothing on a site already running. An installation still using a retired name says so in its log once a day.

Three integrations, three answers

Where the content lives, and where the person proves who they are, are two different questions. Forcing one answer onto every technology is what makes this kind of product awkward to install.

Laravel and WordPress already have users, permissions and somewhere to put words. Neither needs us to duplicate any of it, so we do not: the editor is a better way to write the words, and they stay where they were.

A site with none of that, built as static HTML or generated by a framework, has nothing to borrow. That is what the cloud content model is for.

Set LIVE_EDIT_SIGN_IN to host, service, or either (the default, and the only value that cannot lock somebody out of a site that worked yesterday). A host that defines the live-edit gate itself decides on its own and this is ignored.

Who may edit

The editor appears for whoever passes the live-edit gate. Define it:

Nobody else is served the editor at all, so a visitor's page is the page they would have had without this package.

Optional

The defaults work. Publish the config when you want to declare your own setting keys, models or locales.

Configure

Everything editable is declared in config/live-edit.php:

• setting_model — the Eloquent model backing key/value settings.
• settings / images — setting keys editable as text / as images.
• models — collections (class, fields, creatable, deletable, image_field, defaults).
• style_props, select_options, icon_options, rich_settings, rich_fields — typed field metadata.
• middleware — guards the endpoints (default ['web', 'auth', 'can:live-edit']).
• after_save — invoked after every write, e.g. to bust a content cache.

Define the live-edit gate (or your own middleware) to control who can edit.

Tagging

Two ways, and they mix. Name the handful of things that matter and let the rest be found.

Named keys are what the examples below use. They are stable: the key says what the element is for, so the client's words survive a developer rewriting the sentence around them. Worth writing for anything important.

Derived keys need no attributes at all. Set LIVE_EDIT_AUTO_TAG=true and the editable parts of a page are found as it is served — only for somebody the gate allows, so a visitor's page is never parsed or rewritten. The trade is that a derived key is a signature of the current wording: change that sentence in the template and the client's edit is orphaned. Use it to make a site editable without touching its templates, which is the only option for a site somebody bought rather than built.

A page that already carries data-edit keeps its own keys untouched.

Onboarding an existing site — the auto-mapper

Point the scanner at a rendered page to get a tagging plan, or apply it:

Add --ai to refine the mechanical keys into semantic ones with an LLM:

Set LIVE_EDIT_MAPPER_AI=true and OPENAI_API_KEY (provider-agnostic — override LIVE_EDIT_AI_ENDPOINT / LIVE_EDIT_AI_MODEL for a different model). The scanner still does all the detection; the LLM only renames/labels the elements it found (never adds or drops any), and any failure falls back to the deterministic result. The API key is read from the environment.

--apply writes text, image and link tags directly onto the recognised elements (idempotent — re-running skips tagged nodes). Collections are reported but not auto-tagged: they need a backing model and real ids, which markup alone can't supply. Always review the output — it is a draft.

Load the admin partial once in your layout (@include('live-edit::admin')) and the drawer/toolbar handle the rest.

If something is wrong

@liveEdit appears as text on the page. Blade does not error on a directive it does not know — it prints it, so this ends up visible to visitors. It means the package is not registered. Usually the install skipped Laravel's discovery step, or the views were compiled before it ran:

The runtime loads but no toolbar appears. The editor mounts off the body, not off the script tag. With LIVE_EDIT_AUTO_TAG=true that is done for you; without it, the host's layout has to carry data-admin (and data-csrf) on <body> for whoever may edit.

Edits save and then vanish on reload. The save is working; nothing is putting the value back. With named keys the template renders it from your own model — check it actually does. With derived keys this is the middleware's job, so it means LIVE_EDIT_AUTO_TAG is off. If publishing is switched on, an unpublished change is deliberately only visible to an editor.

Licence

Proprietary. Copyright (c) 2026 TryShipFast. See LICENSE.

The source is public so that customers and integrators can read it, audit it and build against it. Readable is not the same as free to take: a current subscription lets you run it on sites you own or operate, including sites you build for clients, and does not let you redistribute it, resell it, or offer it as a service of your own.

If a subscription lapses, the editor stops. The websites do not. The content your clients wrote is in their own database and stays on their pages — losing the licence means losing the editor, not the site.