Files
ServerKit/backend/tests/test_module_toggles.py
Juan DenisandClaude Opus 4.8 a55e50bc16 feat(extensions): Phase 5 — extract WordPress into serverkit-wordpress (backend)
The largest single move in the plan (#38). The entire WordPress backend leaves
core for the bundled, default-installed serverkit-wordpress extension (D4).

Moved (12 files → builtin-extensions/serverkit-wordpress/backend/, intra-extension
imports made relative, core imports stay absolute):
  api/wordpress.py, api/wordpress_sites.py, api/environment_pipeline.py,
  wordpress_service.py (2676 lines), git_wordpress_service, wordpress_env_service,
  wordpress_plugin_library_service, wp_analytics/reports/security/update/vulnerability.

Wiring:
- Blueprints keep /api/v1/wordpress, /wordpress/projects and the /wordpress/pipelines
  alias (D9) via new manifest `extra_blueprints` support (3 blueprints / 4 mounts).
- Flagship (D4): seeded active on every panel (fresh + upgrade), uninstallable,
  never deletes tracked builtin/pre-bundled files; the `wordpress` module toggle is
  retired (MODULES now empty) — the plugin status guard is the gate.
- Loadability: the dashed package app.plugins.serverkit-wordpress is registered
  in-place via spec_from_file_location (no copy) — uniform across prod/dev/test.
- The 11 WP test files re-pointed through app.services.wordpress_bridge; the 6 lazy
  core callers were re-pointed in the prior commit.
- _regenerate_frontend_manifest() is a no-op under testing so the flagship boot
  seed can't clobber the checked-in plugins-manifest.json.

Deviations (documented, matching the Email precedent):
- WordPress *models* stay core — status_page/environment_activity/promotion_job hold
  FKs into wordpress_sites, so relocation would be a breaking data migration.
- Event catalog + Fail2ban WP filter stay core as two-speed items (extension calls
  them via core APIs); inverting adds risk without blocking the move.
- Frontend UI stays core this session (it lives in a TabGroupLayout — the tab-grouped
  conversion Phase 1 deliberately deferred); the extension is backend-only, so there
  is no route duplication. Frontend contribution is the scoped follow-up.

Verified: clean collection across all 1223 tests; 199 passed / 2 skipped / 0 failed
across the WP + plugin/extension + module + backup + core-caller parity set, incl.
the new tests/test_wordpress_extraction.py proving the move.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-02 00:15:10 -04:00

37 lines
1.6 KiB
Python

"""Module toggles (#14): the generic core-vertical toggle machinery.
Email (#32) and WordPress (#38) both graduated from module toggles to bundled
extensions (serverkit-email / serverkit-wordpress), so the MODULES map is now
empty. Their APIs are gated by the plugin status guard instead — proven in
test_wordpress_extraction.py / test_email_extraction.py. These tests keep the
generic toggle machinery honest so a future core-vertical toggle can be added
without re-plumbing.
"""
from app.services import module_service
def test_modules_default_empty(app, client, auth_headers):
resp = client.get('/api/v1/modules', headers=auth_headers)
assert resp.status_code == 200
mods = {m['name']: m for m in resp.get_json()['modules']}
# WordPress and Email are extensions now, not module toggles.
assert 'wordpress' not in mods
assert 'email' not in mods
def test_unknown_module_404(app, client, auth_headers):
resp = client.put('/api/v1/modules/nope', headers=auth_headers, json={'enabled': False})
assert resp.status_code == 404
def test_wordpress_api_reachable_via_extension(app, client, auth_headers):
"""WordPress ships as a default-installed flagship extension, so its API is
reachable (not 503) on a stock panel — no module toggle stands in front."""
resp = client.get('/api/v1/wordpress/sites', headers=auth_headers)
assert resp.status_code != 503
def test_is_module_enabled_fails_open(app):
# Unknown module name is treated as enabled (never hide a core feature).
assert module_service.is_module_enabled('does-not-exist') is True