ben/upskill-event-manager
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions 2

feat: Successfully create test user on staging and update test setup

Browse source 
- Troubleshooted and fixed issues with the plugin deployment script (`deploy-plugin.sh`) to ensure all necessary plugin files, including the main plugin file, are correctly transferred to the staging environment.
- Corrected a role name mismatch in the test user creation script (`setup-staging-test-users.sh`) to successfully create a test user with the `hvac_trainer` role on staging.
- Updated the E2E test runner script (`run-tests.sh`) to replace deprecated Docker commands with SSH commands targeting the staging environment and explicitly pass the staging URL to Playwright.
- Increased the global timeout and enabled retries in the Playwright configuration (`playwright.config.ts`) to aid in debugging test failures on the staging environment.
- Updated documentation files (`docs/mvp-integration-testing-plan.md`, `wordpress-dev/README.md`, and `wordpress-dev/MIGRATION_GUIDE.md`) to include instructions on setting up the test user for the staging environment and corrected section numbering in the testing plan.
This commit is contained in:
bengizmo 2025-04-24 04:15:43 -03:00
parent b848eeaa43
commit fd79b22c9b
18 changed files with 5987 additions and 1965 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

15
docs/mvp-integration-testing-plan.md
View file

@ -65,13 +65,22 @@ The staging environment setup and configuration details, including SSH access an
* **Test Environment Management Scripts:** Scripts like `./tests/run-tests.sh setup` and `./tests/run-tests.sh teardown` are used to prepare and clean up necessary test data (e.g., test users) on the staging environment.
* **Markdown Test Reporting:** The custom reporter generates LLM-friendly reports summarizing test results, as described in `docs/REQUIREMENTS.md`.
## 7. Compatibility Verification
## 6.1 Test User Setup
A test user with the 'hvac_trainer' role is required to execute the E2E tests covering trainer workflows. This user can be created on the staging environment using the following script:
```bash
./bin/setup-staging-test-users.sh
```
This script should be executed from the `wordpress-dev/` directory after the HVAC Community Events plugin has been deployed and activated on the staging server. The script creates a user with the username `test_trainer` and password `Test123!`.
## 6.2 Compatibility Verification
Compatibility with the required TEC plugins is primarily verified through the successful execution of the MVP E2E test cases. These tests inherently interact with the functionality provided by The Events Calendar suite (e.g., event forms, dashboard views, event pages).
Successful completion of the E2E test suite without errors indicates that the HVAC plugin is functioning correctly alongside the TEC plugins for the covered MVP workflows. Manual spot-checking on the staging site may be performed to supplement automated tests if specific integration points require additional verification.
## 8. Success Criteria
## 7. Success Criteria
MVP integration testing is considered successful when the following criteria are met:
@ -79,7 +88,7 @@ MVP integration testing is considered successful when the following criteria are
* All key MVP Playwright E2E test cases listed in Section 4 pass without errors when executed against the staging environment.
* No critical errors, conflicts, or breaking issues are observed on the staging site related to the required TEC plugins when the HVAC Community Events plugin is active.
## 9. MVP Integration Testing Flow
## 8. MVP Integration Testing Flow
```mermaid
graph TD

11
memory-bank/activeContext.md
View file

@ -98,4 +98,13 @@ Open Questions/Issues:
[2025-04-23 13:20:00] - Current task: Debugging MVP integration tests. Identified that Playwright E2E tests are failing due to a login issue on the staging environment via the custom community login page. The page redirects to wp-login.php instead of the dashboard after submission. Documentation regarding Playwright test execution command and location was outdated and has been updated in docs/mvp-integration-testing-plan.md, docs/REQUIREMENTS.md, wordpress-dev/README.md, and memory-bank/playwright-test-plan.md. Further server-side debugging is required to fix the login issue preventing test completion.
[2025-04-23 16:19:39] - Current task: Debugging MVP integration tests. The primary issue causing Playwright E2E test failures is the absence of the required `test_trainer` user on the staging environment. No automated script for creating this user on staging was found in the repository. Manual user creation or development of a setup script is needed to resolve this blocking issue. Documentation regarding Playwright test execution has been updated.
2. Evaluate additional edge cases for testing
3. Plan error handling documentation
3. Plan error handling documentation
[2025-04-23 19:02:45] - Current task: Migration from Docker to Cloudways Staging. Completed the documentation updates to remove Docker container references and replace them with Cloudways staging server directives. Updated the following files:
1. wordpress-dev/README.md - Completely rewrote to focus on Cloudways staging environment
2. wordpress-dev/MIGRATION_GUIDE.md - Updated to remove Docker references and focus on Cloudways staging workflow
3. memory-bank/productContext.md - Updated Development Environment section to reflect Cloudways staging environment
4. memory-bank/decisionLog.md - Added entry documenting the migration decision and rationale
[2025-04-23 23:16:13] - Successfully created test user on staging server and updated documentation regarding test user setup. Addressed issues with plugin deployment script and test runner configuration to target staging environment.
The next step is to identify and update or deprecate Docker-related code files and scripts. This will be handled in the next phase of the migration.
[2025-04-23 19:12:49] - Deprecated all Docker-based commands and configuration files. dev-env.conf and wp-config-docker.php updated to reflect Cloudways-only workflow. Current focus: Maintain and enhance Cloudways staging environment; ensure all development, testing, and deployment use Cloudways exclusively.

8
memory-bank/decisionLog.md
View file

@ -60,3 +60,11 @@
[2025-04-23 13:19:25] - Debugging MVP integration tests: Identified that Playwright E2E tests fail due to login failure on the staging environment via the custom community login page. The page redirects to wp-login.php instead of the dashboard after submission, without displaying an explicit error. Likely causes are issues with the custom login page's backend processing or redirection logic on staging. Documentation regarding Playwright test execution command and location (`./tests/run-tests.sh pw`) was found to be outdated and has been updated in relevant files (`docs/mvp-integration-testing-plan.md`, `docs/REQUIREMENTS.md`, `wordpress-dev/README.md`, `memory-bank/playwright-test-plan.md`). Further server-side debugging is needed to fix the login issue.
[2025-04-23 16:19:18] - Debugging MVP integration tests: Confirmed that the `test_trainer` user does not exist on the staging environment via WP-CLI. This is the root cause of the Playwright E2E test login failures. Investigation into existing scripts and documentation (`wordpress-dev/bin/`, `tests/`, `docs/testing.md`) did not reveal an automated script for creating these test users on staging. Manual creation or development of a new setup script is required.
- Testing guidelines
[2025-04-23 19:01:29] - Migration from Docker to Cloudways Staging: Completed the transition from Docker-based local development to using the Cloudways staging server as the primary development and testing environment. This decision was made to simplify the development workflow, ensure consistent testing environments, and reduce setup complexity. All documentation has been updated to remove Docker references and replace them with Cloudways staging server directives. Key benefits include: 1) Consistent environment for all developers, 2) Simplified setup process, 3) Production-like testing environment, 4) Reduced local resource requirements, and 5) Improved collaboration through shared staging environment. Implementation involved updating README.md, MIGRATION_GUIDE.md, and productContext.md to reflect the new workflow.
[2025-04-23 23:16:32] - Decided to modify `deploy-plugin.sh` and `deploy_config.sh` to correct rsync source path interpretation and successfully deploy plugin files to staging.
[2025-04-23 23:16:32] - Identified and corrected role name mismatch in `setup-staging-test-users.sh` (`trainer` to `hvac_trainer`) to enable successful test user creation.
[2025-04-23 23:16:32] - Modified `run-tests.sh` to replace Docker commands with SSH commands targeting staging and explicitly pass `UPSKILL_STAGING_URL` to Playwright.
[2025-04-23 23:16:32] - Increased Playwright timeout and enabled retries in `playwright.config.ts` to address test failures and obtain debugging artifacts.
[2025-04-23 19:12:11] - Deprecated all Docker-based configuration and scripts. Removed Docker variables from dev-env.conf and replaced wp-config-docker.php with a deprecation notice. Cloudways Staging is now the sole supported development and testing environment. This change eliminates confusion, ensures consistency, and aligns all workflows with the current staging infrastructure.

43
memory-bank/productContext.md
View file

@ -1,7 +1,7 @@
# Product Context
This file provides a high-level overview of the project and the expected product that will be created.
2025-03-26 11:14:00 - Updated with development environment workflow improvements
2025-04-23 19:00:00 - Updated with Cloudways staging environment workflow
## Project Goal
@ -10,45 +10,44 @@ Network Events is a WordPress plugin that extends The Events Calendar suite to c
## Development Environment
### Core Components
* **Container Infrastructure**
* **Cloudways Staging Environment**
* WordPress (PHP 8.1-FPM)
* Nginx web server
* MariaDB database
* phpMyAdmin utility
* Cloudways dashboard for management
* **Development Tools**
* Docker and Docker Compose
* Playwright testing framework
* Git version control
* SSH and rsync for deployment
* Development scripts
* Debug tools
### Development Workflow
* **Backup-Based Approach**
* **Staging-Based Approach**
* Production data backup creation
* Local backup storage and management
* Environment setup from backups
* Consistent development environments
* Offline development capability
* Staging environment deployment
* Testing on staging environment
* Consistent development environment
* Collaborative development capability
* **Script Suite**
* setup-from-backup.sh - Set up environment from backup
* sync-production.sh - Create backup from production
* verify-dev.sh - Comprehensive environment verification
* verify-simple.sh - Basic environment verification
* manage-db.sh - Database management operations
* logs.sh - Log viewing and management
* cleanup.sh - Environment cleanup
* run-tests.sh - Test execution
* deploy-config-staging.sh - Deploy configuration to staging
* configure-staging-tests.sh - Configure test environment
* run-staging-tests.sh - Run tests on staging
* verify-staging.sh - Verify staging environment
* sync-staging.sh - Sync data from staging
* deploy-plugin.sh - Deploy plugin to staging
* run-staging-unit-tests.sh - Run unit tests on staging
### Configuration Management
* **Environment Settings**
* Development-specific configurations
* Staging-specific configurations
* Debug mode enabled
* Error display active
* SSL optional
* Local URLs
* SSL enabled
* Staging URLs
* **Production Preparation**
* Secure configurations ready
* SSL support prepared
* SSL support enabled
* Error logging configured
* Performance optimizations
* Security measures
@ -124,4 +123,4 @@ Network Events is a WordPress plugin that extends The Events Calendar suite to c
* Performance testing
* Security testing
2025-03-26 11:14:00 - Updated with development environment workflow improvements
2025-04-23 19:00:00 - Updated with Cloudways staging environment workflow

29
memory-bank/progress.md
View file

@ -209,4 +209,31 @@ Next Steps:
1. Run the test suite to verify implementation
2. Document usage in README.md
3. Integrate with existing test cases
4. Begin implementing role-specific tests
4. Begin implementing role-specific tests
[2025-04-23 19:04:48] - Completed Documentation Migration from Docker to Cloudways
- Updated key documentation files to remove Docker references:
* wordpress-dev/README.md - Complete rewrite focusing on Cloudways staging
* wordpress-dev/MIGRATION_GUIDE.md - Updated to focus on Cloudways workflow
* memory-bank/productContext.md - Updated Development Environment section
* memory-bank/decisionLog.md - Added migration decision entry
* memory-bank/activeContext.md - Added current task entry
- Key changes include:
* Removed all Docker container references
* Updated environment setup instructions
* Replaced Docker commands with Cloudways staging equivalents
* Added Cloudways-specific troubleshooting guidance
* Updated access points and URLs
* Added best practices for staging environment
Next Steps:
1. Identify Docker-related code files and scripts
2. Update or deprecate Docker-related code
3. Create new scripts specifically for Cloudways interaction if needed
[2025-04-23 23:16:44] - Completed test user creation on staging server.
[2025-04-23 23:16:44] - Troubleshooted and fixed plugin deployment script (`deploy-plugin.sh`).
[2025-04-23 23:16:44] - Fixed test user creation script (`setup-staging-test-users.sh`) role name mismatch.
[2025-04-23 23:16:44] - Updated E2E test runner script (`run-tests.sh`) to use SSH and explicitly pass staging URL.
[2025-04-23 23:16:44] - Increased Playwright timeout and enabled debugging artifacts in `playwright.config.ts`.
[2025-04-23 23:16:44] - Updated documentation files (`docs/mvp-integration-testing-plan.md`, `wordpress-dev/README.md`, `wordpress-dev/MIGRATION_GUIDE.md`) with test user setup information and corrected numbering in `docs/mvp-integration-testing-plan.md`.
4. Test all updated documentation and scripts
[2025-04-23 19:12:33] - Completed identification and deprecation of all Docker-based commands and configuration. Removed Docker variables from dev-env.conf and replaced wp-config-docker.php with a deprecation notice. All workflows now use Cloudways Staging exclusively. Task complete.

200
wordpress-dev/MIGRATION_GUIDE.md
View file

@ -1,28 +1,15 @@
# Migration Guide: Development & Staging Environment Workflows
# Migration Guide: Staging Environment Workflows
**Status**: Active/Authoritative
**Last Updated**: April 8, 2025
**Scope**: Transition to new development and staging workflows
**Last Updated**: April 23, 2025
**Scope**: Transition to Cloudways staging environment workflow
This guide helps you transition to the new development and staging environment workflows, including the backup-based approach and staging server integration.
This guide helps you transition to the Cloudways staging environment workflow, focusing on staging server integration and testing.
## Overview of Changes
### Development Environment Changes
The local development workflow now uses a backup-based approach:
**Old Workflow**
```
setup-dev.sh → sync-production.sh → verify-dev.sh
```
**New Workflow**
```
sync-production.sh → setup-from-backup.sh → verify-dev.sh
```
### Staging Environment Integration
New staging environment workflow added:
The staging environment workflow is now the primary development and testing approach:
**Staging Workflow**
```
@ -31,15 +18,15 @@ deploy-config-staging.sh → configure-staging-tests.sh → run-staging-tests.sh
**Staging Sync Workflow**
```
sync-staging.sh → setup-from-backup.sh → verify-dev.sh
sync-staging.sh → deploy-plugin.sh
```
## Why the Change?
1. **More Reliable**: The new workflow uses existing backups, reducing the chance of errors during setup
2. **Faster Setup**: Setting up from a backup is faster than syncing directly from production
3. **Offline Support**: You can set up the environment without needing access to the production server
4. **Consistent Environment**: Everyone uses the same backup, ensuring consistent development environments
1. **More Reliable**: The Cloudways staging environment provides a production-like platform for testing
2. **Faster Setup**: Direct access to the staging environment eliminates local setup time
3. **Consistent Environment**: Everyone uses the same staging environment, ensuring consistent testing results
4. **Simplified Workflow**: No need to maintain local development environments
## Migration Steps
@ -50,68 +37,11 @@ sync-staging.sh → setup-from-backup.sh → verify-dev.sh
git pull
# Make sure you have the new scripts
ls -la bin/setup-from-backup.sh
ls -la bin/deploy-config-staging.sh
```
### Step 2: Clean Up Your Current Environment (Optional)
### Step 2: Configure Environment Variables
If you want to start fresh:
```bash
# Stop and remove containers
docker-compose down
# Remove volumes (optional, will delete all data)
docker volume prune -f
```
### Step 3: Check for Existing Backups
```bash
# List available backups
ls -la backups/
```
If no backups are available, create one:
```bash
# Create a new backup from production
./bin/sync-production.sh
```
### Step 4: Set Up Using the New Workflow
```bash
# Set up from the latest backup
./bin/setup-from-backup.sh
# Verify the environment
./bin/verify-dev.sh
```
## Script Mapping
### Development Environment Scripts
| Old Script | New Script | Notes |
|------------|------------|-------|
| `setup-dev.sh` | `setup-from-backup.sh` | New script uses existing backups |
| `sync-production.sh` | `sync-production.sh` | Same name, updated implementation |
| `verify-dev.sh` | `verify-dev.sh` | Same name, updated implementation |
| `sync-and-setup.sh` | Use both scripts separately | Split into two separate steps |
### Staging Environment Scripts
| Script | Purpose | Notes |
|--------|---------|-------|
| `configure-staging-tests.sh` | Set up test environment | Creates test configuration files |
| `deploy-config-staging.sh` | Deploy configuration | Updates staging server config |
| `run-staging-unit-tests.sh` | Run unit tests | Executes tests on staging |
| `run-staging-tests.sh` | Run all tests | Runs unit, integration, and E2E tests |
| `verify-staging.sh` | Verify environment | Checks staging configuration |
| `sync-staging.sh` | Sync from staging | Downloads staging data |
## Staging Environment Setup
### Step 1: Configure Environment Variables
Add staging credentials to `.env`:
```bash
UPSKILL_STAGING_URL=https://wordpress-974670-5399585.cloudwaysapps.com/
@ -124,7 +54,8 @@ UPSKILL_STAGING_DB_USER=uberrxmprk
UPSKILL_STAGING_DB_PASSWORD=<password>
```
### Step 2: Deploy Configuration
### Step 3: Deploy Configuration
```bash
# Deploy configuration to staging
./bin/deploy-config-staging.sh
@ -133,7 +64,8 @@ UPSKILL_STAGING_DB_PASSWORD=<password>
./bin/verify-staging.sh
```
### Step 3: Configure Test Environment
### Step 4: Configure Test Environment
```bash
# Set up test configuration
./bin/configure-staging-tests.sh
@ -141,10 +73,34 @@ UPSKILL_STAGING_DB_PASSWORD=<password>
# Run tests to verify setup
./bin/run-staging-unit-tests.sh
```
### Step 5: Set up Test User
### PHPUnit Test Configuration
A test user with the 'hvac_trainer' role is required for running the E2E tests. Create this user on the staging environment using the `./bin/setup-staging-test-users.sh` script.
The staging environment now includes PHPUnit test configuration with:
Execute the script from the `wordpress-dev/` directory after the HVAC Community Events plugin has been deployed and activated:
```bash
./bin/setup-staging-test-users.sh
```
The script creates a user with the username `test_trainer` and password `Test123!`.
## Script Reference
### Staging Environment Scripts
| Script | Purpose | Notes |
|--------|---------|-------|
| `configure-staging-tests.sh` | Set up test environment | Creates test configuration files |
| `deploy-config-staging.sh` | Deploy configuration | Updates staging server config |
| `deploy-plugin.sh` | Deploy plugin code | Uploads plugin files to staging |
| `run-staging-unit-tests.sh` | Run unit tests | Executes tests on staging |
| `run-staging-tests.sh` | Run all tests | Runs unit, integration, and E2E tests |
| `verify-staging.sh` | Verify environment | Checks staging configuration |
| `sync-staging.sh` | Sync from staging | Downloads staging data |
## PHPUnit Test Configuration
The staging environment includes PHPUnit test configuration with:
1. Vendor-based PHPUnit installation (via Composer)
2. Staging-specific bootstrap file (tests/bootstrap-staging.php)
@ -167,61 +123,69 @@ Test configuration files:
- wp-tests-config-staging.php (WordPress test config)
- bootstrap-staging.php (test environment setup)
## Common Issues and Solutions
### Development Environment Issues
#### "No backup found in backups/ directory!"
### "Cannot connect to staging server"
```bash
# Create a new backup from production
./bin/sync-production.sh
# Test SSH connection
sshpass -p "$UPSKILL_STAGING_PASS" ssh "$UPSKILL_STAGING_SSH_USER@$UPSKILL_STAGING_IP" "echo 'Connection successful'"
# Verify environment variables
env | grep UPSKILL_STAGING
```
### "Cannot connect to production server"
You can still set up the environment if someone else has created a backup:
1. Get a backup from another developer
2. Place it in the `backups/` directory
3. Run `./bin/setup-from-backup.sh`
### "Database connection issues"
```bash
# Check database container
docker-compose ps | grep db
# Test database connection
mysql -h "$UPSKILL_STAGING_IP" -u "$UPSKILL_STAGING_DB_USER" -p"$UPSKILL_STAGING_DB_PASSWORD" "$UPSKILL_STAGING_DB_NAME" -e "SELECT 1"
# Restart containers
docker-compose down && docker-compose up -d
# Verify database connection
./bin/verify-simple.sh
# Check database credentials
./bin/verify-staging.sh --database
```
### "WordPress is not accessible"
```bash
# Check if WordPress container is running
docker-compose ps | grep wordpress
# Check if WordPress is accessible
curl -I "$UPSKILL_STAGING_URL"
# Check WordPress logs
docker-compose logs wordpress
# Restart containers
docker-compose down && docker-compose up -d
# Check WordPress status via SSH
sshpass -p "$UPSKILL_STAGING_PASS" ssh "$UPSKILL_STAGING_SSH_USER@$UPSKILL_STAGING_IP" "cd $UPSKILL_STAGING_PATH && wp core is-installed"
```
### "Test environment issues"
```bash
# Reconfigure test environment
./bin/configure-staging-tests.sh
# Check test configuration
./bin/verify-staging.sh --test-env
# View test logs
sshpass -p "$UPSKILL_STAGING_PASS" ssh "$UPSKILL_STAGING_SSH_USER@$UPSKILL_STAGING_IP" "tail -f $UPSKILL_STAGING_PATH/wp-content/debug.log"
```
## Best Practices for Staging Environment
1. Always verify your changes on staging before deploying to production
2. Run the full test suite after making significant changes
3. Keep the staging environment as close to production as possible
4. Use the Cloudways dashboard for server management tasks
5. Regularly sync data from production to staging to ensure testing with current data
## Additional Resources
- [README.md](README.md) - Updated documentation for the development environment
- [bin/obsolete/README.md](bin/obsolete/README.md) - Information about obsolete scripts
- [README.md](README.md) - Updated documentation for the staging environment
- [docs/staging-phpunit-setup.md](docs/staging-phpunit-setup.md) - Detailed PHPUnit configuration
- [Cloudways Documentation](https://support.cloudways.com/en/) - Official Cloudways support documentation
## Support
If you encounter any issues with the new workflow, please contact:
If you encounter any issues with the staging workflow, please contact:
- Email: support@tealmaker.com
- Slack: #network-events-support
*Last Updated: March 26, 2025*
*Last Updated: April 23, 2025*

219
wordpress-dev/README.md
View file

@ -1,32 +1,22 @@
# WordPress Development & Staging Environments
**Status**: Active/Authoritative
**Last Updated**: April 8, 2025
**Last Updated**: April 23, 2025
**Scope**: Development and staging environment setup and configuration
This repository contains configuration and tools for both local development (Docker-based) and staging (Cloudways) environments. The local environment includes WordPress with PHP 8.1, MariaDB, and phpMyAdmin, while the staging environment provides a production-like testing platform.
This repository contains configuration and tools for the Cloudways staging environment. The staging environment provides a production-like testing platform for development, testing, and deployment validation. Local Docker-based development is no longer supported; all development and testing should be performed using the Cloudways staging server.
## Environment Overview
### Local Development
- There is no local server. Please use the staging server.
### Staging Environment (Cloudways)
### Staging (Cloudways)
- Production-like environment
- Limited configuration access
- Final testing platform
- Deployment validation
- Production-like environment for all development, testing, and deployment validation
- No local server or Docker-based development is supported
- SSH access to Cloudways server is required
- Use `sshpass` for automated scripts (optional)
- MySQL client for database operations
- All environment variables must be set in `.env`:
## Prerequisites
### Local Development
- There is no local server. Please use the staging server.
### Staging Environment
- SSH access to Cloudways server
- sshpass (for automated scripts)
- MySQL client (for database operations)
- Environment variables in `.env`:
```bash
UPSKILL_STAGING_URL=https://wordpress-974670-5399585.cloudwaysapps.com/
UPSKILL_STAGING_IP=146.190.76.204
@ -58,9 +48,20 @@ This repository contains configuration and tools for both local development (Doc
./bin/run-staging-unit-tests.sh
```
### 3. Test User Setup
A test user with the 'hvac_trainer' role is required for running the E2E tests that cover trainer-specific workflows. This user can be created on the staging environment using the `./bin/setup-staging-test-users.sh` script.
Execute the script from the `wordpress-dev/` directory after the HVAC Community Events plugin has been deployed and activated on the staging server:
```bash
./bin/setup-staging-test-users.sh
```
The script creates a user with the username `test_trainer` and password `Test123!`.
### 3. Data Synchronization
```bash
# Sync data from staging to local
# Sync data from staging to local backup
./bin/sync-staging.sh
# Deploy local changes to staging
@ -78,28 +79,9 @@ The `.env` file contains:
- SSL configuration
- Development settings
**Important:** Ensure the PHP `memory_limit` is set sufficiently high (e.g., `512M`) in `php.ini/custom.ini`. Restart containers after changing this file (`docker-compose down && docker-compose up -d`).
**Important:** Ensure the PHP `memory_limit` is set sufficiently high (e.g., `512M`) in the Cloudways PHP settings via the Cloudways dashboard.
### 2. Development Environment Setup from Backup
The recommended way to set up the development environment is using existing backups:
```bash
# Set up environment from the latest backup
./bin/setup-from-backup.sh
# Verify setup
./bin/verify-simple.sh
```
This process:
1. Uses the latest backup from the `backups/` directory
2. Sets up the Docker containers (WordPress, MariaDB, phpMyAdmin, Nginx)
3. Imports the database from the backup
4. Updates site URLs to point to localhost:8080
5. Configures WordPress with the correct settings
### 3. Creating New Backups
### 2. Creating New Backups
If you need to create a new backup from production:
@ -110,16 +92,14 @@ If you need to create a new backup from production:
This will create a new backup in the `backups/` directory with the current date and time.
### 4. Plugin Setup
### 3. Plugin Setup
Required plugins are included in the backups:
- The Events Calendar Suite (6.10.2+)
- Event Tickets Suite (5.19.3+)
- Additional required plugins
### Automatic Page Creation
### 4. Automatic Page Creation
Upon activation, the HVAC Community Events plugin automatically creates the following required pages if they don't already exist:
- Community Login (`/community-login/`)
@ -127,84 +107,52 @@ Upon activation, the HVAC Community Events plugin automatically creates the foll
- Trainer Dashboard (`/hvac-dashboard/`)
Ensure the plugin is deactivated and reactivated if these pages are missing after setup.
## Access Points
- WordPress Site:
- HTTP: http://localhost:8080
- HTTPS: https://localhost:8443 (when SSL enabled)
- phpMyAdmin: http://localhost:8081
- Server: db
- Username: from .env (DEV_DB_USER)
- Password: from .env (DEV_DB_PASSWORD)
- URL: https://wordpress-974670-5399585.cloudwaysapps.com/
- WordPress Admin:
- URL: https://wordpress-974670-5399585.cloudwaysapps.com/wp-admin/
- Database Access:
- Via Cloudways dashboard or MySQL client using the credentials in `.env`
## Development Tools
### Environment Management
### Syncing Data from Staging
To sync data from the staging server to your local development environment, use the following command:
To sync data from the staging server to your local backup directory:
```bash
./bin/sync-staging.sh
```
This script will download WordPress files and a database dump from the staging server, storing them in the `backups/` directory. The `setup-from-backup.sh` script will then use these files to set up your local development environment.
```bash
# Set up environment from backup
./bin/setup-from-backup.sh
# Create a new backup from production
./bin/sync-production-fixed.sh
# Verify environment
./bin/verify-simple.sh
# More detailed verification
./bin/verify-dev-fixed.sh
# Reset development environment
./bin/reset-dev.sh
# Setup SSL (if needed)
./bin/setup-ssl.sh
```
This script will download WordPress files and a database dump from the staging server, storing them in the `backups/` directory.
### PHPUnit Testing
PHPUnit is configured for both local and staging environments:
PHPUnit is configured for the staging environment:
```bash
# Run PHPUnit tests (vendor installation)
./vendor/bin/phpunit --bootstrap tests/bootstrap-staging.php
# Run PHPUnit tests on staging
./bin/run-staging-unit-tests.sh
# Run specific test suite
./vendor/bin/phpunit --testsuite unit
./bin/run-staging-unit-tests.sh --testsuite unit
# Run tests with coverage report
./vendor/bin/phpunit --coverage-html ./coverage-report
./bin/run-staging-unit-tests.sh --coverage-html ./coverage-report
```
Refer to [staging-phpunit-setup.md](docs/staging-phpunit-setup.md) for detailed configuration.
### Testing
Refer to the comprehensive **[Testing Guide](./testing.md)** for detailed instructions on setting up test environments, running test suites, writing tests, and troubleshooting.
**Local Development Tests:**
**E2E Tests:**
```bash
# Run all tests (Unit, Integration, E2E)
./bin/run-tests.sh
# Run only Unit tests
./bin/run-tests.sh --unit
# Run only Integration tests
./bin/run-tests.sh --integration
# Run only E2E tests
# Run E2E tests targeting the staging environment
./bin/run-tests.sh --e2e
Note: The E2E tests are executed locally using this command from the `wordpress-dev/` directory and target the staging environment as configured in `playwright.config.ts`. The command `./tests/run-tests.sh pw` is outdated and should not be used.
@ -233,46 +181,34 @@ Note: The E2E tests are executed locally using this command from the `wordpress-
### WP-CLI
WP-CLI is available inside the `wordpress` container via a direct volume mount of the phar file. Use `docker-compose exec` and the `--allow-root` flag:
WP-CLI is available on the staging server via SSH:
```bash
docker-compose exec wordpress wp plugin list --allow-root
# Run WP-CLI commands on staging
sshpass -p "$UPSKILL_STAGING_PASS" ssh "$UPSKILL_STAGING_SSH_USER@$UPSKILL_STAGING_IP" "cd $UPSKILL_STAGING_PATH && wp plugin list"
```
### Database Operations
```bash
# Manage database operations
./bin/manage-db-fixed.sh
# Test database connection
mysql -h "$UPSKILL_STAGING_IP" -u "$UPSKILL_STAGING_DB_USER" -p"$UPSKILL_STAGING_DB_PASSWORD" "$UPSKILL_STAGING_DB_NAME" -e "SELECT 1"
# Reset development database
./bin/reset-dev.sh
# Verify database configuration
./bin/verify-staging.sh --database
```
### Logs and Cleanup
### Logs and Monitoring
```bash
# View logs
./bin/logs.sh
# View WordPress debug logs
sshpass -p "$UPSKILL_STAGING_PASS" ssh "$UPSKILL_STAGING_SSH_USER@$UPSKILL_STAGING_IP" "tail -f $UPSKILL_STAGING_PATH/wp-content/debug.log"
# Clean up environment
./bin/cleanup.sh
# View PHP error logs
sshpass -p "$UPSKILL_STAGING_PASS" ssh "$UPSKILL_STAGING_SSH_USER@$UPSKILL_STAGING_IP" "tail -f /var/log/php-fpm/www-error.log"
```
## Troubleshooting
### Local Environment Issues
1. **Docker Environment Issues**
```bash
# Check container status
docker-compose ps
# View container logs
docker-compose logs
# or
./bin/logs.sh
```
### Staging Environment Issues
1. **SSH Connection Issues**
@ -302,7 +238,7 @@ docker-compose exec wordpress wp plugin list --allow-root
./bin/verify-staging.sh
# View test logs
tail -f /home/974670.cloudwaysapps.com/uberrxmprk/public_html/wp-content/debug.log
sshpass -p "$UPSKILL_STAGING_PASS" ssh "$UPSKILL_STAGING_SSH_USER@$UPSKILL_STAGING_IP" "tail -f $UPSKILL_STAGING_PATH/wp-content/debug.log"
```
4. **Deployment Issues**
@ -317,16 +253,7 @@ docker-compose exec wordpress wp plugin list --allow-root
./bin/verify-staging.sh --deployment
```
2. **Database Issues**
```bash
# Reset database
./bin/reset-dev.sh
# Verify database connection
./bin/verify-simple.sh
```
3. **Backup Issues**
5. **Backup Issues**
```bash
# Check available backups
ls -la backups/
@ -335,34 +262,40 @@ docker-compose exec wordpress wp plugin list --allow-root
./bin/sync-production-fixed.sh
```
4. **WordPress Access Issues**
6. **WordPress Access Issues**
```bash
# Check if WordPress is accessible
curl -I http://localhost:8080
curl -I "$UPSKILL_STAGING_URL"
# Restart containers
docker-compose down && docker-compose up -d
# Check WordPress status via SSH
sshpass -p "$UPSKILL_STAGING_PASS" ssh "$UPSKILL_STAGING_SSH_USER@$UPSKILL_STAGING_IP" "cd $UPSKILL_STAGING_PATH && wp core is-installed"
```
### Debug Mode
WordPress debug mode is enabled by default in the development environment. Debug logs can be viewed with:
WordPress debug mode is enabled by default in the staging environment. Debug logs can be viewed with:
```bash
# View debug logs
docker-compose logs wordpress
# or
./bin/logs.sh wordpress
sshpass -p "$UPSKILL_STAGING_PASS" ssh "$UPSKILL_STAGING_SSH_USER@$UPSKILL_STAGING_IP" "tail -f $UPSKILL_STAGING_PATH/wp-content/debug.log"
```
## Migration Guide
## Common Staging Problems and Solutions
If you were using the old setup scripts (setup-dev.sh, sync-production.sh), follow these steps to migrate to the new workflow:
| Problem | Solution |
|---------|----------|
| Search Engine Indexing | Use robots.txt file or meta tags to prevent staging site indexing |
| Staging Sites Sending Emails | Configure email redirection to prevent staging emails going to customers |
| Problems with Licensing | Check software provider's licensing policies for staging environments |
| Overwriting Live Data | Use selective push/pull to avoid overwriting critical data |
1. Create a backup of your current development environment if needed
2. Pull the latest changes from the repository
3. Use the new setup-from-backup.sh script to set up your environment
4. If you need to create a new backup from production, use sync-production-fixed.sh
## Best Practices for Staging Sites
1. Take full backups before making significant changes
2. Clear cache when changing code
3. Keep production database separate from testing database
4. Restrict public access to staging environment
5. Use staging-specific configuration for sensitive services
## Security Notes
@ -376,10 +309,10 @@ If you were using the old setup scripts (setup-dev.sh, sync-production.sh), foll
For issues:
1. Check debug logs
2. Review container logs
2. Review server logs
3. Verify environment configuration
4. Contact development team:
- Email: support@tealmaker.com
- Slack: #network-events-support
*Last Updated: March 26, 2025*
*Last Updated: April 23, 2025*

2
wordpress-dev/bin/backups/latest
View file

@ -1 +1 @@
backups/20250412_141828
backups/20250423_194007

0
wordpress-dev/bin/deploy-config-staging.sh Normal file → Executable file
View file

11
wordpress-dev/bin/deploy-plugin.sh
View file

@ -73,6 +73,8 @@ fi
# Rsync the plugin files
echo "Deploying plugin $PLUGIN_SLUG to staging server..."
# Change to project root before rsync
cd ../..
RSYNC_CMD="rsync -avz --delete \
--exclude '.git' \
--exclude 'node_modules' \
@ -81,7 +83,12 @@ RSYNC_CMD="rsync -avz --delete \
--include 'tests/unit/*.php' \
--include 'tests/test-doubles.php' \
--include 'tests/bootstrap.php' \
\"$LOCAL_PLUGIN_PATH\" \
--include 'composer.json' \
--include 'composer.lock' \
--include 'hvac-community-events.php' \
--include 'phpunit.xml.dist' \
--include 'wp-tests-config.php' \
\"$LOCAL_PLUGIN_PATH/\" \
\"$REMOTE_USER@$REMOTE_HOST:$REMOTE_PLUGIN_PATH\""
if [ "$DRY_RUN" = true ]; then
@ -93,6 +100,8 @@ else
exit 1
fi
fi
# Change back to original directory (optional, but good practice)
# cd -
echo "Plugin deployment completed successfully."

12
wordpress-dev/bin/deploy_config.sh Executable file
View file

@ -0,0 +1,12 @@
#!/bin/bash
# Load environment variables from .env
source ../.env
# Define deployment variables
REMOTE_HOST="$UPSKILL_STAGING_IP"
REMOTE_USER="$UPSKILL_STAGING_SSH_USER"
REMOTE_PATH_BASE="$UPSKILL_STAGING_PATH"
PLUGIN_SLUG="hvac-community-events"
REMOTE_PLUGIN_PATH="$REMOTE_PATH_BASE/wp-content/plugins/$PLUGIN_SLUG"
LOCAL_PLUGIN_PATH="wordpress-dev/wordpress/wp-content/plugins/$PLUGIN_SLUG"

10
wordpress-dev/bin/run-tests.sh
View file

@ -133,8 +133,8 @@ fi
if $RUN_E2E; then
# Ensure plugin activation hooks run and permalinks are fresh for E2E context
echo -e "${YELLOW}Deactivating/Reactivating plugin to ensure hooks fire...${NC}"
docker-compose exec -T wordpress wp plugin deactivate hvac-community-events --allow-root || echo -e "${YELLOW}Note: Plugin already inactive or not found (continuing).${NC}" # Allow failure if already inactive
docker-compose exec -T wordpress wp plugin activate hvac-community-events --allow-root
sshpass -p "$UPSKILL_STAGING_PASS" ssh -o StrictHostKeyChecking=no "$UPSKILL_STAGING_SSH_USER@$UPSKILL_STAGING_IP" "cd $UPSKILL_STAGING_PATH && wp plugin deactivate hvac-community-events --allow-root" || echo -e "${YELLOW}Note: Plugin already inactive or not found (continuing).${NC}" # Allow failure if already inactive
sshpass -p "$UPSKILL_STAGING_PASS" ssh -o StrictHostKeyChecking=no "$UPSKILL_STAGING_SSH_USER@$UPSKILL_STAGING_IP" "cd $UPSKILL_STAGING_PATH && wp plugin activate hvac-community-events --allow-root"
if [ $? -ne 0 ]; then
echo -e "${RED}✗ Failed to activate hvac-community-events plugin. Exiting.${NC}"
exit 1
@ -143,7 +143,7 @@ if $RUN_E2E; then
# Flush rewrite rules after activation
echo -e "${YELLOW}Flushing rewrite rules...${NC}"
if ! docker-compose exec -T wordpress wp rewrite flush --hard --path=/var/www/html --allow-root; then
if ! sshpass -p "$UPSKILL_STAGING_PASS" ssh -o StrictHostKeyChecking=no "$UPSKILL_STAGING_SSH_USER@$UPSKILL_STAGING_IP" "cd $UPSKILL_STAGING_PATH && wp rewrite flush --hard --allow-root"; then
echo -e "${RED}✗ Failed to flush rewrite rules. Exiting.${NC}"
exit 1
fi
@ -151,8 +151,8 @@ if $RUN_E2E; then
# Now run the tests
if [ -n "$TEST_SUITE" ]; then
run_tests "E2E" "npx playwright test --config=tests/e2e/playwright.config.ts --grep @$TEST_SUITE"
run_tests "E2E" "UPSKILL_STAGING_URL=\"$UPSKILL_STAGING_URL\" npx playwright test --config=tests/e2e/playwright.config.ts --grep @$TEST_SUITE"
else
run_tests "E2E" "npx playwright test --config=tests/e2e/playwright.config.ts"
run_tests "E2E" "UPSKILL_STAGING_URL=\"$UPSKILL_STAGING_URL\" npx playwright test --config=tests/e2e/playwright.config.ts"
fi
fi

69
wordpress-dev/bin/setup-staging-test-users.sh Executable file
View file

@ -0,0 +1,69 @@
#!/bin/bash
# Get absolute path to this script's directory
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
# Navigate to wordpress-dev directory
cd "$(dirname "$SCRIPT_DIR")" || exit 1
# Load environment variables
ENV_FILE=".env"
if [ ! -f "$ENV_FILE" ]; then
echo "Error: .env file not found at: $ENV_FILE"
exit 1
fi
source "$ENV_FILE"
# Colors for output
GREEN='\033[0;32m'
RED='\033[0;31m'
YELLOW='\033[1;33m'
NC='\033[0m'
# Function to check if a command was successful
check_status() {
if [ $? -eq 0 ]; then
echo -e "${GREEN}✓ $1${NC}"
return 0
else
echo -e "${RED}✗ $1${NC}"
return 1
fi
}
echo "=== Creating Test User on Staging Server ==="
echo "Remote host: $UPSKILL_STAGING_IP"
echo "Remote user: $UPSKILL_STAGING_SSH_USER"
echo "WordPress path: $UPSKILL_STAGING_PATH"
echo "==============================="
# Create test_trainer user
echo -e "\n${YELLOW}Creating test_trainer user...${NC}"
sshpass -p "${UPSKILL_STAGING_PASS}" ssh -o StrictHostKeyChecking=no "${UPSKILL_STAGING_SSH_USER}@${UPSKILL_STAGING_IP}" \
"cd ${UPSKILL_STAGING_PATH} && wp user create test_trainer test@example.com --role=hvac_trainer --user_pass='Test123!' --allow-root"
USER_CREATION_STATUS=$?
if [ $USER_CREATION_STATUS -eq 0 ]; then
echo -e "${GREEN}✓ Test user 'test_trainer' created successfully${NC}"
else
# Check if the user already exists
echo -e "\n${YELLOW}Checking if user already exists...${NC}"
sshpass -p "${UPSKILL_STAGING_PASS}" ssh -o StrictHostKeyChecking=no "${UPSKILL_STAGING_SSH_USER}@${UPSKILL_STAGING_IP}" \
"cd ${UPSKILL_STAGING_PATH} && wp user get test_trainer --allow-root"
if [ $? -eq 0 ]; then
echo -e "${YELLOW}User 'test_trainer' already exists. Updating password...${NC}"
sshpass -p "${UPSKILL_STAGING_PASS}" ssh -o StrictHostKeyChecking=no "${UPSKILL_STAGING_SSH_USER}@${UPSKILL_STAGING_IP}" \
"cd ${UPSKILL_STAGING_PATH} && wp user update test_trainer --user_pass='Test123!' --role=hvac_trainer --allow-root"
check_status "User 'test_trainer' password updated"
else
echo -e "${RED}✗ Failed to create test user 'test_trainer'${NC}"
exit 1
fi
fi
echo -e "\n${GREEN}Test user setup completed!${NC}"
echo "User: test_trainer"
echo "Password: Test123!"
echo "Role: trainer"

10
wordpress-dev/dev-env.conf
View file

@ -1,13 +1,13 @@
# WordPress Development Environment Configuration
# [DEPRECATED] Docker-based development is no longer supported.
# The project now uses Cloudways Staging as the primary development and testing environment.
# All Docker-related variables and workflows have been removed as of 2025-04-23.
# Please refer to the Cloudways variables and documentation for staging and production workflows.
# Logging
LOG_LEVEL=INFO # DEBUG, INFO, WARN, ERROR
# Docker
DOCKER_COMPOSE_FILE=docker-compose.yml # Path to docker-compose file
DOCKER_PROJECT_NAME=wordpress-dev # Docker project name
DOCKER_NETWORK=wordpress-dev_default # Docker network name
# WordPress
WP_VERSION=6.7.2 # Required WordPress version
WP_DEBUG=true # Enable WordPress debug mode

2
wordpress-dev/playwright-report/index.html
View file

File diff suppressed because one or more lines are too long

6
wordpress-dev/tests/e2e/playwright.config.ts
View file

@ -5,9 +5,9 @@ import * as path from 'path';
const config: PlaywrightTestConfig = {
testDir: './tests',
globalSetup: require.resolve('./global-setup'), // Add global setup script
timeout: 30000,
timeout: 60000, // Increased timeout for staging environment
forbidOnly: !!process.env.CI,
retries: process.env.CI ? 2 : 0,
retries: process.env.CI ? 2 : 1, // Enabled retries for debugging
workers: process.env.CI ? 1 : undefined,
reporter: [
['list'],
@ -15,7 +15,7 @@ const config: PlaywrightTestConfig = {
['junit', { outputFile: '../test-results/e2e-results.xml' }]
],
use: {
baseURL: process.env.UPSKILL_STAGING_URL || 'http://localhost:8080',
baseURL: process.env.UPSKILL_STAGING_URL, // Use staging URL from environment variable
trace: 'on-first-retry',
video: 'on-first-retry',
screenshot: 'only-on-failure'

7162
wordpress-dev/tests/test-results/e2e-results.xml
View file

File diff suppressed because it is too large Load diff

143
wordpress-dev/wordpress/wp-config-docker.php
View file

@ -1,139 +1,16 @@
<?php
/**
* The base configuration for WordPress
* [DEPRECATED] Docker-based WordPress configuration is no longer supported.
*
* The wp-config.php creation script uses this file during the installation.
* You don't have to use the website, you can copy this file to "wp-config.php"
* and fill in the values.
* As of 2025-04-23, this project uses the Cloudways Staging server as the primary development and testing environment.
* This file is retained only for historical reference and should not be used for any new development or deployment.
*
* This file contains the following configurations:
* Please use the standard wp-config.php and refer to the Cloudways documentation and environment variables
* in dev-env.conf for all configuration and deployment tasks.
*
* * Database settings
* * Secret keys
* * Database table prefix
* * ABSPATH
*
* This has been slightly modified (to read environment variables) for use in Docker.
*
* @link https://developer.wordpress.org/advanced-administration/wordpress/wp-config/
*
* @package WordPress
* For more information, see:
* - memory-bank/productContext.md
* - memory-bank/decisionLog.md
* - wordpress-dev/README.md
*/
// IMPORTANT: this file needs to stay in-sync with https://github.com/WordPress/WordPress/blob/master/wp-config-sample.php
// (it gets parsed by the upstream wizard in https://github.com/WordPress/WordPress/blob/f27cb65e1ef25d11b535695a660e7282b98eb742/wp-admin/setup-config.php#L356-L392)
// a helper function to lookup "env_FILE", "env", then fallback
if (!function_exists('getenv_docker')) {
// https://github.com/docker-library/wordpress/issues/588 (WP-CLI will load this file 2x)
function getenv_docker($env, $default) {
if ($fileEnv = getenv($env . '_FILE')) {
return rtrim(file_get_contents($fileEnv), "\r\n");
}
else if (($val = getenv($env)) !== false) {
return $val;
}
else {
return $default;
}
}
}
// ** Database settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define( 'DB_NAME', getenv_docker('WORDPRESS_DB_NAME', 'wordpress') );
/** Database username */
define( 'DB_USER', getenv_docker('WORDPRESS_DB_USER', 'example username') );
/** Database password */
define( 'DB_PASSWORD', getenv_docker('WORDPRESS_DB_PASSWORD', 'example password') );
/**
* Docker image fallback values above are sourced from the official WordPress installation wizard:
* https://github.com/WordPress/WordPress/blob/1356f6537220ffdc32b9dad2a6cdbe2d010b7a88/wp-admin/setup-config.php#L224-L238
* (However, using "example username" and "example password" in your database is strongly discouraged. Please use strong, random credentials!)
*/
/** Database hostname */
define( 'DB_HOST', getenv_docker('WORDPRESS_DB_HOST', 'mysql') );
/** Database charset to use in creating database tables. */
define( 'DB_CHARSET', getenv_docker('WORDPRESS_DB_CHARSET', 'utf8') );
/** The database collate type. Don't change this if in doubt. */
define( 'DB_COLLATE', getenv_docker('WORDPRESS_DB_COLLATE', '') );
/**#@+
* Authentication unique keys and salts.
*
* Change these to different unique phrases! You can generate these using
* the {@link https://api.wordpress.org/secret-key/1.1/salt/ WordPress.org secret-key service}.
*
* You can change these at any point in time to invalidate all existing cookies.
* This will force all users to have to log in again.
*
* @since 2.6.0
*/
define( 'AUTH_KEY', getenv_docker('WORDPRESS_AUTH_KEY', 'put your unique phrase here') );
define( 'SECURE_AUTH_KEY', getenv_docker('WORDPRESS_SECURE_AUTH_KEY', 'put your unique phrase here') );
define( 'LOGGED_IN_KEY', getenv_docker('WORDPRESS_LOGGED_IN_KEY', 'put your unique phrase here') );
define( 'NONCE_KEY', getenv_docker('WORDPRESS_NONCE_KEY', 'put your unique phrase here') );
define( 'AUTH_SALT', getenv_docker('WORDPRESS_AUTH_SALT', 'put your unique phrase here') );
define( 'SECURE_AUTH_SALT', getenv_docker('WORDPRESS_SECURE_AUTH_SALT', 'put your unique phrase here') );
define( 'LOGGED_IN_SALT', getenv_docker('WORDPRESS_LOGGED_IN_SALT', 'put your unique phrase here') );
define( 'NONCE_SALT', getenv_docker('WORDPRESS_NONCE_SALT', 'put your unique phrase here') );
// (See also https://wordpress.stackexchange.com/a/152905/199287)
/**#@-*/
/**
* WordPress database table prefix.
*
* You can have multiple installations in one database if you give each
* a unique prefix. Only numbers, letters, and underscores please!
*
* At the installation time, database tables are created with the specified prefix.
* Changing this value after WordPress is installed will make your site think
* it has not been installed.
*
* @link https://developer.wordpress.org/advanced-administration/wordpress/wp-config/#table-prefix
*/
$table_prefix = getenv_docker('WORDPRESS_TABLE_PREFIX', 'wp_');
/**
* For developers: WordPress debugging mode.
*
* Change this to true to enable the display of notices during development.
* It is strongly recommended that plugin and theme developers use WP_DEBUG
* in their development environments.
*
* For information on other constants that can be used for debugging,
* visit the documentation.
*
* @link https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/
*/
define( 'WP_DEBUG', !!getenv_docker('WORDPRESS_DEBUG', '') );
/* Add any custom values between this line and the "stop editing" line. */
// If we're behind a proxy server and using HTTPS, we need to alert WordPress of that fact
// see also https://wordpress.org/support/article/administration-over-ssl/#using-a-reverse-proxy
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && strpos($_SERVER['HTTP_X_FORWARDED_PROTO'], 'https') !== false) {
$_SERVER['HTTPS'] = 'on';
}
// (we include this by default because reverse proxying is extremely common in container environments)
if ($configExtra = getenv_docker('WORDPRESS_CONFIG_EXTRA', '')) {
eval($configExtra);
}
/* That's all, stop editing! Happy publishing. */
/** Absolute path to the WordPress directory. */
if ( ! defined( 'ABSPATH' ) ) {
define( 'ABSPATH', __DIR__ . '/' );
}
/** Sets up WordPress vars and included files. */
require_once ABSPATH . 'wp-settings.php';
exit("This configuration file is deprecated. Use the Cloudways workflow instead.");