diff --git a/.changeset/registry-icon.md b/.changeset/registry-icon.md
new file mode 100644
index 0000000..adce111
--- /dev/null
+++ b/.changeset/registry-icon.md
@@ -0,0 +1,5 @@
+---
+"@eisbachcode/emdash-plugin-analytics": patch
+---
+
+The plugin now has its own icon in the EmDash registry, in search results and on its page, instead of the letter placeholder. Also tested on EmDash 1.1.0, 1.2.0 and 1.3.0; none needed a change.
diff --git a/emdash-plugin.jsonc b/emdash-plugin.jsonc
index ea43695..083dfbc 100644
--- a/emdash-plugin.jsonc
+++ b/emdash-plugin.jsonc
@@ -18,6 +18,10 @@
"release": {
"requires": { "env:emdash": ">=1.0.1" },
"artifacts": {
+ // Uploaded into each release record, not the profile, so it only
+ // shows from the next published version on. 256x256, rendered
+ // from icon.source.html.
+ "icon": { "file": "images/icon.png" },
"screenshots": [
{ "file": "images/analytics-page.png", "lang": "en" },
{ "file": "images/per-entry.png", "lang": "en" },
diff --git a/images/icon.png b/images/icon.png
new file mode 100644
index 0000000..6057421
Binary files /dev/null and b/images/icon.png differ
diff --git a/images/icon.source.html b/images/icon.source.html
new file mode 100644
index 0000000..12992e3
--- /dev/null
+++ b/images/icon.source.html
@@ -0,0 +1,58 @@
+
+
+
+
+
+
+
+
+
+
+
diff --git a/src/index/bootstrap.ts b/src/index/bootstrap.ts
index 102347d..41d8f50 100644
--- a/src/index/bootstrap.ts
+++ b/src/index/bootstrap.ts
@@ -10,8 +10,8 @@
* Two things keep this cheap:
*
* - **It rides on the sync tick** rather than on `plugin:activate`, which
- * is dispatched only by the admin Enable endpoint and never fires for a
- * site that registers the plugin through `plugins: []`.
+ * fires once per activation (and, before EmDash 1.2.0, never for a site
+ * that registers the plugin through `plugins: []`).
* - **It walks a few entries per tick.** `getPublicUrl()` is one bridge
* call per entry and a sandboxed invocation gets ten in total, so the
* page size is deliberately tiny and the pass spreads over many ticks.
diff --git a/src/plugin.ts b/src/plugin.ts
index c73aec8..f08fd76 100644
--- a/src/plugin.ts
+++ b/src/plugin.ts
@@ -63,9 +63,11 @@ const CRON_TIMEOUT_MS = 30_000;
const plugin: SandboxedPlugin = {
hooks: {
/**
- * Fires only when an administrator clicks Enable. A site that
- * registers the plugin through `plugins: []` never gets one, which is
- * why this is not the only place scheduling happens.
+ * Fires when an administrator clicks Enable, and from EmDash 1.2.0 also
+ * on the first start of a site that registers the plugin through
+ * `plugins: []`. Before 1.2.0 such a site never gets one, which is
+ * why this is not the only place scheduling happens. It must not
+ * throw: from 1.2.0 a throwing activate hook disables the plugin.
*/
"plugin:activate": async (_event, ctx) => {
await scheduleFromSettings(ctx);
@@ -101,7 +103,7 @@ const plugin: SandboxedPlugin = {
errorPolicy: "continue",
handler: async (event, ctx) => {
// Also the reliable scheduling entry point for `plugins: []`
- // installs, where `plugin:activate` never fires.
+ // installs before EmDash 1.2.0, where `plugin:activate` never fires.
await scheduleFromSettings(ctx);
await index(ctx, event, "published");
},
diff --git a/src/sync/scheduler.ts b/src/sync/scheduler.ts
index 58dcaca..214ffac 100644
--- a/src/sync/scheduler.ts
+++ b/src/sync/scheduler.ts
@@ -162,12 +162,12 @@ export interface SyncOutcome {
* Schedule both tasks, idempotently.
*
* Called from `plugin:activate`, from the content hooks and from the
- * widget's first `page_load` — because `plugin:activate` is dispatched
- * only by the admin Enable endpoint, and a plugin registered through
- * `plugins: []` in the site config never gets one. That is the npm
- * channel, which is the channel most installs use. `CronAccess.schedule`
- * upserts on (plugin, task), so calling it repeatedly is free of
- * consequence.
+ * widget's first `page_load` — because before EmDash 1.2.0
+ * `plugin:activate` is dispatched only by the admin Enable endpoint, and a
+ * plugin registered through `plugins: []` in the site config never gets
+ * one. That is the npm channel, which is the channel most installs use.
+ * `CronAccess.schedule` upserts on (plugin, task), so calling it repeatedly
+ * is free of consequence.
*/
export async function ensureScheduled(ctx: PluginContext, interval: string): Promise {
if (!ctx.cron) return;