{"active_installs":0,"added":{"timestamp":1776902400,"timezone":"UTC"},"author":"Tony Zeoli","author_profile":{"url":"https://profiles.wordpress.org/tonyzeoli/","alt":"Tony Zeoli"},"banners":[],"changelog":"

2.3.3

Fix: Malformed FAQ heading for the core update banner question — the
\nheading spanned two lines in readme.txt causing a rendering artifact
\non the WordPress.org plugin page.
Fix: Freemius Upgrade link hidden until Pro plans are fully configured
\nand ready to launch. has_paid_plans set to false temporarily — will
\nbe restored to true when the Pro tier goes live.
Copy: SMTP & Email Delivery settings card description updated to
\nreflect Greenskeeper’s role as sender of record for its own emails.

2.3.2

Fix: Freemius opt-in “Allow and Continue” button was redirecting to
\nthe site home URL instead of the Greenskeeper dashboard. Fixed by
\nadding after_activation_url to fs_dynamic_init pointing to the
\nGreenskeeper dashboard page.

2.3.1

Feature: Pre-send email preview on the Email Reports page. A “Preview
\nEmail” button appears next to the Send button whenever there are
\npending sessions to send. Clicking it opens the existing email modal
\nin pre-send mode, rendering a full-fidelity preview of exactly what
\nwill be sent to the client — including the current update note, manual
\nentries, and all session update data. The preview reflects the live
\nstate of the form at the moment Preview is clicked. The modal footer
\noffers three actions: “Send Email” (sends directly from the modal
\nwithout closing it), “Go to Updates →” (navigates to the Updates page
\nif something needs to be retried or corrected), and “Close & Edit”
\n(returns to the form to make changes before sending). The preview uses
\na new wpmm_preview_email AJAX handler that builds the full email body
\nusing the same wpmm_build_email_body() function as the send handler
\nbut saves nothing — no log entry, no pending session changes.

2.3

Feature: About the Developer card shown below the donation card on
\nevery page. Includes Tony Zeoli’s Gravatar (pulled live), two
\nparagraphs of background on Greenskeeper’s origin and Tony’s
\nWordPress contributions, and links to tonyzeoli.com,
\ndigitalstrategyworks.com, and radiostation.pro.
Feature: Retry banner now turns green when all retries succeed.
\nTracks cumulative success/fail counts across all retry passes using
\ntotalItems so the denominator is always the full original batch count.
\nThe green banner shows “All 12 of 12 updates completed successfully”
\nand fires the admin notification email on retry success.
Feature: WordPress core update confirmation notice. After a successful
\ncore update, Greenskeeper dismisses the WordPress “update available”
\nbanner (deletes the update_core transient) and injects a green
\nconfirmation notice above the shell: “WordPress X.X updated
\nsuccessfully.” Auto-dismisses with a fade after 4 seconds.
Feature: Already-succeeded retry warning. Before running any update,
\nGreenskeeper checks whether that item already has a success row in the
\ncurrent session’s update log. If so, shows an amber informational
\nnotice explaining the item is already up to date, with the Retry
\nbutton still available for a force retry. Item counted as successful
\nso batch completion state is not affected.
Feature: No-pending-update error now shown as amber informational
\nmessage rather than red failure. Updated copy explains the item may
\nhave already been updated and directs the admin to the Update Log.
Feature: Persistent session queue for Email Reports (wpmm_queued_session
\noption). Update Log “Send to Email Reports” button queues the session
\nvia AJAX and navigates cleanly to Email Reports where a blue
\nconfirmation panel shows the session date and exact update counts.
\nPanel persists until email is sent or admin clears it. Clear Session
\nbutton with confirmation warning dialog.
Fix: Email log not updating after send. Session ID now passed directly
\nfrom the AJAX handler to wpmm_send_email() — no longer read from
\nwpmm_last_session which could be stale. Note column handled gracefully
\nfor pre-v2.1.6 installs.
Fix: Email history row not appearing after send. JS row ID sanitised
\nto safe DOM selector string with Date.now() fallback.
Fix: Email report could miss entries when retry interrupted session
\naggregation. AJAX send handler now reads all update_log rows for the
\nsession directly from the database.

2.2.4

Fix: Email log not updating after send. The wpmm_send_email() function
\nwas reading session_id from wpmm_last_session which could be stale or
\nmismatched. Now accepts session_id as a parameter passed directly from
\nthe AJAX handler — the correct session is always logged. Also added
\ngraceful handling for sites where the note column does not yet exist
\nin wpmm_email_log (pre-v2.1.6 installs).
Fix: JS email history row prepend failed silently when email_id was 0.
\nRow ID is now sanitised to a safe DOM selector string before use, with
\na timestamp fallback ensuring the row always lands and flashes green.

2.2.3

Feature: Persistent session queue for Email Reports. When the admin
\nclicks “Send to Email Reports” on any Update Log session, the session
\nis stored in a WordPress option (wpmm_queued_session) via AJAX and
\nthe admin is navigated to Email Reports. The queued session panel
\nappears automatically regardless of how the admin arrives at the
\nscreen — it persists across page loads and navigation until the
\nemail is sent or the admin explicitly clears it.
Feature: Clear session button on the queued session panel. A “Clear
\nSession” button appears on the panel with a confirmation dialog
\nwarning the admin that clearing removes the queue pointer (not the
\nunderlying update records, which remain in the Update Log). On
\nconfirmation the panel fades out and the queue is cleared.
Feature: Update Log “Send to Email Reports” button on every non-legacy
\nsession. Clicking queues that session persistently via AJAX (no URL
\nparameters) then navigates to Email Reports where the confirmation
\npanel immediately shows the session date, counts of plugins/themes/
\ncore updates, and failed items excluded.
Fix: Session queue clears automatically on successful email send so
\nthe next batch starts fresh.

2.2.2

Fix: Email report sent from Updates page or Update Log “Send Report”
\nbutton could miss entries when a retry interrupted session aggregation.
\nThe AJAX send handler now reads ALL update_log rows for the session
\ndirectly from the database — the same query the Update Log page uses —
\nrather than relying on pending_sessions state which can be incomplete
\nafter retries or page navigation.
Feature: Session confirmation panel on Email Reports page when arriving
\nfrom the Update Log “Send Report” button. Shows the session date, count
\nof plugins/themes/core updates loaded, and count of failed items excluded.
\nConfirms exactly what data will be included in the email before the admin
\nsends it, eliminating ambiguity about completeness.
Fix: Admin notices from Greenskeeper and other plugins now render above
\nthe Greenskeeper shell rather than inside the content area. The .wpmm-wrap
\ndiv is now closed inside wpmm_page_header() before the shell opens, so
\nWordPress injects notices into the wrap (above the shell) as expected.

2.2.1

Fix: WordPress admin notices from Greenskeeper and other plugins now
\nrender above the Greenskeeper UI shell rather than being injected into
\nthe content area. The new v2.2 shell layout caused notices to appear
\nmid-page. Fixed by firing admin_notices and all_admin_notices manually
\nbefore the shell opens, then removing the hooks to prevent duplication.
Feature: Greenskeeper SMTP conflict resolution. Greenskeeper is now
\nalways the sender of record for its own emails by default. A new
\nwpmm_wp_mail() wrapper function sets $GLOBALS[‘wpmm_sending’] = true
\naround every Greenskeeper wp_mail() call so the phpmailer_init hook
\napplies Greenskeeper’s SMTP settings only to Greenskeeper’s own email
\n— never to WooCommerce orders, contact forms, or any other plugin’s
\nmail. When another SMTP plugin is detected (WP Mail SMTP, FluentSMTP,
\nPost SMTP, Easy WP SMTP, Brevo, Gravity SMTP, WP Offload SES, Gmail
\nSMTP, Postman SMTP), an informational notice appears on the SMTP
\nsettings card naming the detected plugin and confirming Greenskeeper
\nis operating independently. A checkbox lets the admin explicitly defer
\nto the detected plugin instead, with a clear warning that doing so may
\nimpact email log integrity if that plugin fails. The SMTP card remains
\nfully visible and editable in both states.

2.2

Feature: Vertical sidebar navigation — replaced the horizontal tab
\nbar with a vertical left-sidebar navigation panel. The sidebar is
\ndark navy matching the header, uses icon + label links with a blue
\nleft-border active indicator, and has no width constraint — all 8
\nnavigation items display on single lines with no wrapping. The main
\ncontent area is now full-width with no max-width cap, giving all
\npages significantly more horizontal real estate. A new wpmm-shell /
\nwpmm-body / wpmm-sidebar / wpmm-content-area CSS layout replaces the
\nold wpmm-tabs horizontal nav. wpmm_page_footer() added to close the
\nshell structure at the end of each page renderer.

2.1.11

Feature: System Info page — a new dedicated admin page (Greenskeeper →
\nSystem Info) that displays a full report of the server and WordPress
\nenvironment for use when submitting support tickets. Includes:
\nServer Environment (OS, software, PHP version with compatibility
\nindicators, PHP max input vars, PHP max post size, GD/Zip/cURL/mbstring
\nextension status); WordPress Environment (version, site/home URLs,
\nmultisite, max upload size, memory limit, permalink structure, language,
\ntimezone, admin email, debug mode, database version, table prefix);
\nActive Theme (name, version, author, URI, child theme indicator);
\nActive Plugins (name, version, author — all active plugins including
\nnetwork-activated on multisite, sorted alphabetically). A sticky
\ncopy-and-paste sidebar lets you copy the full system report as plain
\ntext to include in support tickets to plugin developers.
Compatibility: Tested and confirmed compatible with WordPress 7.0.
\nTested up to value updated to 7.0. Requires at least and Requires PHP
\nadded to the plugin file header (previously only in readme.txt).

2.1.10.3

Fix: Plugin/theme names were blank in the admin notification email.
\nBatch results are now collected directly from AJAX responses as each
\nupdate completes, not from DOM scraping after the fact.
Compatibility: Tested and confirmed compatible with WordPress 7.0.
\nTested up to value updated. Requires at least PHP 8.0 (above the new
\nWordPress 7.0 minimum of PHP 7.4). No code changes required for the
\niframed editor (Greenskeeper has no block editor integration), the
\nAI Client API, Connections API, or Abilities API.

2.1.10.2

Fix: All three batch completion banners (green/amber/red) were visible
\nsimultaneously on the Updates page after a batch completed. The CSS
\ndisplay:flex rule on .wpmm-notice was overriding the HTML hidden
\nattribute, causing all three banners to render visible regardless of
\nthe batch outcome. Fixed by adding .wpmm-notice[hidden] { display:
\nnone !important } to admin.css so the hidden attribute always wins.

2.1.10.1

Fix: WordPress core updates run through Greenskeeper were not appearing
\nin the email report. Root cause: after a successful core update WordPress
\nforces a page reload which resets the JS sessionId variable. The Email
\nReports page hidden session field was populated from wpmm_last_session
\nat PHP render time, but since the page was not reloaded after the core
\nupdate the field still referenced the previous session. Fixed by
\npopulating the hidden field from the most recent wpmm_pending_sessions
\nentry instead of wpmm_last_session — pending sessions is updated
\nserver-side and survives the page reload correctly.
Fix: WordPress core updates made outside Greenskeeper (via the standard
\nWordPress Updates screen) are now captured in the Update Log. The
\nexternal update catcher previously excluded core updates explicitly.

2.1.10

Fix: Update Log now suppresses failed rows when a retry in the same
\nsession succeeded. The failed row remains in the database for audit
\npurposes but is hidden from the Update Log display and excluded from
\nemail reports. Rule: most recent row per plugin slug wins within a
\nsession. Applied to both the Update Log page renderer and the email
\nbody builder.
Feature: Three batch completion states on the Updates page. Previously
\na single green banner appeared after every batch regardless of outcome.
\nNow: (A) all succeeded — green banner with Send Report link; (B) partial
\nsuccess — amber warning with Retry Failed and Send Partial Report options;
\n(C) all failed — red warning with Retry All option. Send Report is never
\nshown when all updates failed.
Feature: Admin notification emails — Greenskeeper can now send an
\ninternal notification email to the performing administrator when a batch
\ncompletes. Three notification types, each independently toggleable in
\nSettings: all updates succeeded (off by default), some updates failed
\n(on by default), all updates failed (on by default). The notification
\nemail is separate from the client-facing report and includes a summary
\nof successes and failures with links to the Update Log and Email Reports.
Feature: Email Notifications settings card in Settings — toggle each
\nadmin notification type on or off independently.
Fix: WordPress core updates made outside Greenskeeper (via the standard
\nWordPress Updates screen) are now captured in the Update Log and included
\nin the next email report. Previously the external update catcher
\nexplicitly excluded core updates. The new version is read from the global
\n$wp_version (already updated at hook time); the old version from the
\nupdate_core transient’s version_checked property.

2.1.9

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

2.1.8

Fix: Email Reports scope selector now honored on multisite (Codex
\naudit issue #3). When a specific site is selected in Network Admin,
\nthe Email Reports page now switches to that site’s context before
\nreading the recipient email, site name, site URL (for the subject
\nline), pending sessions, last session, default administrator, and
\nemail log history.
Fix: Scoped update filtering no longer applied in wrong blog context
\n(Codex audit issue #4). A redundant second filtering pass read
\nactive_plugins and active theme AFTER restore_current_blog() was
\ncalled, filtering against the main site instead of the selected site.
\nRemoved — the first pass already filters correctly using values
\ncaptured while switch_to_blog() was active.
Fix: Removed blocking wp_update_plugins() and wp_update_themes()
\ncalls from wpmm_get_available_updates() which is called from AJAX.
\nThese caused HTTP 500 on managed hosting (Kinsta, WP Engine).
Fix: Performing administrator no longer lost on page navigation
\n(Codex audit issue #5). The admin_id selected on the Updates page
\nis now stored in wpmm_pending_sessions alongside the session_id.
\nWhen the email is sent from the Email Reports page (cross-page flow),
\nthe stored admin_id is read from the most recent pending session
\nrather than defaulting to 0. Falls back to the site default admin
\nif no session admin_id is available. Previously all of these were read from the main
\nsite 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
\nlogs key site events including user logins, failed login attempts,
\nlogouts, password resets, user account creation and deletion, role
\nchanges, plugin activation/deactivation/deletion, theme switches,
\nWordPress core updates, and key settings changes. Built with GDPR
\ncompliance as a first principle: IP addresses are anonymised by default
\n(last octet of IPv4 / last 80 bits of IPv6 zeroed), a configurable
\nretention period (default 90 days) auto-purges old entries via daily
\nwp-cron, a full CSV data export tool supports Subject Access Requests,
\nand all entries can be bulk-deleted at any time. Full IP storage is
\navailable as an explicit opt-in for sites with a documented legitimate
\npurpose. The activity log can be enabled or disabled independently from
\na new section in Greenskeeper Settings.

2.1.6

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

2.1.5

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

2.1.4

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

2.1.3

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

2.1.1

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

2.1.0

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

2.0.9

Critical fix: HTTP 500 errors on managed hosting (Kinsta, WP Engine)
\nduring plugin and theme updates. Root cause: wp_update_plugins() and
\nwp_update_themes() make loopback HTTP requests back to the WordPress.org
\nAPI. When called from within an AJAX request, these loopback requests
\nare blocked or time out on managed hosting, causing the outer AJAX
\nrequest to return HTTP 500. All blocking wp_update_plugins/themes()
\ncalls during AJAX update requests have been replaced with a non-blocking
\nwp-cron background event (wpmm_refresh_update_transient) that fires
\nafter the request completes. The upgrader proceeds with the existing
\ntransient 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.
\nEmail: multiple sessions grouped by date with clear headers.
\nEmail 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).
\nFix: 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.

\n","contributors":[{"slug":"tonyzeoli","name":"Tony Zeoli","count":4,"is_owner":true,"links":{"profile":{"url":"https://profiles.wordpress.org/tonyzeoli/","alt":"Tony Zeoli's profile"},"plugins":{"url":"https://profiles.wordpress.org/tonyzeoli/#content-plugins","alt":"Tony Zeoli's plugins"},"activity":{"url":"https://profiles.wordpress.org/tonyzeoli/#content-activity","alt":"Tony Zeoli's activity"},"translations":{"url":"https://profiles.wordpress.org/tonyzeoli/#content-translations","alt":"Tony Zeoli's translations"}}}],"description":"

Greenskeeper is a professional WordPress maintenance plugin for developers and agencies. It centralises update management for WordPress Core, plugins, and themes, pairs it with a polished email reporting workflow, and adds layered comment spam protection — all from a single purpose-built admin dashboard.

Updates & Reporting:

Scans for available WordPress Core, plugin, and theme updates in separate sections
Updates items individually or in batch with a real-time progress bar and plain-English error explanations
Logs every update action automatically — searchable by item name or date range, grouped into sessions
Builds a branded HTML maintenance report email from each update session and sends it to your client
Report emails support Update Notes (admin note to recipient) and Additional Manual Updates (for licensed plugins updated outside the plugin)
Configures reliable SMTP email delivery via nine supported providers — no separate SMTP plugin required
Manages agency branding: company logo, company name, and default administrator shown on reports
Works on single-site WordPress installs and Multisite networks
Multisite: Site Scope Selector on Updates, Spam Log, and Settings — view and manage any single site or the full network from Network Admin

Spam Filter & Comments:

Layer 1 — Local filtering (always active): honeypot hidden field, submission time check, link count limit, keyword blocklist, IP blocklist, duplicate comment detection
Layer 2 — Akismet cloud filtering (optional): enter your Akismet API key to enable AI-powered spam detection. Automatically skipped when the standalone Akismet plugin is active
Spam Log page: review every blocked comment attempt — filter by rule or IP, add offending IPs to the blocklist with one click, and bulk-delete entries
Disable Comments: remove comment support from all post types and hide the Comments admin menu site-wide

Important — Akismet licensing: Akismet is free for personal, non-commercial sites only. Any commercial or client site requires a paid Akismet plan available at akismet.com/plans. Greenskeeper provides the integration; you are responsible for having a valid Akismet licence appropriate for your site’s use.

Supported SMTP Providers:

SendGrid, Mailgun, Brevo, SendLayer, SMTP.com, Gmail / Google Workspace, Microsoft / Outlook / Office 365, manual SMTP, or WordPress default.

Who it is for:

Web developers, digital agencies, and WordPress administrators who manage client sites and need a reliable, repeatable maintenance and security workflow with professional client-facing reporting. Named after the greenskeeper who maintains the golf course — meticulous, professional, invisible.

Using the Plugin

Running Updates

Go to Site Maintenance → Updates.
The page loads and automatically scans for available updates.
The Performing Administrator dropdown at the top defaults to your saved default admin (set in Settings). Override it here for this session only.
Check the items you want to update — or use Select All per section.
Click Update Selected. Each item updates sequentially with inline feedback.
When all items are done, the global success banner appears with a link to Send Report Email.

Sending a Report Email

After running updates, go to Site Maintenance → Email Reports.
The plugin automatically selects the session you just ran — you will see “Updates from session on [date]” in the Email Template section.
Confirm the recipient email (pre-filled from Settings) and edit the subject line if needed.
Click Send Report Email.
The sent email appears in the Sent Email History table below.

Using the Spam Log

Go to Site Maintenance → Spam Log.
The stats card at the top shows how many attempts each rule has blocked since activation.
The table lists every blocked attempt with date, rule, IP address, author details, and a content preview.
Click Block IP next to any row to add that IP to the blocklist in Settings immediately.
Use the Rule and IP filters to narrow the list. Click Apply to filter; × Clear to reset.
Check individual rows and click Delete Selected to remove entries, or Clear All to wipe the entire log.

Previewing a Sent Email

Click the eye icon in the Sent Email History table. The email renders in a full modal preview using the current template. Even old emails show current branding because the preview always rebuilds the body from the original log entries.

Resending an Email

Click Resend in the Sent Email History table. The email is rebuilt from the original session entries and sent again to the same recipient.

External Services

This plugin connects to one external service: the Akismet API. All other
\nfunctionality runs entirely on your own server with no external connections.

Akismet Spam Filtering (optional)

What it is: Akismet is a cloud-based spam detection service operated by
\nAutomattic, Inc. Greenskeeper includes an optional integration that allows you
\nto submit comment data to Akismet’s API for spam classification.

This feature is entirely opt-in. Akismet is only activated if you enter an
\nAkismet API key in Greenskeeper → Settings → Spam Filter & Comments. If no key
\nis entered, no data is ever sent to Akismet.

What data is sent and when: When Akismet is enabled and a comment is
\nsubmitted on your site, Greenskeeper sends the following data to Akismet’s API:

Your site URL
The commenter’s IP address
The commenter’s browser user agent string
The HTTP referrer header from the comment request
The URL of the page the comment was submitted on
The comment type, author name, author email, author URL, and comment content

This data is sent each time a new comment is submitted and passes Greenskeeper’s
\nlocal filters. If Akismet is unreachable, Greenskeeper fails open (allows the
\ncomment through) rather than blocking it.

Additionally, when you click “Verify & Save Key” in Settings, your Akismet API
\nkey and your site URL are sent to Akismet’s verification endpoint to confirm the
\nkey is valid.

Akismet’s terms of service and privacy policy:

Important licensing note: Akismet’s free plan is for personal,
\nnon-commercial sites only. Any commercial or client site requires a paid
\nAkismet plan. See https://akismet.com/plans/ for details. Greenskeeper provides
\nthe integration; you are responsible for holding a valid Akismet licence
\nappropriate for your site’s use.

SMTP Setup Guides

Greenskeeper includes a built-in SMTP configuration panel that reconfigures WordPress’s email delivery without requiring a separate plugin. The following guides walk through setting up each supported provider.

Go to Settings → SMTP & Email Delivery, click your provider’s tile, and enter the credentials described below.

WordPress Default

No configuration needed. WordPress sends email via PHP’s built-in mail() function. This is unreliable on most shared hosting — emails are frequently blocked by spam filters or rejected by recipients’ mail servers. Recommended only as a fallback.

SMTP (Manual)

Use this option with any SMTP server not listed as a named provider — for example your hosting provider’s mail server or a self-hosted mail server.

Fields:
\n* SMTP Host — the address of your mail server (e.g. mail.yourdomain.com)
\n* Port & Encryption — port 587 with TLS is recommended for most servers; port 465 with SSL is also common; port 25 with no encryption should only be used on internal networks
\n* Username — your SMTP account login (usually your email address)
\n* Password — your SMTP account password
\n* From Name — the display name on outgoing emails
\n* From Email — must be authorised to send from your SMTP server

SendGrid

Free plan: 100 emails per day. No credit card required.

Setup steps:
\n1. Create a free account at sendgrid.com.
\n2. Complete the Sender Identity verification (domain authentication or single sender).
\n3. Go to Settings → API Keys → Create API Key.
\n4. Choose Restricted Access and enable Mail Send → Full Access.
\n5. Copy the API key (it is only shown once).
\n6. In Greenskeeper Settings: select SendGrid, enter apikey (literally, that exact text) as the Username, and paste the API key as the Password.
\n7. Set your verified sender address as the From Email.

Server details (pre-configured): smtp.sendgrid.net — port 587 — TLS

Mailgun

Free tier: 5,000 emails per month for the first 3 months, then pay-as-you-go.

Setup steps:
\n1. Create an account at mailgun.com.
\n2. Add and verify your sending domain under Sending → Domains.
\n3. Go to Sending → Domain Settings → SMTP credentials.
\n4. Note your SMTP login (usually postmaster@yourdomain.com) and generate or copy the password.
\n5. In Greenskeeper Settings: select Mailgun, enter your SMTP login as the Username, and the SMTP password as the Password.
\n6. Set a verified sender address as the From Email.

Server details (pre-configured): smtp.mailgun.org — port 587 — TLS

Note: Mailgun’s free tier restricts sending to verified recipient addresses only. Add recipients under Sending → Overview → Authorised Recipients if you are on the free plan.

Brevo (formerly Sendinblue)

Free plan: 300 emails per day, unlimited contacts.

Setup steps:
\n1. Create a free account at brevo.com.
\n2. Go to your account profile (top-right) → SMTP & API.
\n3. Under the SMTP tab, note your Login (your Brevo account email) and click Generate a new SMTP Key to create a password.
\n4. In Greenskeeper Settings: select Brevo, enter your Brevo login email as the Username, and the SMTP key as the Password.
\n5. Set a sender address you have verified in Brevo as the From Email.

Server details (pre-configured): smtp-relay.brevo.com — port 587 — TLS

SendLayer

Pricing: Paid plans starting at low volume tiers; free trial available.

Setup steps:
\n1. Sign up at sendlayer.com and add your sending domain.
\n2. From the SendLayer dashboard, copy your SMTP Username and SMTP Password.
\n3. In Greenskeeper Settings: select SendLayer, enter those credentials, and set a verified address as the From Email.

Server details (pre-configured): smtp.sendlayer.net — port 587 — TLS

SMTP.com

Free trial: 50,000 emails.

Setup steps:
\n1. Create an account at smtp.com.
\n2. Go to Sender → SMTP credentials.
\n3. Copy your Sender Name (this is the Username) and your API Key (this is the Password).
\n4. In Greenskeeper Settings: select SMTP.com, enter the Sender Name as Username and the API Key as Password.
\n5. Set your verified sender address as the From Email.

Server details (pre-configured): send.smtp.com — port 587 — TLS

Gmail / Google Workspace

Important: Google disabled plain password (basic auth) for SMTP in May 2022. You must use an App Password. OAuth 2.0 is not supported by this plugin.

Personal Gmail — setup steps:
\n1. Sign in to your Google Account at myaccount.google.com.
\n2. Go to Security and confirm that 2-Step Verification is turned on. (App Passwords are not available without it.)
\n3. In the Security search bar, search for App Passwords.
\n4. Click Create, choose Other (custom name), and type WordPress or Greenskeeper.
\n5. Google displays a 16-character code. Copy it immediately — it will not be shown again.
\n6. In Greenskeeper Settings: select Gmail / Google, enter your full Gmail address (you@gmail.com) as the Username, and paste the 16-character App Password as the Password.
\n7. Set your Gmail address as the From Email.

Google Workspace (paid) — setup steps:
\nThe App Password method above works identically for Workspace accounts. Alternatively, your Workspace admin can configure a SMTP relay in the Google Admin console (Apps → Google Workspace → Gmail → SMTP relay service), which allows sending from any user in your domain without per-account App Passwords and supports higher sending volumes.

Server details (pre-configured): smtp.gmail.com — port 587 — TLS/STARTTLS

Gmail sending limits: personal accounts are limited to approximately 500 emails per day; Google Workspace accounts to 2,000 per day.

Microsoft / Outlook

Important: Microsoft deprecated basic authentication for Exchange Online in October 2022 but preserved it specifically for SMTP AUTH submissions. App Passwords are required for personal accounts; organisation accounts need SMTP AUTH enabled by an admin.

Personal Outlook.com accounts — setup steps:
\n1. Go to account.microsoft.com/security.
\n2. Under Advanced security options, confirm Two-step verification is on.
\n3. Click Create a new app password.
\n4. Copy the generated password.
\n5. In Greenskeeper Settings: select Microsoft / Outlook, enter your full Outlook address (you@outlook.com or you@hotmail.com) as the Username, and the app password as the Password.

Microsoft 365 / Office 365 organisations — setup steps:
\n1. A Microsoft 365 admin must enable SMTP AUTH for the sending mailbox. In the Microsoft 365 Admin Centre go to: Users → Active Users → select the user → Mail tab → Manage email apps → check Authenticated SMTP.
\n2. Once enabled, use the regular Microsoft 365 email address and password as the Username and Password.
\n3. If your organisation enforces Multi-Factor Authentication (MFA), generate an App Password from mysignins.microsoft.com → Security info → Add method → App password.

Server details (pre-configured): smtp.office365.com — port 587 — TLS/STARTTLS

Note: For older personal Outlook.com accounts that do not connect on smtp.office365.com, try using the manual SMTP option with host smtp-mail.outlook.com on port 587.

Copyright

Plugin code is licensed under the GNU General Public License v2.0 or later
\n(GPL-2.0+). You are free to use, modify, and redistribute the plugin code under
\nthe terms of that licence. A copy of the GPL is included in the plugin package
\nand is available at https://www.gnu.org/licenses/gpl-2.0.html.

Documentation and written content — including but not limited to the plugin
\ndescription, installation and usage guides, SMTP setup guides, FAQs, and all
\nother original prose contained in readme.txt, README.md, and within the plugin’s
\nadmin interface — is the intellectual property of Digital Strategy Works LLC and
\nis protected by copyright. Reproduction or redistribution of the documentation
\noutside the terms of the GPL as it applies to software is prohibited without
\nprior written permission from Digital Strategy Works LLC.

Greenskeeper, the Greenskeeper logo, and the golf-flag mark are trademarks of
\nDigital Strategy Works LLC. Unauthorised use of the Greenskeeper name or visual
\nidentity in a manner that implies endorsement or affiliation is prohibited.

For licensing enquiries contact: tony@digitalstrategyworks.com

\n","downloaded":1151,"faq":"\n

\nCan I preview the email report before sending it to the client?\n\n

Yes — from v2.3.1 onward, the Email Reports page includes a “Preview
\nEmail” button next to the Send button. Clicking it opens a full-fidelity
\npreview of the email in a modal window, rendered exactly as it will
\nappear to the client — including the current update note, any manual
\nentries you have added, and all session update data. The preview
\nreflects the live state of the form, so if you add a note and click
\nPreview, the note appears in the preview immediately. From the preview
\nmodal you can: click “Send Email” to send without closing the modal,
\nclick “Go to Updates →” to return to the Updates page if something
\nneeds to be retried, or click “Close & Edit” to return to the form
\nand make changes before sending.

\nWhat happens when I retry an update that already succeeded?\n\n

From v2.3, Greenskeeper checks whether the item already has a successful
\nupdate record in the current session before running the update again.
\nIf it does, an amber informational notice appears explaining the item
\nis already up to date, with a Retry button still available if you want
\nto force a fresh check. The item is counted as successful so the batch
\ncompletion state is not affected.

\nWhy does the WordPress core update banner disappear after Greenskeeper updates core?\n\n

Greenskeeper dismisses the WordPress “update available” admin banner
\nafter a successful core update by clearing the update_core transient.
\nIt then shows its own confirmation notice — “WordPress X.X updated
\nsuccessfully” — which auto-dismisses after 4 seconds. This prevents
\nthe WordPress banner from persisting and confusing the admin into
\nthinking the update needs to be retried.

\nDoes Greenskeeper conflict with WP Mail SMTP or other SMTP plugins?\n\n

No — from v2.2.1 onward, Greenskeeper is always the sender of record
\nfor its own emails by default. It applies its SMTP configuration only
\nto emails it initiates (maintenance reports, admin notifications, test
\nemails) and never interferes with WooCommerce, contact forms, password
\nresets, or any other plugin’s mail. When Greenskeeper detects another
\nSMTP plugin on the site, it shows an informational notice on the SMTP
\nsettings card naming the plugin and confirming Greenskeeper is operating
\nindependently. If you prefer to hand delivery to the detected plugin,
\na checkbox on the settings card lets you do that — with a clear warning
\nthat a failure in that plugin may prevent Greenskeeper reports from
\nsending and will not appear in Greenskeeper’s email log.

\nWhich SMTP plugins does Greenskeeper detect?\n\n

Greenskeeper detects the following SMTP plugins: WP Mail SMTP,
\nFluentSMTP, Post SMTP, Postman SMTP, Easy WP SMTP, Brevo (Sendinblue),
\nGravity SMTP, WP Offload SES, and Gmail SMTP. Detection covers both
\nsite-activated and network-activated installations on multisite.

\nDoes Greenskeeper include a System Info report?\n\n

Yes — from v2.1.11 onward, Greenskeeper includes a System Info page
\n(Greenskeeper → System Info in the WordPress admin sidebar). It displays
\nyour full server environment (PHP version, extensions, server software),
\nWordPress environment (version, URLs, memory limit, debug mode, database),
\nactive theme, and a complete list of active plugins with versions and authors.
\nA sticky copy-and-paste panel lets you copy the full report as plain text
\nto include in support tickets to plugin or theme developers.

\nDoes Greenskeeper send notifications to the administrator after updates?\n\n

Yes — from v2.1.10 onward, Greenskeeper can send an internal notification
\nemail to the performing administrator when a batch of updates completes.
\nThree notification types are available, each independently toggleable in
\nGreenskeeper → Settings → Email Notifications: (1) All updates succeeded
\n(off by default — routine clean batches don’t need an email), (2) Some
\nupdates failed (on by default — partial failures need attention), (3) All
\nupdates failed (on by default — complete failures require immediate action).
\nThese notifications go only to the administrator, not to the client.

\nWhat happens when some updates fail and others succeed?\n\n

The Updates page now shows one of three distinct states after a batch
\ncompletes: (A) All succeeded — green confirmation with a Send Report link;
\n(B) Partial success — amber warning showing how many succeeded and how many
\nfailed, with options to retry the failed updates or send a report with only
\nthe successful ones; (C) All failed — red warning with a Retry All option.
\nThe Send Report link is never shown when all updates failed since there is
\nnothing to report.

\nIf I retry a failed update and it succeeds, does the failure still appear?\n\n

No. If a plugin update fails and you retry it in the same session and the
\nretry succeeds, the failed row is suppressed from both the Update Log display
\nand the email report. Only the successful outcome is shown. The failed row
\nremains in the database for audit purposes but is hidden from the user-facing
\nviews. This applies to both individual retries and batch retries.

\nDoes Greenskeeper log site activity and user logins?\n\n

Yes — Greenskeeper includes a Site Activity Log that records user logins,
\nfailed login attempts, plugin changes, theme switches, user account changes,
\nand WordPress core updates. The log is disabled by default and can be enabled
\nin Greenskeeper → Settings → Site Activity Log.

\nIs the Site Activity Log GDPR compliant?\n\n

Yes. The activity log is designed with GDPR data minimisation principles from
\nthe ground up. IP addresses are anonymised by default — the last octet of IPv4
\naddresses and the last 80 bits of IPv6 addresses are zeroed before storage,
\nfollowing the approach recommended by the European Data Protection Board. Log
\nentries are automatically purged after a configurable retention period (default
\n90 days). You can export all stored activity data as CSV to respond to Subject
\nAccess Requests, and bulk-delete all entries at any time from the Site Activity
\npage. Full IP address storage is available as an explicit opt-in for sites with
\na documented legitimate purpose under GDPR Article 6.

\nWhat events does the Site Activity Log record?\n\n

Authentication: user logins, failed login attempts, logouts, password reset
\nrequests, password changes. User management: account creation and deletion,
\nrole changes, administrator profile updates. Site changes: plugin activation,
\ndeactivation and deletion, theme switches, WordPress core updates, and changes
\nto key WordPress options (site title, admin email, permalink structure, etc.).
\nPost and page editing activity is reserved for a future Pro version.

\nHow long does Greenskeeper keep activity log data?\n\n

By default, log entries are automatically purged after 90 days via a daily
\nWordPress cron event. You can change the retention period in Greenskeeper →
\nSettings → Site Activity Log. Set the retention to 0 to keep entries
\nindefinitely (not recommended for GDPR compliance). Entries can also be
\nmanually deleted individually or in bulk from the Site Activity page at
\nany time.

\nCan I export the activity log for a GDPR Subject Access Request?\n\n

Yes. The Site Activity page includes an Export CSV button that downloads all
\nstored activity log entries as a UTF-8 CSV file. You can also access the
\nexport via Greenskeeper → Settings → Site Activity Log. The export includes
\nall logged fields: event type, category, summary, context, user ID, username,
\ndisplay name, anonymised IP address, and timestamp.

\nDoes Greenskeeper report updates made outside the plugin?\n\n

Yes, from version 1.9.1. Greenskeeper hooks into WordPress’s
\nupgrader_process_complete action, which fires for any update that runs
\nthrough WordPress’s standard Plugin_Upgrader or Theme_Upgrader — including
\nupdates made from the WordPress Updates screen, the Avada plugins dashboard
\n(for Avada Core and Avada Builder), or any other standard WordPress update
\nmechanism.

These external updates are logged automatically with a session labelled
\n“External” in the Update Log, and are included as a separate “Updates Made
\nOutside Greenskeeper” section in the next maintenance report email.

\nHow does Greenskeeper handle Avada theme updates?\n\n

Greenskeeper handles Avada-related updates in two ways depending on the
\nupdate type:

Avada theme, Avada Core, and Avada Builder updates — once your Avada
\nlicense is registered, these appear in the standard WordPress updates list
\nand can be updated from either the WordPress Updates screen or the Avada
\nplugins dashboard. Both routes fire WordPress’s standard upgrade hooks.
\nGreenskeeper detects and logs these automatically and includes them in the
\nmaintenance report email.

Avada Patches — patches applied through Avada’s own Maintenance →
\nPlugins & Add-Ons dashboard use Avada’s proprietary update mechanism and
\ndo not fire WordPress’s standard hooks. Greenskeeper cannot detect these
\nautomatically. They should be documented manually using the Additional
\nManual Updates field on the Email Reports page before sending the report.

The Updates page also shows a contextual notice when the Avada theme is
\ninstalled, explaining the required update order: Avada theme first, then
\nAvada Core, then Avada Builder.

\nWhat is the difference between an external update and a manual update?\n\n

An external update is one that Greenskeeper detected automatically
\nbecause it went through WordPress’s standard update mechanism (Plugin_Upgrader
\nor Theme_Upgrader). These are logged and included in the email without
\nany action from you.

A manual update is one that Greenskeeper cannot detect — for example
\nan Avada Patch, a plugin updated through a vendor’s own proprietary
\ndashboard, or an FTP file replacement. These must be documented using the
\nAdditional Manual Updates field on the Email Reports page.

\nDoes the plugin support Avada theme updates?\n\n

Yes, with important notes. Avada Core and Avada Builder appear in the standard
\nWordPress plugin update list once your Avada license is registered, and the plugin
\ncan update them normally. The Updates page shows a contextual notice when Avada is
\ninstalled, explaining the required update order: Avada theme first, then Avada Core,
\nthen Avada Builder. A confirmation prompt appears if you select the Avada theme for
\nupdate, reminding you to follow up with the companion plugins.

Avada Patches are managed separately through Avada’s own dashboard (Avada →
\nMaintenance → Plugins & Add-Ons) and do not appear in the standard WordPress update
\nAPI, so they cannot be detected or applied from this plugin. The Updates page
\nincludes a direct link to that dashboard so you can check after completing your
\nregular updates.

\nDoes this plugin support WordPress Multisite?\n\n

Yes. It can be network-activated by a Super Admin to cover all sites simultaneously, or activated per-site by individual Administrators. Each site maintains its own isolated database tables, update log, and email log. The plugin handles cross-site AJAX correctly on Multisite so email sending always reads from the correct sub-site’s log table.

\nWhy are my updates not showing in the Update Log?\n\n

If you upgraded the plugin by uploading new files without deactivating first, the database schema may not have been upgraded. Open Update Log, expand the Database Diagnostic panel at the bottom, and click Force DB Upgrade Now. The panel shows both database tables with their column lists highlighted in green (present) or red (missing). After the upgrade click Refresh — all sessions should appear.

\nEmails are not being delivered. What should I do?\n\n

By default WordPress sends email via PHP’s mail() function, which many hosting providers block or which major inboxes mark as spam. Go to Settings → SMTP & Email Delivery and configure a dedicated SMTP provider. Use Send Test Email to verify your connection before sending a real report. See the SMTP Setup Guides section below for step-by-step instructions for each supported provider.

\nWhy did a plugin or theme update fail?\n\n

Premium and licensed plugins that require a valid license key for automatic updates will fail with a mapped error message. The Update Log and email reports both include a plain-English explanation and an action recommendation. These items must be updated manually through the vendor’s dashboard or by providing a valid license key.

\nCan I send the report email from a specific email address?\n\n

Yes. Go to Settings → SMTP & Email Delivery and fill in the From Name and From Email fields. The From Email must be authorised to send from your SMTP provider or domain — using an unverified address is the most common cause of delivery failures.

\nCan I update WordPress Core separately from plugins and themes?\n\n

Yes. The Updates page has three separate sections — WordPress Core, Plugins, and Themes — each with its own Select All checkbox. You can update Core alone, plugins alone, themes alone, or any combination.

\nIs my SMTP password stored securely?\n\n

Yes. Passwords and API keys are encrypted with AES-256-CBC before being saved to the database. The encryption key is derived from your WordPress installation’s AUTH_KEY and SECURE_AUTH_KEY constants, which are unique per site and defined in wp-config.php. The raw password is never output into the browser — only a masked placeholder is shown when a value is already saved.

\nWhere is the plugin data stored?\n\n

Three custom database tables per site:
\n* {prefix}_wpmm_update_log — one row per update action (session_id, item_name, item_type, item_slug, old_version, new_version, status, error_code, message, updated_at)
\n* {prefix}_wpmm_email_log — one row per email send (session_id, to_email, subject, body, status, sent_at)
\n* {prefix}_wpmm_spam_log — one row per blocked comment attempt (rule, author_ip, author_name, author_email, author_url, comment_content, post_id, blocked_at)

Plugin settings (branding, SMTP, spam filter configuration, client email, default admin, API key) are stored in the wpmm_settings WordPress option.

\nCan I review blocked spam comments?\n\n

Yes. Go to Site Maintenance → Spam Log. Every comment attempt blocked by
\nany local filter rule (honeypot, time check, keyword, IP, link count, duplicate)
\nis logged there with the author’s IP, name, email, and a content preview. Akismet-
\nblocked comments are logged here too and also appear in WordPress’s native
\nComments → Spam queue.

From the Spam Log you can: filter by rule or IP, add an IP to the blocklist
\nwith one click, delete individual entries, or clear the entire log.

\nWhy were themes not showing in my email reports?\n\n

This was a bug in versions prior to 1.9.1. Theme update log entries stored
\nwith item_type as ‘themes’ (plural) were incorrectly bucketed into the
\nPlugins section. Version 1.9.1 normalises both spellings. No data was lost
\n— resending any previous email from the Sent Email History table will now
\nshow themes in the correct Themes section.

\nDoes the email report include spam filter activity?\n\n

Yes, from version 1.9.1. Every maintenance report email includes a Spam
\nActivity section listing comment attempts blocked since the last report was
\nsent. Each entry shows when it was blocked, which rule caught it, the
\nsubmitter’s IP, and a content preview. If no spam was blocked since the
\nlast report the section is omitted entirely.

\nHow does the administrator name appear in email reports?\n\n

From version 1.9.1 the email uses the administrator’s First Name and Last
\nName from their WordPress user profile. Go to Users → Your Profile and
\nfill in the First Name and Last Name fields, then click Update Profile. If
\nno first or last name is saved, the Display Name is used as a fallback.

\nWho can access Greenskeeper?\n\n

By default, any WordPress Administrator can access the plugin. Once you save the
\nManage Plugin Access settings (Settings → Manage Plugin Access), only the
\nadministrators you have explicitly checked can see or use any part of the plugin.
\nUnchecked administrators see no menu item and cannot reach any plugin page.

Your own account is always locked in — you cannot accidentally remove your own
\naccess from within the plugin.

\nCan a client with Administrator access see the plugin?\n\n

Not after you configure the Manage Plugin Access card. Go to
\nSite Maintenance → Settings, scroll to Manage Plugin Access, uncheck the
\nclient’s administrator account, and click Save Access Settings. That account
\nwill no longer see the Site Maintenance menu or any plugin page.

\nWhat if I get locked out of the plugin?\n\n

Lockout cannot happen from within the plugin UI — your own account is always
\nkept in the access list automatically. If you are locked out through a direct
\ndatabase change, connect to the database and either delete the wpmm_settings
\noption (which resets to the manage_options fallback) or add your user ID back
\nto the access_user_ids array in that option.

\nDoes the plugin support two-factor authentication?\n\n

The plugin does not implement 2FA itself. Instead, it detects whether a 2FA plugin
\nis active and shows a notice on every plugin page if none is found, with direct
\nlinks to install WP 2FA or Two Factor. We recommend protecting the administrator
\naccounts that have wpmm_access with 2FA via one of these dedicated plugins:
\nWP 2FA (by Melapress), Two Factor (official WordPress.org plugin),
\nWordfence Security, or iThemes Security Pro.

\nHow do spam filter settings work on a Multisite network?\n\n

Each sub-site has its own independent spam filter settings stored in that
\nsite’s wpmm_settings option. From Network Admin, go to
\nSettings → Spam Filter & Comments. The All Sites view shows a summary table
\nof every site with its spam status, Akismet connection, and comments status.
\nSelect a specific site from the Site Scope Bar to edit its settings. Changes
\nonly affect that site and are saved immediately.

\nCan I run updates for all sites at once, or only one site at a time?\n\n

Both. In Network Admin, the Site Scope Bar on the Updates page defaults to
\nAll Sites, which shows all available updates for all installed plugins and
\nthemes. Selecting a specific site filters the list to only the plugins and
\nthemes activated on that site, and runs updates in that site’s context.

\nDoes the network email report cover all sites?\n\n

Yes. When the Email Reports page is in All Sites scope (Network Admin,
\nno site selected), sending the report builds a consolidated email with a
\nsection per site. Each section contains that site’s own Core, Plugins, and
\nThemes update tables. When a single site is selected, the report covers
\nonly that site in the standard single-site format.

\nDoes the spam filter work without an Akismet API key?\n\n

Yes. The local filtering layer (honeypot field, submission time check, link count
\nlimit, keyword blocklist, IP blocklist, and duplicate detection) runs entirely on
\nyour server with no external API calls. Local filtering alone catches the majority
\nof automated bot spam. Adding an Akismet API key activates a second layer of
\nAI-powered cloud filtering for more comprehensive coverage.

\nDo I need a paid Akismet account?\n\n

Akismet’s free plan is for personal, non-commercial sites only. Any commercial
\nwebsite — including client sites managed by an agency — requires a paid Akismet
\nplan. Visit akismet.com/plans to choose the right
\nplan. Greenskeeper provides the Akismet integration; licensing is your
\nresponsibility.

\nWill the spam filter conflict with the standalone Akismet plugin?\n\n

No. Greenskeeper detects when the standalone Akismet plugin is already
\nactive and skips its own Akismet API call automatically. Only the local filtering
\nlayer runs in that case, so you never get double-filtering. The Settings page shows
\na notice when the standalone plugin is detected.

\nWhat happens if Akismet is unreachable when a comment is submitted?\n\n

The plugin fails open — the comment is allowed through rather than being blocked.
\nThis prevents legitimate comments from being lost due to a temporary API outage or
\nnetwork issue. Local filters still run normally regardless of Akismet availability.

\nCan I disable comments completely across the entire site?\n\n

Yes. The Disable Comments toggle in Settings → Spam Filter & Comments removes
\ncomment support from every post type, closes all existing comments via WordPress
\nfilter hooks, hides the Comments admin menu item, redirects direct access to the
\ncomments admin page, and removes discussion meta boxes from the post and page
\neditors. This is a site-wide setting — it applies to all post types including
\ncustom ones.

\nHow do I add an IP address to the blocklist after catching a spammer?\n\n

Two ways to add an IP. From the Spam Log page, click the Block IP button on any row — the IP is added to the blocklist instantly without leaving the page. Alternatively go to Settings → Spam Filter & Comments, add the address to the Blocked IP Addresses textarea (one per line), and click Save Spam Settings.

\nHow does Greenskeeper handle Multisite networks?\n\n

In Network Admin, a Site Scope Bar appears at the top of the Updates, Spam Log,
\nand Settings pages. You can select “All Sites” to operate across the entire
\nnetwork, or choose a specific site to scope the view to that site only.

\nWhat does “All Sites” mode do on the Updates page?\n\n

In All Sites mode the Updates page shows every available update for every plugin
\nand theme installed on the network, regardless of which site has it activated.
\nRunning updates applies them network-wide and logs results to the network admin
\nsite’s update log. The email report lists each site as a separate section with
\nits own Core, Plugins, and Themes tables.

\nWhat does single-site scope do on the Updates page?\n\n

When you select a specific site, the Updates page filters the plugin and theme
\nlist to only show items activated on that site (including network-activated
\nplugins). Updates run in that site’s context and log to that site’s own
\nwpmm_update_log table. The email report uses the single-site format.

\nAre spam filter settings shared across all sites in a network?\n\n

No. Each site has its own independent spam filter settings. In Network Admin,
\nselect a site from the scope bar on the Settings page to view and edit that
\nsite’s spam configuration. Selecting “All Sites” shows a summary table of all
\nsites with their spam filter status, Akismet connection status, and comments
\ntoggle state.

\nCan I use this plugin alongside WP Mail SMTP or other SMTP plugins?\n\n

It is recommended to use either Greenskeeper’s built-in SMTP configuration or a separate SMTP plugin — not both. Both plugins hook into phpmailer_init and will conflict. If you already have WP Mail SMTP, FluentSMTP, or Post SMTP installed and configured, leave Greenskeeper’s SMTP setting on WordPress Default and let the other plugin handle delivery.

\n\n","homepage":"","icons":[{"type":"1x","url":"https://ps.w.org/greenskeeper/assets/icon-128x128.png?rev=3513335"},{"type":"2x","url":"https://ps.w.org/greenskeeper/assets/icon-256x256.png?rev=3513336"}],"installation":"

Single-Site Install

In your WordPress admin go to Plugins → Add New → Upload Plugin.
Upload greenskeeper.zip and click Install Now.
Click Activate Plugin.
Navigate to Site Maintenance in the left-hand admin menu.
Open Settings and configure your company branding, client email, default administrator, SMTP delivery, and spam filtering.

Multisite / Network Install

Log in as a Super Admin and go to Network Admin → Plugins → Add New → Upload Plugin.
Upload greenskeeper.zip and click Install Now.
Click Network Activate to activate across all sites simultaneously, or activate per-site from each site’s own Plugins screen.
Navigate to Site Maintenance in the Network Admin menu or any site’s admin menu.
Each site has its own independent Settings, Update Log, and Email Log.

Manual Install

Unzip the archive and upload the greenskeeper folder to /wp-content/plugins/.
Activate from the WordPress Plugins screen.

\n","internal_ranking":0,"languages":[],"last_seen":{"timestamp":1781816033.778,"timezone":"UTC"},"last_updated":{"timestamp":1781497080,"timezone":"UTC"},"last_wordpress_compatible_version":"7.0","latest_num_ratings":0,"latest_rating":0,"latest_ratings":{"1":0,"2":0,"3":0,"4":0,"5":0,"links":{"1":{"url":"https://wordpress.org/support/plugin/greenskeeper/reviews/?filter=1","alt":"View all 0 one star reviews"},"2":{"url":"https://wordpress.org/support/plugin/greenskeeper/reviews/?filter=2","alt":"View all 0 two star reviews"},"3":{"url":"https://wordpress.org/support/plugin/greenskeeper/reviews/?filter=3","alt":"View all 0 three star reviews"},"4":{"url":"https://wordpress.org/support/plugin/greenskeeper/reviews/?filter=4","alt":"View all 0 four star reviews"},"5":{"url":"https://wordpress.org/support/plugin/greenskeeper/reviews/?filter=5","alt":"View all 0 five star reviews"},"all":{"url":"https://wordpress.org/support/plugin/greenskeeper/reviews/","alt":"View all 0 reviews"}}},"minimum_php_version":"8.0","minimum_wordpress_version":"5.8","name":"Greenskeeper","num_ratings":0,"pluginid":"greenskeeper","rating":0,"ratings":{"1":0,"2":0,"3":0,"4":0,"5":0,"links":{"1":{"url":"https://wordpress.org/support/plugin/greenskeeper/reviews/?filter=1","alt":"View all 0 one star reviews"},"2":{"url":"https://wordpress.org/support/plugin/greenskeeper/reviews/?filter=2","alt":"View all 0 two star reviews"},"3":{"url":"https://wordpress.org/support/plugin/greenskeeper/reviews/?filter=3","alt":"View all 0 three star reviews"},"4":{"url":"https://wordpress.org/support/plugin/greenskeeper/reviews/?filter=4","alt":"View all 0 four star reviews"},"5":{"url":"https://wordpress.org/support/plugin/greenskeeper/reviews/?filter=5","alt":"View all 0 five star reviews"},"all":{"url":"https://wordpress.org/support/plugin/greenskeeper/reviews/","alt":"View all 0 reviews"}}},"reviews":[],"screenshots":null,"short_description":"Manage WordPress updates, filter comment spam, send branded email reports, and configure SMTP delivery — for single sites and Multisite networks.","support_threads":0,"support_threads_resolved":0,"tags":[{"slug":"email","label":"email","count":1317},{"slug":"multisite","label":"multisite","count":388},{"slug":"smtp","label":"smtp","count":249},{"slug":"maintenance","label":"maintenance","count":248},{"slug":"updates","label":"updates","count":130}],"tags_count":2332,"languages_count":0,"age_days":119.08492602050926,"installs_per_rating":null,"downloads_per_rating":null,"installs_per_day":0,"downloads_per_day":9.665371079810473,"reviews_per_day":0,"activation_rate":0,"version":"2.3.3","marketplace":"wordpress","marketplace_url":"https://wordpress.org/plugins/greenskeeper","price":null,"wordpress_link":{"alt":"WordPress","url":"https://wordpress.org/plugins/greenskeeper"}}

Global SMTP vs Greenskeeper