Managing Sites

In the WPCloset ecosystem, a Site represents a specific WordPress installation authorized to consume your private plugins and themes. Registration creates a secure, verifiable link between your repository and the remote server.

The Purpose of a Site Record

Registering a site record is the first step in establishing security. Rather than having a single “master key” for your repository, WPCloset treats every installation as a unique entity. This granular approach allows you to manage security and distribution at scale.

Each site record provides:

• Authentication: A unique digital identity that prevents unauthorized access to your code.
• Workflow Routing: A way to target specific sites with specific versions of your code (e.g., Staging vs. Production).
• Instant Revocation: The ability to immediately disconnect an installation without needing to modify the remote server’s files or database.

Registering a Site

When adding a site to your dashboard, you are defining the “Security Perimeter” for that specific installation.

Site URL (The Digital Fingerprint)

The Site URL is the primary way WPCloset identifies where a request is coming from.

• Exact Matching: The system is designed to only respond to the specific URL registered in your dashboard. If a request comes from an unauthorized domain, the repository remains “invisible.”
• Secure Protocol: Always use the https:// prefix. For security and integrity, the system views encrypted and unencrypted connections as distinct origins.

Site Status (The Availability Toggle)

The Is Active toggle gives you absolute control over the site’s connection to your repository.

• Active: The WordPress installation is authorized to check for updates and download assets.
• Inactive: The connection is severed. The site will no longer see your plugins in its “Add New” screen or receive update notifications. This is useful for retiring old projects, pausing maintenance, or managing subscription lifecycles.

Connecting the Installation

Once a site is registered in your dashboard, you must “handshake” with the remote WordPress instance using a unique API Key.

1. Retrieve the Key: Found in the Site Details screen of your WPCloset dashboard.
2. Paste and Validate: In the target WordPress site, go to Settings > WPCloset and save the key.

Identity Verification

Upon saving, the system verifies that the key being used belongs to the URL where the WordPress site is actually hosted. This “two-factor” validation (Key + URL) ensures that even if an API Key is accidentally leaked, it cannot be used to pull your assets onto a different, unauthorized domain.

Managing Workflows with Environments

WPCloset allows you to assign sites to one or more Environments (such as Production, Staging, or Local). This is the foundation of professional WPOps.

Targeted Distribution

Environments allow you to “fence off” different versions of your code. You can ensure that an experimental “Beta” version of a theme is only visible to your internal Staging or Local sites, while your Production fleet remains on a stable, locked version.

• Environment Assignment: You can toggle which environments a specific site is associated with at any time.
• Visibility Filtering: A site will only be notified of updates for versions that have been explicitly “Deployed” to its assigned environment.

Use Cases for Site Management

The flexibility of Site records supports various management styles:

• Individual/Hobbyist: Use a single Site record to keep your personal projects synced with your latest local code changes.
• Professional/Freelancer: Create separate Site records for your active projects to ensure you can revoke access individually if a project is handed off or archived.
• Agencies: Manage multiple client portfolios by grouping sites into Organizations and using Environments to safely test updates on staging URLs before pushing to live client domains.
• Enterprise: Manage hundreds of internal departmental sites by assigning them to specific tiers. Deploy critical security patches to all “Internal” sites simultaneously while keeping “Public Facing” sites on a different release schedule.

Best Practices

• Granularity is Safety: Always create a separate Site record for staging.example.com and example.com. Mixing them under one record compromises your ability to test updates safely.
• Key Rotation: If a site is moved to a different server or ownership changes, use the “Regenerate Key” feature to ensure the old environment can no longer access your repository.