See llms.txt for all machine-readable content.

Back to Templates

Update and roll back WordPress plugins and themes via SSH with Groq analysis

Quick overview

This workflow runs on a schedule or manually to update WordPress plugins and themes over SSH using WP-CLI, verifies site health with HTTP checks and log inspection, automatically rolls back breaking updates, and emails an HTML report with optional Groq AI analysis of failures.

How it works

  1. Copy selfheal.sh from the GitHub repository (github.com/Christianzimpel/n8n-wp-self-healing-update-agent) to ~/wp-selfheal/selfheal.sh on your server. Provide an SSH private key credential with access to the WordPress server and make sure the server has WP-CLI, PHP CLI, tar, and curl available.
  2. Connects to the server via SSH, checks that the helper script is installed, backs up the database, enables temporary debug logging, and fetches the list of available plugin and theme updates.
  3. If no updates are available or the preparation step fails, sends an email indicating everything is up to date or that the run was aborted.
  4. Processes each plugin and theme update one at a time over SSH by backing up the component, running the WP-CLI update, and building one or more URLs to check.
  5. After each update, requests the configured site paths over HTTP and checks via SSH whether WordPress boots and whether new PHP fatal errors appear, then marks the update as successful or schedules a rollback.
  6. If the site appears broken, restores the plugin/theme from its backup over SSH, and if rollback fails, stops further updates and sends an emergency email.
  7. After all items (including a retry round for previously rolled-back/failed items), restores debug settings, optionally sends failure logs to Groq for analysis, and emails a consolidated HTML report.

Setup

  1. Provide an SSH private key credential with access to the WordPress server and ensure the server has WP-CLI, PHP CLI, tar, and curl available.
  2. Update the Configuration values for siteUrl, wpPath, wpCli, and checkPaths, and (optionally) set phpErrorLog, keepDays, and maxAttempts to match your environment.
  3. Add an SMTP/email credential and set the mailTo and mailFrom addresses used for the report, no-updates notice, aborted-run notice, and emergency alert.
  4. Add a Groq credential (or replace the Groq model with another supported chat model) if you want AI-generated analysis included in the report.
  5. Verify the schedule in the Monday 4 AM trigger (or disable it) and run the workflow manually against a staging site before enabling it in production.