Greenskeeper

Changelog

2.1.9

  • Feature: Resend from Update Log — each session in the Update Log now
    has a “Send Report →” button that navigates to the Email Reports page
    with that session pre-loaded. If the session was previously emailed,
    an amber notice shows when it was sent and to whom. The subject line
    is automatically prefixed with [Updated Report] and the email body
    includes a blue banner informing the recipient this is an update to
    a previously sent report, with the original send date and time.
  • Fix: Manual updates on the Email Reports page are now always included
    alongside the automated session log entries when sending — previously
    adding manual entries caused only the manual entries to appear in the
    email, dropping the full automated update list.

2.1.8

  • Fix: Email Reports scope selector now honored on multisite (Codex
    audit issue #3). When a specific site is selected in Network Admin,
    the Email Reports page now switches to that site’s context before
    reading the recipient email, site name, site URL (for the subject
    line), pending sessions, last session, default administrator, and
    email log history.
  • Fix: Scoped update filtering no longer applied in wrong blog context
    (Codex audit issue #4). A redundant second filtering pass read
    active_plugins and active theme AFTER restore_current_blog() was
    called, filtering against the main site instead of the selected site.
    Removed — the first pass already filters correctly using values
    captured while switch_to_blog() was active.
  • Fix: Removed blocking wp_update_plugins() and wp_update_themes()
    calls from wpmm_get_available_updates() which is called from AJAX.
    These caused HTTP 500 on managed hosting (Kinsta, WP Engine).
  • Fix: Performing administrator no longer lost on page navigation
    (Codex audit issue #5). The admin_id selected on the Updates page
    is now stored in wpmm_pending_sessions alongside the session_id.
    When the email is sent from the Email Reports page (cross-page flow),
    the stored admin_id is read from the most recent pending session
    rather than defaulting to 0. Falls back to the site default admin
    if no session admin_id is available. Previously all of these were read from the main
    site regardless of which site was selected in the scope bar.

2.1.7

  • Feature: Site Activity Log — a new dedicated admin page that tracks and
    logs key site events including user logins, failed login attempts,
    logouts, password resets, user account creation and deletion, role
    changes, plugin activation/deactivation/deletion, theme switches,
    WordPress core updates, and key settings changes. Built with GDPR
    compliance as a first principle: IP addresses are anonymised by default
    (last octet of IPv4 / last 80 bits of IPv6 zeroed), a configurable
    retention period (default 90 days) auto-purges old entries via daily
    wp-cron, a full CSV data export tool supports Subject Access Requests,
    and all entries can be bulk-deleted at any time. Full IP storage is
    available as an explicit opt-in for sites with a documented legitimate
    purpose. The activity log can be enabled or disabled independently from
    a new section in Greenskeeper Settings.

2.1.6

  • Feature: Administrator notes are now stored permanently with each sent
    email. Previously the note was only included in the rendered email body
    at send time — if the template changed, historical previews lost the
    note. A new ‘note’ column is added to wpmm_email_log (existing installs
    are upgraded automatically on first load). The raw note text is stored
    separately from the HTML body so previews always show the exact note the
    administrator typed, regardless of how the email template has evolved.
    The preview modal displays the note in a prominently styled amber block
    above the email iframe. Emails sent before v2.1.6 show no note block
    (null note value) — only emails sent from this version onward will have
    the note stored.

2.1.5

  • Fix: Update Notes field content was being added below the spam section
    where it was easy to miss. Note now appears prominently at the top of the
    email body immediately below the report heading, ensuring clients always
    see administrator notes before the update tables.
  • Fix: Failed update rows in the email template now use amber styling
    (“Needs Attention” with amber background) instead of large red text
    (“Update Failed” in red). License-gated plugins show a friendly
    client-facing message instead of a technical error code. DEBUG diagnostic
    strings are stripped from messages before they reach the client email.
  • Fix: iThemes Security Pro, Google Site Kit, and ShortPixel Image
    Optimizer were being deactivated after updates and not restored.
    These plugins intentionally self-deactivate during their update
    process via their own upgrader_process_complete hooks, then expect
    the updater to re-activate them afterward. The previous snapshot/
    restore approach ran before these self-deactivation hooks fired and
    therefore could not catch them.
    Added a new wpmm_post_update_reactivate() hook on
    upgrader_process_complete at priority 99 — deliberately very late
    so it runs after all plugin-specific hooks. It has two jobs:
    (1) Re-activate the plugin that Greenskeeper just updated if it
    ended up inactive after its own hooks ran; (2) Restore any other
    plugin that was active before the update but is now inactive as
    collateral damage. Uses is_plugin_active_for_network() on multisite
    to correctly handle network-activated vs site-activated plugins,
    and activate_plugin($slug, ”, $is_network) accordingly.

2.1.4

  • Fix: PHP Warning “Undefined variable $api_key” on the Settings page.
    The variable was renamed to $api_key_set in v2.0.5 but one reference
    in the REST API endpoints section was not updated.
  • Fix: Email reports only showing the most recent session when multiple
    unsent sessions exist. The pending sessions list is now always cleared
    after any successful send, regardless of whether it was triggered from
    the Updates page or the Email Reports page.
  • Fix: WooCommerce and other hook-sensitive plugins (WP Rocket, Wordfence,
    Really Simple SSL) not fully restored after collateral deactivation.
    These plugins register activation hooks that are bypassed by direct
    option writes. After the option write, activate_plugin() is now called
    for any hook-sensitive plugin in the restore list to ensure their
    activation hooks fire and they are fully re-initialized.
  • Fix: Sent Email History row not appearing after send when the email
    log database insert returns ID 0 (can occur on multisite when the
    email_log table is in a different blog context). A timestamp-based
    fallback row ID is now used when email_id is 0, ensuring the row
    always appears immediately in the history table.

2.1.3

  • Fix: HTTP 500 errors on some multisite networks caused by the per-site
    snapshot loop introduced in v2.1.1. Both the snapshot and restore loops
    are now wrapped in try/catch blocks for graceful fallback.
  • Fix: HTTP 500 caused by premium plugins with custom updater libraries
    (e.g. WP Offload Media Pro / Delicious Brains updater) throwing ValueError
    or other exceptions during Plugin_Upgrader::upgrade(). All four upgrader
    calls (plugin normal path, plugin injected-entry path, theme normal path,
    theme injected-entry path) are now wrapped in try/catch Throwable blocks.
    When a plugin’s own updater throws an exception, Greenskeeper catches it
    and returns a descriptive error message rather than an HTTP 500, directing
    the user to update via Dashboard → Updates as a fallback.

2.1.1

  • Fix: Plugins activated only on a specific sub-site (not network-activated)
    could still be deactivated by collateral damage during updates. Previous
    versions only snapshotted the primary site’s active_plugins and the network
    active_sitewide_plugins — missing plugins like Custom Post Type UI that are
    activated per-site on individual sub-sites. The snapshot now reads
    active_plugins from every site in the network. The restore checks each
    sub-site’s current active_plugins against its snapshot and re-activates
    any plugin that was deactivated as collateral damage. The updated snapshot
    is persisted back to the network transient so retries also have access to
    the corrected per-site state.

2.1.0

  • Critical fix: network-activated plugins (AIOSEO, Co-Authors Plus,
    Gravity Forms, Sucuri) were still being deactivated on subdirectory
    multisite networks despite the v2.0.8 fix. Three root causes identified
    and resolved: (1) the snapshot was being taken AFTER switch_to_blog(),
    meaning it captured the sub-site plugin list rather than the main site
    network state; (2) per-blog transients (get_transient/set_transient)
    were used for the snapshot, which are stored in the current blog’s
    options table and lost when blog context switches mid-request — replaced
    with network-level site transients (get_site_transient/set_site_transient);
    (3) restore_current_blog() was called after reading the post-update plugin
    state, meaning the comparison was in the wrong blog context — blog context
    is now restored before reading post-update state so both snapshot and
    post-update reads happen in the same (main site) context.

2.0.9

  • Critical fix: HTTP 500 errors on managed hosting (Kinsta, WP Engine)
    during plugin and theme updates. Root cause: wp_update_plugins() and
    wp_update_themes() make loopback HTTP requests back to the WordPress.org
    API. When called from within an AJAX request, these loopback requests
    are blocked or time out on managed hosting, causing the outer AJAX
    request to return HTTP 500. All blocking wp_update_plugins/themes()
    calls during AJAX update requests have been replaced with a non-blocking
    wp-cron background event (wpmm_refresh_update_transient) that fires
    after the request completes. The upgrader proceeds with the existing
    transient URL and the next retry benefits from the refreshed URL.

2.0.8

Critical fix: network-activated plugins (Site Kit, Sucuri, Clarity) restored after collateral deactivation.
Email: multiple sessions grouped by date with clear headers.
Email history: live AJAX update after send. Unit tests added.

2.0.7

Backup warning modal before any update. Collateral deactivation restore improved with session-keyed transient.

2.0.6

Fix: collateral plugin deactivation — active plugins snapshotted before each update and restored after.

2.0.5

Security: cross-site AJAX cap bypass (#1), Akismet site scoping (#7), spam log actions (#8), REST API key hashed (#9).
Fix: All-Sites network email order (#2), dashboard date (#6), log pagination in SQL (#10), false success banner (#11).

2.0.4

Feature: email reports accumulate all unsent sessions — separate plugin/theme updates combined into one email.

2.0.3

Fix: AIOSEO Pro incorrectly flagged as manual update — scan now refreshes before deciding.

2.0.2

Fix: Divi and premium themes now update correctly — freshness check, skin error surfacing, auto-retry.

2.0.1

Fix: Jetpack copy error now reported correctly. Gravity Forms add-ons show manual update warning.

2.0.0

Premium plugin updates confirmed working. Auto-retry with fresh signed URL. AIOSEO Pro verified.

1.9.9

Diagnostic build for AIOSEO Pro null result issue.

1.9.8

Fix: AIOSEO Pro reporting “version unchanged” — auto-retry with fresh signed URL.

1.9.7

Premium plugin updates: forces fresh wp_update_plugins() when package URL is stale.

1.9.6

Critical fix: prevent premium plugin deactivation on failed updates.

1.9.5

Feature: Sent Email History updates instantly via AJAX after send.

1.9.4

Fix: batch update timeouts on shared hosting.

1.9.3

Plugin Check compliance: gmdate(), esc_sql(), prepared queries, short description length.

1.9.2

WordPress.org compliance: sanitize $_SERVER variables, External Services disclosure, inline comments.

Plugin Website
Visit website

Author
Tony Zeoli
Version:
2.1.9
Last Updated
May 18, 2026
Requires
WordPress 5.8
Tested Up To
WordPress 6.9.4
Requires PHP
8.0

Share Post

Join our newsletter.

Get insights into what’s happening at ChangelogWP right in your inbox. We don’t believe in spam.