Axian Ltd.: Вычислил-таки проблему. Их было две:
1) Указан адрес с http в настройках плагин WP Super Cache
2) Плагин Cache Enabler вообще клал болт на возможность использования https. У него в исходниках жёстко прописан http протокол. Пришлось долго выявлять поиском по содержимому файлов и менять вручную в коде плагина.
Спасибо вам за участие :) Думаю именно из-за ваших комментариев серьёзно рассмотрел гипотезу про кэш.
Версия WP 4.8.1
В базе данных первым делом всё исправил.
Примечательно, что на главной проблема проявляется только в логотипах. Стили отображаются.
Ссылки в коде после нескольких часов поиска тоже не обнаружены :(
Спасибо за подсказку про код редиректа, добавил его.
В wp-config.php тоже задал указанное.
Однако это не помогло. Я уже пробовал это ранее, о чём специально написал в вопросе для экономии времени.
Вы точно переходили по ссылке https://teamprospect.ru/articles ?
В моём случае проблема явно где-то ещё.
Axian Ltd.: можно наглядно посмотреть, что не работает по ссылке https://teamprospect.ru/articles. Эмпирически я выяснил, что все "http" появляются в коде, выводимом wp_head(). Вполне допускаю, что проблема не конкретно в этой функции. Это больше для упрощения локализации проблемы.
В документации на странице https://apiok.ru/dev/methods/ сказано session_secret_key = MD5(access_token + application_secret_key). То есть предполагается наличие access_token, полученного на клиенте. "приватный ключ сессии" очень похоже в переводе на "session_secret_key". При этом алгоритм, описанный по ссылке работает только при использовании первого их двух токенов в качестве "access_token". Выходит, что для получения приватного ключа сессии нужно преобразовать приватный ключ сессии, что абсурд.
Здесь очевидно два варианта:
1) Это проблема терминологии и названный вами "приватный ключ сессии" это не session_secret_key
2) Преобразование токена, указанное в документации, излишне
Какой ближе к истине?
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.