Replies: 2 comments
-
|
+1, I've been seeing lots of folks sharing their EmDash admins with severely outdated versions :) |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
PR is up: #1939 — implemented as proposed (daily deferred registry check cached in the options table, admin-only endpoint, per-version dismissible banner, |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
The problem
Coming from WordPress, the single biggest "am I safe?" signal is the update notice in the admin. EmDash already has this for marketplace plugins (
/_emdash/api/admin/plugins/updates+ per-plugin update button), and DB migrations run automatically after a deploy — but for the core there is nothing. A site owner who isn't the developer has no way to know they're running 0.22 while 0.24 is out with security fixes. They find out when something breaks, or never.This matters for exactly the audience EmDash is courting with the migration track: WordPress users who hand the deploy pipeline to an agency or a git repo they don't touch day-to-day.
Proposal
A dismissible update notice in the admin dashboard:
VERSIONis used for plugin host-env checks today).https://registry.npmjs.org/emdash/latestat most once per day, deferred viaafter()so it never blocks a request, result cached in theoptionstable. Sites without outbound internet or with the check disabled simply never show the banner.latest > current, show a banner in the admin: "EmDash X.Y is available (you're on A.B)" with a link to the release notes / update docs. Dismissible per version (dismissing 0.24 re-arms when 0.25 ships).updateCheck: false) for people who consider phoning npm home unacceptable — the request carries no site data, it's a plain public registry GET, but the toggle should exist.Deliberately not in scope: a "update now" button. An EmDash update is an npm bump + rebuild + redeploy, which the admin cannot and should not trigger. The value is the awareness, not the mechanics — the docs can take over from the banner (manual path or Renovate, see #1888 for the drift/tooling side).
Prior art in the repo
The plugin update flow already establishes the pattern (check endpoint, admin surfacing); this extends the same idea to the core package. Happy to build it behind a config flag if maintainers agree it's wanted.
Beta Was this translation helpful? Give feedback.
All reactions