Editor API

Changed

• Editor API is free and open source again. Published under the MIT License from this version on — no per-site fee, no licence key, nothing to buy on the Statamic Marketplace. Versions v1.2.3 to v2.6.1 were released under a commercial licence and keep it; versions up to v1.2.2 were already MIT.
• Documentation names the app and the Drupal module. The iOS app is Editor for Drupal & Statamic (one app for both CMS), and the same contract is available for Drupal 11 as ppcharlier/drupal-editor-api.

Fixed

• HTTPS & mixed content prevention. When the incoming request is secure (Request::isSecure() or proxied with X-Forwarded-Proto: https / X-Forwarded-Scheme: https by a TLS-terminating reverse proxy such as Tailscale, Caddy, Nginx, or Traefik), asset URLs, site URLs, and navigation node URLs are automatically served with https:// rather than http://, preventing iOS App Transport Security (ATS) and browsers from blocking mixed content.

Full Changelog: https://github.com/ppcharlier/statamic-editor-api/compare/v2.5.0...v2.6.0

Added

• cms in GET /config. The identifier of the CMS answering ("statamic"), so an app that serves several CMS can tell which one an account belongs to. A stable identifier, never a display label: the client picks the name it shows. Optional and additive — a client that ignores it behaves exactly as before.

Added

• timezone in GET /config. The site's timezone (app.timezone) so that a client computes an entry's day and shows wall-clock dates in the same zone as the Control Panel.

Fixed

• date fields could not be written back. Statamic 6 validates a date field with time against the Zulu ISO string its Control Panel submits, while it stores Y-m-d H:i in the site's timezone; a client echoing what GET returned — the iOS app resending an untouched field — was rejected « Not a valid date. ». FieldShape now runs Date::preProcess() on the way in (single and range modes, nested fields included), idempotent for the Zulu shape and lossless for the stored one.

Added

• GET /templates — the site's views as template names (articles/index), the option list a client needs to edit a template field. Same discovery rule as the Control Panel; filtering (errors/, partials, folder) stays client-side, as in the CP.

Changed

• Choice options are sent as an ordered [{value, label}] list in the compact blueprint (select, radio, checkboxes, button_group, anything on HasSelectOptions), in blueprint order and whatever the blueprint file's form. A {value: label} JSON object loses its key order in most decoders — the iOS app showed a Left/Center/Right button group as Center/Right/Left.

Fixed

• The two author-visibility permissions read identically for every collection in the roles editor — three collections, three rows saying "List other authors' entries", with nothing to tell them apart. Statamic replaces :collection in a permission label with the collection's title (Permission::label()); the labels now carry it, and each also gained a description.

Added

• Two optional permissions to hide other authors' entries — editor-api list other authors {collection} entries and its child editor-api view other authors of {collection} entries, both per collection, in the role editor's "Editor API" group. They go deliberately BELOW Control Panel parity: the CP lists every entry with its author to anyone who may view the collection, and only writing takes an "other authors" permission. A mobile editor often needs stricter, so this is now a site's choice.

  Without the first, a listing is narrowed in the query (meta.total counts what the user sees) and any entry-by-id route — read, revisions, localizations, publishing — answers 404 not_found rather than confirming the entry exists. Without the second, author.name comes back null while author.id stays, so a client can still tell "somebody else's" from "no author".

  Super users, collections whose blueprint has no author field, and roles holding edit other authors {collection} entries are never restricted — whoever may edit another author's entry already sees it in the CP.

• enforce_author_visibility config key, default false. Off, nothing changes and the permissions lie dormant; the key is read with a fallback, so an installation whose published config file predates it behaves exactly as before after an update. The permissions are registered either way, so a roles.yaml never carries a handle that only exists when a config file says so.

Fixed

• An entry created without author was born ownerless. The CP fills a users field declared default: current with the signed-in user when the form opens; the API applied no blueprint default, and EntryPolicy treats an entry with no author as someone else's — so a writer creating from the app was immediately refused on their own entry. POST /collections/{collection}/entries now defaults author to the current user whenever the blueprint has that field and the payload omits it. An explicit value is kept as sent; blueprints without an author field are untouched.

Added

• access editor-api permission. The counterpart of Statamic's access cp: a non-super user must hold it (granted per role in the CP, under the new "Editor API" group) before a token is issued, and on every request afterwards — revoking it cuts off tokens already in the wild. Super users never need it. Refusals are 403 forbidden, after the password check so they reveal nothing about unknown accounts.

• can blocks on every payload. The same policies that would refuse a write are asked ahead of time for the current user, so a client greys out what it may not do instead of discovering it through a 403:

  Payload	Keys
  entry (list and detail)	edit, delete, publish
  term	edit, delete
  asset	edit, move, rename, delete
  global set	edit
  /config collection	create, publish
  /config taxonomy	create
  /config asset container	upload

• author on entries (list and detail): the first user of the blueprint's author field as { "id", "name" } — the display name only, never the email — or null when the blueprint has no such field.

Upgrade

• Grant access editor-api to every role that uses the app. On a free-edition site nothing changes: the single super user bypasses it.

Fixed

• Every authorization now goes through Statamic's own policies, finishing what 2.0.3 started for entries. Until now the API compared bare permission strings, which diverged from the Control Panel in both directions:

  • More permissive on a multi-site install: nothing checked access {site} site. A user confined to one site could read, list, create or localize entries, edit globals, read navigation trees and create terms in the other sites. Every site resolved from ?site= (or the localization payload) is now checked against SitePolicy, as the CP's site switcher does, and each per-site policy re-checks it. Single-site installs are unaffected.
  • Stricter than the CP: configure collections, configure globals, configure navs, configure taxonomies, configure forms and configure asset containers open their whole area in the CP (the policies' before() hook) but were 403 here. Likewise edit … entries implies view in the CP but not here. Both now match.

  Each endpoint asks exactly what its CP counterpart asks: view/create/publish on the collection or entry, edit on the origin entry when localizing, edit on the global set's localization, view/edit on the navigation tree, view on the taxonomy and create/update/delete on the term, view/store on the asset container and view/edit/move/rename/delete on the asset, view on the form and delete on the submission. Index endpoints filter with the same view policies.

Changed

• The 403 forbidden message reads Not authorized to {ability} this resource. (or Not authorized to access site [{handle}].) instead of naming a permission string.
• On a single resource, an unknown path or localization is a 404 before the 403, as in the CP: the policy needs the resource to decide.
• The route middleware became editor-api.can:{ability},{routeParam}; the internal PermissionMap class is gone. Neither was part of the HTTP contract.

• N/A Changelog not available.

• N/A Changelog not available.

• N/A Changelog not available.

• N/A Changelog not available.