Managing Plugins

In the WPCloset ecosystem, a Plugin is a secure container for proprietary or managed code. While WPCloset is built to host your custom-coded tools, it also allows you to “adopt” plugins from the public WordPress repository to gain absolute control over their lifecycle.

The Concept of a Managed Plugin

A Plugin record in your dashboard serves as the central authority for a specific piece of software. It defines the software’s identity and acts as a parent for all the different versions you release to your fleet.

Managing plugins via WPCloset provides:

• Intellectual Property Protection: Your custom code is never exposed to the public; it is only accessible to authorized sites.
• Stability via Version Locking: By managing a public plugin within WPCloset, you prevent “surprise” updates from the public repo from breaking your sites. You decide exactly when a new version is safe to deploy.
• Unified Workflow: Whether a plugin is a custom build or a public tool, it follows the same deployment path through your environments (Staging, Production, etc.).

Adding Plugins to Your Vault

There are two primary ways to bring a plugin into WPCloset:

1. Custom Upload

If you have built a proprietary plugin, you can create a record and upload your .zip file directly. WPCloset automatically scans your code headers to extract metadata like the Author, Version, and Description.

2. Importing from WordPress.org

You can “bridge” any plugin from the public WordPress repository into your private vault.

• The Import Process: By providing a public plugin slug, WPCloset fetches the asset directly from the official WordPress repository and creates a permanent copy in your private vault.
• Instant Ownership: Once imported, that plugin is no longer “public” to your fleet. It becomes a managed asset, meaning your WordPress sites will stop looking to the public repository for updates and will only listen to the versions you approve in WPCloset.

Identity and “Update Hijacking”

The Slug is the unique identifier for your plugin (e.g., my-custom-slider).

• Slug Priority: If you host a plugin with a slug that matches one in the public repository, WPCloset is designed to “take over” that identity.
• The Firewall Effect: This ensures that your sites are “locked” to your vault. Even if the public developer releases a new version, your sites will not see it until you manually import that update into WPCloset and deploy it to your environments.

Versioning & Lifecycle

In WPCloset, the plugin record is the “Library Card,” but the Versions are the actual “Books.”

• Releasing New Versions: Each time you make a change (or import a new public update), you create a new Version record.
• Semantic Versioning: Sites use these numbers (e.g., 1.0.1 to 1.1.0) to trigger update notifications.
• Release Notes: You can add changelogs to each version so that site administrators know exactly what has changed before they click “Update.”

Distribution via Environments

Simply creating a plugin version does not automatically push it to every site. Distribution is controlled through Deployments to specific Environments.

• Staging vs. Production: You can deploy Version 2.0-beta to your Staging environment to test it on a few select sites, while keeping your Production fleet safely on Version 1.5.
• Instant Availability: The moment a version is “Toggled” as active for an environment, any site assigned to that environment will see the update available in its WordPress dashboard.

Use Cases for Plugin Management

• Hobbyists: Keep a “Utility Belt” plugin of your favorite snippets and keep them synced across all your personal blogs.
• Agencies: Prevent a public plugin update from breaking 50 client sites at once. Import the public plugin into WPCloset, test it on one staging site, and only then “Release” it to the rest of your clients.
• Enterprise: Manage internal proprietary tools (like an HR Portal connector) and “approved” public tools in a single unified dashboard, ensuring every departmental site stays on the organizationally-sanctioned version.