Bluehost WordPress Plugin

WordPress plugin that integrates a WordPress site with the Bluehost control panel, including performance, security, and update features.

Installation

Find the bluehost-wordpress-plugin.zip asset for your preferred version at: https://github.com/newfold-labs/wp-plugin-bluehost/releases/.

Alternatively, check the release API endpoint for the latest version: https://hiive.cloud/workers/release-api/plugins/newfold-labs/wp-plugin-bluehost?slug=bluehost-wordpress-plugin&file=bluehost-wordpress-plugin.php. Access the zip download directly.

Testing Pull Requests

WordPress Playground Preview

Pull requests automatically generate WordPress Playground preview links for one-click browser-based testing. When you open a PR or push new commits, two automated workflows run:

1. Build Plugin - Builds the plugin and creates a GitHub Actions artifact
2. WordPress Playground Preview - Deploys the built plugin to GitHub Pages and posts a Playground preview link

The Playground preview link allows reviewers and contributors to test changes instantly in a complete WordPress environment without any local setup.

Initial Setup (One-time)

GitHub Pages must be enabled for the Playground preview workflow to function:

1. Go to repository Settings → Pages
2. Under Source, select GitHub Actions
3. Save the configuration

Once enabled, all future PRs will automatically receive Playground preview links.

What Gets Posted

Each PR will have two comment links:

• Download Build Artifact - Download the built plugin zip from GitHub Actions (requires GitHub login, expires in 90 days)
• Launch Preview in Playground - One-click link to test the plugin in WordPress Playground (public, no login required)

Security Note

For security reasons, Playground preview links are only generated for pull requests from branches within this repository, not from forks. This prevents potential privilege escalation where untrusted code from forks could trigger workflows with write access to GitHub Pages and pull requests.

Fork contributors will still receive the build artifact download link for manual testing. If you need a Playground preview for a trusted fork PR, a maintainer can manually trigger the deployment workflow after reviewing the changes.

Releasing Updates

Release Steps

Review the version control and releases "How We Work" docs for more information.

Release Script

There is a release script in place to increment the release, perform a build, and update i18n files all at once. Run npm run set-version-bump to have thescript handle a patch version bump. Also available are npm run set-version-bump --minor and npm run set-version-bump --major for those respective releases.

Manual Release

This plugin has version number set in 3 distinct places in 2 files. There is have a validation for proper versioning in the release workflow. All 3 instances need to be incremented in conjuction with new releases via github tagging:

• The plugin header info (bluehost-wordpress-plugin.php line 14) - this is used in the plugin php code.
• The constant BLUEHOST_PLUGIN_VERSION (bluehost-wordpress-plugin.php line 34) - this is used by WordPress.
• In the package.json version value (package.json line 5) this is used by the build step to place the release files within a matching version directory for convenient cache busting.

Pre-Releases Process

• Once code in the develop branch is ready for release testing, a X.Y.Z-alpha.1 version should be created and MUST be tagged as a pre-release. Subsequent alpha releases should increment the last digit of the version (e.g. X.Y.Z-alpha.2). Alpha releases are open to having new features added and/or bugs fixed. Tagging a release will trigger the full test matrix. Any test failures should be addressed.
• After all features are finalized and added to the release, a beta version should be tagged and MUST be marked as a pre-release. Beta releases are only open to having bugs fixed. Version numbers should follow the same pattern as the alpha versions (e.g. X.Y.Z-beta.1). Tagging a release will trigger the full test matrix. Any test failures should be addressed.

Detailed Production Release Process

Steps to follow when releasing a new version of the plugin:

• Schedule the release with the team.
• Ensure that the develop branch is up-to-date with the latest changes.
• Create a release branch for this release: release/X.Y.Z branching from develop.
• Ensure release branch has properly bumped the version.
  • The plugin header version.
  • The plugin constant version.
  • The plugin package version.
• Ensure the release branch has passing tests.
• Ensure the release branch passes linting.
• Tag an initial release candidate version of the plugin (e.g. X.Y.Z-rc.1) and be sure to mark it as a pre-release.
• Ensure that the release branch passes the full test matrix.
• Alert the team via chat and announce that the latest build is available for testing.
• Download the latest build and install on a site for manual testing.
• Confirm no issues are found in testing.
• If issues are found, push changes directly to the release branch, tag a new pre-release version (e.g. X.Y.Z-rc.2) and run through the manual testing process again.
• When ready to release, merge the release branch into the master branch and be sure any changes made directly on the release branch are also merged back into the develop branch.
• Create a new release tagged (X.Y.Z) and named (Version X.Y.Z) for the version. This should NOT be marked as a pre-release.
• Ensure the satis build is triggered and completes.
• Ensure that the update API displays the release as latest/current version.
• Alert the team via chat to announce the end of the release process.
• Watch for the plugin release to rollout in Hiive or monitor by running a query against the Hiive.

Style and Design

See this figma for a style guide.

How We Work

Newfold Labs is an interdisciplinary product and engineering team at Newfold Digital creating next-generation solutions that support our customers and our business. Learn more about how we work.