¿Cómo forzar que los recursos estáticos con fuentes HTTP se carguen a través de HTTPS?

Si los recursos están correctamente encolados (enqueued), están utilizando la URL exacta con la que fueron registrados. Si el protocolo en la URL está codificado de forma rígida (hardcoded), eso causa los problemas de incompatibilidad que estás viendo.

Para un soporte adecuado del protocolo, las URLs encoladas deben ser:

• creadas con funciones de la API de WordPress que sean conscientes del protocolo (la mayoría, si no todas las funciones que generan URLs lo son)
• usar formato relativo al protocolo como //ejemplo.com/hoja-de-estilos.css

Si los enlaces provienen de código de terceros, tendrás que anular el registro y volver a registrar el recurso adecuadamente o (en el peor de los casos si no se usa la cola) reescribir el código / pedir al desarrollador original que lo haga.

Si estás utilizando Balanceadores de Carga de AWS con Terminación SSL, esto es lo que hice:

Asumiendo que tienes tu AWS ELB configurado para hacer terminación SSL y redirigir el tráfico a tu Grupo de Destino de WordPress:

En wp-config.php:

define('WP_HOME','https://TU_SITIO_WORDPRESS');
define('WP_SITEURL','https://TU_SITIO_WORDPRESS');

// Actualización 8-Abril-2018: Moví la redirección https desde la configuración del servidor virtual Apache a wp-config.php usando este fragmento.
if (strpos($_SERVER['HTTP_X_FORWARDED_PROTO'], 'https') !== false)
   $_SERVER['HTTPS']='on';

Fuente: https://blog.lawrencemcdaniel.com/wordpress-aws-elb-ssl/

Esto es lo que hice para configurar SSL para uno de los clientes.

1: Coloca esto en el archivo wp-config.php para habilitar SSL en el área de administración.

define('FORCE_SSL_ADMIN', true);
define('FORCE_SSL_LOGIN', true);

2: Asegúrate de que en Ajustes -> Generales la URL en ambos campos comience con https://

3: Coloca este fragmento (modificado de este tutorial) en el archivo functions.php para que todos los enlaces internos no HTTPS sean redirigidos a sus equivalentes HTTPS.

function wpse_ssl_template_redirect() {
    if ( !is_ssl() ) {
        if ( 0 === strpos($_SERVER['REQUEST_URI'], 'http') ) {
            wp_redirect(preg_replace('|^http://|', 'https://', $_SERVER['REQUEST_URI']), 301 );
            exit();
        } else {
            wp_redirect('https://' . $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI'], 301 );
            exit();
        }
    }
}

add_action( 'template_redirect', 'wpse_ssl_template_redirect', 1 );

Recomiendo editar el archivo .htaccess o crear uno si no existe.

Ejemplo incluyendo el código predeterminado de WordPress:

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301,NE] 

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Redirigir HTTP a HTTPS a nivel de servidor (por ejemplo, en bloques de servidor de Nginx o .htaccess si estás utilizando servidores similares a Apache) siempre es un buen punto de partida para esto.

Del mismo modo, si estás utilizando un proxy como Cloudflare, también puedes forzar la redirección de todas las solicitudes a HTTPS dentro de su página de configuración SSL. Si necesitas reescribir situaciones poco comunes, como algunos recursos antiguos de http://cdn.example.com que tu servidor web no puede manipular, entonces puedes utilizar la función Page Rules de Cloudflare y redirigir esas solicitudes con una regla como esta:

http://cdn.example.com/* >>> 301 REDIRECT >>> https://example.com/wp-content/$1

Pero ninguna de estas soluciones aborda el problema de los hipervínculos internos codificados de forma fija o los recursos estáticos que aún podrían llamarse mediante HTTP, con código como <script src="http://example.com/foo.js">

Con el tiempo, es probable que tu equipo necesite actualizar manualmente dichos recursos donde sea que se carguen, ya sea en archivos de plantillas del tema, publicaciones y páginas, etc. Buscar/reemplazar las URLs absolutas en la base de datos también puede ayudar un poco, pero aún así no corregirá los recursos codificados de forma fija en los archivos de plantilla, y también podría pasar por alto cadenas de datos serializados en MySQL si no estás prestando atención.

En la mayoría de los casos, forzar la reescritura de estos recursos "rebeldes" requiere una combinación de JavaScript en tiempo real y/o apuntar al encolado de estos recursos por parte de WordPress. Pero, debido a que muchos diseñadores web no siguen las mejores prácticas, significa que a veces, por ejemplo, JavaScript es la única solución verdaderamente efectiva.

Esto es lo que hacen algunos plugins gratuitos, como Force HTTPS (el plugin de mi equipo, aunque no se ha actualizado en un tiempo) y varios otros.