WordPress Management

Local-first Laravel 12 application for managing WordPress site profiles, encrypted credentials, SDK-backed connection tests, and override-based content sync.

Stack

• PHP 8.5
• Laravel 12
• MySQL for application data
• MongoDB for package event storage, config-store data, and explicit diagnostics
• Blade, Bootstrap, Font Awesome, and plain JavaScript
• jooservices/wordpress-sdk for WordPress REST API integration
• jooservices/form-builder for dynamic template form parsing, config rendering, submission validation, and normalization
• jooservices/laravel-repository for Eloquent repository CRUD/filter/order composition
• jooservices/laravel-events for MongoDB-backed audit event persistence
• jooservices/laravel-config for MongoDB-backed runtime defaults
• mongodb/laravel-mongodb for MongoDB connections used by events and diagnostic payloads

Current Scope

P1 implements Sites Management. P2 adds Content Management + Basic Override Sync:

• Admin shell with topbar, collapsible sidebar, footer, shared alerts, status badges, empty states, and consistent action placement
• Shared MasterLayout contract: Sidebar -> Topbar -> PageHeader -> Feedback -> FilterSearch -> MainContent -> ResultSummaryPagination -> Footer
• Dashboard counts for total, connected, failed, and untested sites
• WordPress site CRUD with search/filter, soft delete, status, and last connection state
• Per-site credential profiles with encrypted secrets, masked UI display, default selection, and route ownership checks
• SDK-backed connection test with latest MySQL state, classified failures, and sanitized LogService event writes
• Site detail control-center view with quick links, default credential summary, and recent connection logs
• Unified Logs page for sanitized P1 operational debugging
• Docker/WP-CLI foundation for live WordPress connection testing
• Local CRUD for posts, pages, categories, and tags
• Explicit queued pull and push actions only. Pull overwrites local data with remote WordPress data. Push overwrites remote WordPress data with local data.
• Explicit remote delete actions for posts, pages, categories, and tags when a local record already has a remote_id. Remote delete keeps the local record and clears its remote sync link.
• Local delete remains local only and does not delete remote WordPress content or terms.
• Sync center page with per-site pull and push actions, ordered "all supported content" bulk actions, recent sync history, and failed sync visibility
• MySQL sync history plus sanitized MongoDB audit events for content and taxonomy sync operations
• Global media management with private local storage, site filtering, preview/download routes, and runtime defaults from jooservices/laravel-config
• Post template workflows: Create From Template, Generated Drafts, and Post Templates backed by jooservices/form-builder

Setup

composer install
cp .env.example .env
php artisan key:generate
php artisan migrate
php artisan content-templates:import-built-ins
php artisan events:install-indexes
php artisan config-store:ensure-index
php artisan serve

Configure .env for the default host/local application runtime:

DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=jooservices_wordpress_management
MONGODB_URI=mongodb://127.0.0.1:27017
MONGODB_DATABASE=jooservices_wordpress_management_logs
MONGODB_SERVER_SELECTION_TIMEOUT_MS=1000
MONGODB_CONNECT_TIMEOUT_MS=1000
WORDPRESS_ALLOW_PRIVATE_URLS=false

If you run the repository's isolated live WordPress Docker test stack while Laravel still runs on the host, use these testing database overrides:

DB_HOST=127.0.0.1
DB_PORT=3307
DB_DATABASE=jooservices_wordpress_management_testing
DB_USERNAME=root
DB_PASSWORD=wordpress
MONGODB_URI=mongodb://127.0.0.1:27018
MONGODB_DATABASE=jooservices_wordpress_management_logs_testing

The main application does not ship an app-container Compose stack. docker-compose.wp-test.yml is an isolated live-test environment for WordPress, MySQL, MongoDB, and WP-CLI.

For local WordPress targets such as 127.0.0.1, set WORDPRESS_ALLOW_PRIVATE_URLS=true.

Tests

composer test
composer test:unit
composer test:feature
composer test:coverage
composer lint
composer quality
composer ci

Live WordPress Test

Requires Docker.

composer wp:test:up
composer wp:test:reset
composer test:wp-live
composer wp:test:down

This stack exposes services to the host for host-run artisan commands:

• MySQL: 127.0.0.1:3307
• MongoDB: 127.0.0.1:27018
• WordPress: http://127.0.0.1:8089

If MongoDB is available locally, install package indexes after configuration changes:

php artisan events:install-indexes
php artisan config-store:ensure-index

If you are using the live WordPress Docker stack instead of a host-local MongoDB service, run:

MONGODB_URI=mongodb://127.0.0.1:27018 MONGODB_DATABASE=jooservices_wordpress_management_logs_testing php artisan config-store:ensure-index

The live report is written to:

storage/app/test-reports/wp-live-report.json

The report includes site URL, valid and invalid credential results, created local and remote IDs, content sync results, commands executed, and cleanup status. It does not include passwords, tokens, auth headers, or application passwords.

Notes

The installed WordPress SDK supports Basic/Application Password authentication. P1 stores all requested auth profile types, but authenticated SDK validation is only available for application_password and basic until the SDK exposes bearer/JWT authenticators.

Test Strategy

• Treat jooservices/wordpress-sdk as a trusted external dependency.
• Mock only the app-owned SDK boundary (App\Contracts\WordPressClient) in automated tests.
• Do not mock internal Request -> Controller -> FormRequest -> Service -> Repository -> Model flow in feature tests.
• Use jooservices/laravel-repository for reusable Eloquent repository behavior and keep domain-specific queries explicit where they are clearer.
• Use jooservices/laravel-events for audit-worthy site, credential, and connection events.
• Meaningful logs go through LogService; MongoDB is not used as a general log dump.

Usage

• Manage sites at /sites.
• Manage posts at /posts.
• Use /posts/create-from-template to generate post drafts from dynamic template forms. The built-in Default Story form includes title, intro editor, repeater chapters, optional chapter media, and chapter content editor fields.
• Use /generated-drafts to inspect generated form values, rendered HTML, WordPress payloads, template snapshots, and linked local posts.
• Use /post-templates to import built-ins, validate templates, and edit template definition JSON. Template JSON editing is for template definitions only; normal story creation uses rendered forms, not pasted story JSON.
• Manage pages at /pages.
• Manage categories at /categories.
• Manage tags at /tags.
• Use /media for global media management across all sites. Filter by site before queueing a media pull for that site.
• Use /settings for global application media and sync defaults. The storage root/path is shared by all WordPress sites.
• Use /sync-center for explicit queued pull and push sync actions per site.
• Use the sync center bulk actions when you want categories and tags processed before posts and pages.
• Open a site detail page to test the default credential, manage credentials, open WordPress admin, open the REST endpoint, and review recent connection logs.
• Use the Sidebar, Sites table, Dashboard recent-site actions, or site detail quick links to open Media and Settings.
• Site detail links to the global Media index with a site filter and to global Settings; it does not own media management or settings.
• Use /logs?tab=connection for recent sanitized connection events.
• Use /logs for grouped Overview, Audit, Sync, Connections, Jobs, and Errors tabs.

Logs views intentionally show sanitized metadata only. Content and media sync follow override-only rules in this phase: no smart merge, no conflict workflow yet, and no remote media binary replacement. Sync actions dispatch jobs; controllers must not run long WordPress API or download work inline. Private media files stay off the public storage symlink and are rendered through app routes. Route-level auth for preview/download remains future work. The app must continue to use App\Contracts\WordPressClient plus App\Services\WordPress\ClientFactory as the only SDK boundary for WordPress operations. Secrets, tokens, auth headers, and application passwords must not appear in UI, logs, config-store values, or live test reports.