Вставлю свои 5 копеек. Прокомментирую второй вопрос по поводу изображений.
Плясать от размеров изображений и как-то перестраивать генератор для этого - не самая лучшая идея. Объясню почему:

1. Изображение в данном случае - это контент, т.е. наполнитель блока. Блок (его геометрия) в структуре страницы имеет больший приоритет, чем то, что в него система кидает. Блок не должен менять свои горизонтальные размеры в зависимости от содержимого. Иначе вся вёрстка "поедет". Или появится горизонтальная прокрутка.
Ни то ни другое не допустимо.

2. Браузер (по моим наблюдением) более бережно уменьшает изображения, чем растровые редакторы и тем более скрипты обработки изображений встроенные в CMS. Иногда разница почти незаметна, а иногда сильно отличается. Лучше вывести изображение размером 500px и ужать его через CSS до 250, чем жать сразу до 250 и выводить мелкое.

Я сталкивался с подобным, когда мне нужно было выводить логотипы производителей. Также иногда такой подход позволяет делать меньше типоразмеров изображений.

Теперь предметно. На странице, указанной автором темы, следующая разметка:
Я бы сделал следующее:

1. Убрал из шаблона параметры изображения width="" height=""
Они мешают управлять свойствами изображения из CSS, пропадает гибкость в настройки визуальной части.

2. Прописал блоку DIV.news_img необходимую ширину (150px) через CSS. Поскольку блок вложенный, правый внешний отступ (margin-right) нужно повесить на него.
3. Прописал ширину изображения, вложенного в блок DIV.news_img - 100%, а высоту - auto, чтобы оно не искажалось при несоответствии соотношений сторон требуемым размерам. Отступ справа бы убрал.

Таким образом изображение всегда будет подстраиваться под геометрию родительского блока, а визуально вёрстка страницы всегда будет ожидаемой и адаптивной!



CSS для участка вёрстки (нужно добавить). Игорь (alexeev), точнее не скажу, т.к. вы не потрудились отключить кэш на сайте и понять - какие стили у вас в каком файле и в какой строке не представляется возможным:
Если изображения нужны не выше определённой высоты, можно добавить родительскому блоку изображения:
Авторам советов с препарированием изображений рекомендую ознакомиться со старейшим ресурсом The Zen Garden CSS, который пропагандирует философию CSS, а именно изменение внешности страниц путём гибкой настройки только лишь CSS-стилей и использование других средств только тогда, когда возможности CSS исчерпаны. Для того CSS и создавался.

Тоже не соглашёсь. Если шаблон "едет" от того, что в него "прилетело" изображение не того размера или пара лишних буковок, значит он плохо свёрстан и его надо доделывать/переделывать.

Дмитрий, в данном случае "через CMS" - это решение "через задницу". Контент-менеджер загрузит не квадратное, а прямоугольное изображение (и будет конфлик геометрии с настройками компрессора). Или ему взбрендит загрузить пару изображений 100х100 (когда блок 150px).

Постоянно сталкиваюсь с ситуациями, когда контент-менеджер загружает оригинал 1700х1000 для фото 500х500, а где как раз надо 500х500 - грузит 100х100, потому что "других фото пока нет, вот отснимем в следующем месяце...".

Или вдруг через полгода решат, что нужен другой формат - перегенерировать все загруженные изображения в настройках? Это тот ещё гемор может получиться в зависимости от настроек хостинга, кол-ва фото и прочих условий.

Лучше не указывать для обработки и ширину и высоту. Тем более не нужно ставить галку "уменьшать по меньшей стороне". Иначе результат будет сильно зависеть от того, какой исходник загружают - квадратный или прямоугольный и с каким соотношением сторон.

Если нужны фото одинаковой ширины: ставьте ширину какую нужно, а высоту - больше в несколько раз. Тогда исходный файл будет гарантировано жаться по ширине независимо от высоты. Ширина файлов будет одинаковой.

С высотой наоборот.

Тем более не во времена CSS 2.0 живём.

Размер фоновых изображений подгоняется
background-size
background-origin

Размер блоков теперь не надо скурпулёзно просчитывать
box-sizing
calc()

Ну и т.д.

И так до бесконечности. Меня единственный момент удивляет - ТП ответила то же самое, что и Александр. При этом "ТП помогать отказывается", а Александр "Спасибо за быстрый ответ! Очень доступно объяснили."
Александр молодец! ТП молодцы, а у Елены двойные стандарты и работа на публику получается, исходя из вышеизложенного.

Ну Cloud - это скорее тренд. Сейчас много кто предлагает облачные решения и не занять часть этой ниши - значит не наработать опыт в этой области, не получить статистику (выгодно/невыгодно и т.д.) и отстать от конкурентов. А если с течением времени перевес в сторону этого сегмента станет существенным, то и вовсе закрыться.

Поэтому тут Diafan скорее старается быть в тренде, но при этом их ресурсы существенно нагружаются.
Виталий (DIAFAN.CMS), поправьте, если не прав.

Надо поставить галку и прояснить ситуацию. Тариф, небось, левый?



Тогда сразу после клика на галке "Интернет-магазин" магазин закроют, а интернет отключат.
А потом отключат газ, свет, отопление и мобильную связь.

Потому что с высокой долей вероятности левый тариф не имеет шаблонов в комплекте, в которых проработаны модули из правого тарифа, в частности "Интернет-магазин".

Работу ограничили, а рубильник для искушения оставили?

Одно из толкований - Толерантность от лат. tolerantia — добровольное перенесение страданий. К Виталию точно не относится.

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

Я без малого две недели назад отвечал на вопрос по переносу БД, аналогичный вашему. По идее, информация свежая и её можно попробовать найти через поиск, поискав "config.php" (файл, в котором требуется правка).

Только поиск ищет старые темы 2-5 летней давности. Поэтому надеяться на поиск не стоит. Либо "Избранное", либо закладка в браузере.

Дмитрий, вы публикуете эти занимательные материалы для ТП, чтобы они использовали их в качестве ответов на ваши запросы в будущем?

Это "хвост" от шаблонного тега Diafan <insert>
Когда его вставляешь в визуальный редактор TinyMCE, он его по незнанию закрывает <insert></insert>.

При генерации страниы <insert> Diafan обрабатывает, а "хвост" так в коде и остаётся.

JS можно и отключить, но при этом ничего не поменяется. Тег рубится в любом случае. Код можно скопировать без всякого JS в обычный HTML-файл. Ошибка воспроизводится без проблем. Причина в вёрстке.

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

При просмотре кода (тег формы не закрыт):

При просмотре через инструменты разработчика:
тег закрыт, лишняя вложенная форма удалена, остальные элементы формы оставлены. Таким образом браузер исправляет критичное место, чтобы не допустить конфликта в работе.

Пробуйте "закрыть" форму поиска, должно заработать (у меня заработало).

Пожалуйста. В таких ситуациях, кстати, можно получить и другие фокусы. Допустим, на незакрытую форму (или другой незакрытый элемент) повешены CSS-стили. В инструментах разработчика элемент закроется, но по факту останется открытым и все последующие элементы будут как потомки наследовать эти CSS-свойства. И получится чехарда с оформлением.

Алексей, скопируйте из дистрибутива файл includes/mail.php, заархивируйте его в ZIP-архив и прикрепите к своему сообщению, чтобы можно было предметно посмотреть - что у вас там за функция и есть ли она там вообще.

РЕШЕНИЕ:
У вас в конце файла следующее:Проблемная строка 83:
console_log ($mailssend);

Происходит вызов функции console_log(), которой в качестве параметра передаётся переменная $mailssend.
При этом функция не является штатной для PHP, а потому должна быть объявлена до её вызова. Объявление отсутствует и система правильно сообщает, что происходит обращение к функции, которая ранее не была объявлена.

Сотрите 83 строку, либо закомментируйте вот так:ДЛЯ СПРАВКИ:
console_log() является штатным JS-дебаггером и выводит в консоль обозревателя отладочную информацию для контроля работы скриптов. Она нужна исклюительно для разработчиков.

В вашем случае либо не дописали правильно вывод этой функции для JavaScript, либо где-то использовали написанную самостоятельно функцию для PHP, которая конкретно в этом файле не присутствует.

Поэтому ни удаление, ни комментирование данной строки (83) на работе скрипта mail.php не скажется.

Ага, "свой в доску".

Как вариант можно сделать отдельную страницу, адресовать её как новостную.
И вывести всё, что хочешь, шаблонным тегом с настройками.

Большое спасибо!

Сайт тут ни при чём. Это у вашего Chrome несварение . Памяти переел.
С учётом того, что платформа одна, можете попробовать YandexBrowser, Opera или Vivaldi. Возможно они не глючат.
В плане настройки интерфейса Vivaldi весьма неплох.

Да не в HTTPS проблема, а в правильной адресации к файлам, либо в перенаправлениях.
Если вы сами пишете, что сняли редирект и всё заработало, значит редирект у вас неправильно написан, либо не полностью. Либо не везде адреса к файлам правильно указаны.

Ко всему прочему у вас кэш включён.

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

Это не аргумент. Кто-то пьяным за руль садится и тоже "ещё ни разу не попал в ДТП". Ко всему прочему вам помочь становится значительно труднее, поскольку не понятно - какие файлы откуда и каким образом подгружаются (из каких папок).

При отключённом кэше я точно смогу сказать - где именно и какой у вас файл лежит, используете ли вы тему и какую. И в какой строке какого файла что нужно подправить.

А при включённом кэше всё это дело кэшируется, переносится в папку cache, частично или полностью жмётся ну и т.д.. Таким образом, вы себе медвежью услугу оказываете. Всё-таки вы рассчитываете получить помощь на форуме, а не наоборот.

Вот, кстати, аналогичный пример когда включён кэш и помочь практически невозможно. При любых работах на сайте отключайте/сбрасывайте кэш и включайте режим разработчика.

Предлагаю выложить решение в "Базу знаний" с подробностями (в более доступном виде) - где было надо поле, какой файл отредактировал и что в нём поменял. Ну и результат.

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

Влад, вам же в предыдущей теме всё по данному вопросу разжевали и ниже написали дословно код - что на что поменять. Зачем вы одно и то же по нескольку раз спрашиваете?

Влад вчера начал эту тему с вопроса: "Как поставить модуль 'задать вопрос' в ровень с остальными?". Но на этот вопрос ему ответили ещё 16-го февраля в этой теме.

Получается сам создал тему, получил информацию, не ознакомился с этой информацией, создал другую тему. В которой то же самое, что и в первой. Отсюда и мой вопрос - "зачем?".

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

"Режим разработчика" выводит ошибки, если они есть. Это может помочь найти проблему, но не всегда. Попробуйте зайти в админку с другого браузера, которым вы обычно не пользуетесь. Например, популярный плагин LastPass может подставлять в формы старые значения и влиять на сохранение форм ну и т.д..

Создайте копию сайта.

1. Попробуйте изменить настройку с другого браузера. Если не поможет, то:
2. Отключите-включите модуль. Если не поможет, то:
3. Удалите папку с модулем и замените аналогичной из дистрибутива Diafan

Возможно, в ходе этого эксперимента станет ясно - в чём проблема.

Дублирую из соседней темы.

Тут вопрос двоякий. Это как с OEM-лицензией Microsoft Windows. Можете купить OEM и поставить кому хотите (не "коробка", цена в 2 раза ниже). Но по правилам на вас перекладывается бремя тех.поддержки (именно перекладывается), а не "на ваше усмотрение".

Лицензия партнёрская для партнёра идёт на порядок дешевле именно потому, что в неё со стороны Diafan не закладывается стоимость этой самой тех.поддержки конечного пользователя. Вам как партнёру - пожалуйста. А с клиентом вы сами (партнёр получается посредник ТП). Вопрос - должна ли в партнёрской лицензии присутствовать ТП от партнёра? По идее да, должна.

Иначе это получается банальная перепродажа. И тут встаёт вопрос НДС 18% (потому-что просто купи-продай) и гарантийного срока, который если и не озвучен, определяется законом о защите прав потребителей.

Если в партнёрской лицензии выявляются ошибки (как в случае с галочкой, которая не ставится), продавец (в данном случае Дмитрий) должен устранить данную ошибку за свой счёт. Партнёр может в свою очередь обратиться к Diafan как к продавцу с требованием устранить ошибку (брак). Но посылать своего покупателя напрямую к Diafan он права не имеет.

Но дело в том, что это не банальная перепродажа по определению! В памятке партнёра чётко прописано, что:

Перепродавая "партнёрскую" лицензию, вы не просто перепродаёте ПО, а визируете, что человек, которому вы перепродаёте - ваш клиент. Если вы не оформили с ним клиентский договор, это дела не меняет, т.к. он автоматом подпадает под действие закона о защите прав потребителей.

Так что клиент теперь ваш, продукт (поддержка) ваш (а не Diafan). На каких условиях оказывать поддержку - вопрос другой. В рамках ваших с клиентом договорённостей. Но ваши взаимоотношения определены, вашими же действиями подтверждены и исполняются в рамках ЗоЗПП, если вы не потрудились оформить это отдельным юридическим документом.