Загрузка style.css и jQuery через HTTPS
У нас несколько окружений и мы только начали использовать WordPress (Dev, QA, Pre-prod, prod и т.д.). В нижних окружениях у нас не включен https, и всё работает гладко. В продакшн-окружениях сайт перенаправляет весь трафик на https.
Первая проблема, похоже, возникает только в Chrome. Chrome отказывается загружать что-либо на странице, что не использует https. Я не знаю, как заставить WordPress загружать jQuery или styles.css (из моей темы) через https (подробности ниже).
Вторая проблема, также связанная с HTTPS - мы не можем войти в WordPress в окружениях, использующих HTTPS. Когда загружается экран входа (sitename.com/wp-admin), происходит ожидаемое перенаправление на wp-login, но после ввода имени пользователя/пароля страница просто обновляется. Никаких ошибок (проверил консоль, firebug и httpfox - ошибок не обнаружено).
Я знаю, что мы делаем что-то неправильно с https в целом, потому что у нас много проблем в окружениях, которые его поддерживают. Я провел много поисков в Google и, удивительно, не нашел много информации об использовании HTTPS в WordPress. Помимо ответов на вопросы о том, как загружать jQuery через HTTPS и как войти в WordPress-инстансы с https, есть ли хорошие ссылки о том, как работать с HTTPS в WordPress. Почти все, что я нашел, указывает на использование плагина WordPress HTTPS, и мы собираемся попробовать его, но я не уверен, решит ли это все наши проблемы.
Примечание* В моем functions.php я использую Enqueue для правильной загрузки JS и CSS файлов, и я использую относительные пути для этих загрузок //sitename.com/bla/bla, что работает нормально. Я загружаю jQuery в header.php, а styles.css загружается автоматически как часть загрузки моей темы, поэтому я не знаю, как настроить их загрузку через HTTPS или является ли это правильным подходом к решению этих проблем. (jQuery загружается из нашей локальной файловой системы, а не через CDN). Буду признателен за любую помощь. Заранее спасибо.
Поскольку вы используете балансировщик нагрузки (что подтверждено в ваших комментариях выше), ваша установка WordPress не сможет определить SSL с помощью функции is_ssl() и не будет загружать скрипты или таблицы стилей с URI, использующими протокол https:.
Если ваш балансировщик нагрузки поддерживает серверную переменную HTTP_X_FORWARDED_PROTO
, вы можете решить проблему, добавив этот фрагмент в файл wp-config.php:
// Amazon AWS Elastic Load Balancer, CloudFlare и некоторые другие
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https')
$_SERVER['HTTPS']='on';
Если вам не повезло быть размещенным на Network Solutions, сначала побейтесь головой об стол, а затем попробуйте встроить этот сниппет в уже активированный плагин (поскольку вы не можете активировать новые плагины из-за невозможности войти в админку): https://gist.github.com/webaware/4688802
На самом деле, вы можете принудительно отключить SSL в админке, войти, установить необходимые плагины, а затем протестировать работу вашего сайта с SSL перед тем, как принудительно его включать. Добавьте это в ваш wp-config.php, заменив WP_SITEURL
и WP_HOME
на реальные значения вашего сервера:
define('FORCE_SSL_LOGIN', false);
define('FORCE_SSL_ADMIN', false);
define('WP_SITEURL', 'http://example.com/');
define('WP_HOME', 'http://example.com/');

Большинство проблем с SSL возникают из-за плагинов и тем, которые используют неправильный код для загрузки CSS/JS.
В основных настройках WordPress измените адрес WordPress (URL) и адрес сайта (URL) с HTTP на HTTPS. Если у вас нет доступа к админке, вы можете изменить это через файл
wp-config.php
http://codex.wordpress.org/Editing_wp-config.phpИспользуйте правильные пути URL для ваших тем и плагинов: http://codex.wordpress.org/Determining_Plugin_and_Content_Directories. Например, жесткое указание
WP_PLUGIN_URL
не будет работать в отличие отplugin_dir_url
. Функции, как правило, дружелюбны к SSL, так как у них есть время проверить, включен ли SSL на сайте, в отличие от констант.Для админки и входа в систему вы можете принудительно включить SSL через
wp-config.php
:Вход:
define('FORCE_SSL_LOGIN', true);
Админка:
define('FORCE_SSL_ADMIN', true);
Конечно, любые жестко прописанные ресурсы или плагины/темы, которые неправильно загружают ресурсы, будут проблемой.
Вы также можете обновлять темы и плагины через SSL, если на вашем сервере установлена библиотека libssh2
. Вы также можете определить номер порта и ключи аутентификации. Если эта функция включена, вам не нужно ничего настраивать — она просто волшебным образом появится в настройках админки.

Спасибо за ответ. Я разрабатывал плагины, которые мы используем, и все они загружают CSS и JS корректным способом. Однако мой первый вопрос остался без ответа. WordPress загружает jQuery и styles.css на моей главной странице, и делает это через HTTP. Chrome блокирует обе эти важные загрузки. Есть ли способ заставить WordPress загружать ресурсы через HTTPS?

Также вы упомянули libssh2. Где это настраивается? Я искал в httpd.conf Apache, но ничего не нашел. Это PHP-модуль?

libssh2
— это SSH-библиотека для вашей операционной системы, поэтому её нужно установить на уровне ОС, после чего PHP сможет использовать её через что-то вроде http://pecl.php.net/package/ssh2, что является расширением PHP. Вы выполнили шаг №1? Если да, то никакие ресурсы не должны загружаться через HTTP, если только это не ошибка темы или плагина.

Вы можете определить эту настройку в вашем файле wp-config.php
, http://codex.wordpress.org/Editing_wp-config.php#WordPress_address_.28URL.29

Окей! У меня тоже такое было. Убедитесь, что вы правильно загружаете ваш jQuery-файл, а затем дважды проверьте файлы JavaScript, от которых зависят ваши плагины. В WordPress есть несколько способов загрузки JS-файлов. И еще раз проверьте, чтобы не загружался стандартный jQuery-файл WordPress и ваш пользовательский файл с другой версией jQuery. По вашей проблеме с HTTP, пожалуйста, прочитайте html5boilerplate.com они используют более умные подходы для HTTP. Не слишком сильно модифицируйте основные файлы :)

Мы нашли решение, и оно оказалось чисто средовым — проблема была в настройке наших окружений. Оказалось, что наш MySQL-сервер и основной сервер находились на разных машинах, а WordPress необходимо явно указывать разницу между запросами, направляемыми к серверу MySQL и серверу с фактическим кодом. Решение заключалось в том, чтобы определить, какие записи базы данных должны указывать на SQL-сервер, а какие — на веб-сервер.
Как только мы разобрались с настройкой окружений, что позволило мне войти в систему, я включил плагин HTTPS, и мы смогли загрузить сайт в обычном режиме, устранив проблему Chrome с блокировкой не-HTTPS-запросов.
