Developers — build with us

Contribute to the plugin. Get Pro access.

SiteHelm writes to live WordPress sites, so the bugs that matter are the ones found on real ones. If you run it against your own hosting, your own theme, your own plugin stack and find something wrong, that is worth more to this project than anything a test suite can tell us — and it is worth a Pro licence.

Everything is public: the repository, the issue tracker, the release (currently 0.6.0), and the main branch. There is no beta programme and no private build to be invited to.

Where to start

Two versions exist. Run either one.

The released plugin

The version everyone else is running. Bugs found here affect real installs today, which makes them the most valuable reports there are.

Download the current release zip from the download page or from GitHub releases.
Install it on a staging site — not a production site you cannot restore.
Work through the operations you actually care about. The documentation covers every one of them.
When something behaves differently from what the reference says, that is a bug report.

The current main branch

Not a preview programme — just the public repository at its latest commit, which anyone can clone at any time. It has no support promise and may be mid-change.

git clone https://github.com/Mrshahidali420/SiteHelm.git
cd SiteHelm
composer install
vendor/bin/phpunit

The suite runs on PHP 8.1 and above with no WordPress install required. CONTRIBUTING.md has the coding standard, the branch convention and what a pull request needs before it will be read.

1 stars · 0 forks · 0 open issues and pull requests. Figures come from the GitHub API and are cached for six hours.

Open the repository Report a bug

What it is worth

Approved contributions earn Pro, by band.

A maintainer decides which band a contribution falls into after reviewing it. Keep contributing and the licence keeps renewing.

1 month

A reproducible bug report

An issue with steps that reproduce it on a clean install, the versions involved, and what you expected instead. Confirmed by a maintainer.

An operation that refuses on a site where it should succeed
A preview that promises one thing and a write that lands another
A rollback that does not restore what the snapshot recorded

1 month

A documentation contribution

A merged pull request that makes the reference, the install guide, or the operations documentation correct or clearer.

An operation whose described behaviour no longer matches the code
An install step that is wrong on a particular host
A worked example for a dispatcher that has none

3 months

A merged bug fix

A pull request that fixes a real defect, with a test that fails before the change and passes after it.

A capability check that can be bypassed on a specific object type
An integration that breaks against a newer version of its plugin
A verification pass that reports success on a write that did not land

6 months

A new operation, merged

A complete operation: schema, capability, preview, snapshot, rollback, verification, tests, and its row in the reference.

An operation for an integration SiteHelm does not cover yet
A read that closes a gap an existing write depends on

12 months

A major contribution

Work that changes what the plugin is capable of, or removes a whole class of defect. Judged case by case.

A new module, end to end
A security finding with a fix, disclosed privately first
A performance or accessibility rework across the admin console

How it runs

Contribution → review → accepted → licence.

Use the public plugin. Install the released version from GitHub, or clone the repository and run the current main branch on a development or staging site. Both are public. There is no beta, no early access, and no private build to be invited to.
Find something worth fixing. Run it against a real site of your own. The most valuable reports come from a host, a theme, or a plugin combination nobody has tried yet.
Open an issue or a pull request. On GitHub, against the public repository. A bug report needs reproduction steps; a pull request needs a test. CONTRIBUTING.md has the full standard, and the test suite runs on your machine.
A maintainer reviews it. If it is merged, or the report is confirmed and acted on, it qualifies. Volume does not: five trivial pull requests are not a contribution, and reformatting is not a fix.
The licence is issued. A Pro licence key for the band the contribution falls into, sent to the email on your GitHub account, with its expiry recorded. Contributors who keep contributing keep the licence.

What does not qualify

Opening an issue that is already open
Whitespace, formatting, or dependency-bump pull requests
A pull request that does not pass the existing test suite
Reporting behaviour the documentation already describes as intended
Adding your name to a contributors file

Nothing is granted automatically from GitHub activity. Every licence on this programme was issued by a person who read the contribution first, and a contribution can be recorded, approved and still take a few days to reach a key.

Found a security problem? Do not open an issue. Follow SECURITY.md and report it privately — that route has its own band.

Your record

What has been recorded against your account.

Sign in with GitHub Signing in reads your public profile and nothing else — no repository access is requested. It exists so contributions can be matched to your GitHub login and so you can see what has been recorded.

Credit

Everyone with a commit in the plugin.

Mrshahidali420

Read from the GitHub API and cached. A login, an avatar and a link to the profile — nothing else is read, and there is nothing to correct here that is not already yours to change on GitHub.