=== Hakeemify Debloater ===
Contributors: hakeemify
Tags: bloat, debloat, performance, cleanup, optimization
Requires at least: 6.5
Tested up to: 7.1
Requires PHP: 8.1
Stable tag: 0.9.0
License: GPL-2.0-or-later
License URI: https://www.gnu.org/licenses/gpl-2.0.html

Scan, fix and undo site bloat: audits your site against the facts, applies only what you approve, with a recovery point and automatic rollback.

== Description ==

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](https://wordpress.org/about/privacy/).

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=<an administrator>
    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.

== Installation ==

1. Install and activate.
2. Open **Hakeemify Debloater** in the admin menu.
3. Run a scan.
4. Read the findings. Apply what you agree with.

== Frequently Asked Questions ==

= Will this speed up my site? =

It removes work your site is doing. Whether that is measurable depends on what
your site was doing to begin with. Debloater records before-and-after counts —
requests, bytes, rows — on each change, and never reports a change as making
your site faster.

= What happens if a change breaks something? =

After applying, Debloater requests your front page, a post, your dashboard and
your REST API. If one of them fails, it restores the previous state and reports
what failed. From WP-CLI, pass `--user=<an administrator>` so the checks that
need a signed-in user can run. If your site cannot make requests to itself, or
the change was applied from WP-CLI without `--user`, those checks are reported
as not run and the change stays in place.

= Can I undo a change later? =

Yes. Every apply creates a recovery point. You can roll back any of them from
"Changes & recovery" on the dashboard, or with `wp debloater rollback`.

= Does it delete anything? =

Only when you choose a change that deletes rows. Those changes are never part
of "Fix Safe Issues" or the other two profiles. The finding shows how many rows
the scan counted. Before rows are deleted they are copied into a recovery point,
and if that copy does not complete, nothing is deleted.

= What happens when I uninstall? =

The changes Debloater applied stop, and it forgets which changes were applied:
if you install it again, it starts with nothing applied rather than turning them
back on. Rows a change deleted are not put back by uninstalling; roll the change
back first if you want them.

It deletes the files that hold recovery points larger than 8 MB, so those can no
longer be restored, and removes anything an older version left under
`wp-content/`. Exports you wrote under `wp-content/uploads/debloater/` are left
in place. Its database tables and other settings are kept, including smaller
recovery points and the scan history, so after installing it again you can still
see what was changed and roll it back. A rollback puts the site back as it was
just before that change, so changes applied before it come back on too. There is
no setting to remove them on uninstall.

= Where does Debloater write files? =

The changes you apply are stored in your database, not written as PHP files,
and nothing is added to must-use plugins.

Two things are written as files, both of them data, under
`wp-content/uploads/debloater/`:

* A recovery point larger than 8 MB is stored in `backups/`.
* `wp debloater export` and `wp debloater profile export` write their JSON
  there, with a random suffix on the file name.

That folder gets an `.htaccess` refusing web access, which Apache honours; on
Nginx or another server, add your own rule to refuse
`wp-content/uploads/debloater/`. `--file=-` prints an export to standard output
instead, and a file path is refused.

= Does it phone home? =

No. There is no telemetry, licensing call or usage reporting. The requests it
makes on its own go to your own site. The one request to wordpress.org happens
only when you ask for it, and is described under "External services".

= Is it compatible with my caching plugin? =

Debloater does not cache anything. Its command-line end-to-end check runs on a
site with WooCommerce, Elementor, Contact Form 7, Rank Math and LiteSpeed Cache
active.

== Screenshots ==

1. The dashboard: a score out of 100 for Database, Admin and Assets, never averaged into one number, and what the scan found, with the Fix safe issues button.
2. One finding in full: what was found, why it matters, the evidence with the fact each value came from, the risk, the confidence, and what the change would and would not do.
3. The report after a change: each score before and after, and what was measured on the site before and after, as counts rather than time.

== Changelog ==

= 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.
