# WordPress Integration Test Connection Fix ## Problem When testing WordPress integration connection via the frontend, the API was returning: ``` API Error: WordPress site URL not configured endpoint: "/v1/integration/integrations/1/test_connection/" ``` This occurred because the `SiteIntegration.config_json` field didn't have the `site_url` key set when the integration was created. ## Root Cause The integration test was checking for `site_url` in `config_json`, but: 1. Some integrations were created without the `site_url` in config 2. The `Site` model has both `domain` and legacy `wp_url` fields that could be used as fallbacks 3. The test connection method wasn't checking these fallback fields ## Solution ### 1. Updated `integration_service.py` (Backend Fix) Modified `_test_wordpress_connection()` method in: ``` backend/igny8_core/business/integration/services/integration_service.py ``` **Changes:** - Added fallback logic to check `site.wp_url` if `config.site_url` is not set - Added fallback logic to check `site.domain` if neither `config.site_url` nor `site.wp_url` is set - Automatically saves `site_url` to integration config after successful connection test - Provides better error messages with details about what's missing **Before:** ```python site_url = config.get('site_url') if not site_url: return { 'success': False, 'message': 'WordPress site URL not configured', 'details': {} } ``` **After:** ```python # Try to get site URL from multiple sources site_url = config.get('site_url') # Fallback to legacy wp_url if available if not site_url and integration.site.wp_url: site_url = integration.site.wp_url logger.info(f"Using legacy wp_url for integration {integration.id}: {site_url}") # Fallback to domain field if not site_url and integration.site.domain: site_url = integration.site.domain logger.info(f"Using domain for integration {integration.id}: {site_url}") if not site_url: return { 'success': False, 'message': 'WordPress site URL not configured. Please set the site URL in integration config, site domain, or legacy wp_url field.', 'details': { 'integration_id': integration.id, 'site_id': integration.site.id, 'site_name': integration.site.name } } # ... test connection ... # If connection successful and site_url wasn't in config, save it if result.get('success') and not config.get('site_url'): config['site_url'] = site_url integration.config_json = config integration.save(update_fields=['config_json']) logger.info(f"Saved site_url to integration {integration.id} config: {site_url}") ``` ### 2. Created Fix Script (Data Fix) Created script to fix existing integrations: ``` backend/fix_integration_site_url.py ``` This script: - Finds all WordPress integrations - Checks if `config_json.site_url` is set - If not, tries to set it from `site.wp_url` or `site.domain` - Updates the database with the correct site_url ## How to Deploy ### Step 1: Deploy Code Changes Upload the updated file to your server: ```bash # Via FTP/SFTP igny8/backend/igny8_core/business/integration/services/integration_service.py ``` Or via git: ```bash cd /path/to/igny8 git pull origin main ``` ### Step 2: Run the Fix Script SSH into your server and run: ```bash cd /path/to/igny8/backend python fix_integration_site_url.py ``` Expected output: ``` Fixing WordPress integration site URLs... ============================================================ → Using domain for integration 1: https://homeg8.com ✓ Updated integration 1 with site_url: https://homeg8.com ============================================================ Summary: Fixed: 1 Skipped (already set): 0 Errors: 0 ============================================================ ``` ### Step 3: Restart Services ```bash # Restart Django/Gunicorn sudo systemctl restart igny8-api # Or if using Docker docker-compose restart api ``` ### Step 4: Test the Fix 1. Go to your IGNY8 frontend 2. Navigate to **Sites → Settings** 3. Find the WordPress Integration section 4. Click **"Test Connection"** 5. Should now succeed with the message: **"Connection successful"** ## Verification To verify the fix worked: ### Check Database ```sql SELECT id, site_id, platform, config_json->'site_url' as site_url, is_active FROM igny8_integrations WHERE platform = 'wordpress'; ``` Expected: All WordPress integrations should have a `site_url` in their config. ### Check Logs ```bash tail -f /path/to/logs/django.log | grep "IntegrationService" ``` Should see: ``` [IntegrationService] Using domain for integration 1: https://homeg8.com [IntegrationService] Saved site_url to integration 1 config: https://homeg8.com ``` ## Frontend Changes (Already Working) The frontend (line 131 in `SiteIntegrationsSection.tsx`) already correctly sets `site_url` when creating new integrations: ```typescript config_json: { site_url: formData.site_url, // ... } ``` So new integrations created via the UI will have the site_url set correctly. This fix only helps with: 1. Existing integrations that were missing site_url 2. Testing connections when site_url wasn't in config ## Files Changed 1. **backend/igny8_core/business/integration/services/integration_service.py** (Modified) - Updated `_test_wordpress_connection()` method 2. **backend/fix_integration_site_url.py** (New) - Script to fix existing integrations ## Testing Checklist - [x] Code compiles without errors - [ ] Fix script runs successfully - [ ] Existing integration can test connection - [ ] New integrations can test connection - [ ] Site URL is properly saved to config after successful test - [ ] Error messages are clear when URL is truly missing ## Rollback Plan If something goes wrong: 1. **Restore old file:** ```bash git checkout HEAD~1 backend/igny8_core/business/integration/services/integration_service.py ``` 2. **Restart services:** ```bash sudo systemctl restart igny8-api ``` 3. **Database is safe** - The fix script only adds data, doesn't delete anything ## Support If issues persist: 1. Check Django logs: `tail -f /path/to/logs/django.log` 2. Check database: Verify `config_json` has `site_url` 3. Check Site model: Verify `domain` or `wp_url` is set for the site ## Additional Notes - The fix is backward compatible - existing working integrations won't be affected - New integrations will continue to work as before - The fallback logic ensures maximum compatibility with different site configurations - Logging has been added for debugging purposes