wpwing-dev/wpwing-smart-wishlist-product-waitlist-for-woocommerce

1. This is a WordPress/WooCommerce plugin, not a standalone app.

The shipped code lives under src/ and is activated through the main plugin bootstrap file src/wpwing-smart-wishlist-product-waitlist-for-woocommerce.php. Everything else in the repo is either supporting runtime code, build/dev tooling, or tests.

2. The plugin is split into four main runtime layers: Core, Admin, Frontend, and feature modules.

- Core/ handles lifecycle, persistence, settings, cron, GDPR, and deletion hooks.

- Admin/ contains WordPress dashboard pages and list tables.

- Frontend/ handles conditional CSS/JS loading.

- Wishlist/ and Waitlist/ contain the actual user-facing feature flows.

3. Core is the orchestration boundary.

Core/Plugin.php is the central boot sequence/singleton that wires hooks and loads the rest of the plugin. Activator.php creates data structures on activation, Settings.php wraps WordPress options, Database.php centralizes table naming, and Cron.php schedules cleanup tasks. GdprHandler.php and ProductDeleteHandler.php connect the plugin to WordPress compliance and product lifecycle events.

4. The plugin uses custom database tables instead of storing everything in post meta.

The README explicitly calls out “custom database tables for performance.” That means the key architectural boundary is between WordPress/WooCommerce native entities (products, users, sessions, options) and plugin-owned tables used for wishlist and waitlist records. This is important for diagramming because the plugin is not just a thin UI layer; it owns its own persistence model.

5. Wishlist and waitlist are separate feature pipelines with similar structure.

Each feature has:

- a frontend renderer,

- an AJAX controller,

- and a guest merge handler for logged-out users who later authenticate.

Wishlist lives in src/app/Wishlist/, waitlist in src/app/Waitlist/. This separation matters because they are related but independent data flows.

6. Frontend interaction is mostly AJAX-driven and uses small asset bundles.

assets/js/wpwing-wishlist.js and assets/js/wpwing-waitlist.js handle client-side requests. Frontend/Assets.php enqueues the shared CSS/JS only when needed, keeping the plugin lightweight. The frontend PHP templates in src/templates/ render the shortcode/UI markup that these scripts enhance.

7. The wishlist flow is centered on product intent capture.

FrontendWishlist.php renders the wishlist button/shortcode output, WishlistController.php processes toggle/check requests, and GuestMergeHandler.php merges guest selections into a user account after login. AdminWishlist.php provides an admin-side view of stored wishlist data.

8. The waitlist flow is centered on back-in-stock subscription and notification.

FrontendWaitlist.php renders the email capture form and shortcode output, WaitlistController.php handles join/leave actions and downstream notifications, and GuestMergeHandler.php preserves anonymous intent across login. The templates waitlist-form.php and waitlist-view.php define the markup boundary for this feature.

9. Admin functionality is operational, not content-authoring.

AdminMenu.php adds plugin pages to the WordPress dashboard, AdminSettings.php exposes settings screens, AdminWaitlist.php surfaces waitlist entries, and WelcomeNotice.php handles a one-time activation notice. This subsystem is for configuration and operational oversight rather than end-user shopping behavior.

10. The plugin integrates with WooCommerce and WordPress lifecycle events.

Key cross-cutting triggers are activation, product deletion, login/guest merge, cron, and GDPR export/erasure hooks. Those are the main edges where the plugin connects into the host platform, so an architecture diagram should show these as event-driven integrations rather than direct user-facing services.

11. Repository tooling is split cleanly from runtime code.

Root-level composer.json, Makefile, PHPCS/PHPStan config, PHPUnit, and Playwright are dev/test tooling. docker-compose.yml plus docker/ provide a local WordPress/PHP/Caddy environment. dist/ is the release artifact boundary, while tests/ cover unit and end-to-end behavior.

12. Net effect: one plugin, two customer-intent products, shared infrastructure.

The shared infrastructure is the important architectural idea: both wishlist and waitlist use the same plugin bootstrap, settings, assets pipeline, admin shell, and lifecycle handlers, while keeping their UI and controllers separate. That makes the diagram naturally split into a common core with two feature branches feeding a shared persistence layer.