The live editor
Turning it on, and the site helper
In short
The live editor stays off until you switch it on, then shows the local site you already run; it never starts or installs anything by itself. The site helper is an optional add-on for Drupal or WordPress, installed on your click, that tells Wanigan what made every part and lets it save through the site’s own core.
On this page
Switch it on
Open the Live tab
Every project has a Live tab in its project bar. While the live view is off it says “The live view is off”, with Switch on the live view: the same switch as in Settings › Live view. When only this kind of site is off, the button says Switch it on for Drupal sites (or WordPress sites, or other sites).
The Northstar Storefront project’s Live tab while the live view is off: “The live view is off”, the Switch on the live view button and Settings beside it.. Picture to come Picture: to come
A screenshot of the real app, with the demo’s data, of what the title above says.
Choose the site
The first time, Wanigan asks “Where is Northstar Storefront’s local site?” and lists the addresses it found in the project, each saying where it found it. Press Use this on one, or type the Address, choose what it Runs on (Drupal, WordPress or Another site) and press Open it.
Choosing Northstar Storefront’s site: https://northstar-demo.ddev.site listed as found in .ddev/config.yaml with Use this, and the Address field and Runs on choice below.. Picture to come Picture: to come
A screenshot of the real app, with the demo’s data, of what the title above says.
Change it later
The site menu at the left of the toolbar has Site settings…: the address, the helper and the hosted environments. Forget this site clears the address.
Settings › Live view
| Setting | What it does |
|---|---|
| Show each project’s local site inside Wanigan | The switch for the whole live view: a Live tab on the project and beside a session’s terminal. |
| Drupal sites, WordPress sites, Other sites and JS apps | Each kind of site on or off. |
| Follow the agents’ edits | Reload as they change files, and outline what each file made. Off, an edit only says what changed, and you reload. |
| Keep before and after screenshots on cards | A full-page picture of the card’s page as its session begins, and after each turn that changes files. Off until you switch it on. |
Every other setting is in Settings.
How it finds the site
Wanigan reads a few small files in the project and offers the addresses they name. It starts nothing, reaches nothing and changes nothing to find them.
| It reads | It offers |
|---|---|
.ddev/config.yaml, with its config.*.yaml overrides | The ddev project’s address, and each extra hostname |
wp-config.php, in the project, web/, docroot/, public/ or ddev’s docroot | WP_HOME and WP_SITEURL |
package.json | http://localhost: and the port its dev (else start) script names, or its tool’s usual port, such as Vite’s 5173 |
.lando.yml | https:// and its name, then .lndo.site |
A ddev site’s certificate is trusted when this computer’s own mkcert authority issued it for the site’s host. Every other certificate gets Chromium’s own verdict.
When the site is not shown
When the page cannot be shown, the editor says why in its place, with what to do. For a ddev site it asks ddev itself (ddev describe -j in the folder the site serves) whether the site is running, as the view opens and again whenever a page fails.
A paused or stopped site is said as that, “This site isn’t running”, with ddev’s own words, and never as a certificate problem, even when ddev’s router answered with another project’s certificate for it. Start it runs ddev start in the project’s folder on your click, shows the command and its lines as they come, then loads the page. If ddev fails, you see what it said.
Picture: to come
A screenshot of the real app, with the demo’s data, of what the title above says.
A refused certificate is described as it states itself (who issued it, what it covers, when it expires) and named for what it is:
| What it is | What to do |
|---|---|
| Made by another machine’s mkcert | Restart the site (ddev restart) so ddev makes its certificate with this computer’s authority. |
Kept in the project, in .ddev/traefik/certs or .ddev/custom_certs (it names the file, and says whether git tracks it) | Remove the file and its key from the project, then restart the site. |
| ddev’s router answering for another project | Start the site, or restart it when ddev says it is running, so the router has its route again. |
| Expired | Restart the site so ddev makes its certificate again. |
| For another name | Use one of the project’s ddev hostnames, or add this one to .ddev/config.yaml and restart. |
| No mkcert authority on this computer yet | Run mkcert -install in a terminal, then restart the site. |
Nothing is changed without your click. Restart it appears where a restart is the fix, and Check again asks ddev again.
A Lando site or a dev script that does not answer is named, with how it is started (lando start, or the dev script), and Wanigan does not start those. A card’s screenshots and the helper’s saves give the same reasons. More in Troubleshooting.
The site helper
Without the helper, the editor still shows the page, follows the agents and names what the page marks itself: Drupal’s templates while Twig debug is on, WordPress’s blocks and Elementor’s elements. The helper, written into the site on your click, lets the site say much more:
- What made every part, read through core: its template and the ones it could have used, the hooks and filters that shaped it (timed, with what each changed), its variables, cache and queries.
- Edits where a part shows, through the site’s own form or API, saved as you, with a revision where the site keeps one.
- Moves, and taking an item out, where the site itself keeps an order, each with Undo.
- A template copied into your theme to override it, only when you ask.
- Go to’s list: admin pages and their tabs, content, terms, users and media.
- One piece shown alone: a piece of content, and on Drupal also a component with its examples, a block, or sample content where there is none yet.
- A reload when content changes (an editor saving, an agent running drush or wp-cli), not only when files change.
The Drupal helper is a development-only module, wanigan_live. The WordPress helper is one must-use plugin file, wanigan-live.php, which WordPress loads by itself. Neither names any contributed module or plugin: whatever is built on core shows up through it.
Install it
Find the offer
Under Layers, the editor offers Set up the Drupal helper… (or the WordPress helper). The same offer is in Site settings…, and in Go to and the Inspector wherever the helper would say more.
The Layers tab for Northstar Storefront before the helper is installed, its offer under the tree: one line of what it adds and Set up the Drupal helper….. Picture to come Picture: to come
A screenshot of the real app, with the demo’s data, of what the title above says.
Read the plan
The dialog says what the helper adds, exactly which files it writes and where, the line it adds to
.git/info/excludeso git never sees them, and every command it runs. Nothing has been written yet.The “Set up the Drupal helper” dialog for Northstar Storefront: what it adds, What it writes (the wanigan_live files), the .git/info/exclude line, What it runs (four ddev drush commands), and Install the helper.. Picture to come Picture: to come
A screenshot of the real app, with the demo’s data, of what the title above says.
Install
Press Install the helper. On Drupal it runs four ddev commands, which can take a minute; on WordPress it runs nothing. The page reloads with the helper.
| Drupal | WordPress | |
|---|---|---|
| Writes | A development-only module in modules/custom/wanigan_live under the site’s docroot | One file, wp-content/mu-plugins/wanigan-live.php |
| Runs | ddev drush state:set wanigan_live.token …, ddev drush pm:install wanigan_live -y, ddev drush php:eval (Twig development mode on: debug, no Twig or render caching), ddev drush cache:rebuild | Nothing: WordPress loads a must-use plugin by itself |
| Kept out of git | The module’s folder, by a line in .git/info/exclude | The file, by a line in .git/info/exclude |
| Needs | A .ddev folder, and Drupal in the project | WordPress in the project |
Twig development mode makes pages slower, as it does when you switch it on yourself. The settings it found are kept in Drupal’s own state, so removing the helper puts them back, whichever Wanigan removes it.
Update the helper
A newer Wanigan can carry a newer helper. When the one in the site is older, Wanigan says so where it matters, and updating rewrites only the helper’s own folder or file.
This release carries the Drupal helper at version 4 and the WordPress helper at version 5. Version 5 is what lets Try a style offer a WordPress site’s declared palette, so a WordPress site set up with an earlier Wanigan needs one Update the helper to get it.
Open Site settings
In the site menu at the left of the toolbar, choose Site settings…. The helper’s section says where it is installed, and that “this Wanigan has a newer one” when it is out of date.
Northstar Storefront’s site settings, the Drupal helper section: where it is installed, that this Wanigan has a newer one, and the Update it… and Remove the helper buttons.. Picture to come Picture: to come
A screenshot of the real app, with the demo’s data, of what the title above says.
Update it
Press Update it…, read the same plan as at install, and press Update it.
The “Update the Drupal helper” dialog for Northstar Storefront, the same plan as at install, with Update it.. Picture to come Picture: to come
A screenshot of the real app, with the demo’s data, of what the title above says.
The same update is offered as Update the helper… under Layers when a trace needs it (“Update the helper to see this”), in Go to (“This site’s helper is older than this Wanigan”), and under Take out when a helper older than version 4 cannot say whether a part can be taken out.
A helper another Wanigan set up
The helper answers only the Wanigan that set it up (on another computer, before a reinstall, in a test), because it acts only for requests carrying that Wanigan’s key. The editor says so at the top of Layers, “This site’s helper answers to another Wanigan”, and Go to says so too. Set up the helper… sets it up again here and gives it this Wanigan’s key; the other Wanigan would then need to do the same.
Remove the helper
Open Site settings
Choose Site settings… in the site menu.
Remove it
Press Remove the helper. On Drupal, Wanigan uninstalls the module, deletes its key from Drupal’s state, puts the development settings back as they were, rebuilds the cache, deletes the folder and takes its line out of
.git/info/exclude. On WordPress it deletes the file, and themu-pluginsfolder only if installing made it and nothing else is in it.Northstar Storefront’s site settings just after Remove the helper: the status line saying “The Drupal helper is gone, and the development settings are as they were.” and the section offering Set up the Drupal helper… again.. Picture to come Picture: to come
A screenshot of the real app, with the demo’s data, of what the title above says.
In depth
How it answers only the live view
- Every request from the live view carries an
X-Wanigan-Liveheader with a key: on Drupal a token kept in Drupal’s state, on WordPress a token written into the plugin file. A request without it gets the page exactly as core makes it, so the site looks the same in any other browser. Open in the default browser, in the toolbar’s More menu, opens the page without the key. - A page rendered for the key answers with an
X-Wanigan-Traceheader and wraps each traced part of its output in<!-- wl:part id="…" -->comments. Wanigan reads that render’s trace from/_wanigan/trace/and its id; the helper keeps the last 20 traces per user for ten minutes. - While the live view is on, the page’s HTML also carries the helpers’
wl:comments anddata-wl-*attributes (on Drupaldata-wl-entity,data-wl-field,data-wl-view,data-wl-blockanddata-wl-paragraph; on WordPressdata-wl-block). The DevTools tab says what of the page is Wanigan’s, and its Network panel shows theX-Wanigan-Livekey on the page’s own loads. - Its own routes are under
/_wanigan/, among them the trace, an edit, a move, an insert, a removal, undo, Go to’s list (find), the component library, and a piece shown alone (/_wanigan/piece/). - On Drupal, a traced render reads and writes no render cache, so nothing that made a part is skipped and no marks are stored for anyone else.
- On WordPress, a request without the key runs only the change counter that tells the view content changed. A traced page sets
DONOTCACHEPAGEand sends no-cache headers, so no page cache keeps a page with marks in it. - Content changes are followed by asking the helper for its count every two seconds: cache tag invalidations on Drupal, content saves on WordPress. A site that changes its content on its own more than four times in a minute stops these reloads until you reload the page.
What it refuses
- The Drupal helper in a project with no
.ddevfolder: Wanigan installs it with ddev. Lando and other setups are something Wanigan does not do yet. - A project where Drupal or WordPress cannot be found: no
core/lib/Drupal.phpunderweb/,docroot/or the folder itself, or nowp-contentbesidewp-includesorwp-config.php. - A folder or file of the helper’s name that Wanigan did not write: nothing is changed.
- A second install or removal while one runs: wait for the first to finish.