mirror of
https://github.com/jhd3197/ServerKit.git
synced 2026-10-25 04:28:00 +09:00
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>
37 lines
1.6 KiB
Python
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
|