Как принудительно загружать статические ресурсы с HTTP-источников через HTTPS?

Если ресурсы правильно добавлены в очередь (enqueued), они используют точный URL, с которым были зарегистрированы. Если протокол в URL жёстко прописан, это вызывает проблемы несоответствия, которые вы наблюдаете.

Для правильной поддержки протокола URL при добавлении в очередь должны быть либо:

• созданы с помощью API-функций WordPress, учитывающих протокол (большинство, если не все функции, генерирующие URL, делают это)
• использовать протокольно-относительный формат, например: //example.com/stylesheet.css

Если ссылки поступают из стороннего кода, вам придётся отменить регистрацию и перерегистрировать ресурс соответствующим образом или (в худшем случае, если очередь не используется) переписать код / попросить оригинального разработчика сделать это.

Если вы используете балансировщики нагрузки AWS с SSL-терминацией, вот что я сделал:

Предполагая, что ваш AWS ELB настроен для SSL-терминации и перенаправления трафика в вашу целевую группу WordPress:

В файле wp-config.php:

define('WP_HOME','https://ВАШ_САЙТ_WORDPRESS');
define('WP_SITEURL','https://ВАШ_САЙТ_WORDPRESS');

// Обновление от 8 апреля 2018: Я перенес редирект на https из конфигурации виртуального сервера Apache в wp-config.php, используя этот сниппет.
if (strpos($_SERVER['HTTP_X_FORWARDED_PROTO'], 'https') !== false)
   $_SERVER['HTTPS']='on';

Источник: https://blog.lawrencemcdaniel.com/wordpress-aws-elb-ssl/

Вот что я сделал, чтобы настроить SSL для одного из клиентов.

1: Добавьте это в wp-config.php, чтобы включить SSL для административной части.

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

2: Убедитесь, что в Настройки -> Общие URL в обоих полях начинается с https://.

3: Добавьте этот сниппет (модифицированный из этого руководства) в functions.php, чтобы все внутренние ссылки без HTTPS перенаправлялись на их 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 );

Я рекомендую отредактировать файл .htaccess или создать его, если он отсутствует.

Пример с включением стандартного кода 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

Перенаправление HTTP на HTTPS на уровне сервера (например, в блоке сервера Nginx или файле .htaccess, если вы используете серверы типа Apache) — это всегда хорошая отправная точка.

Аналогично, если вы используете прокси, например Cloudflare, вы также можете принудительно перенаправлять все запросы на HTTPS в настройках SSL. Если вам нужно переписать нестандартные ситуации, например, старые ресурсы типа http://cdn.example.com, которые ваш веб-сервер не может изменить, тогда можно использовать функцию Page Rules в Cloudflare и перенаправить такие запросы с помощью правила:

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

Однако ни одно из этих решений не решает проблему жёстко прописанных внутренних ссылок или статических ресурсов, которые всё ещё могут загружаться по HTTP, например, с помощью кода вроде <script src="http://example.com/foo.js">.

Со временем вашей команде, вероятно, придётся вручную обновлять такие ресурсы везде, где они загружаются — будь то файлы шаблонов темы, записи или страницы и т.д. Поиск и замена абсолютных URL в базе данных также может помочь, но не исправит жёстко прописанные ресурсы в файлах шаблонов и может пропустить сериализованные строки данных в MySQL, если вы не будете внимательны.

В большинстве случаев принудительное исправление таких "упрямых" ресурсов требует комбинации динамического JavaScript и/или управления их загрузкой через WordPress. Но поскольку многие веб-дизайнеры не следуют лучшим практикам, иногда единственным по-настоящему эффективным решением остаётся JavaScript.

Именно так работают некоторые бесплатные плагины, например, Force HTTPS (плагин моей команды, хотя он давно не обновлялся) и несколько других.