v4.3.3 — Admin pages factory-driven
Production-ready ✓ (staging-verified)
v4.3.3 has passed WordPress staging smoke on a real install: plugin activates cleanly, admin pages load (the refactored factory-driven Frameworks / Settings / System Status / home dashboard), and a live translation flow round-trips end-to-end. This is the recommended deployment target.
The 4.3.x patch chain (v4.3.0 → v4.3.3) is now closed; future framework-coverage work will land on 4.3.x or a 4.4 line.
Drift-source cleanup on top of v4.3.2. External code review of v4.3.2 found four more hardcoded 9-framework pockets in functions.php that the string-by-string errata pass missed. Rather than chase strings a third time, this release refactors the affected admin pages to delegate to the converter factory so the drift surface is eliminated.
This is a forward commit on main and a normal annotated tag — no history rewriting.
What changed in functions.php
| Site | Before | After |
|---|---|---|
| Admin home "Supported Frameworks" card | static <ul> of 9 hardcoded <li> + literal "72 Translation Pairs" |
foreach over factory data; count + pairs computed live |
| Frameworks page "Translation Matrix" table | hardcoded $frameworks + parallel $formats map of 9 |
single foreach over get_framework_info(); new "Target CMS" column |
| Frameworks page "Framework Details" card | literal "182 (14 frameworks × 13 targets)" | computed $count * ($count - 1) |
| Settings page "Default Source Framework" select | 9 hardcoded <option> tags |
foreach over factory + selected() honors saved choice |
| System Status table | literal "9 (Bootstrap, DIVI, ..., Oxygen)" / <td>72</td> |
factory-derived count + names + pairs |
Also fixed: two version_compare(PHP_VERSION, '7.4.0', '<') gates in functions.php were missed by the v4.3.1 PHP floor bump — now '8.1.0' to match composer.json.
Tests: tests/Unit/FrameworkConversionsTest.php had two doc-comments claiming "110 / 11 × 10" and "72" — both updated. No assertion logic changed.
Why a refactor instead of more string edits
The same 9-framework copy resurfaced in five separate admin contexts across two prior patch passes (v4.3.1's matrix-consistency work, then v4.3.2's errata cleanup). The pattern was clearly going to keep biting. Replacing the hardcoded data with a factory call removes the divergence risk for these surfaces entirely — adding a 15th framework later only requires updating the factory, not hunting admin templates.
What did NOT change
No code or test behavior changed for any user-visible flow. PHPUnit stays at 284 tests / 4,133 assertions / 0 errors / 0 failures / 0 deprecations.
Verification
| Check | Result |
|---|---|
| WP staging smoke (activation / admin load / translation flow) | ✓ passed |
| PHPUnit | 284 / 4,133 passing, 0/0/0 |
php -l across repo |
clean |
composer audit |
no advisories |
| Admin ESLint | clean |
| Admin Vite build | clean |
Factory smoke (get_framework_info()) |
14 frameworks returned, computed pairs = 182 |
./devtb --version |
v4.3.3 |
./devtb list-frameworks |
14 Total / 182 pairs |
./devtb translate bootstrap kadence ... --dry-run |
✓ |
Upgrade
```bash
git fetch && git checkout v4.3.3
composer install
cd admin && npm ci && npm run build && cd ..
./devtb --version # → DevelopmentTranslation Bridge v4.3.3
```
🤖 Generated with Claude Code