Racinage
Get Started

Rules

Plugin publishing rules

Clear expectations for safe packages, trusted publishers, and family-account privacy.

Publishing standard

Build trust into the bundle.

Start with one standalone ZIP. Racinage detects the catalog details, keeps source quarantined, and publishes only after automated and human review.

One ZIPDeclared accessNo execution on upload
01

How publishing works

Five predictable steps. Your source is never activated during upload.

01

Upload

Choose the complete ZIP. plugin.json must be at its root.

02

Automatic checks

Paths, size, manifest, entrypoint, and media are inspected without executing code.

03

Confirm details

Review the detected name, description, features, permissions, and catalog images.

04

Set terms

Explain pricing, plan limits, provider costs, support, refunds, and compatibility.

05

Human review

Racinage reviews security, privacy, tenant isolation, UX, and claims before publishing.

02

What plugin.json explains

The manifest is the contract between the author, Racinage, and the user.

{
  "slug": "meal-planner",
  "entrypoint": "runtime.php",
  "assets": { "logo": "assets/logo.webp" },
  "feedback": {
    "duration": 10000,
    "position": "center-top",
    "show_close_button": true
  },
  "capabilities": {
    "pages": ["/dash/plugin/meal-planner"],
    "functions": ["Read selected people"]
  }
}
Identity
Name, author, version, description, images, and support.
Runtime
Entrypoint, compatibility, routes, and dependencies.
Access
Pages, functions, data, and operations users will approve.
03

Declare access in plain language

Use a verb, a specific target, and the condition that allows it.

ClearRead people explicitly selected from a family account the user manages.Verb + data + scope + user condition
Too vagueAccess family data.No operation, boundary, or reason
04

Review requirements

Four groups make the standard easier to scan and harder to misunderstand.

Package

  • Keep every runtime file, asset, migration, translation, and dependency inside one plugin folder.
  • Use safe relative paths. Do not include secrets, user data, generated caches, or development credentials.
  • Local Free downloads receive a separate production-only portable artifact, never the reviewed source ZIP.

Images and media

  • Declare valid WebP files for the plugin logo, cover, screenshots, developer profile image, and developer cover.
  • Accept JPEG, PNG, or WebP uploads only when needed, then decode and re-encode them server-side as WebP instead of keeping the original file.
  • Strip image metadata and create at least a small list preview and a large detail or lightbox variant. Authorize private media before streaming it.
  • Non-WebP raster media may require release changes or cause rejection during review.

Permissions and data

  • Declare every page, data type, and read, create, change, or delete operation.
  • Scope every family-owned query and action to family_long_id and recheck permissions on the server.
  • Support secure export and import, plus Keep data or Delete data during uninstall.

Experience and support

  • Follow familiar Racinage patterns, Inter typography, responsive layouts, dark mode, and accessible labels.
  • Translate all visible text into English and French and show useful empty, loading, error, and success states.
  • Use the shared feedback popup API for transient success, warning, error, and information messages. Custom feedback is allowed when declared and accessible, but the shared API is recommended for interface consistency.
  • Give honest support targets, compatibility notes, changelogs, and real screenshots.

Trust and enforcement

  • No credential harvesting, spam, hidden tracking, permission bypass, destructive defaults, obfuscated code, or remote code execution.
  • Paid publishers must provide verified identity, payout, tax, pricing, support, and refund details.
  • Delisting stops discovery and new installs. Security revocation may disable an unsafe version without erasing family data.

Pricing, promotions, and renewals

  • Subscription plugins must state a monthly or yearly interval, renewal terms, refund conditions, and the 21-day grace period.
  • User publishers normally retain 80%. A seller-funded reduction is limited to the reviewed maximum approved by the publisher.
  • The platform blocks promotions that cannot preserve the publisher share and the full eligible affiliate commission.
  • After grace expires, paid runtime access pauses. Tenant data and authenticated exports remain retained and available according to the plugin terms.

Current library rules

  • Upload a complete ZIP bundle before entering listing and pricing details.
  • Declare every dashboard page, public route, background job, and host capability the plugin uses.
  • Keep all plugin code and assets inside one plugin folder and include a valid plugin.json manifest.
  • Request only the minimum data and permissions required for the advertised features.
  • Sanitize untrusted content, enforce tenant scope, protect state changes with CSRF, and never expose credentials.
  • Describe pricing, plan limits, data import/export, uninstall retention, and external providers clearly.
  • For subscriptions, publish the monthly or yearly interval, renewal terms, the 21-day grace period, and refund rules.
  • User publishers retain 80% of the listed price unless they approve a reviewed maximum seller-funded reduction; promotions cannot exceed that limit.
  • Use original or properly licensed code, media, fonts, templates, and trademarks.
  • Store bundled and user-uploaded raster images as WebP. Re-encode uploads server-side, strip metadata, and create small preview and large-view variants instead of serving original JPEG, PNG, or GIF files.
  • Declare only WebP logos, covers, screenshots, profile images, and other catalog media. Non-WebP raster media may require release changes or cause rejection during review.
  • Provide accurate screenshots, support details, release notes, tests, and rollback instructions.
  • Deleted plugins are hidden and disabled, while packages and tenant data may be retained for legal compliance and authenticated user data-access requests; retained data is not exposed to developers, staff interfaces, or third parties.
05

Final check

Use this before submitting a new plugin or update.

Before you submit

  • plugin.json contains the schema version, slug, name, author, version, category, entrypoint, logo, cover, screenshots, features, capabilities, compatibility, privacy, and support details.
  • The ZIP expands into one plugin folder and does not depend on source files scattered through the Racinage core.
  • The public description names every page, function, data type, and operation the plugin can manipulate.
  • Every setting, button, empty state, and error message is translated in English and French.
  • Transient action results use the shared feedback popup API or an explicitly disabled and accessible custom alternative.
  • Screenshots show the real plugin interface, not placeholder or misleading images.
  • All declared catalog images and stored raster uploads are WebP, with small preview and large-view variants where applicable.
  • The plugin works with the selected family account and does not mix data between families.
  • The package has been tested in light mode, dark mode, desktop, tablet, and mobile widths.

Common rejection reasons

  • Unsafe files, missing manifest, or suspicious paths.
  • Unclear permissions, privacy risks, or family-account data leaks.
  • Broken layout, untranslated user-facing text, or confusing install flow.
  • Misleading pricing, unsupported claims, or missing support details.
  • Catalog or uploaded raster media is stored as JPEG, PNG, GIF, or another non-WebP format.
Need to publish?

Request developer permission first. If you plan to sell paid plugins, complete the publisher payout profile before review.

Request developer permission