Problem
Data Machine cannot be installed cleanly from a tagged release into a standard WordPress site (or a Playground blueprint via `installPlugin: git:directory`) because the plugin's entry file `data-machine.php` does:
```php
require_once DIR . '/vendor/autoload.php';
```
`vendor/` is correctly gitignored — composer dependencies should not live in version control. But that means:
- A user cloning the repo and dropping it into `wp-content/plugins/` gets a fatal on activation.
- A WordPress Playground blueprint using `resource: git:directory` to pull the source from GitHub gets the same fatal.
- A site administrator downloading the GitHub source zip and uploading it through wp-admin gets the same fatal.
The fix that every other distributed WordPress plugin uses is to publish a vendor-bundled release artifact (typically a `.zip` with `composer install --no-dev --optimize-autoloader` already run) attached to the GitHub Release as a downloadable asset.
Concrete failure
Today I tried to add Data Machine to the public Playground blueprint at `chubes4/world-of-wordpress/blueprints/world.json` so the runtime a visitor sees matches the runtime the agent wakes into during a CI day cycle. Activation fataled:
```
Fatal error: Uncaught Error: Failed opening required '/wordpress/wp-content/plugins/data-machine/vendor/autoload.php'
(include_path='.:') in /wordpress/wp-content/plugins/data-machine/data-machine.php:26
```
CI runs work because `homeboy-action`'s reusable workflow clones each dependency repo into `.ci//` and runs `composer install --no-dev --prefer-dist` on the host before bind-mounting the directory into Playground. The public Playground path through `git:directory` has no such hook.
What this issue asks for
Add a release-artifact build step to the existing homeboy-action release flow in `.github/workflows/homeboy.yml`. When homeboy-action creates a release (push to main with releasable conventional commits), a follow-up job should:
- Check out the tagged commit.
- Run `composer install --no-dev --optimize-autoloader --prefer-dist`.
- Run the existing `npm run build` to produce the wp-scripts admin UI bundle.
- Stage everything into a clean `data-machine/` directory excluding `tests/`, `docs/`, `.github/`, `node_modules/`, `*.md` other than `README.md`, etc.
- Zip it as `data-machine.zip`.
- `gh release upload data-machine.zip`.
The released ZIP becomes the canonical distributable: drop it into `wp-content/plugins/` and the plugin activates cleanly.
Why this matters beyond Playground
- wp-coding-agents installs that pull DM into a local Studio site can use the release zip instead of running composer locally.
- A8C Intelligence WP Cloud deploys can deploy from a release zip via Homeboy's plugin deploy path without depending on composer being available on the destination.
- Future installs we haven't planned yet — any consumer that wants "DM as a normal WordPress plugin" gets one.
Suggested workflow shape
```yaml
build-release-asset:
if: needs.homeboy.outputs.released == 'true'
needs: [homeboy]
runs-on: ubuntu-latest
permissions:
contents: write
steps:
- uses: actions/checkout@v4
with:
ref: ${{ needs.homeboy.outputs.release-tag }}
- uses: shivammathur/setup-php@v2
with: { php-version: '8.3' }
- uses: actions/setup-node@v4
with: { node-version: '20' }
- run: composer install --no-dev --optimize-autoloader --prefer-dist --no-interaction
- run: npm ci && npm run build
- run: |
cd ..
mkdir -p dist/data-machine
rsync -av --exclude-from=data-machine/.gitignore \
--exclude='tests' --exclude='docs' --exclude='.git' --exclude='.github' \
--exclude='node_modules' --exclude='phpstan-baseline.neon' --exclude='phpunit.xml*' \
data-machine/ dist/data-machine/
# restore vendor (excluded by .gitignore)
cp -r data-machine/vendor dist/data-machine/vendor
cd dist && zip -r data-machine.zip data-machine
- run: gh release upload "${{ needs.homeboy.outputs.release-tag }}" ../dist/data-machine.zip
env:
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
```
Exact rsync exclude list to be tuned to match what a distribution actually needs.
Related issue in data-machine-code
Filing the matching issue against `Extra-Chill/data-machine-code` — same gap, same fix.
AI assistance
- AI assistance: Yes
- Tool(s): Claude Code (Sonnet 4.5)
- Used for: Diagnosed the activation fatal in a Playground blueprint test, traced the difference between CI and public Playground install paths, and drafted this issue with a concrete proposed workflow shape. Chris specified the principle: the public Playground should be the same runtime the agent works on, and the right fix is upstream release artifacts rather than a workaround in the blueprint.
Problem
Data Machine cannot be installed cleanly from a tagged release into a standard WordPress site (or a Playground blueprint via `installPlugin: git:directory`) because the plugin's entry file `data-machine.php` does:
```php
require_once DIR . '/vendor/autoload.php';
```
`vendor/` is correctly gitignored — composer dependencies should not live in version control. But that means:
The fix that every other distributed WordPress plugin uses is to publish a vendor-bundled release artifact (typically a `.zip` with `composer install --no-dev --optimize-autoloader` already run) attached to the GitHub Release as a downloadable asset.
Concrete failure
Today I tried to add Data Machine to the public Playground blueprint at `chubes4/world-of-wordpress/blueprints/world.json` so the runtime a visitor sees matches the runtime the agent wakes into during a CI day cycle. Activation fataled:
```
Fatal error: Uncaught Error: Failed opening required '/wordpress/wp-content/plugins/data-machine/vendor/autoload.php'
(include_path='.:') in /wordpress/wp-content/plugins/data-machine/data-machine.php:26
```
CI runs work because `homeboy-action`'s reusable workflow clones each dependency repo into `.ci//` and runs `composer install --no-dev --prefer-dist` on the host before bind-mounting the directory into Playground. The public Playground path through `git:directory` has no such hook.
What this issue asks for
Add a release-artifact build step to the existing homeboy-action release flow in `.github/workflows/homeboy.yml`. When homeboy-action creates a release (push to main with releasable conventional commits), a follow-up job should:
The released ZIP becomes the canonical distributable: drop it into `wp-content/plugins/` and the plugin activates cleanly.
Why this matters beyond Playground
Suggested workflow shape
```yaml
build-release-asset:
if: needs.homeboy.outputs.released == 'true'
needs: [homeboy]
runs-on: ubuntu-latest
permissions:
contents: write
steps:
- uses: actions/checkout@v4
with:
ref: ${{ needs.homeboy.outputs.release-tag }}
- uses: shivammathur/setup-php@v2
with: { php-version: '8.3' }
- uses: actions/setup-node@v4
with: { node-version: '20' }
- run: composer install --no-dev --optimize-autoloader --prefer-dist --no-interaction
- run: npm ci && npm run build
- run: |
cd ..
mkdir -p dist/data-machine
rsync -av --exclude-from=data-machine/.gitignore \
--exclude='tests' --exclude='docs' --exclude='.git' --exclude='.github' \
--exclude='node_modules' --exclude='phpstan-baseline.neon' --exclude='phpunit.xml*' \
data-machine/ dist/data-machine/
# restore vendor (excluded by .gitignore)
cp -r data-machine/vendor dist/data-machine/vendor
cd dist && zip -r data-machine.zip data-machine
- run: gh release upload "${{ needs.homeboy.outputs.release-tag }}" ../dist/data-machine.zip
env:
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
```
Exact rsync exclude list to be tuned to match what a distribution actually needs.
Related issue in data-machine-code
Filing the matching issue against `Extra-Chill/data-machine-code` — same gap, same fix.
AI assistance