ConfirmAccount扩展修复失败求助：旧拒绝请求残留致重复申请报错

I’ve run into this exact problem with the ConfirmAccount extension before—those stale denied requests sticking around and blocking re-registrations are super frustrating. Here are the solutions that worked for me:

1. Tweak the Built-in Pruning Configuration #

First, check your LocalSettings.php to adjust how often old requests get cleaned up and how long denied requests are kept. Add or modify these two settings:

• $wgConfirmAccountPruneAge: Sets how many days a denied request stays in the system before being pruned. Default is usually 30 days; you can lower it to 7 or even 1 for faster cleanup:

  $wgConfirmAccountPruneAge = 7; // Keep denied requests for 7 days
  

• $wgConfirmAccountPruneInterval: Controls how often the pruning job runs. By default it might be set to a week—change it to run daily or hourly:

  $wgConfirmAccountPruneInterval = 86400; // Run every 24 hours (in seconds)
  

Save the file and run php maintenance/runJobs.php manually once to trigger an immediate cleanup, in case the job queue was backed up.

2. Manually Clean Up Stale Denied Requests #

If you need to fix the issue right away instead of waiting for the scheduled job, run this SQL query on your MediaWiki database (always back up your database first!):

DELETE FROM confirm_account 
WHERE ca_status = 'denied' 
AND ca_timestamp < DATE_SUB(NOW(), INTERVAL 7 DAY); -- Adjust the interval as needed

This deletes all denied requests older than 7 days. To target a specific user, add AND ca_name = 'target-username' or AND ca_email = 'user@example.com' to the query.

3. Set Up a Custom Cron Job for Reliable Pruning #

Sometimes MediaWiki’s internal job queue doesn’t run consistently, so a dedicated cron job ensures pruning happens on schedule. Add this line to your server’s cron tab (replace /path/to/mediawiki with your actual installation path):

0 0 * * * php /path/to/mediawiki/maintenance/runJobs.php --type=ConfirmAccountPruneJob

This runs the pruning job every day at midnight. Adjust the timing (e.g., 0 */6 * * * for every 6 hours) if you need more frequent cleanup.

4. Emergency Bypass for Specific Users #

If a user needs to re-register immediately, go to Special:ConfirmAccount as an admin—look for their denied request in the list and delete it directly if the option exists. If not, use the targeted SQL query from step 2 to remove just their stale request.

内容的提问来源于stack exchange，提问作者johny why