<?php
/**
 * Complete removal of everything the plugin created.
 *
 * This used to live in uninstall.php. It moved here because Freemius manages
 * the uninstall process itself and requires plugins to hook `after_uninstall`
 * instead of shipping their own uninstall.php — two competing uninstall paths
 * is how cleanup silently stops running.
 *
 * If somebody removes this plugin they should get their database back exactly
 * as it was. Leaving orphaned tables and options behind is how plugins earn a
 * reputation for being parasites, and it is a common reason for a one-star
 * review.
 *
 * @package AdinavAccessibilityAuditEAA
 */

defined( 'ABSPATH' ) || exit;

class ADNVAA_Uninstall {

	/**
	 * Every option this plugin can create, in FREE and PREMIUM builds alike.
	 *
	 * The premium option names are written out as literal strings rather than
	 * referenced from the classes that own them, because those classes do not
	 * exist in the free build. A user who buys Pro, uses it, then downgrades
	 * and later uninstalls must still get a clean database — and at that
	 * moment the only code running is the free build, which has never heard of
	 * ADNVAA_History. Hard-coding the names is the only thing that works here.
	 *
	 * Keep this list in step with any new option. A forgotten entry is
	 * invisible until somebody inspects their database and finds our litter.
	 */
	const OPTIONS = array(
		// Free.
		'adnvaa_db_version',
		'adnvaa_last_scan',
		'adnvaa_settings',
		// Premium — see note above on why these are literals.
		'adnvaa_scan_history',
		'adnvaa_last_fingerprints',
		'adnvaa_crawl_queue',
	);

	/**
	 * Premium cron hook. Same reasoning as the option names: the free build
	 * must be able to clear a schedule the premium build created.
	 */
	const CRON_HOOK = 'adnvaa_scheduled_scan';

	/**
	 * Unschedule the weekly scan, whichever build is running.
	 *
	 * Also used on plugin deactivation, where the rest of this class must NOT
	 * run: deactivating is not uninstalling, and a user who switches the plugin
	 * off for ten minutes to debug a theme conflict would be furious to find
	 * their scan history gone when they switch it back on.
	 */
	public static function clear_schedule() {
		$timestamp = wp_next_scheduled( self::CRON_HOOK );
		while ( $timestamp ) {
			wp_unschedule_event( $timestamp, self::CRON_HOOK );
			$timestamp = wp_next_scheduled( self::CRON_HOOK );
		}
		wp_clear_scheduled_hook( self::CRON_HOOK );
	}

	/**
	 * Registered with Freemius via add_action( 'after_uninstall', ... ).
	 */
	public static function run() {
		global $wpdb;

		// Stop the weekly scan before removing what it writes to, so a job
		// firing mid-uninstall cannot recreate the table we are dropping.
		self::clear_schedule();

		foreach ( self::OPTIONS as $option ) {
			delete_option( $option );
		}

		// The identifier is $wpdb->prefix plus a hard-coded suffix; it can never
		// contain user input, and a table name cannot be bound through
		// $wpdb->prepare(). Dropping the table IS the point of an uninstall
		// routine — the alternative is leaving it in someone's database forever.
		$table = $wpdb->prefix . 'adnvaa_issues';
		// phpcs:ignore PluginCheck.Security.DirectDB.UnescapedDBParameter, WordPress.DB.DirectDatabaseQuery.DirectQuery, WordPress.DB.DirectDatabaseQuery.NoCaching, WordPress.DB.PreparedSQL.NotPrepared, WordPress.DB.PreparedSQL.InterpolatedNotPrepared, WordPress.DB.DirectDatabaseQuery.SchemaChange
		$wpdb->query( "DROP TABLE IF EXISTS {$table}" );
	}
}