=== RobArt Update Guard ===

Contributors: robword
Donate link: https://paypal.me/robsnowcreative
Tags: deprecation, compatibility, update, developer, maintenance
Requires at least: 6.2
Tested up to: 7.0
Requires PHP: 8.0
Stable tag: 0.1.0
License: GPL-2.0-or-later
License URI: https://www.gnu.org/licenses/gpl-2.0.html

See which plugins use a retired WordPress function, class, file, hook — or code newer PHP breaks — with file, line and fix. No AI, no network.

== Description ==

Every WordPress release quietly retires a few things — a function, a class, a core file, an action or filter. Nothing is removed the day it is deprecated, so a plugin that still calls a retired function keeps working for a while. Then a later release finally drops it and something breaks, often with no error you can see — just a button that no longer does anything.

The same is true of PHP: each release removes or deprecates functions, constants and settings, so a plugin still using one can fail when your host upgrades PHP.

**RobArt Update Guard tells you, before either happens, which of your installed plugins still lean on something WordPress has retired or a newer PHP version has removed — with the file, the line, and what to use instead.**

= How it works =

WordPress marks its own retirements directly in its source code. A single line like `_deprecated_function( __FUNCTION__, '5.5.0', 'add_allowed_options()' )` carries all three facts a report needs: what was retired, when, and what to use instead. Update Guard reads those markings from the copy of WordPress already on your site, builds an index, then walks the PHP of your installed plugins for anything that still calls one.

PHP is checked differently: it doesn't mark its own retirements in a readable way, so Update Guard carries a verified list of what each PHP version (8.0 through 8.4) removed or deprecated, checked against the official PHP migration guides. For PHP it also parses each plugin file into a syntax tree, which lets it catch patterns a plain search can't — a reversed `implode()` argument order, or a parameter typed non-nullable yet defaulting to `null` — and never mistakes a name in a comment or string for real use.

Because the answer comes from your own WordPress install and a bundled, network-free list, it is as authoritative as your site itself — no changelog parsing, no external service, no guesswork, and no AI.

= What it does =

* **Report** — one scan checks every installed plugin for both retired WordPress APIs and code a newer PHP version removes or deprecates, split into WordPress and PHP tabs, each with the exact file and line and the recommended replacement. A toggle lets you skip the PHP checks for a faster WordPress-only pass.
* **Appearance exposure** — see where your plugins lean on WordPress's own admin styling, so you know which screens to glance at after a core restyle (nothing broken — just a heads-up on where the look may shift).
* **Lexicon** — a searchable reference of everything your WordPress version has retired, plus what recent PHP versions removed or deprecated, each grouped by the release that changed it, with replacements.

= What it covers reliably =

For WordPress: retired functions, classes, core files, and actions/filters — each with a real, exact line number, because all four can be found unambiguously in source. For PHP: functions, constants and php.ini directives removed or deprecated in PHP 8.0–8.4, plus a few usage patterns a name alone can't catch (reversed `implode()` arguments, a no-argument `get_class()`, an optional parameter before a required one, an implicitly-nullable parameter).

= What it deliberately leaves out =

Update Guard is honest about its edges rather than padding the report with guesses:

* **Class methods** — many share everyday names (`reset()`, `render()`); telling a retired one from an unrelated method needs runtime type information a static scan doesn't have.
* **Same-name behaviour changes** — when a function keeps its name but changes what it does. This is the commonest cause of breakage and no code reader can detect it, so a clean report means "no known retirements," not "guaranteed safe."
* **jQuery in plainly named variables** — it reports only calls whose receiver is visibly jQuery, because the removed jQuery names are ordinary words like `load` and `error` and matching them loosely would bury real findings in noise.
* **Minified and bundled files**, and third-party libraries inside plugins (`vendor/`, `node_modules/`) — not yours to change, and they would dominate the results.

= Privacy =

Everything is read from the copy of WordPress and the plugins already on your site. No code leaves your server, nothing is fetched from the network, and no AI is involved. To parse plugin code for the PHP checks it bundles one open-source library, nikic/php-parser (BSD-3-Clause), which runs entirely on your server and makes no network calls; nothing else is bundled. It only reads — it never edits a plugin or makes changes for you.

== Installation ==

1. Upload the plugin to `/wp-content/plugins/robart-update-guard`, or install it from the Plugins screen in your WordPress admin.
2. Activate it through the **Plugins** menu in WordPress.
3. Open the **Update Guard** menu in the admin sidebar and click **Run a scan**.

== Uninstall ==

Update Guard cleans up after itself. When you delete the plugin from the Plugins screen, it removes everything it stored:

* Its options (install date, last-scan record, and onboarding state).
* Its cached scan reports (stored as transients).

It creates no custom database tables, writes nothing outside your own site, and leaves no orphaned data behind. Deactivating the plugin keeps your settings and last report; only deleting the plugin runs the clean-up.

== External services ==

Update Guard performs all of its scanning locally on your own server. It makes no automatic network requests and sends no data anywhere.

The plugin displays a few ordinary links to information pages for other Rob Art plugins, hosted at `robsnow.eu`. These are plain links you may choose to click; the plugin never contacts any external service on its own, and no data is transmitted unless you follow a link.

Support and review links point to WordPress.org, which is governed by the WordPress.org privacy policy.

== Frequently Asked Questions ==

= Does a clean report mean it is safe to update? =

It means nothing your plugins use has been retired by WordPress or removed by the PHP versions checked. It cannot promise an update is safe, because a function can change what it does while keeping its name — the commonest cause of breakage, and something no code reader can detect. Treat a clean report as "no known retirements or removals," not "guaranteed safe."

= Why didn't it flag a method I know is deprecated? =

Class methods are excluded on purpose. Many share everyday names, and distinguishing a retired one from an unrelated method needs runtime type information a static scan doesn't have. Flagging them would produce more noise than signal.

= What PHP versions does it check? =

PHP 8.0 through 8.4. The report shows the highest version reached. The list is verified against the official PHP migration guides and travels with the plugin, so it works with no network access.

= Can I turn the PHP checks off? =

Yes. The "Include PHP compatibility checks" tick-box sits next to the scan button. It's on by default; unticking it runs a faster WordPress-only scan and the choice is remembered.

= Will it slow my site down? =

No. Nothing runs on the front end. A scan happens only when you click the button, and the result is cached for a day. The PHP checks parse every plugin file, so they add a few seconds to a scan — untick them for a quicker WordPress-only pass.

= Does it change any of my files? =

No. Update Guard only reads. It never edits a plugin — it points you to the file and line so you can decide.

= Does it send my code anywhere or use AI? =

No. It reads only the WordPress and plugin files already on your server. Nothing is sent to any external service and no AI is involved.

== Screenshots ==

1. The Dashboard — an at-a-glance summary of your last scan, with a heads-up when WordPress has an update waiting or has moved on since you last scanned.
2. The Report — a scan showing which plugins call retired functions, with file, line and replacement.
3. Appearance exposure — where your plugins lean on WordPress's own admin styling.
4. The Lexicon — a searchable reference of everything your WordPress version has retired.

== Changelog ==

= 0.1.0 =
* PHP compatibility scanning is here. A single scan now checks your plugins for both retired WordPress APIs and code that a newer PHP version removes or deprecates — functions, constants, php.ini directives, and risky patterns like reversed implode() arguments or implicitly-nullable parameters.
* The Report is now tabbed: WordPress and PHP compatibility, each with its own count, file, line and fix. A clean report confirms both were checked.
* The Lexicon gains "Removed in PHP" and "Deprecated in PHP" sections, grouped by the PHP version that changed each one.
* New "Include PHP compatibility checks" toggle on the Report screen — on by default; turn it off for a faster WordPress-only scan.
* The Dashboard and its at-a-glance widget now show your PHP version alongside WordPress, and how far forward the PHP checks reach.
* Still entirely local: PHP breakage data ships with the plugin, nothing is fetched, and no AI is involved.

= 0.0.3 =
* Groundwork for PHP-version compatibility scanning: the report will soon flag plugin code that breaks on newer PHP, not only retired WordPress APIs. Internal foundation only in this release — no change to the current scan yet.

= 0.0.2 =
* The "more plugins from Rob Art" links now point to each plugin's information page rather than a purchase page.

= 0.0.1 =
* Initial release. Report (deprecated function, class, core-file and hook scan), Appearance exposure, and Lexicon reference. Reads the site's own WordPress install; no network, no AI.
