> ## Documentation Index
> Fetch the complete documentation index at: https://docs.stackshift.cloud/llms.txt
> Use this file to discover all available pages before exploring further.

# WordPress plugin and theme releases

> Connect a WordPress plugin or theme repo, let StackShift package it into a release, preview it, promote draft/beta/stable channels, and install the exact release on a running StackShift WordPress site.

<Tip>
  **Live.** This area is documented as current, user-reliable behavior.
</Tip>

## Goal

Ship WordPress extensions through StackShift without manually exporting zip files, uploading through wp-admin, or guessing which version is installed.

## Prerequisites

* A WordPress plugin or theme repository
* A successful build artifact
* A StackShift WordPress site for live install

## Workflow

<Steps>
  <Step>
    Connect the plugin or theme repository to StackShift. The code stays in your repo; StackShift detects the WordPress extension and runs the configured build/package steps.
  </Step>

  <Step>
    Review the generated zip artifact, extension slug, version, checksum, and compatibility metadata.
  </Step>

  <Step>
    Open the isolated WordPress preview for the build and verify the plugin or theme before promoting it.
  </Step>

  <Step>
    Promote the artifact to draft, beta, or stable so the channel points at a specific release.
  </Step>

  <Step>
    Install the current release into a running StackShift WordPress site and track the install history.
  </Step>
</Steps>

## What StackShift does

StackShift does not replace your code editor. You still write the plugin or theme in your normal repository and push it to GitHub.

StackShift handles the release workflow around that repository: detection, build commands, zip packaging, preview, channel promotion, install into a running WordPress site, and install history.

## Release channels

* Draft is useful for internal handoff or early review.
* Beta is useful when the extension has passed preview and needs stakeholder testing.
* Stable is the release you intend to install on a running WordPress site.
* Promoting a new artifact to a channel makes it the current release for that channel without deleting older release history.

## Live install behavior

When you install a release, StackShift uses the exact promoted artifact. That gives you a clearer answer to what was installed, when it was installed, and which WordPress site received it.

Backup-before-install is part of the intended safe path when backup storage is configured for the environment.

## Common workflow

```bash From repo to WordPress site theme={null}
1. Push plugin/theme code to GitHub
2. Connect the repo to StackShift
3. Let StackShift build and package the extension zip
4. Preview the artifact in an isolated WordPress environment
5. Promote the artifact to draft, beta, or stable
6. Install that release into a running StackShift WordPress site
7. Review install history when you need to audit or recover
```

## Expected result

<Check>
  A WordPress extension release has a traceable artifact, preview, promotion channel, live install record, and backup-backed restore path.
</Check>

## Common failures

<Warning>
  * The project is not detected as a WordPress plugin or theme because the plugin header or theme style.css metadata is missing.
  * A beta or stable promotion is blocked until the build preview is running.
  * Backup-before-install fails if stack backup storage is not configured in the environment.
  * The target install is blocked if the selected target project is not a StackShift WordPress site.
</Warning>

## Related guides

<CardGroup cols={2}>
  <Card title="WordPress Control Surface" href="/wordpress/wordpress-control-surface">
    A first-class operational surface for direct WordPress projects: overview, narrow safe actions, diagnostics, and recent history.
  </Card>

  <Card title="Back up and restore a WordPress stack" href="/wordpress/back-up-and-restore-a-wordpress-stack">
    Use StackShift stack backups for WordPress content and bundled MariaDB data, then validate the app after restore.
  </Card>
</CardGroup>
