Developer tools

Every switch between programs loses your place: which element you were looking at, which file made it, which line. The dock beneath the live page holds the tools for working on that page, next to it.

• DevTools: Chromium’s own DevTools for the page, the same panels as in Chrome.
• Code: a real code editor, with the file that made the part you chose.
• Problems and Request: what the page reports as wrong, and the request behind it.

A fix can take either of two routes, and the page follows both.

• You change it. Open the part’s file in the code editor beside the page (Code, .), change it, and save with On a Mac, ⌘S·; on Windows and Linux, Ctrl+S.
• An agent changes it. Hand the part, a snap or what the page reports to a coding agent as a note (Build with an agent), and it edits the files in its own session.

Either way, the page reloads (or swaps only its stylesheets) and outlines the parts the changed file made. Your save is in the project’s Activity as yours; an agent’s change is in its session, for you to review in Changes. The editor never saves over an agent’s change, and says who changed a file while you had it open.

The dock sits beneath the page, closed until you open it. Its tabs:

• The tabs wait at the end of the status line. A tab opens the dock on itself; pressing the tab already shown closes it.
• On a Mac, ⇧[·; on Windows and Linux, Shift+[ and On a Mac, ⇧]·; on Windows and Linux, Shift+] open the dock on the tab it last showed, then step through the tabs, from the window or from the page.
• On a Mac, ⌘J·; on Windows and Linux, Ctrl+J stays the code editor’s: from another tab it shows Code, and from Code it hides the dock.
• Drag its edge to resize it, or focus the edge and use the arrow keys, Home and End. A button puts it beside the page instead of beneath, and back.
• What it shows, its height (or its width beside the page), its side and whether it is open are kept on this computer.

DevTools is the browser’s own set of panels for looking inside a page: its HTML and styles, its console, its network requests. In the dock it is Chromium’s DevTools for the page you see, beneath it or beside it, following the dock as you resize or move it.

1. 1

   Open DevTools

   Click DevTools among the dock’s tabs, or press On a Mac, ⌥⌘I·; on Windows and Linux, Ctrl+Shift+I, Chrome’s own key, which works from the window, from the page and from DevTools itself. View › Page DevTools does the same, and so does “Page DevTools” in search and commands (On a Mac, ⌘K·; on Windows and Linux, Ctrl+K) once you type it.

   

2. 2

   Choose a part

   Select a part on the page (P), or choose it in Layers.

3. 3

   Show it in DevTools

   Press Show in DevTools beside the part’s name in the Inspector, or the same button at the end of its row in Layers, or On a Mac, ⇧D·; on Windows and Linux, Shift+D. The dock opens on DevTools if it was closed, the page scrolls to the part if none of it is on screen, and Elements selects its element.

   

4. 4

   Work as in Chrome

   Every panel is DevTools’ own: Elements with its own picker, Console, Network, Sources, Application and Performance.

• Open in its own window puts DevTools on a second screen. The tab then says “DevTools is in its own window.”, with Back into the dock and Close DevTools.
• Hiding the tab (another tab, or the dock closed) keeps DevTools as it was, its console and its selection with it. Going to another page keeps it too. Leaving the project closes it.

While the live view is on, the page’s HTML holds a few things that are Wanigan’s, not your site’s. The line under DevTools says so.

• Wanigan’s page script, and the outlines it draws.
• With the site helper, its wl: comments around each traced part (<!-- wl:part id="…" -->) and its data-wl-* attributes: on Drupal data-wl-entity, data-wl-field, data-wl-view, data-wl-block and data-wl-paragraph; on WordPress data-wl-block.
• In the Network panel, the helper’s key, the X-Wanigan-Live header, on the page’s own loads. The line under DevTools says to keep it out of what you share.

The helper acts only for requests that carry the key, which only the live view sends, so the site looks the same in any other browser. The site helper explains the key.

These are the page’s own DevTools, with none of Wanigan’s privileges. Wanigan’s own window has separate ones, View › Wanigan’s Developer Tools, which moved to On a Mac, ⌥⇧⌘I·; on Windows and Linux, Ctrl+Alt+Shift+I because Chrome’s key now belongs to the page.

A real editor, CodeMirror 6, for changing files by hand without leaving Wanigan. It loads the first time you open a file and stays loaded while the window is open, so every open file keeps its own undo history, cursor and scroll.

• In the live view it is the dock’s Code tab, beneath or beside the page.
• In any other view of a project it is a drawer beneath the view, or beside it; On a Mac, ⌘J·; on Windows and Linux, Ctrl+J shows or hides it.
• The project’s Code tab (G then E) shows the same editor as the whole view, beside the project’s files. It is the drawer’s own editor, not a second one: the drawer steps aside while the tab shows and comes back as you left it. On a Mac, ⌘J·; on Windows and Linux, Ctrl+J on the tab goes back to the view you came from.

Quick open lists the files git sees: tracked ones, and untracked ones it does not ignore. Include vendor and node_modules adds installed code. With nothing typed, it lists the files open now and the places you visited lately.

1. 1

   Choose the part

   On a Northstar page that lists products, select one product card: P, then click it.

2. 2

   Open its file

   Press Code in the Inspector’s Design tab, or .. The dock opens on Code with the part’s file: its component’s Twig file (here product-card.twig), or the template that made it. When the file writes the words you picked, the cursor lands on them; words that come from content are not in a template.

   

3. 3

   Change it, and save

   Edit as in any code editor; a dot on the file’s tab marks it unsaved. On a Mac, ⌘S·; on Windows and Linux, Ctrl+S saves.

4. 4

   Watch the page follow

   The page reloads, or swaps only its stylesheets for a CSS file, and outlines the parts the file made. The status line names the file and how many parts it outlined, and the save is in the project’s Activity as “You edited …”.

   

Code is greyed out, saying why, when the page does not say which file made the part, when its template is outside the project’s folder, or when the site’s folder is not known.

• Highlighting for PHP, Twig (with the HTML, CSS and JavaScript around it), HTML, CSS, Sass and SCSS, JavaScript and TypeScript, JSON, YAML, Markdown, XML, shell scripts, TOML, .env and other settings files, Dockerfiles and nginx configuration.
• Line numbers, folding, bracket matching and closing, several cursors and rectangular selection. On a Mac, ⌘D·; on Windows and Linux, Ctrl+D adds the next match of what is selected.
• Search and replace (On a Mac, ⌘F·; on Windows and Linux, Ctrl+F) and go to a line (On a Mac, ⌃G·; on Windows and Linux, Ctrl+Alt+G).
• Completion from the language (CSS properties, HTML tags and attributes, JavaScript) and from words already in the file.
• New lines indent the way the file already does. Line endings and a byte order mark are kept as the file has them.
• Soft wrap (On a Mac, ⌥Z·; on Windows and Linux, Alt+Z) and Vim keys, each a switch in the line under the text, which also gives the line and column, the language, the indentation, the line endings and the encoding.
• Revert puts the saved file back, and can itself be undone.
• Esc then Tab leaves the editor for the rest of the window.

Breadcrumbs are the trail above the text: the file’s folders, the file, and where the cursor is inside it, such as a PHP class and method, a Twig block and the HTML in it, a CSS rule, a YAML key or a Markdown heading.

• Each crumb opens a menu of what is beside it: a folder’s other files, a method’s sibling methods, a rule’s sibling rules. Typing narrows the menu.
• On a Mac, ⌘⇧.·; on Windows and Linux, Ctrl+Shift+. moves to the breadcrumbs; ← and → walk them; Enter or ↓ opens one; Esc goes back to the text.
• Back and Forward go between every place you jumped to, across files: On a Mac, ⌃-·; on Windows and Linux, Alt+← and On a Mac, ⌃⇧-·; on Windows and Linux, Alt+→, the two buttons, or the mouse’s own back and forward buttons. Hold either button, or right-click it, for the recent places.
• A jump is opening a file, going to a line, a breadcrumb, Code from the live view, switching tabs, or moving the cursor ten lines or more at once.

Agents edit the same files you do. A save names the version of the file it was made from, and if anything changed the file since, nothing is written.

• With nothing unsaved, a file an agent changes reloads, keeping your cursor where the text did not change, and says who changed it, such as “Claude Code (its session’s title) changed this file.”, with Compare.
• With your changes open, nothing is replaced. The notice says your changes are not saved yet, and offers Compare and merge, Reload theirs or Save mine over it.
• A save refused because the file changed first opens the merge at once.
• An agent’s edit is noticed at once, and any other program’s within a few seconds. The name given is the agent session whose own hooks last reported writing the file, or “Another program”.
• A file deleted, moved or renamed while open says so; its text stays to copy, but saving cannot bring it back.

The merge shows the file as it is now on the left and your text on the right. The right side is what gets saved: the arrows take a change across from the left, and you can type in it freely. Save merged writes it, Use theirs takes the file as it is, and Back to my text closes the merge.

Code you did not write is replaced the next time it updates, and a change made there is lost. So it opens read-only: you can read, search and copy it, but not type in it. The notice above the text says why, and what to do instead.

Edit anyway unlocks it if you mean it. The notice then says “Editing someone else’s code: a change here is lost when it updates.”, and Activity records the save as someone else’s code, edited anyway. A file the disk itself will not let you write stays read-only: Wanigan will not change its permissions.

To change a core or contributed template the lasting way, copy it into your theme with Create override… in the Inspector’s Edit menu (Picking and the Inspector).

• Anything outside the project folder, or a card’s own worktree, including through a link.
• Git’s own records.
• A binary file, UTF-16, or text in any encoding but UTF-8.
• A file over 2 MB.

Unsaved text survives closing the window. It is kept on this computer until you save it or throw it away, and comes back when the file opens again: “Your unsaved changes from … are back.” If the file changed meanwhile, it says so and offers Compare and merge or Throw them away.

Closing an unsaved file’s tab asks first: Save and close, Close without saving, or Cancel.

Some faults never show where you are looking: a script error in the console, a warning the site printed at the top of a long page. Problems gathers what the page reports as wrong.

1. 1

   Open Problems

   Click Problems among the dock’s tabs. Its count is how many the page reports, red when one is an error. With none, it says “Nothing wrong on this page.”

   Picture: to come

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

2. 2

   Read them

   Each row says Error or Warning, and where it came from. On the page is a message the site itself printed: Drupal’s error and warning messages, a WordPress error or warning notice, or an Xdebug error. Console is an error or warning the page logged since it loaded, with its file and line.

3. 3

   Hand them on, or check again

   Add to notes puts every problem listed into one note that begins “Fix what this page reports:”, waiting in Notes to send to an agent (the message it gets). Check again reads the page again after you fix something yourself.

An agent’s own look at a page (live_problems) also lists requests that failed, from a fresh load in a hidden window. Your view records none.

With the site helper, Request shows the request behind the page shown: what it cost, and what ran to make it. Every number is what the helper measured in that one render, on this computer.

• Totals: time, queries and their time, memory and hooks, with the address, who it was rendered for and how many parts it has.
• Hooks, the points where a module, plugin or theme steps in to change what core does: in the order they fired, filtered by who implements them (Implemented by) or searched; the five slowest are marked, and the first 400 are listed.
• Queries, the database queries: slowest first, or grouped by the code that ran them. Pointing at one outlines the part it was for on the page, and Copy the SQL copies it.
• Assets: the scripts and stylesheets it added, with sizes where reported, and who added each.
• Logs: what was logged while the page rendered.

Nothing in it sends anything. To hand a slow query to an agent, choose the part it outlines, write a note, and paste the SQL into it.