How the registry works

Structure

Everything the site renders comes from data/plugins.js. Pages are plain HTML, styles are one CSS file, and the client script does the filtering, detail rendering and manifest generation.

Ecscripts_web/
├── index.html          home: hero, stats, featured, categories
├── browse.html         searchable, filterable library
├── plugin.html         release detail (?p=slug)
├── publish.html        manifest builder + submission
├── docs.html           this page
├── data/plugins.js     the registry (single source of truth)
└── assets/
    ├── css/style.css
    └── js/site.js

Entry format

Each release is one object in the plugins array. Only slug, name, tagline, version and category are strictly required, but a sparse entry looks unfinished and gets flagged in review.

{
  slug: "v-bokeh",                 // URL id, lowercase, hyphenated
  name: "V-Bokeh",
  tagline: "Native depth-of-field bokeh for After Effects.",
  publisher: "VIBE-PLUG",
  version: "1.1.0",                // semver
  category: "effects",             // see categories below
  platforms: ["After Effects"],
  license: "Commercial",
  released: "2026-09-18",          // YYYY-MM-DD
  updated: "2026-10-02",
  downloadUrl: "https://…/V-Bokeh.zip",
  repoUrl: "https://github.com/…",
  requirements: "After Effects CC 2019+, Windows 64-bit",
  about: ["Paragraph one.", "Paragraph two."],
  features: ["Radius-independent cost", "32-bit float"],
  changelog: [
    { version: "1.1.0", date: "2026-09-18", items: ["GPU path", "Anamorphic bokeh"] }
  ],
  install: ["Drop the .aex in Plug-ins.", "Restart the host."]
}

Categories in use: effects, scripts, tools, utilities, templates. Add a new one to the categories array and it appears in every filter automatically.

Submission flow

• Build the entry on the Publish page, copy the JSON, or open a prefilled issue from it.
• Either paste the entry into an issue, or open a pull request that appends it to data/plugins.js.
• A reviewer checks the download link, the license and the declared hosts, then merges.
• Merges to main publish themselves. There is no build step to break.

Downloads and hosting

The registry indexes releases, it does not host binaries. Point downloadUrl at something you control and that resolves without a login: a GitHub release asset, an S3 or R2 object, your own CDN path.

Keep old versions reachable if you can. Users pin builds, and a dead link is the most common reason an entry gets removed.

Licensing

Free, open source and commercial tools all belong here, but the license has to be stated. Acceptable values include SPDX identifiers (MIT, GPL-3.0, Apache-2.0), Commercial, or Freeware for closed but free builds.

• Commercial entries must name where the product is purchased.
• Demos and trials are listed as the full product, with the limitation in the description.
• Redistributed builds need permission from the original author. Unlicensed repacks are rejected.

Versioning

Semantic versions, no date-stamps and no "final2". updated changes whenever a build changes; released stays on the first public version of that line. The changelog entries are dated and newest first.

Support policy

Support runs through the publisher, not the registry. Each entry links to its source or homepage, and issues about a tool should go there. The registry handles listing corrections, broken links and licensing disputes.

• Broken link: report it, the entry is hidden from the library until fixed.
• Abandoned tool: marked as unmaintained, not deleted.
• Malware or undisclosed telemetry: removed immediately.

Running it locally

No toolchain needed. Open index.html directly in a browser, or serve the folder:

python3 -m http.server 8000
# then open http://localhost:8000

To check the data file before committing:

node scripts/validate.mjs