Archivum Inactive Archiver

Plugins → Installed Plugins → Inactive lists every plugin that is switched off. Active plugins nothing uses any more need a check of their own: whether anything on the site still relies on each one. Once plugins are archived, the Archived Plugins screen shows when each was last updated and how long it has been archived, so you can decide by dates rather than memory. Step by step: How to find unused plugins in WordPress.

No. WordPress never loads an inactive plugin, so it has no effect on page speed. Its files stay on the server and its settings stay in the database, which is why security scanners still count it and its updates still show. More: Do inactive plugins slow down WordPress?

Delete what you are sure nobody needs: it is the one step you cannot undo without a backup. For the rest, archive first, let the site run, and delete once nothing has needed them. Archiving keeps the files and the settings, so a restore gives you back a working configuration. More: Remove unused plugins, or archive them first?

Some sites use a plugin filter: a must-use plugin, or a plugin such as a performance tool, that loads each plugin only on the pages that need it. Archivum compares the plugins you have activated with the ones that actually loaded on each request. An active plugin that has not loaded on any front-end page, wp-admin screen or background task for 30 days is skipped everywhere, so it may not be needed: deactivate it and archive it, and restore it if something turns out to need it. A plugin that loads only in wp-admin or background tasks gets a quieter note, which is normal for admin tools.

• It starts the first time a request shows a plugin being skipped. Notes appear after 30 days, and only once at least 14 days of front-end visits have been seen.
• The Plugins, Add Plugins, plugin editor and Updates screens are not counted: plugin filters load every plugin there.
• If your plugin filter skips Archivum itself on front-end pages, Archivum cannot see those pages. It says so on its own row; let the filter load Archivum everywhere.
• With full-page caching, a front-end page is counted only when it is built, so notes can take longer to appear.
• Single sites only, for now. On multisite nothing is recorded.
• Turn it off in Plugins → Archived Plugins → Settings. That also deletes what was recorded.

No. On each request Archivum compares the stored list of active plugins with the plugin files PHP loaded, which takes a fraction of a millisecond. On a site without a plugin filter every active plugin loads on every request, so nothing is ever written. With a plugin filter it writes to the database at most once a day for each kind of request (front end, wp-admin, background), into one small option. Nothing leaves your site.

Archiving moves the plugin's files to another folder without changing them. Nothing in the database is altered. Restoring moves them back.

No. Deactivate it first. This is deliberate: deactivation runs the plugin's own clean-up code, and that should be your decision.

A folder named wp-content/archived-plugins- followed by twelve random characters, for example archived-plugins-3f9a1c0b7d2e, with one folder per plugin inside it. The Archived Plugins screen shows the exact name. Developers can change the location with the archive_inactive_dir filter, for example to move it outside the web root.

So that nobody can guess its address. Archived plugins are often old, and old plugins can contain files that are unsafe to run. The plugin already blocks web access to the folder, but some servers ignore that block. A name that differs on every site means that, even there, an outsider does not know where to look. The characters are chosen once per site and do not change.

Not while they are archived: WordPress only updates plugins in the plugins folder. When you restore a plugin, this plugin updates it to its latest version straight away, using WordPress's own updater. This works for any plugin that shows an update on the Plugins screen, and needs the update_plugins capability. At most five plugins are updated per restore; any others are named so you can update them from the Plugins screen. It can be turned off in Plugins → Archived Plugins → Settings.

Rarely, and no more than updating any inactive plugin. The plugin stays inactive after the update. Most plugins make their database changes the next time they are activated, whichever version they come from. If a plugin skipped several versions while it was archived, read its changelog before activating it.

Yes. "Download" under each archived plugin sends it as a zip that can be installed again with Plugins → Add Plugin → Upload Plugin. Only the plugin's own files are included. It is offered to users who may delete plugins, and works up to 200 MB; for larger plugins, copy the folder over FTP or SSH.

Deleting an archived plugin removes its files only. Settings it stored in the database stay, because WordPress removes those only by running the plugin's own uninstall routine. Archivum Pro's "Clean up and delete" runs that routine for you; without Pro, restore the plugin and delete it from the Plugins screen, which runs it.

They stay on disk in the archive folder. Reactivate or reinstall this plugin and it finds the folder again, so they reappear on the Archived Plugins screen. You can also move a folder back into wp-content/plugins by hand over FTP or SSH.

Not automatically. nginx does not read .htaccess files, and neither does Apache when the host has switched overrides off. The Archived Plugins screen requests a file in the archive folder from your own site and shows a warning if it is served; Tools → Site Health shows it too. If you see it, ask your host to deny web access to every address beginning /wp-content/archived-plugins (on nginx: location ^~ /wp-content/archived-plugins { deny all; }), or use the archive_inactive_dir filter to store the archive outside the web root.

No. The plugin manages .htaccess, web.config and index.php in the archive folder and rewrites them if they change. Put your own rules in the server configuration instead.

Archive and restore need the activate_plugins capability. Permanent deletion and Download also need delete_plugins. Updating on restore needs update_plugins. On multisite all of these need manage_network_plugins. If DISALLOW_FILE_MODS is set, the screen is read-only.

Only through WordPress itself: when a plugin is updated on restore, WordPress's own updater checks for and downloads the update, exactly as it does on the Plugins screen. The Archived Plugins screen also requests a file from your own site, to check that the archive folder is blocked from the web. Nothing is sent to the plugin's authors.

A separate, paid add-on from the same authors, sold at inactivearchiver.com. It needs this plugin. It adds automatic archiving after a period you choose, automatic deletion after a period in the archive (always announced a week ahead, and only after someone has seen the announcement), email reports, Clean up and delete, flags for plugins closed or abandoned on WordPress.org, an activity log, WP-CLI commands and two more Site Health checks. Nothing in this plugin is locked or limited without it. Plans start at $19 a year for one site at the launch price ($29 regular). See Pricing for every plan.

Your host requires FTP or SSH credentials for WordPress to change files (you will see the same prompt when installing plugins). This plugin only works where WordPress can write directly.

Earlier versions were distributed in a folder named archive-inactive, archive-inactive-plugins or inactive-archiving-system. Deactivate the old version, install and activate this one, then delete the old one. They use different folder names, so WordPress treats them as separate plugins and will not update one into the other. Everything you archived before is picked up automatically.

Open Plugins → Archived Plugins. Version 1.2 and later pick up everything in the archive folder, including folders they cannot identify as a plugin, so nothing is hidden.

No. See "Disclaimer" below.