SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsmaintain-wordpress

maintain-wordpress

Deployment & operations

View repository

Updated 10-15 22:14

About this skill

Maintain WordPress

Check first, report, then update only what the user approves — one site at a time, proving each still loads before moving to the next.

Calling the operations

  • Read the inputSchema that search returns before the first call of each operation. If a name below is rejected as unknown, search for what the step does (e.g. "wordpress plugins update").
  • Batch reads with multi-execute (up to 20 steps a batch). Batches chain operations from one server only — the Hostinger Connector runs wordpress, hosting and agency-hosting as separate servers.
  • Updates, activations, uninstalls and core changes are queued jobs: a success response means "queued". Poll the matching read operation every 10–20 s until the change shows; never re-send the write.

1. Find the installs

  • One site: wordpress_installations_list with domain (substring match — take the exact entry). Every site: wordpress_installations_list without filters, adding ownership: "all" to include sites the user manages for others.
  • Keep id (the software parameter of every wordpress_* call), username, domain, directory, is_valid and validation_error.
  • Agency Plan WordPress sites come from agency-hosting_websites_list-plan with website_types: ["wordpress"]. When wordpress_installations_list does not include them, only agency-hosting_wordpress_settings and core version changes (agency-hosting_wordpress_list-versions, agency-hosting_wordpress_change-version) are available; plugins and themes are updated from wp-admin.

2. Check (read-only)

Per install:

  • wordpress_installations_show-core-version — core version and the known vulnerabilities that affect it.
  • wordpress_installations_list-core-updates — available core versions.
  • wordpress_plugins_list-installed — status, update (the newer version, when there is one) and vulnerabilities[] with fixed_in.
  • wordpress_themes_list-installed — the same for themes.

Four steps per install fit five installs in one batch. For an install with is_valid: false, run wordpress_installations_check-if-are-valid with force: true for a fresh reason and leave it out of updates — a broken install is the troubleshoot-website skill's job.

3. Report before changing anything

## example.com (WordPress 6.8.1)
Vulnerable: contact-form-x 5.2 → fixed in 5.3 (update available)
Vulnerable, inactive: old-slider 1.0 — no fix; uninstall recommended
Updates: core 6.8.1 → 6.8.3 (minor), 4 plugins, 1 theme

Vulnerable items come first. A vulnerable plugin without a fix, or an inactive one, is better removed with wordpress_plugins_uninstall than left installed — inactive code on disk can still be reached. Ask which updates to apply.

4. Back up first

The API has no backup operation. Before updating, ask the user to create a backup in hPanel or confirm the latest automatic one is recent enough. Say it plainly; the user may choose to go ahead without one.

5. Update, one site at a time

  1. Plugins that fix a vulnerability — wordpress_plugins_update with their slugs.
  2. The remaining approved plugins, then themes with wordpress_themes_update.
  3. Core with wordpress_installations_update-core: minor: true for patch releases; a major version only when the user asks for it.

For a busy site the user may want wordpress_maintenance_toggle with enabled: true during the run — and it is always turned off again afterwards, even when something failed.

After each site:

  1. wordpress_litespeed-cache_purge-lite-speed.
  2. curl -s -o /dev/null -w "%{http_code}\n" https://DOMAIN/ and the same for https://DOMAIN/wp-login.php — both should be 200 with no PHP error in the body.
  3. wordpress_installations_check-if-are-valid with force: true.

When a site breaks: stop the run, deactivate the plugin updated last with wordpress_plugins_deactivate, check again, and report which update caused it before touching any other site.

6. Performance and access

  • Page cache: wordpress_litespeed-cache_show-lite-speed-status; purge after design or content changes.
  • Object cache: wordpress_object-cache_show-memcached-status, then wordpress_object-cache_toggle-memcached with enabled: true — the usual quick speed-up.
  • PHP version: hosting_php_get is large (around 25 KB), so read it only when the user asks about PHP. PHP 8.x is markedly faster than 7.x; confirm plugin compatibility before hosting_php_update-version.
  • wp-admin: wordpress_login_create-links returns temporary one-click login links. Give them to the user only; never store or reuse them.
  • Hostinger's own plugins update with wordpress_plugins_update-hostinger (slug).

Many sites

Tell the user how many installs there are before starting. Check in batches, keep one running report, and update site by site so a failure stops the run with the rest untouched.