Drupal

A Drupal page is built from many pieces: templates, fields of a piece of content, blocks placed in regions, views, menus, Layout Builder sections, components. To change one word you first have to find which of them holds it, and then the right form to change it in. Wanigan finds that for you and saves through Drupal itself.

The helper names no module. Anything built on Drupal core’s render pipeline, theme system, entities, fields, forms and configuration shows up through it, and a few modules that keep words where core’s saves cannot reach get an adapter.

Northstar, the Drupal demo, is a made-up outdoor-goods shop on Drupal core. These three steps show the helper, a save and a refusal. The full how-to is in the site helper and Make real.

1. 1

   Install the helper

   Open a product, such as the Lakeside Enamel Mug. Under Layers, choose Set up the Drupal helper…, read what it writes and runs, and press Install the helper. It runs four ddev commands, which can take a minute, then reloads the page with every part named.

   

2. 2

   Retype the title and make it real

   Select the product’s title (P), press E, type new words and press Enter. Open Edits (On a Mac, ⇧E·; on Windows and Linux, Shift+E) and choose Make it real. The words are saved to the title of that product, in that language, as a new revision by you, and the edit becomes In the site, not verified until you run Verify.

   

3. 3

   Try a page with a draft waiting

   The Ember Camp Mug has a newer draft waiting over the version visitors see. Retype its title the same way and choose Make it real: nothing is saved, and the edit says “This content has a newer draft than the version the page shows, and Wanigan does not save into a draft yet”, with Tell an agent… under it. Saving would leave the draft behind, so change it in Drupal’s form, which edits the draft.

   Picture: to come

   A screenshot of the real app, with the demo’s data, of what the title above says.

Wanigan reads the project’s own files and offers the address they name: a ddev project from .ddev/config.yaml, a Lando site from .lando.yml, or a dev script from package.json. It starts nothing to find them. Details are in Turning it on.

• For a ddev site, Wanigan asks ddev whether the site is running, and Start it runs ddev start on your click. A Lando site or a dev script that does not answer is named, with how it is started; Wanigan does not start those.
• The helper installs with ddev only. In a project with no .ddev folder Wanigan does not install it yet; the page is still shown, and Twig debug still names its templates.

Twig is the language Drupal’s templates are written in. When Twig debug is on, Drupal writes a comment around every template’s output saying which file printed it and which other file names it could have used. Switch it on in Configuration › Development › Development settings.

From those comments alone, Layers names each template and single-directory component, nested as the page nests them, and says whose code each file is from where it sits: core, contributed, or yours. A single-directory component is one whose template, styles and .component.yml (its props and slots) live in one folder.

With Twig debug off and no helper, Layers says “Nothing on this page says what made it”. You can still select a part and point an agent at it.

The Drupal helper is a development-only module, wanigan_live, that Wanigan writes into the site’s modules/custom folder on your click and installs with ddev drush. A module is a package of code that adds to Drupal; this one adds nothing a visitor can see.

• It switches on Twig development mode (debug on, Twig and render caching off) and keeps the settings it found in Drupal’s state, so removing the helper puts them back. Pages are slower meanwhile, as they are when you switch it on yourself.
• It acts only for requests that carry the token Wanigan keeps in Drupal’s state, which only the live view sends. Every other request gets exactly what core makes, so the site looks the same in any other browser.
• Its folder is listed in the repository’s .git/info/exclude, so git never sees it and it cannot be committed.
• It carries a version (4 in this build). When the one in the site is older than your Wanigan’s, Wanigan says so and offers Update the helper…, which rewrites only its own folder.

What it adds, in the words of its install dialog:

• What made every part of the page, read through Drupal core: its template and the suggestions it could have used, the preprocess and alter hooks that shaped it (each with its time and what it changed), its variables, cache tags and queries.
• Edits any field where it shows, in Drupal’s own form for that one field, saved as a new revision by the user you are logged in as in the live view.
• Moves blocks between regions, menu links, a field’s items and a display’s fields by dragging, through core, each with Undo, and says first when a move changes configuration every page shares.
• Copies a template into your theme to override it, only when you ask.
• Go to: admin pages and their tabs, content, terms, users and media.
• One piece shown alone: a piece of content, a component with its examples, a block, or sample content where there is none yet.
• Reloads the view when content changes in Drupal (an agent running drush, an editor saving), not only when files change.

How to install, update and remove it, and what happens when another Wanigan set it up, is in Turning it on.

With the helper, each part is named the way the site names it: a piece of content as “Product: Lakeside Enamel Mug”, a field by its label, a block, a region, a view or a menu by its name, a component by its .component.yml name. A template nothing else names keeps its file name. See the Inspector for how Layers shows them.

Each part also says what the site stores it as, so an edit finds it again after a reload or a reorder: an entity (Drupal’s word for a stored thing, such as a piece of content, a term or a user), a field and its item (a reference by what it points to, so a reorder does not lose it), a component inside a part, a block placement, a menu or menu link, a view, and a Layout Builder component by its id on the content it is shown for. A paragraph is named as itself, with the revision the page showed.

On Northstar, 318 of 394 parts were named this way, and a moved menu link kept its name as it moved.

Make it real saves the words you typed on the page into the one thing that holds exactly those words. On Drupal that is one of these, chosen from what the helper says made the part:

A field’s label, a block’s title, the site’s name and slogan, a view’s words and a webform are configuration: Drupal’s settings, kept in the database and usually exported to files in the code. The next configuration import puts back what is exported, so every such save says so. Export the configuration to keep the change.

Words the page shows in another language are saved to that language’s configuration translation, which needs the “translate configuration” permission. Words with no translation are never saved to another language.

Every save answers with the content’s address before and after. When a new title gives the page a new address, as it does on a site where the Pathauto module makes addresses from titles, the view goes to the new address instead of reloading the old one.

A Layout Builder default layout, which every page of a kind without its own layout shows, a Paragraphs Library item and a webform’s shared words say how far they reach before anything is saved. Make it real again to save them. More in Make real.

For a change that is more than words, choose Edit ▾ on a part. Under In the site · saved by Drupal as you, each way to change it opens beside the part: Drupal’s own form, saying “Drupal’s own form, saved by Drupal as you, as a new revision.” where the content keeps revisions, or for a single value, such as a block’s title, a short form Wanigan draws that Drupal checks when you save. Saving reloads the page.

Where a part cannot be changed here, the menu says why: your user may not, the field is computed or read only, no widget edits its type, or the content belongs to other content or is shown as one pinned revision of it.

Before you save, the sheet says whose code also runs on that save: the modules that implement the entity’s save hooks, or listen to a configuration save. Drupal core has no AI API, so Wanigan cannot list a Drupal site’s AI, and says so in the Inspector’s AI on this site.

Drag a part by its handle, or press M on a chosen part, to move it where Drupal itself keeps an order. Each move first checks the order is still what the page showed, and answers with the order as it is now when it is not.

Inserts add a block from the block library to a region, placed as the block form places one, or a new item to a field whose type can make a sample value. A new reference is never inserted, since it would create content of another kind, and a component is never inserted: core has no place that stores one.

Take out (On a Mac, ⇧X·; on Windows and Linux, Shift+X) takes only the placement or reference away, never what it showed:

• A block placement is switched off, not deleted, and stays in Block layout with its settings.
• A menu link is switched off in the menu, not deleted.
• A field item’s reference goes, and the content, media or file it pointed to stays. A Layout Builder component goes from the layout, and what it showed stays.
• Refused where core would delete what the part showed: an inline block in a layout without revisions, or a file, image or other owned reference on content that keeps no revisions. A link with links under it is refused too.
• Anything shared says where it shows and asks first. Taking something out of configuration says to export the configuration to keep it in code.

Undo puts a move or a removal back for ten minutes, and only while nothing else has changed what it touched.

The library (On a Mac, ⇧B·; on Windows and Linux, Shift+B) lists what the site can place, as Drupal core lists it: its single-directory components and the blocks its block library offers. Each is pictured alone in the site’s own theme at a phone’s and a desktop’s width, with its props, slots and files.

• Where it is used across the site: its placements in every theme, Layout Builder default and per-page layouts, and for a component the templates that include it, found by Drupal’s own Twig parser. It says what no search of stored data can see.
• A component cannot be placed on a page by itself through core: Drupal keeps no such thing outside a template or a field, and the library says so. Blocks can be placed from it.
• Seen in the real app on Northstar: 73 entries, pictured at exact sizes.

How the library looks and works is in Components.

Canvas is a contributed page builder for Drupal that keeps a page’s design in its own component tree. In this build, Canvas pieces by their own ids are on the list of what is not built yet.

The stored-words search leaves a Canvas component tree’s inputs out, so it never writes into one. Words a Canvas page keeps there are not saved from here: change them in Canvas, or tell an agent from Edits.

Every refusal says why, and which kind of why. Drupal keeps no such thing means core stores those words nowhere it can write, so they are code: an agent or you change the code. Wanigan does not do it yet means core could save it and Wanigan does not, from here; change it in Drupal’s own form meanwhile.

Other refusals are about now: the content changed since the page loaded, several things hold the same words (each named), your user may not change it, or Drupal refused, in its own words. Reload and try again. More in Make real.