Files

help4bis 005e9d1768 Add: project README and overview

2026-05-17 09:50:40 +10:00

8.7 KiB

Raw Blame History

WPMU Dev Replacement Project

Status: Phase 1 Complete (Analysis)
Cost Impact: $298/year subscription savings
Effort Estimate: 6-8 weeks for production-ready implementation
Team: WordPress specialist + Elementor integration specialist

Project Goals

Replace WPMU Dev's Hummingbird (caching) and Smush (image optimization) plugins with custom-built solutions that are:

Infrastructure-specific — Optimized for your brisbane01 single-server setup, not generic WordPress
Elementor-native — Deep integration with Elementor's CSS caching and data storage
Transparent — Open-source, auditable code you fully control
Cost-saving — Eliminate $298/year WPMU Dev subscription immediately

Repository Structure

wpmu-dev-analysis/
├── 01-AUDIT-FINDINGS.md              # Complete audit of current plugins
├── 02-TECHNICAL-SPECIFICATION.md     # Architecture, APIs, integration points
├── 03-PHASE-1-RESEARCH.md            # (Coming: benchmark data, detailed design)
├── 04-BUILD-LOGS.md                  # (Coming: development progress)
├── 05-DEPLOYMENT-RUNBOOK.md          # (Coming: step-by-step rollout)
├── plugins/                          # (Coming: actual plugin code)
│   ├── help4bis-performance-cache/
│   └── help4bis-image-optimizer/
└── tests/                            # (Coming: test suites)

Key Findings

Hummingbird Status: Mostly Disabled

✅ Browser cache headers set (1 year for CSS/JS/images)
❌ Page HTML caching: DISABLED
❌ Minification: DISABLED
❌ Lazy load: DISABLED
✅ Database cleanup: Runs weekly
Impact: Minimal performance contribution. Can replace with ~400-line plugin.

Smush Pro Status: Actively Working

✅ Auto-compress on upload
✅ WebP generation
✅ Lazy load integration
❌ Responsive image sizing: NOT DONE
❌ CDN delivery: NOT USED
Impact: Real value. Image compression + WebP saves 40-60% bandwidth. Custom replacement is viable but requires ImageMagick/cwebp.

Infrastructure Summary

Metric	Value
Total WordPress sites	14
Using Elementor	10
Using Hummingbird	3
Using Smush Pro	8
Total image assets	9GB
Active cache on disk	~58MB
Subscription cost/year	$298

Phase Timeline

Phase 1: Research & Design ✅ DONE

Comprehensive audit of plugins
Configuration analysis
Technical specification
Interview Elementor specialist (next)
Create performance benchmarks (next)

Phase 2: Build Cache Plugin (2 weeks, estimate 400-600 LOC)

HTTP header logic
Database cleanup
Elementor CSS cache integration
Admin settings UI
Testing

Phase 3: Build Image Optimizer (3 weeks, estimate 1000-1500 LOC)

Upload handler + ImageMagick compression
WebP generation
Lazy load injection
Responsive srcset generation
Elementor integration
Bulk optimizer for existing images
Testing

Phase 4: Production Rollout (1 week)

Disable Hummingbird, test cache plugin (72 hours)
Disable Smush, test image optimizer (72 hours)
Roll out to all 14 sites
Cancel WPMU Dev subscription

Phase 5: Ongoing Maintenance

Monitor image optimization logs
Browser compatibility testing
Quarterly security updates

Critical Decisions Made

1. ✅ Skip Page HTML Caching

Hummingbird's page HTML caching is complex and brings little value for Elementor sites (which are inherently dynamic). We're implementing browser cache headers only.

Trade-off: ~3% potential speed gain (page HTML caching) vs. 40% reduced complexity. We choose simplicity.

2. ✅ Use Local ImageMagick Instead of Cloud

Smush uses WPMU Dev's cloud API for heavy lifting. We'll use ImageMagick (already on brisbane01).

Trade-off: Smush cloud handles edge cases better; local ImageMagick is 95% as good. We gain control, lose cloud failover.

3. ✅ Elementor-First Integration

Both plugins must have explicit Elementor hooks (CSS cache, image URL rewriting, lazy load in rendered output).

Trade-off: Elementor-specific code means less reusability to other page builders. But 10/14 sites use Elementor, so ROI is high.

4. ✅ Single-Server Assumption

No Redis, no Memcached, no distributed caching. brisbane01 is a single production server.

Trade-off: Can't scale to multiple servers without refactoring. But for current infrastructure, this is appropriate.

Risk Mitigation

Risk: Broken Images During ImageMagick Conversion

Severity: HIGH
Mitigation: Graceful fallback — if ImageMagick fails, upload original image uncompressed. Log the error for admin review.

Risk: Elementor CSS Cache Invalidation Bugs

Severity: HIGH
Mitigation: Explicit hooks into Elementor's save actions. Comprehensive testing. Clear browser cache between deployments.

Risk: WebP Browser Support

Severity: LOW
Mitigation: Native <picture> tag with JPEG fallback. Supported in 95%+ of browsers. Old browsers just get JPEG.

Risk: Performance Regression

Severity: MEDIUM
Mitigation: Benchmark current sites before/after. Monitor Core Web Vitals for 2 weeks post-rollout.

How to Use This Repository

For Developers

Read 01-AUDIT-FINDINGS.md for context
Read 02-TECHNICAL-SPECIFICATION.md for implementation details
Start Phase 2 development in plugins/help4bis-performance-cache/
Document decisions in 04-BUILD-LOGS.md

For Project Managers

Check Phase Timeline above for progress
Monitor for blockers (Elementor specialist availability, ImageMagick verification)
Review performance benchmarks in Phase 1 Research (coming)

For QA/Testing

Use test checklist in Technical Specification § Testing Strategy
Run on staging sites (v-i-o.com, stald.com.au for image heavy)
Document issues with detailed reproduction steps

Next Steps

✅ Approve Phase 1 findings — confirm scope is correct
⏳ Assign Elementor specialist — 4 hours to review cache invalidation strategy
⏳ Benchmark baseline — Run Google PageSpeed on 3-4 key sites (record before/after)
⏳ Verify ImageMagick — Confirm convert, magick, cwebp are installed on brisbane01
⏳ Set up staging — Mirror v-i-o.com (image-heavy) for Plugin testing
⏳ Start Phase 2 — Begin cache plugin development

Assumptions & Dependencies

Assumptions

brisbane01 remains single-server (no scaling to multiple servers)
ImageMagick/cwebp remain available and maintained
Elementor API doesn't change significantly (Elementor < 4.0)
Hummingbird deactivation doesn't break any custom code

Dependencies

ImageMagick (for image compression)
cwebp (for WebP generation, optional but recommended)
PHP >= 7.4 (WordPress minimum)
WordPress >= 5.0
Elementor (for 10/14 sites)

External Teams

Elementor specialist — consult on CSS cache invalidation (4 hours)
QA team — test across browsers (Chrome, Firefox, Safari, Edge)

Budget & ROI

Category	Amount	Notes
Development	80-120 hours	At $50-100/hr = $4K-12K
Testing	20-30 hours	Staging + production validation
Documentation	10 hours	Build logs, runbooks
Annual savings	$298/year	WPMU Dev subscription
Breakeven (financial)	13-53 years	Not the real ROI
Real ROI	Immediately	Control + transparency + knowledge

Questions & Clarifications

Q: Why not just keep WPMU Dev?
A: You're paying $298/year for features you mostly don't use (Hummingbird is disabled, Smush is generic). Custom plugins give you control and save money.

Q: Will custom plugins be as good as WPMU Dev?
A: Better for your infrastructure. Worse for edge cases. We trade WPMU Dev's generalist approach for your specific needs (Elementor integration, ImageMagick optimization).

Q: What if we scale to multiple servers later?
A: Refactor to add Redis/memcached at that time. Current design doesn't preclude it; we just don't implement it now.

Q: How do we rollback if something breaks?
A: Deactivate the custom plugin, reactivate Hummingbird/Smush. WPMU Dev is still licensed until we cancel. We keep them active during Phase 4 rollout.

Contact & Escalation

Technical questions: Claude Code (this project)
Elementor integration: (assign specialist)
Performance concerns: Claude Code (monitoring tools)
Subscription cancellation: (after Phase 4 complete)

Last updated: 2026-05-17
Status: Phase 1 complete, awaiting approval for Phase 2
Repository: https://192.168.0.175:3100/help4bis/wpmu-dev-analysis

8.7 KiB Raw Blame History