igny8/WORDPRESS_INTEGRATION_FIX.md

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:

site_url = config.get('site_url')
if not site_url:
    return {
        'success': False,
        'message': 'WordPress site URL not configured',
        'details': {}
    }

After:

# 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:

# Via FTP/SFTP
igny8/backend/igny8_core/business/integration/services/integration_service.py

Or via git:

cd /path/to/igny8
git pull origin main

Step 2: Run the Fix Script

SSH into your server and run:

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

# 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

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

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:

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

• 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:

   git checkout HEAD~1 backend/igny8_core/business/integration/services/integration_service.py
   

2. Restart services:

   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