Загрузка style.css и jQuery через HTTPS

2 июл. 2013 г., 03:55:18
Просмотры: 25K
Голосов: 4

У нас несколько окружений и мы только начали использовать 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). Буду признателен за любую помощь. Заранее спасибо.

3
Комментарии

Ваш рабочий сайт находится за обратным прокси / балансировщиком нагрузки? Это может мешать WordPress определять SSL, и скрипты не будут загружаться через SSL. Если не уверены, установите плагин SSL Insecure Content Fixer и запустите тест is_ssl() со страницы плагинов.

webaware webaware
3 июл. 2013 г. 03:24:26

Наш сайт точно находится за балансировщиком нагрузки. Раньше я работал с сайтом на WordPress за балансировщиком нагрузки с включенным HTTPS, и таких проблем не было (но у меня были отличные сетевые специалисты, которые, вероятно, решили эти вопросы за меня). Так что мы можем сделать, чтобы WordPress определял SSL за балансировщиком нагрузки?

RAC RAC
3 июл. 2013 г. 20:56:08

Я также не могу загружать плагины в этих проблемных окружениях, потому что НЕ МОГУ ВОЙТИ В WORDPRESS. К сожалению, все исправления, связанные с загрузкой плагинов, не помогут.

RAC RAC
3 июл. 2013 г. 21:03:13
Все ответы на вопрос 4
2

Поскольку вы используете балансировщик нагрузки (что подтверждено в ваших комментариях выше), ваша установка 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/');
4 июл. 2013 г. 02:20:29
Комментарии

Спасибо за это! Я немного удивлен, что это не встроено по умолчанию.

Noz Noz
23 нояб. 2015 г. 20:41:31

Спасибо за ответ! Обновление wp-config.php отлично сработало при настройке HTTPS с использованием AWS ELB.

Leon Leon
10 авг. 2018 г. 08:09:02
5

Большинство проблем с 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. Вы также можете определить номер порта и ключи аутентификации. Если эта функция включена, вам не нужно ничего настраивать — она просто волшебным образом появится в настройках админки.

2 июл. 2013 г. 04:15:16
Комментарии

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

RAC RAC
2 июл. 2013 г. 19:39:57

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

RAC RAC
2 июл. 2013 г. 19:58:44

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

Wyck Wyck
2 июл. 2013 г. 21:14:20

Я не могу выполнить первый шаг, потому что не могу войти в WordPress.

RAC RAC
3 июл. 2013 г. 00:52:21

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

Wyck Wyck
3 июл. 2013 г. 03:00:59
1

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

2 июл. 2013 г. 21:27:18
Комментарии

Я уже пробовал отключить все плагины через базу данных (поскольку я не могу войти в админ-панель WordPress, я не могу ничего редактировать, кроме файловой системы или базы данных, ничего в интерфейсе WordPress).

RAC RAC
3 июл. 2013 г. 00:54:36
1

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

Как только мы разобрались с настройкой окружений, что позволило мне войти в систему, я включил плагин HTTPS, и мы смогли загрузить сайт в обычном режиме, устранив проблему Chrome с блокировкой не-HTTPS-запросов.

9 июл. 2013 г. 03:36:06
Комментарии

Темы не закрываются здесь, вам просто нужно выбрать ответ.

Wyck Wyck
9 июл. 2013 г. 03:47:05