С мая у 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, может это только у нас всё как то не просто.

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

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

Хорошо, давайте, для того чтобы всё стало понятно, ;) мы возьмём какой-нибудь сайт, уже нормально работающий по протоколу http на Diafan CMS и запустим по 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 для того, чтобы мы могли протестировать дополнительный способ проверки.

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

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

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

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

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

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

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

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

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

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

5.4.8.4

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

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

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

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

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

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

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

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

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

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

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

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