jkohlbach · May 2, 2025 08:07 · jkohlbach · May 2, 2025
diff --git a/wp-plugin-scaffold-ai-prompt.txt b/wp-plugin-scaffold-ai-prompt.txt
 You are a senior software engineer/architect specializing in WordPress and WooCommerce. 
 In this project, implement that basic structure of a new plugin ready for further development 
 using the following details:

 The plugin will be called [your plugin name here]

 It is a plugin that [brief description of your new plugin here]

 WordPress Plugin Project Structure
 ==================================

 1. Directory Structure
 plugin-name/
 ├── .cursor/                    # Cursor rules, config
 ├── .github/                    # Github config, issue & PR templates
 ├── .vscode/                    # VSCode config
 ├── assets/                     # Assets such as images, fonts, and raw source files
 │   ├── images/                 # Image files used in the plugin
 │   └── fonts/                  # Font files if custom fonts are used
 ├── dist/                       # Compiled assets (JS, CSS) - generated by build process
 │   ├── css/                    # Compiled CSS files
 │   └── js/                     # Compiled JavaScript files
 ├── includes/                   # PHP classes and core functionality
 │   ├── Abstracts/              # Abstract classes for inheritance
 │   ├── Admin/                  # Admin-related classes
 │   ├── API/                    # API-related functionality
 │   ├── Classes/                # Main plugin classes
 │   ├── REST/                   # REST API controllers
 │   ├── Traits/                 # PHP traits for code reuse
 │   └── Utilities/              # Helper and utility classes
 ├── languages/                  # Translation files (.pot, .po, .mo)
 ├── src/                        # Source code for JS/CSS
 │   ├── apps/                   # JavaScript applications
 │   │   ├── admin/              # Admin dashboard applications
 │   │   └── frontend/           # Frontend applications
 │   ├── scss/                   # SCSS source files
 │   │   ├── admin/              # Admin styles
 │   │   └── frontend/           # Frontend styles
 │   └── js/                     # JavaScript utilities and shared code
 ├── templates/                  # Template files used by the plugin
 │   ├── admin/                  # Admin page templates
 │   └── frontend/               # Frontend templates
 ├── tests/                      # Test files
 │   └── cypress/                # Cypress E2E tests
 │       ├── e2e/                # E2E test specs
 │       ├── fixtures/           # Test fixtures/mock data
 │       ├── plugins/            # Cypress plugins
 │       └── support/            # Support files and commands
 ├── .eslintrc.js                # ESLint configuration
 ├── .gitignore                  # Git ignore file
 ├── .phpcs.xml                  # PHP Code Sniffer configuration
 ├── composer.json               # Composer dependencies and scripts
 ├── cypress.config.js           # Cypress configuration
 ├── package.json                # NPM dependencies and scripts
 ├── phpunit.xml                 # PHPUnit configuration
 ├── plugin-name.php             # Main plugin file
 ├── readme.txt                  # WordPress.org readme file
 └── webpack.config.js           # Main webpack configuration

 2. Important Design Patterns
   ▸ Singleton Pattern  
     • Used for main class instances (single instance per class)  
     • Typically implemented via `Singleton_Trait`  

   ▸ Namespace Organization  
     • All plugin code uses namespaces based on directory structure  
     • Example: `PluginName\Classes\Feature_Class`  

   ▸ Service Container Pattern  
     • Main plugin class acts as a service container  
     • Registers and initializes all services/classes  

   ▸ Factory Pattern  
     • For creating complex objects or object collections  

   ▸ MVC-like Structure  
     • Models: Data classes in `Classes/`  
     • Views: Templates in `templates/`  
     • Controllers: Various handler classes  

   ▸ Class Organization  
     • Single-responsibility per class  
     • PSR-4 autoloading standards  
     • Abstracts for base functionality  
     • Traits for shared functionality  

   ▸ Hook-based Architecture  
     • Classes register their own hooks in a `run()` method  
     • Main plugin class orchestrates all components  

 3. Build Information
   ▸ Webpack  
     • Builds JS / CSS assets  
     • Separate configs for dev & prod  
     • Bundling, minification, optimization  

   ▸ Composer  
     • Manages PHP dependencies  
     • PSR-4 autoloading  
     • Dev tools: `phpcs`, `phpunit`  

   ▸ NPM Scripts  
     • `npm run dev` – dev build with watch  
     • `npm run build` – production build  
     • `npm run lint` – JS linting  
     • `npm run test` – JS tests  
     • `npm run cypress:open` – open Cypress runner  
     • `npm run cypress:run`  – headless Cypress  

   ▸ Composer Scripts  
     • `composer install`  
     • `composer dump-autoload`  
     • `composer lint`  
     • `composer test`  

   ▸ Cypress Setup  
     • Config: `cypress.config.js`  
     • Tests: `tests/cypress/e2e`  
     • Commands: `tests/cypress/support/commands.js`  
     • Fixtures: `tests/cypress/fixtures`  

   ▸ CI/CD Integration  
     • GitHub Actions for tests & deployment  
     • Automated versioning  
     • Cypress in CI pipeline  

 4. Essential Files for Quick Setup
   ▸ **Main Plugin File** (`plugin-name.php`)  
     • Plugin header & metadata  
     • `VERSION` constant  
     • Autoloader init  
     • Main plugin class bootstrap  

   ▸ **Main Plugin Class** (`includes/Classes/Plugin.php`)  
     • Service container  
     • Hook registration  
     • Component initialization  
     • Activation / deactivation handlers  

   ▸ **Abstract Base Class** (`includes/Abstracts/Abstract_Class.php`)  
     • Shared functionality  
     • Base constructor  
     • Hook pattern  

   ▸ **Singleton Trait** (`includes/Traits/Singleton_Trait.php`)  
     • Singleton implementation  
     • Static `instance()` methods  

   ▸ **Admin Class** (`includes/Admin/Admin.php`)  
     • Admin menu & pages  
     • Asset registration  

   ▸ **Sample REST Controller** (`includes/REST/Base_Controller.php`)  
     • REST routing & permissions  
     • Response formatting  

   ▸ **Utility/Helper Class** (`includes/Utilities/Helper.php`)  
     • Static helpers & utilities  

   ▸ **Base Webpack Config** (`webpack.config.js`)  
     • Entry points & output  

   ▸ **Cypress Config** (`cypress.config.js`)  
     • Base URL, creds, timeouts  

   ▸ **Cypress Support** (`tests/cypress/support/index.js`)  
     • WP-admin login commands  
     • Global hooks  

   ▸ **Package Configs**  
     • `composer.json` (autoloading)  
     • `package.json` (deps & scripts)  

   ▸ **Sample Vue/React Component** (`src/apps/admin/App.js`)  
     • Base admin application  

 5. General Considerations
   • Follow WordPress coding standards  
   • Use namespaced, OOP code  
   • Sanitize & validate all data  
   • Separate frontend and admin assets  
   • Optimize assets via build tools  
   • Maintain i18n readiness  
   • Provide comprehensive docs & readme  
   • Use semantic versioning  
   • Organize classes by feature, not layer  
   • Employ dependency injection where useful  
   • Plan clear upgrade paths  
   • Write resilient Cypress tests  

 This structure offers a solid foundation for a modern, maintainable WordPress plugin with clear separation of concerns, efficient build processes, and automated testing.
	You are a senior software engineer/architect specializing in WordPress and WooCommerce.
	In this project, implement that basic structure of a new plugin ready for further development
	using the following details:

	The plugin will be called [your plugin name here]

	It is a plugin that [brief description of your new plugin here]

	WordPress Plugin Project Structure
	==================================

	1. Directory Structure
	plugin-name/
	├── .cursor/ # Cursor rules, config
	├── .github/ # Github config, issue & PR templates
	├── .vscode/ # VSCode config
	├── assets/ # Assets such as images, fonts, and raw source files
	│ ├── images/ # Image files used in the plugin
	│ └── fonts/ # Font files if custom fonts are used
	├── dist/ # Compiled assets (JS, CSS) - generated by build process
	│ ├── css/ # Compiled CSS files
	│ └── js/ # Compiled JavaScript files
	├── includes/ # PHP classes and core functionality
	│ ├── Abstracts/ # Abstract classes for inheritance
	│ ├── Admin/ # Admin-related classes
	│ ├── API/ # API-related functionality
	│ ├── Classes/ # Main plugin classes
	│ ├── REST/ # REST API controllers
	│ ├── Traits/ # PHP traits for code reuse
	│ └── Utilities/ # Helper and utility classes
	├── languages/ # Translation files (.pot, .po, .mo)
	├── src/ # Source code for JS/CSS
	│ ├── apps/ # JavaScript applications
	│ │ ├── admin/ # Admin dashboard applications
	│ │ └── frontend/ # Frontend applications
	│ ├── scss/ # SCSS source files
	│ │ ├── admin/ # Admin styles
	│ │ └── frontend/ # Frontend styles
	│ └── js/ # JavaScript utilities and shared code
	├── templates/ # Template files used by the plugin
	│ ├── admin/ # Admin page templates
	│ └── frontend/ # Frontend templates
	├── tests/ # Test files
	│ └── cypress/ # Cypress E2E tests
	│ ├── e2e/ # E2E test specs
	│ ├── fixtures/ # Test fixtures/mock data
	│ ├── plugins/ # Cypress plugins
	│ └── support/ # Support files and commands
	├── .eslintrc.js # ESLint configuration
	├── .gitignore # Git ignore file
	├── .phpcs.xml # PHP Code Sniffer configuration
	├── composer.json # Composer dependencies and scripts
	├── cypress.config.js # Cypress configuration
	├── package.json # NPM dependencies and scripts
	├── phpunit.xml # PHPUnit configuration
	├── plugin-name.php # Main plugin file
	├── readme.txt # WordPress.org readme file
	└── webpack.config.js # Main webpack configuration

	2. Important Design Patterns
	▸ Singleton Pattern
	• Used for main class instances (single instance per class)
	• Typically implemented via `Singleton_Trait`

	▸ Namespace Organization
	• All plugin code uses namespaces based on directory structure
	• Example: `PluginName\Classes\Feature_Class`

	▸ Service Container Pattern
	• Main plugin class acts as a service container
	• Registers and initializes all services/classes

	▸ Factory Pattern
	• For creating complex objects or object collections

	▸ MVC-like Structure
	• Models: Data classes in `Classes/`
	• Views: Templates in `templates/`
	• Controllers: Various handler classes

	▸ Class Organization
	• Single-responsibility per class
	• PSR-4 autoloading standards
	• Abstracts for base functionality
	• Traits for shared functionality

	▸ Hook-based Architecture
	• Classes register their own hooks in a `run()` method
	• Main plugin class orchestrates all components

	3. Build Information
	▸ Webpack
	• Builds JS / CSS assets
	• Separate configs for dev & prod
	• Bundling, minification, optimization

	▸ Composer
	• Manages PHP dependencies
	• PSR-4 autoloading
	• Dev tools: `phpcs`, `phpunit`

	▸ NPM Scripts
	• `npm run dev` – dev build with watch
	• `npm run build` – production build
	• `npm run lint` – JS linting
	• `npm run test` – JS tests
	• `npm run cypress:open` – open Cypress runner
	• `npm run cypress:run` – headless Cypress

	▸ Composer Scripts
	• `composer install`
	• `composer dump-autoload`
	• `composer lint`
	• `composer test`

	▸ Cypress Setup
	• Config: `cypress.config.js`
	• Tests: `tests/cypress/e2e`
	• Commands: `tests/cypress/support/commands.js`
	• Fixtures: `tests/cypress/fixtures`

	▸ CI/CD Integration
	• GitHub Actions for tests & deployment
	• Automated versioning
	• Cypress in CI pipeline

	4. Essential Files for Quick Setup
	▸ Main Plugin File (`plugin-name.php`)
	• Plugin header & metadata
	• `VERSION` constant
	• Autoloader init
	• Main plugin class bootstrap

	▸ Main Plugin Class (`includes/Classes/Plugin.php`)
	• Service container
	• Hook registration
	• Component initialization
	• Activation / deactivation handlers

	▸ Abstract Base Class (`includes/Abstracts/Abstract_Class.php`)
	• Shared functionality
	• Base constructor
	• Hook pattern

	▸ Singleton Trait (`includes/Traits/Singleton_Trait.php`)
	• Singleton implementation
	• Static `instance()` methods

	▸ Admin Class (`includes/Admin/Admin.php`)
	• Admin menu & pages
	• Asset registration

	▸ Sample REST Controller (`includes/REST/Base_Controller.php`)
	• REST routing & permissions
	• Response formatting

	▸ Utility/Helper Class (`includes/Utilities/Helper.php`)
	• Static helpers & utilities

	▸ Base Webpack Config (`webpack.config.js`)
	• Entry points & output

	▸ Cypress Config (`cypress.config.js`)
	• Base URL, creds, timeouts

	▸ Cypress Support (`tests/cypress/support/index.js`)
	• WP-admin login commands
	• Global hooks

	▸ Package Configs
	• `composer.json` (autoloading)
	• `package.json` (deps & scripts)

	▸ Sample Vue/React Component (`src/apps/admin/App.js`)
	• Base admin application

	5. General Considerations
	• Follow WordPress coding standards
	• Use namespaced, OOP code
	• Sanitize & validate all data
	• Separate frontend and admin assets
	• Optimize assets via build tools
	• Maintain i18n readiness
	• Provide comprehensive docs & readme
	• Use semantic versioning
	• Organize classes by feature, not layer
	• Employ dependency injection where useful
	• Plan clear upgrade paths
	• Write resilient Cypress tests

	This structure offers a solid foundation for a modern, maintainable WordPress plugin with clear separation of concerns, efficient build processes, and automated testing.