FonX Delete User

Description

FonX Delete User turns account erasure into a controlled, reviewed process instead of a one-click auto-delete.

Most “delete my account” plugins force visitors into their own button or form. FonX Delete User takes the opposite approach: you keep the form you already have and the plugin quietly powers it in whichever way fits your site.

What makes it different

• Bring-your-own-form — integrate any existing HTML form on your site with a CSS selector and data-fxldu-field mapping. The form you styled stays the form your visitors see; the plugin’s JavaScript attaches to it without blocking its own handler.
• Config-only mode — toggle the plugin’s own markup off entirely. The shortcode or block still emits the per-site request token and configuration, so an existing form can drive submissions with nothing extra rendered.
• Admin approval pipeline — nothing is deleted automatically. Every request waits in the admin queue for you to approve, reject, or delete it.
• External API mode — instead of deleting inside WordPress, forward erasure submissions to your own endpoint for the external system to complete.
• Audit logging — every request and outcome is recorded in the database or a file, with a built-in viewer.

Features

• Dual deletion modes — store requests pending admin approval (wordpress_db) or forward submissions immediately to an external endpoint (external_api).
• Form builder — add text, email, password, textarea, checkbox, select, and hidden fields with required toggles, placeholders, options, and validation regexes.
• Flexible injection — the [fxldu_form] shortcode, a native Gutenberg block, or integration with an existing page form via CSS selector and data-* field mapping.
• Email notifications — alert the administrator (or a custom admin email) about new requests, and acknowledge the requester by email with configurable subject/body and placeholders.
• Security hardening — honeypot anti-bot field, per-site HMAC-compatible request tokens, per-IP rate limiting, capability-gated admin endpoints, prepared SQL, and fully escaped output.

Submission flow

1. A visitor submits the form (shortcode, block, or an integrated existing form).
2. The frontend checks the honeypot, validates required fields, and posts a JSON request containing a per-site token, the user email, and the collected fields.
3. The request is stored with status pending (rate-limited per IP).
4. The administrator is notified; the requester can also receive an acknowledgement email.
5. On approval, the user is permanently deleted via wp_delete_user() (WordPress Database mode) or the request is marked approved for the external system (External API mode). On rejection, the request is marked rejected and no deletion happens.
6. The requester is notified of the outcome.

Additional Information

This release addresses the points raised during the plugin review and hardens two runtime paths found while testing. Details of what changed and why:

• Global prefix — every global identifier now uses the unique fxldu prefix instead of the generic du_ / delete_user_ names: option keys, database tables, transients, the REST namespace (fxldu/v1), action/filter names, nonces, admin menu slugs, the [fxldu_form] shortcode, the fxldu/form block, enqueue handles, JavaScript globals, and frontend CSS classes. PHP constants are FXLDU_* and the class namespace is Fxldu. The text domain fonx-delete-user and the plugin folder name are unchanged.
• Database cleanup — the admin list tables (Fields, Requests, Logs) and the REST listing endpoint no longer pass an empty argument list to $wpdb->prepare() when no filter or search is applied; in that case the static count query runs directly instead of emitting the “the query argument must have a placeholder” notice.
• Existing-form integration — when the integration selector matches a non-form container (some themes wrap their form in a div that is matched instead of the <form> itself), field collection and email resolution now read the named inputs directly instead of throwing inside new FormData(). The window integration-guard is __fxlduIntegrationBound.
• Script output — the frontend form configuration is no longer printed as raw inline <script> tags. The shortcode and block register the fxldu-frontend script through wp_enqueue_script() and inject the config object with wp_add_inline_script( 'fxldu-frontend', $js, 'before' ). The unused print_frontend_config() method was removed from the main plugin file, and no <script> or <style> strings remain in the plugin source.
• Sanitization of custom headers — the admin live-test of the API connection now passes the custom headers through sanitize_textarea_field( wp_unslash( $_POST['api_headers'] ) ) before building the request, matching the sanitization applied when the headers are saved.
• Contributors — the Contributors: header now uses the plugin owner’s WordPress.org username.
• Log file location — file logging no longer writes to a hard-coded WP_CONTENT_DIR path. Logs now go to a plugin-specific subfolder under the uploads directory ({uploads}/fxldu/fxldu-logs.log), created with wp_mkdir_p(), and each line is appended with error_log( $line, 3, $log_path ).
• External-request REST proxy — the /external-request route remains open for anonymous form submissions but is now hardened: it keeps the honeypot check and the per-site token verification, strips internal keys from the forwarded payload, fails closed with HTTP 403 unless External API mode is active, and is rate-limited per IP (its own transient counter so a normal submission still counts only once per endpoint leg).
• Uninstall cleanup — the broad option_name LIKE query (which could delete options owned by other plugins sharing the old prefix) and a usermeta LIKE cleanup (the plugin writes no user meta) were removed. uninstall.php now deletes an explicit list of the 26 options owned by this plugin plus the three plugin-owned database tables.
• Rate-limit filter — the fxldu_rate_limit filter documented in the FAQ is now actually applied. Both the /request and /external-request endpoints enforce their per-IP limit through a shared helper whose default is max( 1, Options::get_rate_limit() ) and which honors apply_filters( 'fxldu_rate_limit', $limit, $ip ).

Technical details