Auto-Close v3.2: Per-post-type ages, previews, and a status panel

I built Auto-Close around one global age for closing comments and one for pingbacks and trackbacks. That worked fine until a site had pages that should stay open forever next to a news section that needed closing after a week. One age couldn’t do both, and the workaround was always exceptions and post ID lists.

3.2.0 fixes that, adds a way to see what a scheduled run is about to do before it does it, and gives revision cleanup a real retention policy. There’s also a full set of WP-CLI commands for anyone running Auto-Close on a site they don’t want to click through in wp-admin.

Per-post-type closing ages

The Comments and Pingbacks/Trackbacks tabs now accept an age override for each post type, alongside the existing global age. Each override has three states: leave it on the default and the post type inherits the global setting; set Never and that post type is never closed automatically, even if the global age is configured; or set an explicit number of days, which overrides the global age.

Never is what the pages-stay-open-forever case actually wants. Note that an explicit age of zero is the opposite of that — it removes the age condition entirely, so every post of that type becomes eligible on the next run.

Existing installs aren’t affected until you touch these fields. Your current global age keeps working exactly as it did in 3.1.x.

Close by approved comment count

Some posts get closed less by age than by activity. The Comments tab now has an optional approved-comment count threshold: once a post reaches that number of approved comments, its comments close, independent of age. Set both an age and a count, and a post closes when it hits whichever condition first.

Preview changes before you run anything

The destructive actions on the Tools page (Tools → AutoClose Tools) now have a Preview changes button: one for the closing algorithm, one for deleting pingbacks and trackbacks, and one for deleting all revisions. Each shows the matching post count, the scope, and a sample of affected posts without touching anything. The Tools page clearly states it’s a preview and that matching content can shift before you click Run. The two reopening actions don’t have a preview — they’re additive, so there’s nothing to lose by running them.

Revision cleanup gets a retention policy

This is the biggest behavior change in 3.2.0, so read this one even if you skim the rest.

Auto-Close could already cap how many revisions a post keeps. What its scheduled cleanup did, though, was blunter than most people realized: with Delete post revisions enabled, every scheduled run deleted every revision on the site, regardless of the retention limits you’d set, and it took autosaves with it.

3.2.0 replaces that with an actual policy. Scheduled cleanup now deletes a revision only when it is both beyond the number of revisions its post keeps and older than the age cutoff, which defaults to 90 days and is set on the Revisions tab. Scheduled cleanup never deletes autosaves.

If you were relying on the old sweep-everything behavior, it’s still available — the Tools page delete-all action is unchanged, still ignores retention limits and age, and is still explicit. Alternatively, set the age cutoff to 0 and revisions-to-keep to 0 to get the old effect on a schedule.

Two filters tune the new cleanup, and neither is the retention limit — that stays in your per-post-type settings:

• acc_revisions_prune_limit — the maximum number of revisions a single run may delete, 1000 by default. Zero removes the bound.
• acc_revisions_prune_cutoff — the UTC timestamp a revision must predate to be pruned. Return null to drop the age condition entirely.

Your existing revision settings carry forward untouched. If you have scheduled revision deletion enabled, you’ll see a one-time admin notice explaining the new policy; if you don’t, nothing about this affects you, and you won’t see it.

Per-post close dates run on one sweep now

The other behavior change worth knowing about. Setting a close date on a post used to schedule its own one-off cron event. That’s tidy with a handful of dates and a problem at scale: the number of scheduled events grew with the number of close dates, and WordPress keeps its entire cron array in a single autoloaded option. On a site with thousands of close dates, that option can reach megabytes, and it gets loaded on every request.

3.2.0 replaces all of those with one hourly autoclose_close_dates_event sweep that applies every date that’s come due. The event count no longer grows with your content.

The tradeoff is precision. A close date now takes effect at the first sweep after the time you set, rather than to the exact minute. If you need it tighter than an hour, acc_close_dates_recurrence changes the sweep schedule.

Your close dates themselves are untouched, and the old per-post events are removed automatically on upgrade — there’s nothing to clean up by hand.

An AutoClose Status panel

The Tools page now has an AutoClose Status panel showing whether the cron schedule is healthy, when the next run is due, and how the last run went. If the schedule drifts or drops, a Repair schedule button re-registers it without you needing to deactivate and reactivate the plugin.

WP-CLI support

Auto-Close now ships commands under wp autoclose: status and run at the top level, plus settings, comments, pings, pingbacks, revisions, close-date, and cron. Everything that changes content supports --dry-run, so you can script a check across a multisite network before committing to it anywhere. The one write command without it is wp autoclose cron repair, which only re-registers the schedule and touches no content.

Configuration report

The Tools page has an on-demand Configuration Report covering effective settings, exception counts, close-date and reopen-window counts, and revision policy, useful when you’re debugging why a post didn’t close the way you expected. It never includes post content, comment text, or credentials.

Other fixes in this release

Drafts don’t get closed anymore. Unpublished posts were eligible for closing, which meant a draft could be published with its discussion already closed before anyone had a chance to comment. Only published and private posts are closed now, and acc_close_post_statuses adjusts that list if your workflow needs something else.

Reopening comments no longer fights with scheduled closing. Saving a post with a close date set, or restoring a revision, was reopening comments that were supposed to stay closed. Both paths now leave closed comments alone.

The age cutoff was off by one day. Posts at the exact boundary of your configured age were being closed a day early. Fixed the comparison so the cutoff matches what you set.

Posts with no publish date no longer skip the age check. An empty post_date_gmt was bypassing the age cutoff entirely instead of being measured against it.

Legacy close discussion statuses are migrated automatically. Older installs using the pre-WordPress-canonical status value get migrated to closed once, and the caches that depended on the old value are invalidated along with them.

Close dates survive reactivation. Deactivating and reactivating the plugin was silently dropping scheduled closings. Activation now reconciles the sweep from your stored close dates, including catching up on any that were already overdue, and works its way across every site on a network activation. The Repair schedule button triggers the same reconciliation if you need it later. A restore that keeps failing now backs off instead of retrying every minute.

Bulk maintenance runs report what actually happened. A run that closed nothing used to look identical to a run that failed outright. Results now distinguish a genuine no-op from a partial failure, and per-run notification counts no longer double-count across retries. A failed pingback/trackback deletion is reported as a failure too, rather than as zero deletions.

Fortnightly and monthly maintenance now actually run. The General tab has offered both for a while, but neither recurrence was ever registered with WordPress, so choosing one meant the maintenance event failed to schedule, and nothing ran at all — not on a longer interval, not ever. Both are registered now. If you’re on fortnightly or monthly, check the AutoClose Status panel after updating; if it doesn’t show a next run, click Repair schedule.

The first run after activation isn’t skipped. Activation was scheduling maintenance at your configured time even when that time had already passed for the day, so the first run didn’t happen until the following day. It now schedules the next actual occurrence.

Cleaner deletes and uninstalls. Revision deletion now clears orphaned metadata and term relationships instead of leaving them behind, and uninstall walks large multisite networks in batches rather than loading every site at once.

Guidance on what deactivation actually does. The General tab now spells out what stays and what stops if you deactivate: already-closed discussions stay closed, scheduled and per-post closing stop, an active reopen window may not close again on its own, and your revision limits stop applying.

Upgrade notes

1. Back up your database before updating, as always.
2. If you have scheduled revision deletion enabled, read the revision cleanup section above — that behavior has changed. You’ll also get a one-time admin notice about it after updating, on whichever admin screen you land on first.
3. If you rely on wp_revisions_to_keep or the revision filters directly, check acc_revisions_prune_limit and acc_revisions_prune_cutoff against your existing setup, and note that neither one sets the retention count.
4. If you use per-post close dates and need minute-level precision, note that closing now happens at the first hourly sweep after the set time. Use acc_close_dates_recurrence to sweep more often.
5. If your maintenance recurrence is fortnightly or monthly, confirm a next run is scheduled on the Tools page.
6. Nothing else requires action. Global ages, exceptions, and reopen windows carry over unchanged.

What’s next

This is the last feature release I have planned for Auto-Close. From here, it moves to maintenance-only support: security, compatibility, and regression fixes continue, but I’m not planning new features. Nothing about your settings, scheduled jobs, or existing behavior changes because of that.