WordPress Plugin Development Team -- v1 Completion (PHP + React/TypeScript) ======================================== OVERVIEW ======================================== We are looking for an experienced DEVELOPMENT TEAM -- not a solo developer -- to complete a proprietary WordPress plugin currently ~55% complete. The architecture, database schema, REST API structure, and requirements documentation are all well-established. Your team's job is to complete the implementation. This is a SCHEMA-DRIVEN, FRAMEWORK-STYLE PROJECT. The heavy architectural thinking is done. The work remaining is completing the framework components and filling in the gaps where implementations are stubbed or partial. Bids from solo developers will not be considered. ======================================== TECHNOLOGY STACK ======================================== - Backend: PHP 8.2+, WordPress 6.0+, custom REST API, Composer-managed dependencies (MPDF, chillerlan/php-qrcode) - Frontend: React 18+, TypeScript, Webpack, @wordpress/components, CKEditor 5 - Database: MySQL -- single physical table architecture with a logical table abstraction layer - Standards: WordPress Coding Standards (PHPCS enforced), TypeScript strict mode, full multisite compliance ======================================== ARCHITECTURE HIGHLIGHTS ======================================== This is not a typical WordPress plugin. Understanding the architecture is essential: - SINGLE PHYSICAL TABLE, MULTIPLE LOGICAL ENTITIES. All entity types are stored in one physical MySQL table via a Query Builder / Query Runner abstraction layer. Adding a new entity type is a schema change, not a schema + table change. - SCHEMA-DRIVEN REST API. A PHP schema definition drives automatic endpoint registration, field validation, and response shaping. REST handlers are largely generic -- adding a new resource does not mean writing a new handler. - SCHEMA-DRIVEN ADMIN UI. The frontend consumes a TypeScript schema module (auto-generated from PHP at build time) to render list views, detail views, forms, and actions. Renderers are generic, shared components -- not per-resource code. - SHARED COMPONENT ARCHITECTURE. Collection, group, table, and detail renderers are written once and reused across all resources via schema configuration. The gap between 55% and 100% is completing the framework itself (query runner edge cases, renderer TODOs, permission middleware, pipeline integrations) -- not writing bespoke code for each resource. ======================================== WHAT IS ALREADY DONE ======================================== - Database schema (95%): physical table, logical table mapping, Query Builder, Query Runner - REST API routing and schema-driven dispatch (80%): all endpoints registered, generic handlers partially implemented - Admin UI framework (70%): schema-driven renderer architecture, PHP -> TypeScript schema pipeline, webpack config, shared component library scaffolded - Third-party adapter architecture (40%): abstract base class, WPForms adapter stubbed - Plugin activation, deactivation, and multisite hooks (scaffolded) - Full written requirements: separate backend and frontend developer requirements documents with detailed specifications for every feature ======================================== WHAT NEEDS TO BE COMPLETED ======================================== BACKEND (PHP) - Complete the generic REST handler layer (query runner relationship handling, result transformation, permission middleware) - Hierarchical RBAC permission system (6-level resolution) -- resolves once, cached per request, consumed by all handlers - WPForms adapter: event hook integration and stat aggregation - Custom Field Definitions system: three-source CDF merging, key uniqueness enforcement, utility endpoints - Dashboard stats aggregation endpoint - PDF generation pipeline: CKEditor 5 Twig templates + MPDF + chillerlan/php-qrcode - Settings admin page - Multisite compliance: per-site DB migration with lazy version checks, network admin panel - Notes sub-entity support (generic, applies to all entity types via schema flag) FRONTEND (React/TypeScript) - Complete shared renderer TODOs in collection, group, and table components (the gap is in the framework, not per-resource) - Dashboard stats view + system info panel - Custom Fields UI: definition editor (shared component -- add/reorder/delete/validate, source badges, option set picker) and value input fields (type-mapped inputs driven by field type in schema) - Network admin panel: site overview table, per-site and bulk migration actions - CKEditor 5 integration in template editor - Settings page UI - QR code preview in detail view ======================================== TEAM COMPOSITION EXPECTED ======================================== We expect bids from TEAMS. Please include in your proposal: - Number of backend developers and relevant experience (PHP 8.2+, WordPress plugin development, REST APIs, RBAC systems, Twig templates + MPDF + chillerlan/php-qrcode) - Number of frontend developers and relevant experience (React 18+, TypeScript, schema-driven UI, @wordpress/components, CKEditor 5 Twig templates) - QA / testing resources - Any additional team members you propose (project management, DevOps, etc.) Bids from solo developers will not be considered. ======================================== REQUIREMENTS FOR YOUR PROPOSAL ======================================== 1. Describe your full team composition as outlined above 2. Provide examples of similar projects -- especially schema-driven architectures, RBAC systems, or generic/shared admin UI frameworks 3. Describe your QA and testing approach 4. Propose a milestone-based delivery structure 5. Ask any clarifying technical questions -- detailed written requirements documents will be shared with shortlisted teams for review and final scope/price negotiation prior to award ======================================== NOTES ======================================== - Full requirements documentation is available to shortlisted teams under NDA prior to award - The existing codebase will be shared with winning team under NDA after the project is awarded - WordPress Coding Standards compliance is required -- PHPCS is configured and enforced - TypeScript strict mode is required -- no "any" types - All queries to the plugin's physical table must go through the Query Builder / Query Runner -- no direct $wpdb calls against that table - All other $wpdb queries must use $wpdb->prepare() ======================================== IMPORTANT -- PLEASE READ ======================================== To confirm that your bid -- both amount and timeline -- is a genuine estimate based on the full scope of work described in this posting and not a placeholder bid, please include the phrase SOLI DEO GLORIA at the beginning of your proposal. Bids without this phrase will be declined without response.