Operate WordPress

synsmarts provides the managed runtime and services. Your deploy source provides the WordPress application, including WordPress core, plugins, themes, and application configuration.

Prepare the source

A WordPress deploy must use one of these source layouts:

• a complete WordPress tree with wp-load.php and wp-config.php at the selected source root; or
• a Composer-managed layout such as Bedrock that installs WordPress core during the build and provides the root wp-config.php expected by the runtime.

Both layouts must include every custom plugin, theme, and must-use plugin required by the release.

Don’t hardcode DB_NAME, DB_USER, DB_PASSWORD, or DB_HOST in wp-config.php. Read database connection values with getenv() so synsmarts can inject the environment-specific values.

When composer.json is present, the build runs:

Install production Composer dependencies

composer install --no-dev --optimize-autoloader --no-interaction

Include composer.lock when Composer manages any production dependency. Commit it when using Git.

Choose the source for each release

Each release explicitly uses Git or Workspace:

• Choose Git when the intended release is a branch, tag, or commit in the connected repository.
• Choose Workspace when the intended release is the current server-side files prepared through SSH, SFTP, SCP, or another deployment tool.

When a repository is connected, both sources remain available. A Workspace deploy doesn’t commit its files to Git. After a successful Git deploy, synsmarts attempts to refresh non-preserved Workspace code from the built release. Refresh failure doesn’t block the Git release and can leave older code in Workspace. A later Git deploy whose Workspace refresh succeeds can remove non-preserved changes that exist only in the Workspace. Make the equivalent repository change when it must survive future Git releases.

Deploy a release

1. Confirm the source contains WordPress core or a dependency declaration that installs it.
2. Confirm wp-config.php reads database credentials from environment variables.
3. Run your project tests and dependency security checks.
4. Deploy an exact Git commit when reproducibility matters, or deploy the current Workspace when those server-side files are the intended release.
5. Follow the deploy until it completes.
6. Test the home page, WordPress admin, login, media upload, and any checkout or form path used by the site.

WordPress deploys are treated as code-only releases. synsmarts doesn’t statically classify plugin database changes and doesn’t create a dedicated pre-migration backup for a WordPress deploy. Database changes performed by WordPress core or a plugin can still affect compatibility, so review release notes and verify a recent backup before a high-risk update.

See Manage deploys and Use the synsmarts CLI.

Use WP-CLI

The managed SSH shell includes WP-CLI for WordPress Apps. Start with read-only checks:

Inspect WordPress from the managed shell

wp core version
wp plugin status
wp theme status
wp cron event list

Mutating WP-CLI commands change the Workspace:

• To publish the current result, submit a Workspace deploy.
• If the change must survive future Git deploys, make the equivalent dependency, plugin, theme, or core change in the repository and deploy that Git revision.

Don’t assume wp core update, wp plugin update, or wp theme update also updates the connected repository.

Schedule recurring work

New WordPress Apps include a Scheduled Job named wp-cron. It runs every minute with Forbid concurrency and executes due events through WP-CLI. The App also starts with DISABLE_WP_CRON=true, so web requests don’t start a second, traffic-driven scheduler.

The seeded job is an ordinary customer-owned Scheduled Job. It is visible, editable, pausable, and deletable; counts toward the 50-job limit; and isn’t recreated after deletion. To return to traffic-driven WordPress cron, set DISABLE_WP_CRON=false under Vars and secrets and remove or pause the wp-cron job. Do both so the two schedulers can’t run the same event.

Use Scheduled Jobs for commands that must run independently of web traffic. Before moving a recurring task, confirm it isn’t also triggered by a plugin, system cron, or request-driven WordPress cron. Duplicate schedulers can run the same task twice.

Useful verification commands include:

Inspect and run due WordPress events

wp cron event list
wp cron event run --due-now

Use the manual run only for controlled verification. Keep the durable schedule in Scheduled Jobs and review its run history after deployment.

See Manage scheduled jobs.

Manage media and persistent data

Treat these as separate release concerns:

• application code belongs in the selected Git revision or Workspace snapshot;
• database content belongs in MySQL and is protected by database backups;
• uploaded media belongs in managed media storage and is protected by media version history.

Don’t commit production uploads to the code repository or expect code rollback to restore database or media state.

See Manage backups before a risky change.

Update WordPress safely

1. Review the WordPress, plugin, and theme compatibility requirements.
2. Update the source intended for the release and its lock file.
3. Test the combined change outside production.
4. Take or verify a recent backup for changes that may alter the database.
5. Deploy one reviewable release.
6. Verify admin login, scheduled jobs, forms, media, and customer-facing paths.
7. Review diagnostics and application logs for new warnings or failures.

synsmarts updates the runtime and managed services, but WordPress core and customer-selected plugins and themes remain your responsibility.

Troubleshoot a release

• A build that reports missing wp-config.php needs that file at the source root.
• A build that reports hardcoded database credentials needs getenv()-based configuration.
• A coreless build needs a full WordPress tree or a Composer project that installs core.
• A plugin failure should be reproduced with the exact deployed Git revision or captured Workspace release before changing unrelated services.
• A scheduled task failure should be checked in Scheduled Jobs run history and then reproduced with the same command in the managed shell.

Use Review diagnostics and Get support when the failing layer isn’t customer code.