Hi Rod Price,
Based on above analysis, the issue is likely due to: Plugin conflicts post-restore (common with .wpress
imports) / Restricted MySQL connectivity via VNet-only access/ Memory or permission errors triggered under App Service Linux
Lets do some troubleshooting:
- Safely Disable All Plugins- This ensures any faulty plugin doesn’t block the login process.
Via Kudu Console or FTP:
mv /home/site/wwwroot/wp-content/plugins /home/site/wwwroot/wp-content/plugins_disabled
Alternate (via MySQL):
UPDATE wp_options SET option_value = 'a:0:{}' WHERE option_name = 'active_plugins';
- Verify MySQL Flexible Server Connectivity- Ensure the App Service is correctly integrated with the same VNet/subnet as the MySQL server.
Check from Kudu Console:
nc -zv <mysql-name>.mysql.database.azure.com 3306
If this fails, update NSG rules or expose MySQL to App Service outbound IPs for testing.
- Fix File Permissions and Increase Memory
File permission issues often occur post-import on Linux.
chown -R www-data:www-data /home/site/wwwroot
chmod -R 755 /home/site/wwwroot
In wp-config.php
, increase memory and enable debug logging:
define('WP_MEMORY_LIMIT', '256M');
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
Retain your current VNet + Private MySQL architecture, as it's more secure. Only consider switching to public access temporarily for debugging, if absolutely necessary.
If you have any further assistant, do let me know.