SiteHelm 0.15.0 — a media item can be deleted

A media item can now be deleted, and two faults a real site turned up while the last release was being exercised on it.

The media dispatcher could upload a file, import one from a web address, rename it, resize it and attach it to a post, and it could not take one away. media-delete removes one item and the files behind it. It is the one media operation with no way back, so it always previews, and the preview names the file that goes, how many resized copies go with it, and any content using it as a featured image.

Operations no longer disappear from the catalogue because the plugin they belong to is missing. The eight WooCommerce operations were listed on a site without the add-on and then vanished the moment the add-on arrived; they are now listed either way, marked unavailable, with the reason. The saved catalogue and the operation search had the same problem in reverse, reporting every operation as available whatever state its plugin was in.

A write that fails its check now says what actually went wrong. The engine used to throw the operation's own verdict away and report the same sentence every time, then tell the administrator to restore a snapshot that, for a delete, was never taken.

Full changelog: https://github.com/Mrshahidali420/SiteHelm/blob/main/CHANGELOG.md

SiteHelm 0.14.0

An agent can now find an operation from a plain description of what it wants to do, and every route that put a file into the media library works again.

An agent can find the operation it needs

A client reads the eleven dispatcher names when it connects and, unless it opens a catalogue, never learns anything more. So an operation could be present, switched on and permitted and still be reported to you as missing, because nothing in the words "install a plugin from a zip" points at a dispatcher called content-write. system-operation-find takes the words and answers with the operations that match, wherever they live, each with a runnable example call. It names the ones the add-on carries as well as the ones this site has, so "the add-on does that" is a possible answer instead of silence.

The whole surface can also be saved as one document. system-catalog-export returns every operation this site publishes as Markdown or JSON, grouped by subject, with the risk and rollback flags a choice turns on. It carries a version stamp that changes only when the surface does, so a saved copy can tell it is stale without re-exporting. The same document is published as an MCP resource, sitehelm://catalog — reconnect your client after updating or that resource stays invisible to the session, the operation works either way.

Naming an operation this site does not have now points at the ones it does, and each dispatcher lists its operations in the tool list rather than leaving them to be discovered.

Uploading a file works again

Every route that put a file into the media library failed. The array describing the file was handed to WordPress as a literal, WordPress takes that argument by reference, and PHP 8 answers that with a fatal rather than an error the plugin knows how to describe. media-upload, media-import, media-svg-upload and the upload ticket were all affected. On the ticket route the fatal escaped altogether: you got WordPress's own critical-error page, the ticket was already spent, and the activity row stayed open at Started for good. That route now answers anything that goes wrong inside it with a readable refusal and closes its row either way.

Also in this release

A menu item can be removed. A read of a page shows the custom fields that are actually on it, not only the ones SiteHelm may write. A mistyped id reads as a missing target instead of a permissions problem. retryable no longer says retry on errors that can never succeed. And Check again on the Updates screen now finds a new version instead of answering from a stale note for another half a day.

Install: download sitehelm-0.14.0.zip below and upload it in Plugins → Add New → Upload Plugin. Sites already running SiteHelm can update in place from the Updates screen.

SiteHelm 0.13.0 — a file on your own computer can reach the site

Twenty merged changes. The one that shapes the release: an agent could only ever hand the site things the site could already reach. A plugin, a theme or an image sitting on your own computer had no route in, and the answer was always "upload it yourself first, then tell me where it is."

A file on your own computer can now reach the site

The agent asks the site for a one-time upload ticket, sends the bytes straight to it, and hands the operation the reference it gets back. The ticket is good for one upload, for a short window, and for the size and type it was issued against. Nothing is base64'd through the conversation, and no address on your machine is ever fetched by the site.

That covers what you would otherwise have done through Media → Add New, and it covers the two installs below.

Plugins and themes can be installed from a zip

Installing used to mean WordPress.org, by slug, only. A client's own theme, a premium plugin, anything not in the directory — none of it could be handed over. It can now be installed from a zip the site already holds in its media library, or one sent up with an upload ticket. Installed things are still stored switched off; turning one on stays a separate, deliberate call.

A theme's own files can also be read before anything replaces them, so "what does this theme currently do" is answerable without FTP.

Why a page looks wrong, without opening a browser

SiteHelm could show you what a page rendered, but not why it renders that way. content-style-check takes a page, a selector and a screen width, reads the stylesheets that page actually loads, and reports which rules apply at that width and which one wins. If a menu button is still showing on a phone, this says whether the rule you wrote reaches it.

Things that used to be refused

• Custom fields could not be written at all, and could not hold a number or a yes/no value. Both fixed.
• Content types with no public face could not be listed, and now can.
• Menus had to already exist before any menu operation would work. Menus can now be created.
• The site icon and the site logo can be set — two of the first things any new site needs.
• Content can be put in a chosen order, and a page can be given its address, its parent and its template.
• content-list accepts private and any as a status.

Things that used to be wrong

• A dormant SEO plugin — installed, active, and configured for nothing — was reported as healthy. It is now a caveat.
• "This is not available" covered three different problems: a plugin the site has not installed, a feature with no Pro licence, and a service outside the site that did not answer. Only the last one fixes itself, and they now read as three different refusals.
• The plugin list reported a plugin still parked behind its own setup wizard as perfectly healthy. There is now an onboarding column, which says "unknown" rather than guessing.
• Redirect reads and writes now show what another plugin is holding for the same path, so a site running two redirect plugins can see the collision instead of finding it in production.
• A write that failed for an unforeseen reason said the details were logged on the server, and wrote them to a file most shared hosts never hand over. The failure is now recorded on that write's own entry in SiteHelm → Activity.
• "By SiteHelm" links to the website, "View details" answers about this plugin, and the activity log names the app that made each change and names plugins and themes rather than their file paths.

In Pro

Snippets can live in WPCode or Code Snippets if the site already runs one, plugins and themes can be deleted, a plugin's own setup wizard can be answered, and the redirections listing shows both plugins' rules.

Pro users: update this plugin before updating the add-on. Pro 0.10.0 requires 0.13.0.

---

109 free operations, 51 in Pro, 160 in total across twelve modules. The full list is in docs/OPERATIONS.md; the complete changelog is in CHANGELOG.md.

SiteHelm 0.12.0 — the page, not the row

Update this one promptly if you have bought Pro. Activating a licence led to a page that
refused to open, so a paid site could not turn the add-on on by following either route the
plugin offered. That is fixed below, and it is the reason this release should not wait.

Fixed — the licence route

• "Activate a licence" led to a page that refused to open. The button on Health, and the
  sentence an agent was given when a Pro operation refused, both pointed at an account page
  the licensing SDK never registers for an add-on, so following either was answered with
  "Sorry, you are not allowed to access this page" — and the Add-Ons screen, the other route
  offered, could not load at all on a host that cannot reach the licensing service. Every
  link about Pro now goes to SiteHelm's own Upgrade screen, which this plugin registers and
  which works whether or not anything outbound succeeds, and the Add-Ons screen is gone.

Added

• An agent can now see the page a visitor is served, not the row it wrote. Every write
  SiteHelm performs reports success by reading the database back, which says the value was
  stored and says nothing about whether the page renders. content-rendered-get fetches one
  published item's own front-end address and reports what came back: the status code, any
  redirect, the title, meta description, canonical and robots tags, the Open Graph and
  Twitter tags, the heading outline with a count of H1s, how many images carry no alt text,
  how many links point inside the site and how many out, and the word count — with the
  markup itself on request. The address is not something you pass in: there is no property
  for one, so the only page that can ever be fetched is the permalink of the item you named,
  on this site's own host. Drafts, password-protected items and post types with no public
  page are refused before anything is requested, because a fetch that carries no cookies
  would report them as broken.

• A section can now be asked for full bleed, instead of being told what padding to
  cancel. Elementor's kit puts 10px on all four sides of every container and boxes its
  content by default, and neither of those is stored on the container itself — so a section
  built to run edge to edge was written, read back exactly as sent, verified green, and
  rendered inset, with nothing in the response to say why. elementor-element-add takes a
  preset of full-bleed on a container, which stores the zeroed padding and the full-width
  content the look actually needs. It is shorthand, never an override: sending your own
  padding or content width beside it is refused rather than silently losing one of them.

• A free site now says what Pro would add, instead of reading as impossible. Ask an
  agent to do something only the add-on does and it used to answer that SiteHelm cannot do
  it at all — because a listing is the only place most agents look, and an operation absent
  from one does not read as locked, it reads as unavailable anywhere. Every listing now ends
  with the operations that dispatcher would gain, each one named and described, and where to
  read about them. An operation the add-on registered and the site then switched off is not
  listed: it is not for sale, it is turned off.

• Upgrading and activating now happen inside wp-admin, on a screen SiteHelm owns.
  "Upgrade to Pro" opens a page in the console that shows every plan with its price —
  annual and lifetime, the recommended one flagged — and takes you to the same Freemius
  checkout the website does. Prices come from wpsitehelm.com and are cached for half a day,
  with the plugin's own copy standing in whenever the site cannot be reached, so the page
  never shows a price it is not sure of. A site that already has the add-on installed sees
  the licence field first instead of the plans, and a site with an active licence is not
  sold to at all.

• A site running Pro without a licence says so on every admin screen, not only on the
  ones you happen to open in SiteHelm, and the notice leads to the field where the key
  goes. The key itself is entered in Freemius's own dialog: SiteHelm never reads, stores or
  forwards it.

Changed

• Getting started asks for one thing, in a dialog, instead of handing you a list of five.
  Home used to open with a numbered "Get started" block whose first step was connecting an
  app and whose other four — permissions, a test call, a first change, undoing it — read as
  four more things you had to finish before the plugin counted as set up. None of them were
  required. Connecting now gets a dialog of its own that opens on any SiteHelm screen while
  nothing can reach the site, says what an app needs and how long it takes, and goes to the
  Connect tab; "Not now" or the × closes it for that administrator for good, and a connected
  site never sees it again. The other four moved below the numbers as "When you're ready" —
  no numbering, no tally, no order — and the list removes itself once they are all done.
• Connect leads with the credential, not the address. The application-password path needs
  two things and the screen only ever showed one, with the working path — create a password,
  then copy a snippet that already carries it — sitting below the fold. Choosing that path
  now shows a card that says so in a sentence and a button straight to the credential form,
  which sits above the snippets that carry it, with the bare address demoted to the bottom
  for a client the snippets do not cover. The sign-in card no longer claims the address is
  the whole configuration without qualification: it says which apps that is true for, and
  what to do when nothing happens.

Fixed

• Editing the words in an Elementor heading no longer breaks the widget, or quietly
  deletes the links inside it. Elementor's newer widgets do not store their text as a
  string: they store it beside the editor's own record of the links, bold and italic runs
  inside that text. A write that sent the words on their own put them where that record
  belongs, which the page rendered perfectly — and then the first person to open the widget
  and press update was told "Settings validation failed", with nothing to say when the
  damage was done. Writes now store the words in the shape the editor reads, and carry the
  existing formatting across an update that only changes the wording, so a link inside a
  sentence survives a rewrite of that sentence. Because formatting is anchored to positions
  in the text it was written against, a plan that keeps it now says so and suggests checking
  the widget when the wording changed substantially. Asking for the formatting to be cleared
  is still possible: send an empty set of it deliberately.
• Reading a large Elementor page no longer returns a response the client cannot receive.
  A real landing page nests containers inside containers and reaches several hundred elements
  without anybody thinking of it as large; returned whole, that tree was megabytes of JSON,
  and the app on the other end either truncated it, spent its whole context on it, or dropped
  it — three failures that all read as "the read did not work" and none of which said the size
  was why. elementor-document-get now answers a shorter true tree instead: it drops the
  deepest levels until the response fits, and reports in a new narrowed member how deep it
  went and how many elements it left out. An element whose children were dropped still says
  how many it has, so there is no way to mistake the shortened answer for the whole page. To
  see what was left out, name an element with the new rootId and get that band back at full
  depth. The totals and the authoring hints keep describing the whole document either way.
• A template SiteHelm created no longer goes missing from the screen you would look at
  next. Elementor records what a template is in two places: a value on the template itself,
  which is what this plugin's reads and its own verification ask for, and a term in the
  library's taxonomy, which is what the Templates list and the Theme Builder actually query
  by. Creating, saving and importing all wrote the first and not the second, so a header came
  back correct from every check and was absent from the only list an operator would open.
  All three now record both.
• A global style class no longer stores properties Elementor will never render. The
  repository these classes live in keeps whatever it is handed; the parsing that decides
  which style properties are real happens a layer above it, on the route the editor uses. A
  property outside that schema was therefore stored intact, read back identical, and applied
  to nothing. Creates and updates now ask Elementor what it accepts before anything is
  written, store its answer rather than the request, and name every discarded property in a
  warning and in the preview. A class Elementor keeps nothing of is refused, because it would
  render nothing at all. An Elementor that cannot be asked is a warning and not a refusal.
• Buttons in the console were drawn in their own background colour, label and all. A link
  colour meant for bare links in prose outweighed every button, tab and menu item built from
  an anchor, so a primary button rendered as a solid block of colour with the text
  invisible inside it. The rule now applies only to links that carry no class of
  their own.

SiteHelm 0.11.0

Until now the only way to connect a client was to create an application password and paste it into a config file. An app can now register with the site, send you to a page in your own dashboard that names it and asks whether to allow it, and hold its own credential afterwards — nothing to copy, nothing to paste. It is on wherever the site is served over HTTPS and can be switched off entirely. Application passwords keep working exactly as they did; this is a second way in, not a replacement, and a connection made this way still acts as the account that approved it and can do nothing that account could not.

Added

• Apps can sign in to the site themselves. Register, approve from your own dashboard, done. A connection you can see and cut off from the site rather than from the app.
• Connect asks how your app signs in before it shows you anything to paste, and the snippets follow the choice. On a site that cannot offer signing in, it says which of the two reasons it is and points at the path that does work. Below that: every app that has signed in, with when it registered, when it was last let in, how many live tokens it holds, and a Sign out or Remove button that names the app before it acts. Below that again: whether apps may sign in at all, the address they are given (for hosts answering on a different domain to the one WordPress recorded), and a Test discovery button that asks this site for its own sign-in documents over the network and reports, per address, whether the answer came from this site or from something sitting in front of it. The same verdict appears on Health.
• Home opens with five steps that tick themselves off — connect a client, choose what it may touch, make a test call, make a first change, undo it. Nothing is remembered and nothing is dismissed: every step reads its own answer back off the site, and once all five are done the block folds to one line.

Fixed

• A client that asks for an older MCP protocol revision now gets the one it asked for. The handshake answered with this server's newest revision whatever the client named, and several clients read that disagreement as the end of the conversation and never asked for the tool list — so the whole site looked like it had no operations at all.
• Two schema shapes that strict clients refused to load. A menu item's target offered an empty string as one of its two choices, and the dispatcher tools never said which of their inputs were required. "Same tab" is now the plain _self you would write in HTML; an empty string is still accepted and still means the same thing, but it is deprecated and no longer listed.
• Two sites no longer collide in one client's config. The generated server name carries the site's host — sitehelm-example-com.
• One unreadable global class no longer hides all the others in elementor-global-class-list. The bad entry is reported in its place with a short reason.
• A style class nothing wears is refused instead of silently rendering nothing.

Install

Download sitehelm-0.11.0.zip below and upload it in Plugins → Add New → Upload. Sites already running SiteHelm are offered the update in place. Requires WordPress 6.6 and PHP 8.1 or newer.

SiteHelm 0.10.0

Added

• SiteHelm now tells the agent driving it how to build a page. Connecting returns a short
  set of instructions: how a write is previewed and then applied, and the four mistakes that
  produce a page which reports success and still looks wrong — leaving the layout at its
  default so the theme's header, footer and title stay put, leaving containers at Elementor's
  10px kit padding so nothing runs edge to edge, writing a hover colour that only works over a
  light background, and giving a section's CSS class names general enough to collide with the
  theme. They are deliberately terse, because they are sent on every connection.

• elementor-document-get reports what a page has earned a note about. Alongside its
  elements it now returns hints: whether the layout is still the default, whether the two
  layout records disagree, and how many top-level containers will inherit the kit's padding.
  The list is always there and is usually empty — it only ever says something the page itself
  demonstrates, never general advice.

• Every Elementor write now says so when an image will be served without srcset. A
  media setting given an image URL with no media-library attachment stores and renders, but
  WordPress cannot build srcset or sizes for it, cannot add the wp-image class, and will
  not lazy-load it — so the page serves one full-size file to every visitor. The plan now
  carries a warning naming the setting, and a bulk write that degrades many images reports the
  totals instead of a wall of sentences. It is a warning, not a refusal: the write still
  happens, because pointing a widget at an image outside the library is a legitimate thing to
  ask for.

Changed

• Bulk SEO metadata and audit fixes are free — content-seo-bulk-set and
  content-seo-audit-fix shipped in SiteHelm Pro from 0.2.0 and now ship here. Batch size
  was never a good reason to charge: the free plugin already carries the single-post write
  each of them repeats, so an agent could always reproduce either in a loop — but only by
  giving up the one preview, one snapshot and one rollback the batched form performs. That
  put the safer path behind the licence and the riskier one in front of it. Both operations
  are unchanged in behaviour; they simply no longer ask for a licence.
• An add-on that has not caught up keeps working. The two plugins update on their own
  schedules, so a site can briefly run this version beside a SiteHelm Pro that still
  registers the same two operations. It now yields: an identifier the add-on already holds
  is left with the add-on, every other Pro operation still registers, and this plugin picks
  the identifier up on the next add-on update. Nothing is lost in between, and the same
  rule covers any future operation that moves out of the add-on.

Fixed

• A page whose elements were written without ids lost every style on it. Elementor
  generates its CSS one element at a time, keyed on each element's own id, and an element
  that arrived without one produced a selector with nothing after the prefix. CSS discards
  a whole rule group when any selector in it is malformed, so a single unnamed element took
  the entire page's stylesheet with it — the page still held its content, its settings read
  back exactly as written, and it rendered unstyled. Every element now gets an id as it is
  written, and a page an earlier version left in that state repairs itself the next time
  anything on it is written.
• Repeater rows are named, so a row can be styled on its own. Elementor gives each row
  of a repeater control — an icon in a social-icons list, a tab, a slide, a form field —
  an id of its own, and generates that row's styles against it. The three operations that
  merge settings into an existing element wrote rows with no id at all, which cost the
  ability to style or address any single row, plus the row identity Elementor's editor
  tracks for the open tab, the current slide and the active accordion panel. The rows
  rendered, so nothing reported a problem. They are now named on the same terms as
  elements: deterministically, and a row that arrives with an id of its own keeps it.
• A style setting Elementor would store but never render is now refused. Elementor hides a
  control whose group switcher is unset, and drops its value at CSS-generation time: writing
  background_color without background_background, or border_color without
  border_border, was accepted, saved, read back unchanged, and rendered nowhere. Those
  writes are now refused before the save, naming the companion setting and the values it
  accepts, so the fix is one more key in the same request rather than a page that reports
  success and looks untouched. The check reads only what the widget itself declares, so it
  leaves alone the groups that genuinely need no switcher — typography and box shadow — and
  stands aside on anything it cannot read with certainty.
• Setting an Elementor page layout actually changes the page now. WordPress and
  Elementor each keep their own record of which template a page uses, and only WordPress's
  decides what a visitor sees. SiteHelm was writing Elementor's, so canvas or
  headerFooter was stored, read back correctly, and reported as verified while the page
  went on rendering with the theme's header, footer and title — the change looked done from
  every angle except the site itself. Both records are now written together, and rolling
  back restores both. Reads report the layout the page is really rendered with, and say so
  when the two records disagree; every page an earlier version set a layout on is in that
  state, and setting the layout again repairs it. Pages created with a layout are no longer
  born that way.
• elementor-document-get now returns the page's own page settings — the layout it
  renders with, whether the theme title is hidden, and the whole stored row behind both.
  Reading a page used to answer only its elements, so anything built from that read came out
  inside the wrong page frame, and there was no way to tell.
• Elementor edits work on ordinary widgets again. Elementor ships two kinds of widget:
  the newer atomic ones, and the classic ones nearly every page is actually built from —
  HTML, Heading, Image, Text Editor, Button, Shortcode, and everything third-party plugins
  add. SiteHelm could only read the newer kind's settings, so a write touching a classic
  widget was refused with a message blaming Elementor for not being loaded, and retrying
  never helped. Worse, because a save validates the whole page at once, a single classic
  widget anywhere on it blocked every edit to that page. SiteHelm now recognises both kinds,
  writes each in the form Elementor stores it, and still refuses a setting the widget does
  not accept — so an edit is never silently discarded.
• Containers, sections and columns can be styled again. Every Elementor settings write
  used to refuse anything that was not a widget, so padding, width, background and gap on a
  container — the settings that decide whether a section runs edge to edge — could not be
  changed by any operation at all. A page built entirely through SiteHelm therefore kept
  Elementor's default 10px on all four sides of every container and there was nothing an
  agent could do about it. Elementor keeps two registries of settings, one for widgets and
  one for layout elements, and SiteHelm only ever read the first; it now reads whichever one
  owns the element in hand. A container is still never checked against a widget's settings,
  which is what the old refusal was really protecting.
• Adding a container with a setting it does not accept is refused. The check already ran
  when a container was edited, but not when one was created, so a misspelled key was accepted,
  quietly dropped by Elementor, and reported as written. Both paths now check the same way.

SiteHelm 0.9.0 — plugins & themes

The site's own extensions are now on the table.

Free — two new reads. system-plugin-list and system-theme-list report every installed plugin and theme: version, which are active, which the network activated, which theme is live, and which have an update waiting. The update column is read from WordPress's own last check and stamped with when that check happened, so it is exactly as fresh as the Plugins screen — asking the question never sends the site off to wordpress.org.

Acting on them is SiteHelm Pro 0.7.0. Activate, deactivate, switch theme, update either, install either. The three that flip an option are previewed, snapshotted and reversible; the two updates and two installs say plainly that they cannot be rolled back, because WordPress has no clean way back to an older version.

Installing is deliberately narrow. It takes a WordPress.org slug and nothing else — there is no argument anywhere in the plugin that accepts a URL, a zip or a file path, the only address ever fetched is the download link WordPress.org itself answers with, and what lands is stored deactivated. A failed install removes exactly the folder it part-wrote and nothing the site already had. The free tier still declares neither install capability, and the six remaining execution capabilities stay permanently excluded.

A site that sets DISALLOW_FILE_MODS or DISALLOW_FILE_EDIT refuses the four file writes by name, and keeps the three that only flip an option.

101 free operations across twelve modules; 47 in Pro. Update from the Plugins screen, or install sitehelm-0.9.0.zip below.

SiteHelm 0.8.0

From this release on, updates come straight from GitHub: new versions appear on the Plugins screen and install with one click, and a console notice says when the installed version is behind the latest release. Only the built sitehelm-<version>.zip asset attached to a release is ever offered.

Also in 0.8.0:

• Calling a Pro operation without a licence now refuses with a message naming SiteHelm Pro and the pricing page, instead of a bare "integration unavailable" — so an agent hitting the boundary can tell its user exactly what would unlock it.
• Pro card on the console Home, a Get Pro link on the Plugins row, and an Upgrade to Pro menu entry; all of it disappears once a licence is active.
• Community link in the console, pointing at the user group.
• WordPress.org listing files (readme.txt, banners, icons, screenshots) now live in the repo.

Full details in CHANGELOG.md.

Install/update: download sitehelm-0.8.0.zip below, or if you're on 0.8.0 or later already, update from the Plugins screen.

SiteHelm 0.7.0

Changed

• A risk level for code, and the gate that goes with it (REQ-0107) — operations that
  store or run code get their own tier above High, because the honest claim about them is
  different: for everything else we can say what will change, and for a program we can only
  say what was stored. Adding the tier turned up a real hole. The "Read & edit" permission
  level — the one whose own description promises an app can change things but never delete —
  decided what to allow by asking whether an operation was High, so anything above High was
  not High and went straight through. It now compares levels in order, which refuses a new
  top tier by default rather than admitting it. Nothing in the free plugin uses the new tier;
  the console learns the words for it, and the test suite refuses any free operation that
  claims either the tier or the code module. The Pro screen also lists the eighteen
  operations that module will carry, so the console can say what switching it on would
  let an app do before any of it is written.
• A preview never reproduces an executable payload (REQ-0106) — where a change
  touches a code field, the before-and-after shows a byte count and a short digest
  instead of the body. The values a preview renders travel further than the preview:
  into the response, into the stored plan an operator approves, and into the rollback
  table in the console. A snippet's contents are routinely an API key or an SMTP
  password, so those three places would have held a live credential. The change is
  reported exactly as loudly as before — the field is named, and a rewritten payload
  never describes the same as the one it replaced — and rollback still restores the
  real body, because restoration reads the snapshot rather than the preview. No
  operation writes to one of these fields yet; this lands first so that none can.

Added

• SVG images can reach the media library, safely (REQ-0105) — media-svg-upload
  adds one SVG so Elementor's icon and image controls can point at it. The file that is
  stored is never the file that was sent: the document is rebuilt from an allowlist of
  drawing elements, and scripts, event handlers, embedded HTML, stylesheets, external
  references and entity declarations do not survive that rebuild. Everything removed is
  reported as a warning and the exact document that will be stored is shown in the
  preview, so what is approved is what will exist. It is the only path allowed to store
  markup — the ordinary upload and import operations still refuse SVG outright — and it
  asks for unfiltered_html as well as upload_files, because storing an SVG is closer
  to publishing markup than to uploading a photograph. The site's own upload permissions
  are untouched: nothing about the WordPress media screen changes.
• Build, empty and create whole Elementor pages (REQ-0104) —
  elementor-document-build replaces a page's entire layout with one you supply,
  elementor-document-clear empties a page, and elementor-document-create makes a
  new page for a layout to live on. All three refuse a layout using a widget this site
  does not have installed, and refuse any setting key the widget carrying it does not
  declare, rather than storing it and letting Elementor drop the text silently. Build
  and clear both preview, snapshot and roll back, and both refuse a request that would
  leave the page exactly as it already is instead of reporting a change that never
  happened. A created page is always a draft, so nothing an agent sends can put an
  unreviewed page in front of visitors, and it is a real Elementor page from the moment
  it exists — the layout you ask for reaches its page settings, and every other
  Elementor operation will work on it.
• Elementor page settings, child order and element names (REQ-0103) —
  elementor-page-settings-get and elementor-page-settings-set read and change the
  settings a page carries as a whole (its layout template, whether the title shows),
  elementor-elements-reorder sets the order of one element's children, and
  elementor-element-label-set names an element in the navigator. Page settings live in
  their own meta row, so the write snapshots that row and not the document — a rollback
  puts the settings back and leaves the page's content untouched. The write reaches a
  closed list of settings and merges into the stored row, so anything SiteHelm does not
  name survives it, while the read returns the whole row so an agent can see what else is
  there. A reorder demands the parent's complete list of children, so a request written
  against a page that has since gained one fails loudly instead of quietly guessing where
  the new element belongs.
• The Elementor template library, as a first-class surface (REQ-0102) —
  elementor-template-list and elementor-template-get read the templates the site has
  saved, elementor-template-save stores a document or a single element as a new one,
  elementor-template-apply inserts one into a page, elementor-template-import brings
  in a template this site did not produce, and elementor-theme-template-create makes an
  empty theme document. An apply re-mints every element id against the destination page
  and rebinds the styles that pointed at them, so the same template inserted twice does
  not collide with itself. Apply and import both check a template against the widgets this
  site actually has and name the missing ones, rather than writing a tree the page cannot
  render. A theme document is created with no display conditions, so it shows nowhere
  until elementor-theme-conditions-set says where.
• Elementor 4 global classes (REQ-0101) — elementor-global-class-list,
  elementor-global-class-create, elementor-global-class-update,
  elementor-global-class-delete and elementor-global-classes-reorder cover the
  reusable style classes Elementor 4 keeps site-wide: read them in cascade order, add one,
  rename one or merge style properties into it, remove one, and set the order they cascade
  in. The class set is one snapshotted unit, so every change is reversible as a whole. A
  write refuses while the editor is holding unpublished class changes instead of
  overwriting them, and the read reports that divergence as inEditorSync. A delete says
  how many documents wear the class before it is approved, and never edits a document — so
  restoring the class restyles every element that wore it.
• Find a phrase everywhere on the site (REQ-0092, Free half) — content-search names
  every post, page and custom post type whose title, content, excerpt or Elementor data
  mentions a phrase, with a per-field count, a plain-text excerpt of the first occurrence,
  and a link to each document. The phrase is matched whole, not split into words, so
  searching for an old company name does not return every page carrying the word "name".
  Results are filtered document by document against your own WordPress user's
  edit_post capability, so a search cannot become a way to read drafts you may not open.
  Elementor pages are found — their text lives in post meta, which WordPress's own search
  does not read — and reported at the document level, with elementor-element-search
  naming the individual elements inside one of them. A phrase JSON would store escaped is
  flagged elementorExact: false rather than presented as a complete answer, and a search
  broad enough to match most of the site stops at five hundred documents and says so.
• WooCommerce is a module the console knows about (REQ-0057, groundwork) — the
  Modules screen lists WooCommerce alongside the built-in nine, with its own permission
  level and its own requirement line, and the Pro screen names the eight operations it
  brings: products listed, read, created and updated (name, description, SKU, price, sale
  price, stock and categories), product categories listed, and orders and customers read.
  Orders and customers are read-only by design — SiteHelm will not rewrite a shop's
  financial record. The operations themselves ship in the SiteHelm Pro add-on; the free
  plugin carries the identifier, the console copy and the capability reservation so that
  an add-on can register them without the free plugin changing again.
• Forms, listed and read (REQ-0084, Free tier) — form-list names every form the
  site's form plugin holds with its embed shortcode, form-get reads one form's fields
  (name, type, required) exactly as the stored template declares them, and
  form-entries-list reads a form's recent entries where the plugin stores any — for
  Contact Form 7, which delivers each entry by email and stores none, the answer says so
  plainly instead of erroring. Entries gate on manage_options because a submission can
  carry a visitor's personal information. Everything is read-only: no form write, no
  entry deletion. Other form plugins arrive through the same provider seam as an add-on.
• Five more SEO plugins speak the shared vocabulary (REQ-0083) — All in One SEO,
  SEOPress, The SEO Framework, Slim SEO, and SureRank now serve the six existing SEO
  operations alongside Yoast SEO and Rank Math. The same field names read and write
  whichever plugin the site runs, the answer names its provider, and precedence
  across a multi-plugin site is fixed (Yoast, Rank Math, All in One SEO, SEOPress,
  The SEO Framework, Slim SEO, SureRank). A field a plugin has nowhere to store reads
  as null and a write to it promises null in the preview instead of failing after
  the fact.
• Site settings, read and write (REQ-0062) — site-settings-read answers the whole
  thirteen-field allowlist (title, tagline, timezone, date and time formats, posts per
  page, front page geometry, permalink structure, default comment and ping status,
  search-engine visibility) typed in one call, and site-settings-set changes any subset
  of it as one previewed, snapshotted, re...

SiteHelm 0.6.0

Added

• Three more Pro operations in the Tools-tab catalogue — content-seo-schema-get,
  content-seo-schema-set and content-seo-audit-fix (SiteHelm Pro 0.2.0), so a site
  without the add-on sees them as locked rows in their groups.

• Pro operations on the Tools tab. The SiteHelm Pro operations are listed in the
  groups they belong to, each with a Pro tag. Without the add-on they appear as locked
  rows — full description, no switch — under one note with the one link to the Add-Ons
  page; with it installed but unlicensed the note says so and points at the Account page;
  with it active the tag stays and the rows are ordinary switches. No admin notice, and
  nothing on any other screen.

• The plugin now carries the Freemius SDK: an opt-in insights prompt on first run, and
  Account and Add-Ons pages under the SiteHelm menu. SiteHelm Pro is sold and licensed
  through it as an add-on; nothing about the free operations changes.

• SEO scores and a site-wide SEO audit (REQ-0098, free part). Two new reads for sites
  running Yoast SEO or Rank Math. content-seo-score-get reports one post's SEO and
  readability scores exactly as the plugin stored them (never recomputed, so the number
  matches the editor; Rank Math has no separate readability score and says null), plus
  a list of findings derived from the metadata — missing, too-short or too-long
  description, over-long title, missing focus keyword or one absent from the title, a
  published post kept out of search, a score under the caller's floor.
  content-seo-audit walks a page of posts (default 50, at most 100) and reports each
  one's scores and findings with a count of every finding across the page, detecting
  duplicate titles and descriptions within it; posts the caller may not edit are skipped
  and counted, not shown. The finding vocabulary is fixed and published in both output
  schemas.

• Term SEO metadata (REQ-0098, free part 2). content-term-seo-get and
  content-term-seo-set read and write a category's or tag's title, description,
  canonical, focus keyword and noindex in Yoast SEO (the wpseo_taxonomy_meta option)
  or Rank Math (term meta, with the robots directive list edited rather than replaced).
  Both admit on edit_posts and then ask the taxonomy's own edit capability, so a
  contributor cannot rewrite what a category archive tells search engines. The write
  is previewed, snapshotted and reversible like every other. 74 operations.

• Extension points. Three hooks let another plugin extend SiteHelm without touching it:
  sitehelm_modules (add a module), sitehelm_register_operations (add operations to a
  module) and sitehelm_status_sections (add a section to the Health tab). Every hook is
  additive and contained: nothing an add-on returns can remove a built-in module, and a
  throwing handler is logged rather than allowed to break the boot.

• SiteHelm Pro: deep SEO (REQ-0098, Pro part). Five Pro operations for sites running
  Yoast SEO or Rank Math, each gated by the licence first and manage_options second.
  seo-settings-get / seo-settings-set read and write an allowlist of the plugin's own
  settings — separator, knowledge-graph name and logo, default social image and
  breadcrumbs at site scope; title and description templates, noindex and sitemap
  inclusion per public post type — as one previewed, snapshotted, reversible change per
  scope, translating between the two plugins' option layouts (Yoast's separator codes,
  Rank Math's two-key robots rule). content-seo-bulk-set applies the content-seo-set
  fields to up to fifty posts at once as a single reversible change, refusing the whole
  set if one post is missing or not the caller's to edit. seo-404-log-list and
  seo-redirection-list page Rank Math's 404 monitor and redirections newest first (at
  most 200 a page), and say plainly when a Yoast site has no such tables or the Rank Math
  module is switched off. The free plugin is unchanged: the operation count stays at 74.

• SiteHelm Pro foundation. A separate add-on plugin (source in a private repository, not part of the
  free zip) with an offline-signed per-site licence key, a Licence card on the Health tab, and
  a gate every Pro operation checks itself. The free plugin carries no Pro file, no nag and no
  crippled operation.

• A Home tab. The console now opens on a plain-language summary: one sentence on how the
  week went, three tiles (changes this week, could not be done, undone), the last five things
  an app did, and a "Connect an app" prompt when nothing has happened yet.

• Permission levels. Each module card on the Permissions tab carries four buttons — Off,
  Read, Edit, Full — in place of the single on/off switch. Read allows only reads; Edit adds
  writes that are neither destructive nor high risk; Full allows everything. A module whose
  per-operation switches match no level reads "Custom", and a link leads to the Tools tab for
  fine-tuning.

Changed

• Tabs speak the owner's language. Modules is now Permissions, Operations is Tools,
  Activity is History, Status is Health, and the Connect tab is "Connect an app" at
  ?page=sitehelm-connect (the console's first page is now ?page=sitehelm, Home).

• History reads as sentences — "claude-code changed the page About us" — with the
  operation id kept in small print underneath; the columns are When, What happened,
  Outcome, Took, Who, Undo.

• The Tools tab opens with an "advanced" note saying most owners only need the
  Permissions tab.

• Tabs no longer stretch to fill the bar, so the row can take more tabs and scrolls when
  it must.

• The admin console's look. A new design throughout: indigo accents, Geist headings,
  one white content panel under the tab bar, headline stat tiles, and a "Get help" menu in
  the app bar that links to the documentation, the changelog and the issue tracker.

• The Operations screen lays its operations out as cards — switch, name, description,
  module and required capability on each — in place of the table. Clicking anywhere on a
  card flips its switch, each tool's group can be collapsed, and "All on / All off" is now a
  segmented control.