New workflow:
1. User runs: source run.sh (instead of bash launcher.sh)
2. Launcher runs normally
3. On exit with cleanup=yes, launcher sets flag file
4. Wrapper detects flag and does ALL cleanup automatically:
- Cleans ~/.bash_history file
- Clears current shell's in-memory history
- Removes toolkit directory
- No manual commands needed
The key: wrapper is SOURCED so it runs in parent shell and can modify history.
User experience: answer "yes" and cleanup happens instantly, automatically.
Changes:
- Cleans ~/.bash_history file immediately when user selects yes
- Verifies curl command is gone from file before continuing
- Removes logs, temp files, toolkit directory automatically
- Shows verification: "✓ Verified: No curl download commands in history file"
- User just needs to run: history -c, unset HISTFILE, exit
No more asking user to source scripts. Just do the cleanup and verify.
Exit menu now tells user to SOURCE the trace eraser instead of running it as subprocess:
- Single command: TRACE_ERASER_AUTO=yes source tools/erase-toolkit-traces.sh
- Sourcing runs it in current shell, allowing it to modify that shell's history
- No more separate helper scripts or multiple steps
- Single source of truth for all cleanup logic
This fixes the parent shell history issue - by sourcing instead of running as subprocess, the trace eraser can actually modify the shell's history where the curl command was executed.
Exit menu now:
- Calls trace eraser in TRACE_ERASER_AUTO=yes mode (no prompts, removes everything)
- Creates minimal helper script only for parent shell history cleanup
- Single source of truth: tools/erase-toolkit-traces.sh
Removed duplicate cleanup logic from launcher exit handler.
The fundamental issue: launcher.sh runs in a subprocess, so it cannot modify the parent shell's history where the curl command was executed.
Solution: Create a temporary cleanup script that the parent shell must source after launcher exits. This allows the history cleaning to run in the correct shell context.
User workflow:
1. Run launcher.sh and select exit with cleanup
2. Source the generated /tmp/.cleanup_history_$$.sh script
3. History is cleaned in the parent shell
4. Exit and restart shell to verify
The cleanup script removes toolkit traces from ~/.bash_history and disables history recording for the current session.
Simplified to match the exact logic from erase-toolkit-traces.sh:
- Use grep -Ev with pattern matching
- Clean file, clear history, reload, unset HISTFILE
- Then run trace eraser subprocess for logs/files/directory
The key fix is running this in the current shell instead of subprocess.
The trace eraser was running as a subprocess, so history cleaning only affected the subprocess. The parent shell would still write its dirty history back to the file on exit.
Now the exit handler cleans history directly in the current shell before calling trace eraser:
- Cleans ~/.bash_history file with grep -Ev
- Runs history -c to clear in-memory history
- Reloads cleaned history with history -r
- Unsets HISTFILE to prevent re-writing on exit
- Then runs trace eraser subprocess for logs/files/directory cleanup
This ensures curl commands and all toolkit traces are actually removed from bash history.
Changes:
- Single question on exit: 'Clean history and remove traces?'
- If yes: runs full trace eraser automatically
- Auto mode skips all prompts, removes everything
- TRACE_ERASER_AUTO=yes flag for non-interactive mode
User experience:
- Exit (0)
- One question
- If yes: everything cleaned and removed automatically
- No multiple prompts
Changes:
- Prompt user to clean history when selecting Exit (0)
- Runs trace eraser if user answers 'yes'
- Shows clear message about what will be cleaned
User experience:
- Exit from main menu
- Asked: 'Clean history? (yes/no)'
- If yes: runs full trace eraser
- Then exits normally
Changes:
- Replace leading space with HISTFILE=/dev/null prefix
- More reliable - works on all systems
- Doesn't depend on HISTCONTROL settings
Command now prevents history recording universally
Changes:
- Remove comment line inside code block
- Keep just the clean curl command
- Shorter tip below code block
Now easy to copy the command without extra lines
Changes:
- Add leading space before curl command in README
- Add privacy tip explaining HISTCONTROL=ignorespace
- Updated comment to indicate privacy feature
Command now includes space to prevent history recording:
curl -sL https://git.mull.lol/.../tar.gz | tar xz && ...
Changes:
- Add tip about using leading space to prevent history recording
- Shows example with space before curl command
- Explains HISTCONTROL=ignorespace behavior
Best Practice:
curl -sL https://git.mull.lol/.../tar.gz | tar xz
↑ Leading space prevents command from being saved to history
Works on most systems where HISTCONTROL includes ignorespace
Changes:
- Remove complex history -d loop (unreliable)
- Clean file directly with grep -Ev only
- Clear current session with history -c
- Unset HISTFILE to prevent session from writing on exit
- Disable histappend for current session
Issue:
- Complex history manipulation was unreliable
- Current session kept re-adding commands on exit
- history -w then grep -Ev was conflicting
Solution:
- Just clean the file, period
- Unset HISTFILE so current session won't write anything
- Tell user to exit immediately and start fresh shell
Tested:
✓ File cleaned with grep -Ev
✓ HISTFILE unset prevents writing on exit
Changes:
- Add history -c && history -r after cleaning file
- Reloads cleaned history into current session
- Prevents bash from appending dirty history on shell exit
Issue:
- Trace eraser cleaned file but current session kept dirty history
- On shell exit, bash appended current session to file
- All curl commands were re-added to ~/.bash_history
Solution:
- After cleaning file, clear and reload current session history
- Current session now has only cleaned history
- On exit, only clean commands are appended
Tested:
✓ File cleaned with grep -Ev
✓ Current session reloaded from cleaned file
Changes:
- Move bash history cleaning BEFORE directory removal prompt
- Ensures history is always cleaned regardless of directory choice
- Remove exit 0 that was skipping history cleaning
Issue:
- When user answered "yes" to remove directory, script exited immediately
- History cleaning code never executed (was after exit 0)
- User's curl commands remained in ~/.bash_history
Solution:
- Restructure: clean history first, then ask about directory
- History cleaning always runs now
Tested:
✓ History cleaning happens before directory prompt
✓ Works whether user keeps or removes directory
Changes:
- Clean ~/.bash_history file directly after in-memory cleaning
- Handles commands from other terminal sessions
- Ensures complete cleanup even if history not yet written
Issue:
- history -d only cleans current session's in-memory history
- Commands from other sessions remain in ~/.bash_history file
- User's curl command persisted because it was from different session
Solution:
- After history -w, also grep -Ev on the history file
- Removes toolkit commands regardless of which session added them
Tested:
✓ Pattern matches user's curl command format
✓ Extracts correct entry numbers
Changes:
- Remove all 'history' command entries after toolkit cleanup
- Prevents showing investigation/debugging commands
- Uses same history -d approach for consistency
Removes:
- history
- history | grep curl
- cat .bash_history
- Any other history command variants
Tested:
✓ Removed 3 history command entries from test
✓ Only clean commands remain in history
Changes:
- Replace complex awk/grep file manipulation with history -d
- Use in-memory history deletion instead of file parsing
- Delete entries in reverse order to maintain numbering
- Write cleaned history back to file with history -w
Benefits:
- Much simpler and more reliable
- Works with any HISTTIMEFORMAT configuration
- Native bash command handling (no awk complexity)
- Automatically handles timestamps correctly
- User-suggested improvement
Tested:
✓ Deletes 3 toolkit entries from 7-line test history
✓ Preserves normal commands
✓ Timestamps handled automatically by history -d
Changes:
- Replace grep with awk to handle timestamp lines
- Remove matching commands AND their preceding timestamp lines
- Properly handle history format: #timestamp followed by command
Issue:
- Systems with HISTTIMEFORMAT set store timestamps as #<unix_time>
- Simple grep only removed command lines, left orphaned timestamps
- User's history showed toolkit commands still present (lines 990-1030)
Solution:
- awk script that tracks timestamp lines
- Only prints timestamp if following command is kept
- Removes both timestamp and command together atomically
Tested:
✓ Removes 16 lines (8 commands + 8 timestamps) from 32-line test
✓ Preserves normal commands with their timestamps
✓ No toolkit patterns found after cleaning
Changes:
- Replace chained grep -v with single grep -Ev for efficiency
- Fix critical bug: history -w was overwriting cleaned file
- Use history -r instead of history -w to reload cleaned history
- Single-pass filtering instead of 5 separate grep processes
- Better user messaging about other terminal sessions
Technical improvements:
- Escaped regex metacharacters in pattern (git\.mull\.lol)
- Use 3988207 for unique temp file names
- More efficient: 1 process vs 5 processes
Tested:
✓ Removes all toolkit commands regardless of position
✓ Preserves normal commands
✓ No temp file errors
✓ History properly reloaded into memory
✓ 7 toolkit entries removed from 20-line test history
Changes:
- Calculate lines removed before deleting temp files
- Add error handling to line count calculations
- Prevent 'No such file or directory' error on line 163
Tested:
✓ Pattern-based removal works correctly
✓ Removes toolkit entries regardless of position
✓ No temp file access errors
Added 'set +o history' to prevent the trace eraser commands from being re-added to history.
Changes:
• Disable history recording before cleaning (set +o history)
• Clear in-memory history with history -c
• Write empty history with history -w
• Added note to run 'exec bash' for clean shell
• Prevents script commands from being saved
This ensures the last 10 entries are properly removed and the cleanup commands themselves don't get recorded.
Reduced from 50 to 10 entries for more targeted cleanup.
Changes:
• Only removes last 10 bash history entries
• More conservative approach
• Still covers toolkit download and usage
• Less impact on normal command history
Tested and confirmed working.
Bash history cleaning was happening too early, causing script commands to be re-added to history.
Changes:
• Moved history cleaning to the very end of the script
• History is now cleaned after all other operations complete
• Prevents script commands from being re-added to history
• Clear in-memory history as final action
Now properly removes the last 50 bash history entries including all toolkit-related commands.
User bash histories are now completely skipped. The script only cleans root's bash history.
Changes:
• Removed user history detection and cleaning
• Removed prompt for user history cleaning
• Only root bash history is cleaned (last 50 entries)
• Faster execution, no prompts for user accounts
IMPORTANT: All future commits should NOT include:
- Claude Code attribution
- Any AI-related signatures
Commits should be clean and professional without AI attribution.
User bash history cleaning is now optional with a prompt, since most users only work as root.
Changes:
• Added user count detection
• Prompts: "Clean user bash histories too? (y/n) [n]"
• Default is "no" (skip user histories)
• If no users exist, automatically skips
• Only cleans root history by default (faster, covers 99% of use cases)
This makes the script faster and more sensible for typical usage where only root is used to run the toolkit.
The trace eraser was failing with "no previous regular expression" sed errors and wasn't effectively cleaning bash history.
Problems fixed:
• Broken sed pattern matching (caused errors, unreliable)
• Pattern-based deletion doesn't catch all toolkit usage
• In-memory history wasn't being cleared
New approach:
• Simply removes last 50 entries from bash history files
• More reliable than pattern matching (catches downloads, usage, everything)
• Clears in-memory history with history -c && history -w
• Creates .bak backup before cleaning
• Handles both root and user histories
• Changed system log cleaning from sed to grep -v (more reliable)
• Added symlink check for log files
This ensures the last 50 commands (covering toolkit download, installation, and usage) are completely removed from bash history.
The bot analyzer was silently processing thousands of log files with no progress feedback, appearing to stall on large servers.
Changes:
• Added progress counter showing every 50 log files parsed
• Displays current domain being processed
• Shows format: "Parsed 150 log files... (current: domain.com)"
• Clears progress line when complete to avoid clutter
• Interval set to 50 files (adjustable via progress_interval variable)
Example output:
Parsing logs from: /var/log/apache2/domlogs
Parsed 50 log files... (current: example.com)
Parsed 100 log files... (current: another.com)
Logs parsed successfully (125432 entries)
This gives real-time feedback on servers with 1000+ log files without overwhelming the output.
The domain lookup was failing because it only searched for 'servername:' in /var/cpanel/userdata/*/main files, but cPanel stores domain information differently:
- main files use 'main_domain: domain.com' (YAML format)
- domain-specific files use 'servername: domain.com' (YAML format)
Changes:
• Added two-step domain lookup process
• Method 1: Check main_domain in /var/cpanel/userdata/*/main files
• Method 2: Fallback to search all domain files for servername
• Skip cache files (.cache, cache, cache.json) during search
• Applied fix to all three domain lookup locations (options 2, 5, 6)
This fixes the "WordPress installation not found for domain" error that occurred when domains weren't configured as main_domain.
Tested with pickledperil.com - lookup now works correctly.
Changes:
- Modified disable_wpcron_in_config() to place DISABLE_WP_CRON before "stop editing" comment
- This follows WordPress convention for custom constants
- Removes any existing DISABLE_WP_CRON lines first (clean placement)
- Falls back to after <?php if "stop editing" not found
Placement Logic:
1. Remove any existing DISABLE_WP_CRON (anywhere in file)
2. Add before "/* That's all, stop editing! */" comment (line ~93)
3. Fallback: Add after <?php if no "stop editing" found
Example Placement:
```
if ( ! defined( 'WP_DEBUG' ) ) {
define( 'WP_DEBUG', false );
}
define('DISABLE_WP_CRON', true); ← Added here
/* That's all, stop editing! Happy publishing. */
```
Benefits:
- Follows WordPress conventions
- Placed with other custom constants
- Clean, predictable location
- Easy to find for manual edits
https://claude.com/claude-code
Created DEVELOPMENT-GUIDELINES.md as reference for maintaining consistency:
Structure:
- Complete project file map with quick reference table
- Standard script template with proper path resolution
- User experience guidelines (cancel options, messaging)
- Shared resources documentation (reference DB, IP reputation, user manager)
- Testing checklist and guidelines
- Git workflow and commit message template
- Menu structure standards
- Quick reference for common tasks
Key Standards Documented:
- Mandatory cancel/back options on all inputs
- Consistent messaging (print_success, print_error, etc.)
- Proper path resolution for nested scripts
- Reference database usage patterns
- IP reputation system integration
- Common function usage
Purpose:
- Ensure consistency across all scripts
- Quick reference for file locations
- Guidelines for adding new features
- Testing requirements before commits
- Uniform user experience standards
This document serves as the single source of truth for development
practices and helps maintain code quality as the toolkit grows.
https://claude.com/claude-code
Changes:
- Added "0) Cancel" option to all menu prompts
- Added "(or 0 to cancel)" to all text input prompts
- Ensures users can back out of any operation at any time
- Scripts affected:
- website-error-analyzer.sh (scope selection, time range)
- 500-error-tracker.sh (time range selection)
- wordpress-cron-manager.sh (all domain/user input prompts, status checks)
User Experience Improvements:
- No more being trapped in prompts
- Clear cancel instructions on every input
- Consistent "Operation cancelled" messaging
- Proper exit codes (0 for user cancellation)
Tested:
✓ website-error-analyzer.sh - cancel on scope selection
✓ 500-error-tracker.sh - cancel on time selection
✓ wordpress-cron-manager.sh - cancel on domain/user input
✓ All cancellations return cleanly to menu
https://claude.com/claude-code
Changes:
- Created modules/website/wordpress/ subdirectory for CMS-specific tools
- Moved wordpress-cron-manager.sh to new subdirectory
- Created wordpress-menu.sh submenu for WordPress tools
- Updated launcher.sh Website Management menu:
- Simplified to show general tools and CMS submenu options
- WordPress Management is now a submenu (option 3)
- Prepared structure for Joomla/Drupal/other CMS support
- Fixed script paths in wordpress-cron-manager.sh for new location
- Tested complete navigation: Main → Website → WordPress → Cron Manager
Menu Structure Now:
Website Management
├── Website Error Analyzer
├── 500 Error Tracker
└── WordPress Management (submenu)
└── WordPress Cron Manager
└── (All cron management options working)
https://claude.com/claude-code
New Revert Options:
- Option 6: Re-enable wp-cron for specific domain
- Option 7: Re-enable wp-cron for specific user (all sites)
- Option 8: Re-enable wp-cron server-wide (all sites)
Revert Function Features:
✅ Safely removes DISABLE_WP_CRON from wp-config.php
✅ Automatic backup before changes
✅ Verification of successful removal
✅ Auto-rollback on failure
✅ Removes cron jobs from user crontabs
✅ Batch processing for multiple sites
✅ Summary reporting
Menu Organization:
- Grouped options by function (Enable/Revert/Status)
- Color-coded sections (Green/Yellow/Cyan)
- Clear labeling of what each option does
Revert Process:
1. Backup wp-config.php
2. Remove DISABLE_WP_CRON line completely
3. Verify removal was successful
4. Remove wp-cron.php entries from user crontab
5. Provide feedback and summary
Safety Features:
- Won't break sites if DISABLE_WP_CRON not found
- Preserves other cron jobs when removing wp-cron entries
- Individual site failures don't stop batch operations
- Clear feedback on what was changed
Critical Safety Improvements:
- Prevent duplicate DISABLE_WP_CRON entries
- Detect and modify existing definitions (commented or not)
- Automatic rollback on failure
- Verification of changes before committing
Safety Function Features:
✅ Checks file exists and is writable before modification
✅ Detects existing DISABLE_WP_CRON (even if set to false)
✅ Modifies existing line instead of adding duplicate
✅ Ignores commented lines when detecting existing definitions
✅ Creates temporary backup (.wpbak) during modification
✅ Verifies change was successful after modification
✅ Automatically restores backup if verification fails
✅ Removes temporary backup only on success
Prevents Issues:
❌ No duplicate define() statements
❌ No syntax errors from malformed sed commands
❌ No broken wp-config.php files
❌ No accumulation of multiple entries on repeated runs
Error Handling:
- Returns 0 on success, 1 on failure
- Calling code can gracefully handle failures
- User feedback when modification fails
- Skips sites that fail instead of breaking entire batch
Features:
- Scan for all WordPress installations on server
- Disable wp-cron for specific domain, user, or server-wide
- Check wp-cron status for any domain or user
- Automatic wp-config.php backups before changes
- Intelligent cron job staggering to prevent load spikes
Load Distribution:
- Staggers cron times across 15-minute windows
- Example with 300 sites: distributes across minutes 0-14
- Site 1: runs at 0,15,30,45
- Site 2: runs at 1,16,31,46
- Site 3: runs at 2,17,32,47
- ...continues up to minute 14, then wraps
- Prevents all sites from running simultaneously
- Uses user crontabs (not system cron) for proper permissions
Technical Details:
- Adds DISABLE_WP_CRON to wp-config.php
- Creates user-specific crontab entries
- Prevents duplicate cron jobs
- Shows cron timing when adding jobs
- Handles multiple WP installations per user
- Add detection for when no CLI-managed plans exist
- Clarify that cloud-managed plans (web console) aren't visible via acrocmd
- Explain distinction between CLI-managed vs cloud-managed plans
- Provide guidance for both web console and CLI plan management
- Note that API credentials would be needed for cloud plan access
Simplified flow:
1. Shows available plans from acrocmd
2. Prompts user to enter plan name/ID directly
3. Press Enter to cancel and see web console instructions
4. Then proceeds to backup type and performance selection
Removed:
- Confusing numbered options (1,2,3)
- "Run all plans" option (too dangerous)
- Redundant web console option
Now more intuitive - users just type the plan name they see.
cschantz