С мая у mail.ru изменились тех требования по безопасности и теперь, если Вы отправляете сообщения с сайта на ящик в сервисе mail.ru и ставите в качестве отправителя так же ящик в их же сервисе, то оно вряд ли будет доставлено. Если проблема именно в этом, то решить её можно указав в админке "E-mail, указываемый в обратном адресе пользователю", например, site@domain.ru, где domain.ru домен Вашего сайта.

Конечно, надёжнее использовать SMTP-авторизацию при отправке почты с сайта, но иногда это бывает затруднительно.

спасибо Вам огромное за идею!

Диафан и все кто тут что либо кому либо предоставляет :) Срочно вписываем в договоры с разделом обязанности клиента:
"Клиент обязуется не критиковать товар, услугу и любые действия исполнителя в какой бы то ни было форме"

Насколько я понял, проблема не работы автоопределения http/https возникает при использовании на сервер nginx, и с ещё большей вероятностью это проявляется в том случае, если за nginx находится Apache MPM-ITK. Потому что для корректной работы с данным кодом требуется fastcgi_param HTTPS on, т.е. мало того что настройка должна присутствовать в nginx, но и сам апач должен быть собран в Apache PHP-FPM FastCGI. И как бы это всё очень не однозначно.
Поправьте если я ошибаюсь.

Пробовали работать с https?

Да, вопрос был больше про использование сертификатов с Diafan, может это только у нас всё как то не просто.

ВИТАЛИЙ (NVGPRO), Вы точно учили только теорию/читали википедию или всё же пробовали это использовать на разных сайта/CMS размещаемых на разных серверах?

Хорошо, давайте, для того чтобы всё стало понятно, ;) мы возьмём какой-нибудь сайт, уже нормально работающий по протоколу http на Diafan CMS и запустим по https. Мы даже установим туда сертификат! :)
И в этой ветке, с непосредственным участием разработчика, разберём что к чему, за одно разыграем лицензии на Diafan CMS в честь успешного запуска сайтов на Diafan по протоколу https без навыков программирования и досконального знания движка.

Как обстоят дела с простым и универсальным использованием https?
И Вы и мы позиционируем Diafan CMS как изначально оптимизированную для поисковиков, говорим клиентам о том, что сайты, сделанные на Diafan будут максимально соответствовать рекомендациям поисковиков. Но как можно на это опираться, если использование https невозможно запустить ни «по-умолчанию», ни какими-либо простыми настройками. Для этого приходится искать и править отвечающие за это файлы и ждать, когда же ещё что-то «отвалится». Да, Вы говорили о том, что при определённой конфигурации сервера всё работает само по себе, но судя по всему в эту конфигурацию нужно угадать, да и не является она оптимальной и поголовно используемой.

Для всех же остальных, активно участвующих в дискуссии и строящих предположения:
разместите по парочке сайтов на Diafan которые Вы сами сделали и запустил на https, а то как-то не убедительно звучат Ваши слова.

Виталий :), Ваши слова не могут быть убедительными или нет, Вы разработчик, у Вас другие задачи. Мы пробуем поднять свои глаза, но видимо до Ваших небес они не дотягиваются. У нас тоже найдется парочка "вымученых" вариантов, но мы никак не можем сдать их клиенту из-за того, что не уверены в стабильности работы.

Если вы не против чуть-чуть опустить свои глаза на бренную землю, то вот вам реальность:

http://test.onsoft24.com/

https://test.onsoft24.com/

Так оно "выглядит из коробки". Возможно мы что-то упускаем и будем признательны Вам за указания на наши недочёты ;)

Да, конечно писали и там рекомендовали сначала внести правки в одни файлы, затем в другие. После этого основа вроде как работала, но в будущем мы наткнулись ещё на моменты где обработка https не проходила нормально и браузер сообщал о незащищённом содержимом. К тому моменту мы уже перестали помнить все файлы, которые поправили и места, которые в них правили и поняли, что, наверное, это не верный путь.

Работает ВСЕ только работает не корректно. Никто не говорит, что что-то с чем-то конфликтует, уж тем более о шифровании. Речь о том, что CMS формирует http урлы вместо https и искать где нам нужно заменить одно на другое не совсем верный путь, т.к. это далеко не один фал нуждающийся в правках. Более того, внеся эти правки сайт перестаёт корректно работать по http и это тоже не правильно.

Из переписки с тех.поддержкой по этому вопросу:

DIAFAN.CMS: http:// прописано в файле adm/themes/adminauth.php. Замените в этом файле http:// на https://.

Мы: Пару http:// заменили, но видимо это ещё не всё. Т.к. некоторые блоки вывдятся так:
<insert name="show_head">
<insert name="show_background">
и в них присутствуют http://, хотя на самом сайт всё решается изменинем одной строки с
define('BASE_PATH', "http".(isset($_SERVER['HTTPS']) && $_SERVER['HTTPS'] != 'off' ? "s" : '')."://".getenv("HTTP_HOST")."/".(REVATIVE_PATH ? REVATIVE_PATH.'/' : ''));

на

define('BASE_PATH', "https://".getenv("HTTP_HOST")."/".(REVATIVE_PATH ? REVATIVE_PATH.'/' : ''));

и даже если залогиниться, то внутри админки всё тоже как то сумбурно.

Мы не против в качестве эксперимента отредактировать файлы вручную, но точно нет более простого способа использовать https? :)

DIAFAN.CMS: К сожалению, ничего более простого посоветовать Вам не можем.

DIAFAN.CMS: Если код не срабатывает, значит не задана серверная переменная $_SERVER['HTTPS']. Предоставьте временный доступ к сайту по FTP для того, чтобы мы могли протестировать дополнительный способ проверки.

Всё работает, серьёзно? :)

Хорошо, про path понял, проверим этот момент.

Обновления это отдельная «нерабочая» тема , но здесь не об этом. Скорее речь о какой-то определённой версии 5.4

5.4.8.4

С начало в тех.поддержку, но там "К сожалению, ничего более простого посоветовать Вам не можем.", потом на форум, но тут "И бухучет ведет, отчетность сдаёт, и в случае чего, в налоговую сама ездит.", давайте напишем в багтрекер и подождём когда это там окончательно похоронится.
Считаете что проблемы нет, хорошо, читайте так дальше.

Т.е. по Вашему "феншую" пути назад в http быть не должно?

В приведённом примере редирект отключен для того чтобы можно было понять, как выглядеть "до" и "после".

На приведённых мною примерах нет папки cache и файла index.html нет, не знаю хорошо это или нет, но как-то вот так. Видимо и кэш не используется?

Ну и ответа на вопрос что же мы (не CMS и её файлы) делаем не так, я не увидел, ну или может опять что-то упустил из виду, столько полезной информации по теме вопроса.

Ещё раз повторюсь, мы можем "вымучать" это, но считаем, что это не правильный путь. Это не архиуникальная задача и это должно работать без "плясок с бубном" и "замены пары файликов". Мы не против правильной вёрстки и настройки, но против правки файлов CMS под такого рода типовые вопросы. Это должно либо работать из коробки, либо иметь настройку через админку/конфиг, как включение/выключение кэширования. Для того чтобы его включить Вы ведь не правите рабочие файлы CMS и не руководствуетесь "феншуями" настройки сервера, хотя там тоже есть разные варианты?

И да, если всё дело только в path, то отчего же "сыплется" админка? Там мы используем "стандартный шаблон" :)

Я не знаю, как и что у кого-либо получается. Судя по некоторым высказываниям и предложениям даже в этой ветке чувствуется заинтересованность в наличие некоторых проблем в CMS, видимо для кого-то это лишний повод заработать на «правке некоторых файлов».
Нам же хочется, чтобы CMS была максимально удобной и требовала минимального кол-ва вмешательств для нормальной работы. Именно поэтому мы сообщаем о подобного рода вопросах, дабы решить их, а не корить в том, что есть эти недочёты.
Я привёл пример того, как это видим мы и наверняка другие пользователи, которые пытаются следовать рекомендациям поисковиков запуская сайты на https. Если бы всё работало как нужно, подобная проблема не проявлялась бы. Мы же не стали бы писать о ней, не потратив для её изучения приличного кол-ва времени.
В сухом остатке мы имеем ответ со смыслом «ну у других как-то работает вроде, поковыряйтесь там, и у вас должно». Да, у нас тоже это может работает. Только для этого приходится тратить время и отслеживать ситуацию, ведь CMS иногда обновляется и в ней что-то меняется. Возможно это не критично, если это твой единственный сайт, но, если ты хочешь запускать сайты более-менее регулярно, а зарабатывать на их нормальной работе, а не на мелких правках, которых могло бы и не быть, то это немного раздражает.

Ну если тех.подержка оценив ситуацию сама добавляет в багтрекер информацию об опечатке/ошибке, а разработчики её устраняют в течении хотя бы 5 месяцев это волшебство, то да, наверное, мы ждём именно волшебства.

Что касается шаблона, бегло глянул, там следующее:

<head>
<insert name="show_head">
<meta name="viewport" content="width=1170">
<link href="<insert name="path">css/reset.css" rel="stylesheet" type="text/css">
<link href="<insert name="path">css/style.css" rel="stylesheet" type="text/css">
<link href="<insert name="path">css/animate.css" rel="stylesheet" type="text/css">

На сайте (view-source:https://test.onsoft24.com/) выводится как:
<meta name="viewport" content="width=1170">
<link href="http://test.onsoft24.com/css/reset.css" rel="stylesheet" type="text/css">
<link href="http://test.onsoft24.com/css/style.css" rel="stylesheet" type="text/css">
<link href="http://test.onsoft24.com/css/animate.css" rel="stylesheet" type="text/css">
<script type="text/rocketscript" data-rocketsrc="http://test.onsoft24.com/js/jquery.min.js" charset="UTF-8"><</script>

да, в шаблоне есть ряд абсолютных ссылок с http, но это линки кнопок, не влияющих на визуальную составляющую сайта.

Доступ к ftp предоставил, но не для того чтобы настроить конкретный сайт, а для того, чтобы разобраться в чём именно заключается проблема.

Спасибо Андрею что предоставил доказательства недальновидности утверждавших что все работает и проблем нет ;)

Благодарю за уделённое время и решение вопроса. В последних версиях всё работает без необходимости дополнительных правок каких либо системных файлов CMS.

Не думаю что связка apache+nginx является редкой.
Согласен с тем что CMS не обязана работать на всех подряд серверах, но нужно же учитывать, что они бывают разные, с разными настройками. Не для этого ли перед установкой запускается тест системы, сообщающий о её состоянии?
Ну либо сообщите о том, что CMS работает только под Apache, с другими серверами не тестирована и возможны сбои. Некоторые CMS не стесняются говорить о том, что для них нужен особенный хостинг, с особенными настройками. Зато люди знают что лучше с ними не связываться :)))

p.s. если бы у нас был самописный сервер, то и CMS у нас была бы самописная.

Леонид, здравствуйте!
Да, всё работает и у нас мы всем своим клиентам предлагаем размещаться именно по https настраивая это. Наверное, единственный минус заключается в том, что нужно делать принудительную переадресацию с http на https, т.к. Diafan может закэшировать и выдать на одной странице объекты с разными протоколами и получиться не очень.

Есть бесплатные сертификаты ;) и все прекрасно работает.

Я думаю отличия должны описывать те, кто за них денег хочет, чтобы было понятно за что. Нашим клиентам вполне достаточно бесплатных и пока просьб заменить их на платные не поступало. Сайты нормально открываются в браузерах. И да, редирект с http на https в нашем случае происходить на уровне настроек хостинга, а не через .htaccess, но это наверное дело вкуса и конкретных условий.

Было подобное с rss для Яндекс.Новостей. Руками переместили файл на место, не стали разбираться.

Мы не стали. В ТП не писали. Больше времени бы ушло на разбирательства.
Таких как этот "коясков" в CMS порядочно и если есть вариант как можно сделать по другому, мы делаем по другому :) Хотя порой они, конечно, обескураживают.

Здесь вообще бесплатно ;)