Files
wpmu-dev-analysis/README.md

244 lines
8.7 KiB
Markdown

# 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:
1. **Infrastructure-specific** — Optimized for your brisbane01 single-server setup, not generic WordPress
2. **Elementor-native** — Deep integration with Elementor's CSS caching and data storage
3. **Transparent** — Open-source, auditable code you fully control
4. **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
- [x] Comprehensive audit of plugins
- [x] Configuration analysis
- [x] 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
1. Read `01-AUDIT-FINDINGS.md` for context
2. Read `02-TECHNICAL-SPECIFICATION.md` for implementation details
3. Start Phase 2 development in `plugins/help4bis-performance-cache/`
4. Document decisions in `04-BUILD-LOGS.md`
### For Project Managers
1. Check Phase Timeline above for progress
2. Monitor for blockers (Elementor specialist availability, ImageMagick verification)
3. Review performance benchmarks in Phase 1 Research (coming)
### For QA/Testing
1. Use test checklist in Technical Specification § Testing Strategy
2. Run on staging sites (v-i-o.com, stald.com.au for image heavy)
3. Document issues with detailed reproduction steps
---
## Next Steps
1.**Approve Phase 1 findings** — confirm scope is correct
2.**Assign Elementor specialist** — 4 hours to review cache invalidation strategy
3.**Benchmark baseline** — Run Google PageSpeed on 3-4 key sites (record before/after)
4.**Verify ImageMagick** — Confirm `convert`, `magick`, `cwebp` are installed on brisbane01
5.**Set up staging** — Mirror v-i-o.com (image-heavy) for Plugin testing
6.**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