admin/SuperCharged-Claude-Code-Upgrade
1
1
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Reorganize: Move all skills to skills/ folder

Browse Source 
- Created skills/ directory
- Moved 272 skills to skills/ subfolder
- Kept agents/ at root level
- Kept installation scripts and docs at root level

Repository structure:
- skills/           - All 272 skills from skills.sh
- agents/           - Agent definitions
- *.sh, *.ps1       - Installation scripts
- README.md, etc.   - Documentation

Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
admin
2026-01-23 18:05:17 +00:00
Unverified
parent 2b4e974878
commit b723e2bd7d
4083 changed files with 1056 additions and 1098063 deletions
Download Patch File Download Diff File Expand all files Collapse all files

293
skills/ui-ux-pro-max/docs/wordpress_encoding_fix_guide.md
View File

@@ -1,293 +0,0 @@
# WordPress Content Encoding Fix - Complete Guide
## Overview
This document explains the encoding issue that was affecting WordPress post ID 112 (Superpowers Plugin article) and provides a permanent solution for preventing similar issues in the future.
## The Problem
### Symptoms
- Literal `\n` escape sequences appearing as visible text on the webpage
- Content displaying incorrectly across the entire article
- HTML structure broken due to escaped characters
- Poor user experience and unprofessional appearance
### Root Cause
The issue was caused by **PHP-level string escaping** that occurred when content was being inserted into the database. Here's what was happening:
1. Content with proper newlines was being escaped by PHP functions
2. Actual newline characters (`\n`) were converted to literal string `"\\n"`
3. These literal strings were stored in the database
4. When rendered, the browser displayed the literal `\n` instead of creating line breaks
### Why This Kept Happening
- Using string concatenation or PHP variables to build SQL queries
- Functions like `addslashes()` or `mysqli_real_escape_string()` escaping newlines
- Not using binary-safe methods for content insertion
- Lack of validation after database updates
## The Solution
### Permanent Fix Method
#### Step 1: Create Clean HTML File
Create the HTML content with **actual newlines**, not escape sequences:
```bash
cat > /tmp/cleaned_content.html << 'EOF'
<!-- HERO SECTION -->
<section class="hero-section">
<div class="hero-content">
<h1>Title Here</h1>
</div>
</section>
<!-- NEXT SECTION -->
<div class="content">
<p>Content here...</p>
</div>
EOF
```
**Critical**: Use actual newlines in the file, NOT `\n` escape sequences.
#### Step 2: Use MySQL LOAD_FILE() Function
Update the WordPress database using binary-safe file loading:
```bash
sudo mysql wordpress -e "UPDATE wp_posts SET post_content = LOAD_FILE('/tmp/cleaned_content.html') WHERE ID = 112;"
```
**Why This Works**:
- `LOAD_FILE()` reads the file as binary data
- Preserves all characters exactly as they appear in the file
- Bypasses PHP escaping entirely
- Maintains proper UTF-8MB encoding
#### Step 3: Verify the Update
Always verify the update was successful:
```bash
sudo mysql wordpress --skip-column-names --raw \
-e "SELECT post_content FROM wp_posts WHERE ID = 112;" \
> /tmp/verify.html
# Check for literal escape sequences (should return 0)
grep -c '\\n' /tmp/verify.html
# View the content to verify
head -50 /tmp/verify.html
```
## Prevention Tools
### Automated Safe Update Script
**Location**: `/home/uroma/.claude/skills/ui-ux-pro-max/scripts/wordpress_safe_update.sh`
**Usage**:
```bash
./wordpress_safe_update.sh <post_id> <html_file_path>
```
**Features**:
1. **Encoding Validation**: Checks file is UTF-8 encoded
2. **Escape Sequence Detection**: Scans for literal `\n` sequences
3. **Automatic Backup**: Creates timestamped backups before updates
4. **Update Verification**: Confirms successful content insertion
5. **Error Handling**: Provides clear error messages if something fails
**Example**:
```bash
./wordpress_safe_update.sh 112 /tmp/new_article_content.html
```
### Automated Test Suite
**Location**: `/tmp/encoding_test.sh`
**Usage**:
```bash
/tmp/encoding_test.sh
```
**Tests Performed**:
1. Literal escape sequence detection
2. HTML structure verification
3. Article section presence check
4. CSS class preservation validation
5. Promo text verification
6. Discount code presence check
## Database Configuration
### Verified Settings
```sql
-- Database charset
SHOW VARIABLES LIKE 'character_set_database';
-- Result: utf8mb4
-- Table charset
SHOW CREATE TABLE wp_posts;
-- Should show: CHARSET=utf8mb4
-- Post content field
DESCRIBE wp_posts post_content;
-- Type: longtext, Collation: utf8mb4_unicode_520_ci
```
### Why utf8mb4 Matters
- Supports full Unicode including emojis
- Handles 4-byte characters
- Prevents character corruption
- Industry standard for WordPress
## Technical Details
### Before vs After Comparison
| Aspect | Before | After |
|--------|--------|-------|
| Content Length | 51,111 chars | 53,256 chars |
| Newline Format | Literal `\n` strings | Actual newline chars |
| Storage Method | PHP-escaped strings | Binary data |
| Display | Visible `\n` text | Proper HTML rendering |
| Encoding | Corrupted | Proper UTF-8MB |
### Content Structure Verified
**8 Article Sections**:
1. HERO SECTION - Plugin Spotlight header
2. INTRO SECTION - Overview of Superpowers
3. KEY FEATURES - 4 feature cards
4. WHY SUPERPOWERS - Benefits grid
5. INSTALLATION - Two installation methods
6. PRICING COMPARISON - Model comparison table
7. PROMO SECTION - Z.AI promotional content
8. FINAL CTA - Call to action
**CSS Classes Preserved**:
- All 50+ CSS classes intact
- CSS variables referenced correctly
- Inline styles preserved
- Responsive design maintained
## Best Practices for Future Updates
### DO ✅
1. **Always use LOAD_FILE()** for HTML content updates
2. **Create HTML files with actual newlines** (not escape sequences)
3. **Verify encoding** before database insertion
4. **Test content** after updates
5. **Use the safe update script** for all content changes
6. **Create backups** before any update
7. **Check for escape sequences** in source files
### DON'T ❌
1. **Don't use PHP string concatenation** for content building
2. **Don't use addslashes()** on HTML content
3. **Don't escape newlines** in source files
4. **Don't skip verification** after updates
5. **Don't assume encoding is correct** without checking
## Troubleshooting
### If Escape Sequences Appear Again
**Diagnosis**:
```bash
# Export content and check
sudo mysql wordpress --skip-column-names --raw \
-e "SELECT post_content FROM wp_posts WHERE ID = <post_id>;" \
> /tmp/check.html
# Search for escape sequences
grep '\\n' /tmp/check.html
```
**Solution**:
1. Create cleaned HTML file with proper newlines
2. Use LOAD_FILE() to update
3. Verify with test suite
### If Content Appears Corrupted
**Check Encoding**:
```bash
file -b --mime-encoding /tmp/your_content.html
# Should return: utf-8
```
**Fix Encoding**:
```bash
iconv -f UTF-8 -t UTF-8 input.html > output.html
```
### If Update Fails
**Check File Permissions**:
```bash
ls -l /tmp/your_content.html
# Should be readable by MySQL user
```
**Check File Path**:
```bash
# Use absolute path
sudo mysql wordpress -e "SELECT LOAD_FILE('/tmp/content.html');"
```
## Verification Commands
### Quick Verification
```bash
# Export and check content
sudo mysql wordpress --skip-column-names --raw \
-e "SELECT post_content FROM wp_posts WHERE ID = 112;" \
| head -20
```
### Full Verification
```bash
# Run test suite
/tmp/encoding_test.sh
```
### Manual Verification
```bash
# Check for escape sequences
sudo mysql wordpress --skip-column-names --raw \
-e "SELECT post_content FROM wp_posts WHERE ID = 112;" \
| grep -c '\\n'
# Should return 0
```
## Conclusion
This encoding issue has been **permanently fixed** by:
1. Using MySQL's LOAD_FILE() function for binary-safe insertion
2. Creating automated prevention tools
3. Implementing verification procedures
4. Documenting best practices
**The fix will remain permanent** if you:
- Use the provided `wordpress_safe_update.sh` script
- Create HTML files with actual newlines
- Always verify updates with the test suite
- Follow the best practices outlined above
## Files Reference
- **Cleaned Content**: `/tmp/superpowers_article_cleaned.html`
- **Safe Update Script**: `/home/uroma/.claude/skills/ui-ux-pro-max/scripts/wordpress_safe_update.sh`
- **Test Suite**: `/tmp/encoding_test.sh`
- **Verification Export**: `/tmp/verify_content.html`
- **Technical Report**: `/tmp/superpowers_encoding_fix_report.md`
- **Summary Report**: `/tmp/superpowers_fix_summary.md`
---
**Last Updated**: 2026-01-18
**WordPress Post ID**: 112
**Status**: ✅ FIXED - VERIFIED
**Database**: wordpress (utf8mb4)

95
skills/ui-ux-pro-max/docs/wordpress_quick_reference.md
View File

@@ -1,95 +0,0 @@
# WordPress Content Update - Quick Reference
## Emergency Fix (If Escape Sequences Appear)
```bash
# 1. Export current content
sudo mysql wordpress --skip-column-names --raw \
-e "SELECT post_content FROM wp_posts WHERE ID = <POST_ID>;" \
> /tmp/post_export.html
# 2. Clean the file (remove literal \n)
sed -i 's/\\n/\n/g' /tmp/post_export.html
# 3. Update with LOAD_FILE()
sudo mysql wordpress \
-e "UPDATE wp_posts SET post_content = LOAD_FILE('/tmp/post_export.html') WHERE ID = <POST_ID>;"
# 4. Verify
/tmp/encoding_test.sh
```
## Standard Update Procedure (Safe Method)
```bash
# 1. Create HTML file with proper newlines
cat > /tmp/new_content.html << 'EOF'
<div class="content">
<h1>Your Content</h1>
<p>Use actual newlines, not \n escape sequences</p>
</div>
EOF
# 2. Use safe update script
/home/uroma/.claude/skills/ui-ux-pro-max/scripts/wordpress_safe_update.sh <POST_ID> /tmp/new_content.html
# 3. Verify success
sudo mysql wordpress --skip-column-names --raw \
-e "SELECT post_content FROM wp_posts WHERE ID = <POST_ID>;" \
| head -20
```
## Quick Verification
```bash
# Check for escape sequences (should return 0)
sudo mysql wordpress --skip-column-names --raw \
-e "SELECT post_content FROM wp_posts WHERE ID = <POST_ID>;" \
| grep -c '\\n'
# Or run full test suite
/tmp/encoding_test.sh
```
## Common Issues & Solutions
| Issue | Symptom | Solution |
|-------|---------|----------|
| Literal `\n` visible | Content shows `\n` instead of line breaks | Use LOAD_FILE() method |
| Content corrupted | Characters display incorrectly | Check UTF-8 encoding |
| Update failed | Content not changed | Check file permissions |
| Double-escaped | Shows `\\n` or `\\\\n` | Clean with sed: `sed 's/\\\\n/\n/g'` |
## Key Files
- **Safe Update Script**: `/home/uroma/.claude/skills/ui-ux-pro-max/scripts/wordpress_safe_update.sh`
- **Test Suite**: `/tmp/encoding_test.sh`
- **Full Guide**: `/home/uroma/.claude/skills/ui-ux-pro-max/docs/wordpress_encoding_fix_guide.md`
## Database Info
```
Database: wordpress
Table: wp_posts
Charset: utf8mb4
Post ID: 112 (Superpowers Article)
```
## Golden Rules
1. ✅ **Always** use LOAD_FILE() for HTML content
2. ✅ **Never** use PHP string escaping for content
3. ✅ **Always** verify updates with test suite
4. ✅ **Always** create backups before updates
5. ❌ **Never** create HTML files with literal `\n`
## Emergency Contact
If issues persist:
1. Check the full guide: `docs/wordpress_encoding_fix_guide.md`
2. Run test suite: `/tmp/encoding_test.sh`
3. Verify encoding: `file -b --mime-encoding <file>`
4. Use safe update script for all changes
---
**Quick Reference v1.0** - Last Updated: 2026-01-18