Bouzin Fresh Reset

A fresh WordPress start, with strict safety checks. Bouzin Fresh Reset guides an administrator through an irreversible reset of a supported single-site WordPress installation. It obtains and verifies official WordPress core files, prepares a protected recovery workflow, and preserves the selected administrator account and its existing password hash. Main features

• Guided reset: A single confirmation followed by preparation, WordPress reinstallation, and final cleanup, with visible status and progress.
• Verified WordPress files: Checks the official WordPress package and core-file integrity before using it.
• Administrator access retained: Keeps one selected administrator account and its password hash, subject to the eligibility checks shown before confirmation.
• Resumable recovery: Maintains a private operation journal; verifies the actual server state after interruptions rather than blindly repeating destructive requests.
• Safety-oriented preflight: Checks files, permissions, SQL structures, supported paths, locks, HTTPS and public access restrictions before destructive steps.
• Strict cleanup boundaries: Limits the reset to the target WordPress installation and temporary resources demonstrably owned by the current operation.
• Better troubleshooting: Gives clearer failure codes and a read-only progress display without exposing database contents or private recovery files.

What's improved in version 0.1.2? This update concentrates on interruptions, hosting compatibility, accurate progress and narrowly scoped cleanup. It improves the handling of HTTP 502/503/504 responses, stale browser state, interrupted SQL preparation, proxy-modified HTTP responses, cache-related rewrite rules, selected symbolic links, and the final cleanup of verified operation-owned resources. A new optional on-screen terminal view describes confirmed progress and shows the target WordPress version and downloaded package size; it does not run shell commands. See the detailed 0.1.2 changelog below. Important: destructive operation. This is not a backup, migration, or site-recovery tool. A completed reset permanently removes the existing website and its content, including themes, plugins and media according to the approved cleanup scope. It cannot reconstruct your previous website after irreversible deletion. Create and independently verify a full filesystem and database backup before starting. A temporary standalone recovery runner may continue the operation while the original WordPress core is unavailable. Its private operation journal is placed outside the public document root. The runner, locks, and associated resources are subject to ownership and state checks before cleanup. Remote sites require HTTPS. Plain HTTP is permitted only on strictly local development installations with explicit approval. Compatibility: Intended for supported single-site installations with a conventional, writable WordPress layout, direct filesystem access, a compatible SQL database and a private recovery area. Multisite, FTP-only access, unverified shared resources and ambiguous server configurations are refused. Support for any particular hosting provider must be confirmed by testing its actual server configuration.

0.1.2

• Safer handoff near 40%: Prevented an obsolete WordPress AJAX status request from producing misleading JSON errors while files are being moved; the standalone runner remains the authority for progress.
• Read-only monitoring after transient errors: Improved bounded retry and status polling for temporary HTTP 502, 503 and 504 failures, without replaying a destructive request.
• Verified resume after interruption: Improved recovery of an already confirmed operation after browser navigation, reload, or interrupted HTTP responses; stale browser markers are reconciled against server-side evidence.
• Guarded fresh start: An administrator may begin a new reset only after strict confirmation that any previous preparation is inactive or safely retired; ambiguous, active, or partially destructive operations remain blocked.
• More robust SQL recovery: Improved reconciliation of interrupted SQL backup steps and pre-destructive restorations, including stale recovery journals and changes to the currently selected database, while preserving historical evidence.
• Clearer SQL failure reporting: Added more specific, actionable diagnostic codes for SQL refusals and unexpected server responses, without treating unverified database structures as safe.
• Safer SQL cleanup: Restricted deletion to tables and backups verified as belonging to the current reset; removed redundant legacy sidecar metadata from the current operation's workflow.
• Verified ownership manifest: Added/strengthened a private operation-bound manifest to track and validate temporary files, paths and SQL backup identities before final cleanup.
• Cleanup restricted to this operation: No cleanup based solely on sibling folder scans, naming patterns, old archives or before/after directory differences; unrelated installations and hosting resources remain outside scope.
• Final cleanup checks: Tightened cleanup of verified private journals, temporary runner resources, locks and operation-specific artifacts, with safeguards for resumable checkpoints.
• Improved plugin interference handling: Added scoped isolation of ordinary plugins on authenticated Bouzin requests and guarded deactivation before handoff, with restoration after a proven non-destructive refusal.
• HTTP isolation checks: Strengthened origin checks and server-generated challenge/response validation; a generic HTTP 403 or modified proxy header is not treated as proof that a recovery endpoint is safely isolated.
• Reverse-proxy resilience: Improved independent verification when proxies modify response headers or Content-Type during read-only HTTP checks.
• Safer server rewrite handling: Improved inspection and reconstruction of .htaccess, retaining only explicitly verified WordPress or PHP handler requirements and excluding recognized temporary cache rules where safe; unknown access/security directives still block the operation.
• Cache and security plugin compatibility: Added narrowly validated handling of relevant BerqWP/LiteSpeed cache-related rules, without disabling unknown or host-level protections.
• Symbolic-link safety: Improved handling of selected terminal links within wp-content without following external destinations; symbolic links affecting protected WordPress core paths remain refused.
• Progress integrity: Corrected misleading phase transitions and counter totals so the interface reports confirmed operation states rather than estimates presented as completed work.
• Optional read-only terminal display: Added a Debian-style on-screen progress panel with descriptions of confirmed phases; it does not execute commands or modify the operation.
• WordPress download information: Displays the target official WordPress version and actual downloaded archive size in the progress experience.
• Plugin Check preparation: Improved readme metadata, direct-file access protection and narrowly documented static-analysis exceptions for necessary low-level recovery operations; destructive engine behavior was not redesigned to silence warnings.

0.1.1

• Unified the reset interface into a single progress bar and three visible stages from start to finish.
• Improved the handoff to the temporary recovery runner and detection of interrupted requests without automatically repeating destructive submissions.
• Fixed restoration of a previously confirmed operation after navigation or reload in the same tab, with session and form validation.
• Improved validation of request methods, confirmation data and recovery actions; documented code-standard exceptions used by the autonomous recovery mechanism.
• Improved refusal messages and cleanup checks while retaining safeguards for unrelated files and database tables.
• Restored the administrator's optional checkboxes for eligible additional files and same-prefix SQL tables, preserving server-side safeguards and unchecked defaults.
• Prepared release metadata and documentation for WordPress.org review.