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: