Hakeemify Debloater

Most optimisation plugins ask you to trust a switch. Debloater asks you to read a finding. It scans your site, records what it found, and shows you each change it could make: what the change does, what it might break, how confident it is, and how to get back. Nothing is applied until you confirm it, and every apply takes a recovery point first. After applying, it checks your site, and if the check finds a page broken it puts everything back. What it does Scans, and records facts. Which core features are loading, how many revisions and expired transients you have, what your autoloaded options weigh, which of your plugins do the same job, and what your admin shows. Each scan is stored with the facts it read. Explains every finding. Each finding names the facts it came from, so you can disagree with it and leave it alone. Scores each area separately, and says what it covers. The Debloat Score is three scores out of 100 — Database, Admin and Assets — and they are not averaged into one number. None is a speed measurement. Each counts what your site has that Debloater offers to change, and not what WordPress does out of the box: a fresh install scores 100. Something it reports but cannot change for you, such as two plugins doing the same job or XML-RPC being on, is listed as a finding and costs nothing. Each finding that costs points says how many. When everything left in an area is behind deleting data — which Fix Safe Issues never does — the score says what is left and offers to review deleting it. If any check in an area could not run, that area is shown as not scored, with the reason, rather than as clean. Reads your admin as you. Findings about the admin come from a request the scan makes to your dashboard, signed in as the person scanning, and describe what that person sees. The dashboard has 30 seconds to answer a scan started from the dashboard, and 120 seconds from WP-CLI. From WP-CLI, run the scan with --user=<an administrator>; without it, the admin is not read and the scan says so. Plans before it acts. You get a preview: every change, its risk level, what it touches, and the recovery point that will be taken. The same scan and the same profile always produce the same plan. Takes a recovery point first. Before anything changes, the current configuration is captured. Before rows are deleted, the rows themselves are captured, and the deletion does not run unless that capture completed. Verifies, then rolls back if it has to. After applying, Debloater requests your front page, a post, your dashboard and your REST API, and if one of them fails, it puts everything back and tells you what failed. It also requests the login page, and warns rather than rolling back if that looks wrong. When you apply from the dashboard, it also asks a fresh request whether each change loaded, and puts everything back if one did not. From WP-CLI the same checks run as the administrator you name with --user=<an administrator>, and a failure puts everything back there too. Without --user, or on a site that cannot make requests to itself, these checks cannot run; the change stays, and Debloater reports which checks could not run. Adds nothing to a page when nothing is selected. With no changes selected, a front-end page loads none of Debloater's change handlers and makes no query to Debloater's own data. Three profiles

• Safe — changes rated safe or low risk. This is what the "Fix Safe Issues" button applies.
• Performance — Safe, plus changes rated medium risk.
• Maximum — every change rated safe to high risk.

Every change carries a declared risk. Debloater raises it one level when something on your site depends on what the change touches, and on any host it does not recognise (it recognises WP Engine, Kinsta, SiteGround and LiteSpeed servers). On an unrecognised host that means the front-end changes are rated high, so Performance leaves them out and only Maximum includes them. The host does not raise a database change that deletes nothing — clearing expired transients, or stopping large options from loading on every request — because nothing a host does changes what those rows are. Nor does it raise a change whose finding already read what the host did: the revision limit, which the scan reads as it is actually in effect. When a change is left out of a plan because its risk was raised, the preview says why. Stopping the Dashicons icon font from loading for visitors is rated on evidence. The scan reads the pages it fetched as a visitor, and the stylesheets they load from your site, for any use of the font. If none uses it, the change is low risk and Fix Safe Issues can include it; if any does, or a stylesheet could not be read, it is medium, and the finding says which. Pages outside the sample, and icons added by JavaScript after a page loads, are not seen. None of the three profiles includes a change that deletes rows or a change to the admin. Those are chosen one at a time, from their findings. What it can change Twenty-six changes at present, across WordPress core (emoji scripts, embeds, the generator tag, RSD and shortlink headers, jQuery Migrate, heartbeat interval, revision limits, self-pingbacks, Dashicons for guests), the admin (dashboard widgets, the welcome panel, the news widget, plugin notices), the database (expired transients, auto-drafts, orphaned meta, old revisions, spam comments, trash, autoloaded options), WooCommerce (cart fragments and block styles loaded only where they are needed, admin analytics, marketplace suggestions) and Elementor (Google Fonts). What it will not do

• No admin notices and no dashboard widget.
• No telemetry, no analytics, no AI.
• No requests to other sites, except one optional request to wordpress.org described under "External services". The requests Debloater makes on its own are to your own site: to sample your pages and read your dashboard during a scan, and to check your site after a change.
• No claim that your site got faster. Debloater records before-and-after counts and leaves the conclusion to you.
• Recovery points, verification and rollback are all in this free plugin, and none of them needs a licence.

External services Plugin release dates, from wordpress.org. Only when a scan asks for it — wp debloater scan --check-plugin-updates, or the check_plugin_updates parameter of the REST scan endpoint; the dashboard never does — Debloater asks https://api.wordpress.org/plugins/info/1.2/ for the last-updated date of each installed plugin, one request per plugin, so it can tell you which look abandoned. Each request names the plugin's slug, and its user agent names this site's address. Nothing else about your site is sent. The dates are cached, and the choice is not remembered: the next scan does not ask unless told to. This is WordPress's own API; see the wordpress.org privacy notice. The rules Debloater reasons with ship inside the plugin and are never fetched. A newer set arrives when you update the plugin. Nothing else leaves your server. WP-CLI wp debloater scan --user= wp debloater findings wp debloater preview --profile=safe wp debloater apply --profile=safe --yes wp debloater rollback --yes wp debloater status Exit codes: 0 applied and verified, 1 error, 2 rolled back, 3 applied with warnings.

0.9.0

• Initial public release.
• Scans the site and records what it found: core features, the database, the admin as you see it, and the pages a visitor downloads.
• Explains every finding with the facts it came from, its risk and its confidence, and scores Database, Admin and Assets separately.
• Fix Safe Issues applies only low-risk changes that delete nothing. Every other change is reviewed and applied one at a time.
• Takes a recovery point before every change, checks the site afterwards, and puts everything back if a check fails, from the dashboard or from WP-CLI.
• Every step is also a WP-CLI command, including scan, preview, apply, verify and rollback.