upskill-event-manager/memory-bank/decisionLog.md

[2025-03-31] - E2E Registration Test Debugging

• Decision: Add novalidate attribute to the <form> tag in class-hvac-registration.php.
• Rationale: Native HTML5 validation (required attributes) was preventing form submission during E2E tests when invalid data was entered, thus blocking testing of the server-side validation and error display mechanism. Adding novalidate allows the form to be submitted regardless, enabling testing of the PHP handler.
• Implementation Details: Added novalidate attribute directly to the form tag in the display_form_html method.

Decision Log

This file records architectural and implementation decisions using a list format. 2025-03-26 11:11:00 - Updated with development environment workflow decisions

Core Architectural Decisions

Development Environment Configuration

• Decision: Implement Docker-based development environment with PHP-FPM
• Rationale: Better performance, control, and similarity to production
• Implementation Details:
  • WordPress with PHP 8.1-FPM
  • Nginx as web server
  • MariaDB for database
  • Custom PHP-FPM configuration
  • Development-specific WordPress settings

Development Environment Workflow

• Decision: Implement backup-based workflow for development environment setup
• Rationale: More reliable, faster setup, offline support, and consistent environments
• Implementation Details:
  • Create backups from production using sync-production.sh
  • Set up environment from backups using setup-from-backup.sh
  • Standardized script naming and organization
  • Comprehensive documentation and migration guide
  • Improved error handling and verification

WordPress Configuration Strategy

• Decision: Use environment variables and wp-config.php overrides
• Rationale: Maintain security and flexibility across environments
• Implementation Details:
  • Environment-based configuration
  • Debug mode in development
  • Custom site URL handling
  • SSL configuration options
  • Security settings management

Database Management

• Decision: Use MariaDB with custom configuration
• Rationale: Better performance and compatibility
• Implementation Details:
  • Custom character set and collation
  • Optimized buffer settings
  • Development-specific permissions
  • Backup and restore capabilities
  • Data synchronization tools

Version Control Strategy

• Decision: Implement Git-based version control with GitHub hosting
• Rationale: Enable collaborative development, code review, and version tracking
• Implementation Details:
  • Git repository with main branch
  • GitHub remote for collaboration
  • .gitignore to exclude environment-specific files
  • Structured commit messages
  • Clean repository history

Registration and Authentication Architecture

• Decision: Implement custom registration and authentication system
• Rationale: Need fine-grained control over user registration process and role management
• Implementation Details:
  • Custom database table for trainer profiles
  • Client and server-side validation
  • Automated venue creation integration
  • Email notification system
  • Role-based access control
  • Security measures following WordPress best practices

SSL Configuration for Development

• Decision: Disable SSL requirement in development
• Rationale: Simplify local development while maintaining production security
• Implementation Details:
  • Configurable SSL settings
  • Environment-specific SSL handling
  • Production-ready SSL configuration
  • Secure cookie handling
  • HTTPS redirection management

Custom Role Architecture

• Decision: Implement hvac_trainer custom WordPress role
• Rationale: Provide specific capabilities while restricting administrative access
• Implementation Details:
  • Role name: hvac_trainer
  • Custom capabilities for HVAC-specific features
  • Integration with The Events Calendar capabilities
  • Automatic role management through plugin lifecycle
  • Strict security boundaries

Integration-First Development Approach

• Decision: Maximize use of existing WordPress and The Events Calendar functionality
• Rationale: Leverage proven solutions, reduce custom code, ensure maintainability
• Implementation Details:
  • Use WordPress core features whenever possible
  • Extend The Events Calendar functionality rather than rebuild
  • Custom development only when necessary
  • Maintain plugin upgrade compatibility

2025-03-26 11:11:00 - Added development environment workflow decisions 2025-03-26 11:40:00 - Architectural Decision: Plugin Structure

• Decision: Created custom plugin rather than modifying existing registration plugins
• Rationale: Need complete control over form fields and validation specific to HVAC trainers
• Implementation Details:
  • Standalone WordPress plugin structure
  • Custom form handler class

2025-03-27 13:54:00 - Testing Environment Architecture

• Decision: Implement WordPress unit testing framework within Docker container
• Rationale: More reliable, consistent testing environment that matches production configuration
• Implementation Details:
  • Install testing dependencies directly in WordPress container
  • Configure database access from container to MariaDB
  • Share test files via Docker volumes
  • Standardize test execution process with helper scripts
  • Allow for both local and CI/CD testing with same configuration

2025-03-28 05:32:00 - Test Configuration Architecture

• Decision: Configure WordPress test environment using wp-tests-config.php in Docker container
• Rationale: Ensure consistent test environment across all development machines while maintaining Docker isolation
• Implementation Details:
  • Use environment-specific database settings (host: 'db', proper credentials)
  • Configure correct WordPress core paths for Docker container (/var/www/html/)
  • Standardize test framework file locations
  • Maintain separation between development and test databases
  • Use Docker environment variables for sensitive configuration

[2025-03-28 16:24:00] - Test Environment Configuration Decisions

• Decision: Use Composer (wp-phpunit/wp-phpunit) for PHPUnit test framework installation, removing manual/SVN steps from Dockerfile and documentation.

• Rationale: Aligns with standard PHP practices, simplifies Dockerfile, resolves SVN dependency issues.

• Decision: Configure PHPUnit environment using a combination of files:

  • phpunit.xml.dist: Defines test suites only (no PHP constants).
  • wp-tests-config.php (host wordpress-dev/): Defines test DB credentials (hardcoded root password) and ABSPATH. Mounted via volume.
  • tests/bootstrap.php (host wordpress-dev/): Defines ABSPATH early, defines WP_TESTS_CONFIG_FILE_PATH, defines WP_TESTS_RUNNING, finds vendor test library, loads plugin, requires main test bootstrap.
  • wp-config.php (host wordpress-dev/wordpress/): Wraps main DB constant definitions in if (!defined('WP_TESTS_RUNNING')).

• Rationale: Resolves constant redefinition errors, ABSPATH errors, and database connection failures during PHPUnit bootstrap by ensuring correct loading order and configuration precedence.

• Decision: Install WP-CLI via direct volume mount (./bin/wp-cli.phar:/usr/local/bin/wp) in docker-compose.yml instead of Dockerfile RUN commands.

• Rationale: Bypasses persistent failures during Docker image build process related to curl/chmod/mv steps.

• Decision: Increase PHP memory_limit to 512M via mounted php.ini/custom.ini.

• Rationale: Resolves fatal memory exhaustion errors encountered when running WP-CLI and potentially PHPUnit.

• Decision: Modify bin/run-tests.sh to exit 1 on unit/integration test failure.

• Rationale: Prevents unnecessary execution of E2E tests when earlier, fundamental tests fail.

• Decision: Consolidate docs/test-environment-plan.md and wordpress-dev/testing.md into wordpress-dev/testing.md.

• Rationale: Centralizes testing information, removes redundancy, incorporates fixes identified during debugging.

[2025-03-28 16:47:00] - Automatic Page Creation

• Decision: Implement automatic creation of required plugin pages (Login, Registration, Dashboard) upon plugin activation.
• Rationale: Ensures consistent environment setup, simplifies user experience, and resolves E2E test failures caused by missing pages. Avoids manual setup steps.
• Implementation Details:
  • Use register_activation_hook in the main plugin file.
  • Callback function checks for existing pages by slug using get_page_by_path.
  • If page doesn't exist, create it using wp_insert_post with predefined title, slug, and content (using Gutenberg block format for shortcodes).
  • Refer to docs/automatic-page-creation-plan.md for full details.

• Theme-compatible CSS styling
• Integration with The Events Calendar planned