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.