Пара моментов:
1. JivoSite закрывает надпись в подвале. Можно снизу margin добавить.
2. Выровнить кнопку поиска.


А ещё меня всегда вот эта штука забавляет (хоть это и не к вам):


Но можно в скрипт .stop() добавить. У всех пользователей PrettyPhoto "прыгалка" будет, а у Диафана - нет.

Сами файлы шаблона (обновления) входят в аренду. А вот рабочее время программиста, которое может понадобиться на обновление уже существующего сайта - нет. Поясню.

Обычно в таких случаях поступают так:
Делают второй сайт на том же шаблоне. Оплачивают месяц аренды для активации FTP. Переносят на новый сайт изображения и базу данных + свои доработки (если имеются).

Мы перекрепляем домен и SSL-сертификат, если он имелся на старом сайте. И потом переносим оплату со старого сайта на новый. Клиент получает новую версию шаблона и сохраняет срок аренды (оплату) и SSL-сертификат.

А если нужны работы на старом сайте после обновления, то тут нужно привлекать стороннего специалиста, т.к. по регламенту такие работы в поддержку не входят. Если обёъм небольшой (5-10 минут), тех.поддержка поможет. Если больше - откажет, сославшись на регламент. Обновление CMS - это возможность, такая же, как и возможность доработки любой части сайта.

Если пользователь во время доработок сам сломает сайт, тех.поддержка его восстанавливать не будет, если причина не будет прозрачна и понятна, а восстановление не займёт более 5 минут. Это не входит в тариф. Имеется ввиду "Ставндарт".

Если в процессе обновления сайт начнёт работать с ошибками, потому что версия шаблона старая, значит нужно либо откатывать обновления, либо переносить сайт, как описано выше, либо нанимать специалиста для корректировки кода шаблона. Работа специалиста поддержки в таких случаях арендой не предполагается (опять же имеется ввиду тариф "Стандарт").

Схема достаточно проста - Вы разворачиваете сайт в облаке на выбранном шаблоне. В нём присутствуют все исправления, которые применялись в шаблоне ранее. Если Вы найдёте/столкнётесь с какой-то проблемой или ошибкой шаблона, обращаетесь в тех.поддержку, Вам её исправляют вручную и вносят это же исправление в шаблон, который в системе.

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

Тут вопрос не в "использовать" или "не использовать". Тут вопрос в том, что Вы получаете на момент аренды. Мы предоставляем сайт с полной поддержкой функционала шаблоном на момент его создания.

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

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

Если будут незначительные работы из-за обновлений, в тех.поддержке помогут. Но если будет что-то серьёзное, то 100% откажут. Обновление функционала шаблона в аренду не входит.

Если Вы создаёте сайт на шаблоне версии 1.2, а через год хотите обновить систему и шаблон с поддержкой этих обновлений уже версии 2.4, то допиливание своей версии до версии 2.4 - Ваше право, но не наша обязанность.

Если покупается машина, например, Honda CRV-3 с кузовом 1-го поколения, с гарантией и обслуживанием на год и в этот год выпускают CRV-3 c новым кузовом (рестайлинг), никто не бежит менять кузов по гарантии, потому что он стильнее старого. Хотя техническая возможность есть.

Это касается нового функционала, но баги используемой версии шаблона конечно же правим при обращении.

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

Если модуль в шаблоне используется и в нём появилась новая функция, которая предполагается (например, кнопка "Показать ещё"), то она добавлена будет, т.к. пагинатор везде используется. А если изначально не использовалось сравнение и оно доработано в обновлении CMS, то оно выведено не будет.
Произойдёт после выхода обновления. Точного срока никто не скажет, потому что шаблонов десятки и после одного обновления нужно будет скорректировать 10 шаблонов, а после другого - 90. Всё зависит от обновления CMS.

Как я уже отметил выше, обновления CMS получаются автоматически в админ-панели. А обновления шаблона - в зависимости от ситуации. Когда было обновление упомянутой выше корзины, было очень много обращений. Те из них, которые касались оригинального кода, мы правили. А если пользователь самостоятельно кастомизировал файлы, которые в этом обновлении использовались, то нередко отказывали. Но это стандартная процедура, описанная в нашем регламенте поддержки, п.4, 6.

Он не официальный представитель, он просто модератор форума. Уже, наверное, раз 10 точно об этом говорилось.

Вполне может быть, что выводится весь массив, а потом отфильтровывается или не отфильтровывается.

Если характеристик должно быть 10, а выводится 1000, то проблема на поверхности. Надо просто посмотреть эту часть алгоритма и оптимизировать этот участок. Переписать или дописать какие-то условия в админке.

Может стоит разобраться, почему у товара по словам Алексея 10-15 характеристик, а выводятся все возможные, а не "запрещать и не пущать"?

Понимаете, Алексей, Diafan CMS не идеальна. И как и любой цифровой продукт, поставляется "как есть" (as is). Вот если бы вы группе программистов поставили задачу разработать систему под конкретные условия и она на выходе этим условиям не соответствовала бы - дело другое. Я с коллегой как раз сейчас реализую мини-ERP на базе Diafan. Там чёткие условия по ТЗ, которые я обязан выполнить. Тут можно говорить, что "система должна", раз в ТЗ это есть.

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

Баба Валя уборщица тоже сотрудник, но интересы Diafan она не представляет. Доступ доступом, а официальный статус - модератор форума. Он же не начальник технического отдела.

Посмотрел в стандартной деме 6-ки. В деме на магазин в общей сложности 27 характеристик всего. Берём первый рюкзак из каталога. У него в карточке 6 характеристик:

1. Размер
2. Цвет
3. Вес
4. Материал каркаса
5. Размеры
6. Максимальная нагрузка

Отключаем JS, вываливаются все 27. Следовательно, на страницу загружается весь раздел характеристик ("вот же круто! А зачем?" (с) ). И затем средствами JS скрываются не относящиеся к товару,

Странно, почему сюда до кучи не грузятся также и все товары из каталога, за компанию с характеристиками.

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

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

А теперь придётся проблему решать в рамках одного продукта.

Для этого ajax придумали, чтобы без перезагрузки получать данные от сервера. Ну можно проще: "Это косяк".

Видимо, не самый удачный. Конечно, "косяк" воспринимается как альтернатива слову "ошибка". Если с этой стороны смотреть, то ошибки тут нет. Тут вопрос в тестировании продукта. Вот подразумевается некоторое количество единиц/элементов - от нуля до бесконечности.

Тестируется на деме, где всего понемногу. Но в реальности получается по-другому. То у кого-то вылезет ошибка в форматировании, когда добавишь больше 5 характеристик, то что-то съедет, если укажешь более 20 символов и т.д..

Я так понимаю, что тестировать продукт надо на загрузке выше средней. Количество указывать не 2, а 20, характеристик ставить не 6, а 36 и т.д.. Тогда все тонкие и проблемные места будут на поверхности.

Не думаю, что заложить запас на будущее в системе, в которую можно вложить 100 000 товаров - это переоптимизация. В этом есть целый ряд минусов:

1. Нужно будет что-то переписывать и в зависимости от реализации переписывание одного, может потянуть за собой переписывание другого. Так появляются совершенно ненужные "костыли".
2. К моменту появления прецедента проблемный участок может так обрасти связями и зависимостями, что придётся переписывать чуть менее, чем полностью.

Это конечно моё личное мнение, но аргументы выше я взял не из воздуха, это реальные прецеденты последних 3-х месяцев.

Я разве пишу, что дебилы? Есть множество прецедентов, судя по которым (а только по ним я и сужу) тестируете вы менее качественно, чем оно должно быть. Зато сколько бесполезных телодвижений было вокруг этого сделано. Это можно было вообще всё свернуть и решить до того, как оно развернулось. Вот вы в очередной раз всё объяснили. Никакой разницы - было оно или не было до этого.

У вас с валютой тоже ведь не было прецедентов или были просто их не заметили / о них не написали / не поняли, что это косяк CMS.

https://user.diafan.ru/wishlist/show1411/
https://user.diafan.ru/wishlist/show2263/

Это не случайности.

Вы правы, не знаю. Зато я знаю, как вы НЕ тестируете систему.

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

Делается проект с ценами после запятой, с копейками, проще говоря и параметрами с дробными значениями. Всё, кругом ошибки. Вывод один - в систему не забивали данные с дробными значениями или забивали, но не "гоняли" на предмет связанных с этим проблем. Хотя Дмитрий Афанасьев ещё пару лет назад на "сёрче" говорил, что "у нас всё с этим супер-пупер". Скрины приводил в доказательство.

Добавляет человек более 3-х характеристик, а у него в админке опять вёрстка поехала. Значит не добавляли больше трёх, иначе бы увидели эту проблему и исправили её.

Беру я свой каталог по софту, копириую в Диафан, сохраняю. Получается какая-то хрень. Ищу проблему в вёрстке, теги не закрытые, свои косяки ищу. А получается, система не переваривает тексты длиннее 38000 букв в отдельно взятом модуле, причём модуль этот "Статьи". А статьи - это не анонсы или новости. Они могут быть просто очень длинными.

Значит не проверяли опять же. Я таких примеров с цитатами, скриншотами и видео могу минимум с десяток привести, чтобы не казаться голословным и пояснить, что я не понапрасну наговариваю и представление имею, хоть и не "с кухни". Только зачем? Вы позицию всегда ставите от противного: "У нас всё хорошо, это что-то у вас" или "Ну правильно, так же вообще никто не делает. До вас не делали и после вас не будут".

Хотя я могу и тут ошибиться и на самом деле всё выглядит так где-то:
- Смотри, я добавил длинное название и вёрстка поехала, надо исправлять.
- Да ну! Смеёшься что ли? Кто сюда будет что-то длинное вводить? Ты хоть раз такое видел? Я нет.
- Ну тогда ладно, оставляем.

Вот опять крайности. Чуть что, сразу : "Да вы нас ненавидите, да вы нас презираете". Ни то, ни другое. Мне система очень даже нравится. И довольно часто на форуме я занимаю именно вашу сторону, за что неоднократно мне уже писали, что Diafan мне якобы доплачивает.

Меня не интересует, что там у других компаний. У них там хрень куда большая, нежели у вас тут бывает. Даже сравнивать не надо. Поэтому я деньги плачу за лицензии вам, а не UMI или Bitrix. И на сервисах регистрируюсь и отзывы оставляю для того, чтобы вам рейтинг поднять, а не из-за того, чтобы всего одну лицензию личную за 3500 получить.

Я уже говорил, что админил сайт и форум Linux-дистрибутива с суммарной посещаемостью 1К человек в сутки. Каждый день приходилось отвечать на письма, удалять кучу спаммеров, переписываться на форуме. Принимать участие в разработке дистрибутива, писать документацию для wiki, вести 3 разных движка (сайта, документации и форума) и т.д..

Каждый день мне кто-то писал, задавал элементарные вопросы, иногда глупые. Кто-то крыл непечатными словами, потому что я требовал, чтобы материалы оформлялись соответствующим образом и программисты не тратили время на глупые вопросы типа: "А комп у вас вообще в розетку включён"?

Ни разу за полгода ни один конфликт не разрешился в ключе "сам дурак" ни в итоге, ни на каком-то этапе. Более того, пользователи, крывшие меня матом в первых сообщениях, потом сами извинялись за свою резкость, признавали, что были неправы и делали то, что я от них требовал. И отношения со всеми были хорошие. Да, иногда я тратил на переписку с таким "проблемным" пользователем весь день. Но на вверенных мне ресурсах не было недовольных, хотя я периодически раздавал недельные баны и т.п.. Это того стоило, потому что потом они мне помогали управляться с ресурсами даже больше остальных.

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

Вместо "давайте разберёмся" какие-то подколы, "ржачки" и прочее. Не постоянно, но 20%-30% отнести сюда можно. Если начинается какая-то проблемная переписка, тогда вероятность того, что начнутся приколы и подколы - 50-70%. Нет чтобы углубиться в вопрос, проанализировать, тихо-мирно вопрос решить. Вообще не выносить его за рамки ЛС. Ну или нормально доходчиво объяснить, почему вопрос решить [пока] нельзя.

Элементарный подход, дающий очень хороший результат: "Возможно, это наша проблема. Давайте разбираться...". Второй момент - не писать как всё круто и т.д.. скромнее подавать информацию. А то вас послушать, так вообще впереди планеты всей и всё супер-круто. Ну и ожидания такие же. А по факту всё выше среднего и часто лучше, чем у других. Но не супер-круто.

Напишите, что у вас небольшой штат, что программисты загружены и ответить смогут не всем и т.д. и т.п.. Вы же часто наоборот делаете. Чего удивляться, что итог не такой, как того бы хотелось. Надо не спорить, а делать выводы и менять своё отношение и поведение. И результат другой будет - 100%.

Можно сказать, что вы тут один, что времени нет, что [нужное дописать] и поэтому ничего не поменяешь. Только я точно знаю, что и один человек запросто может много чего изменить, потому что я это делал на проекте, не меньшем, чем ваш. И всё это при правильном подходе 100% работает.

Если шапка не включена в шаблон отдельным блоком, то в файле шаблона: /themes/site.php
Для разных страниц могут быть указаны разные шаблоны.

Много для чего id нет. Для товаров, например. Странно (лично мне), но поправимо.

И как ссылка выведет статью? Недопонял этот пример. Может понадобится во всплывающем окне, например. Это много где можно использовать. При этом ID есть у всех элеметов - и родительских и дочерних и у страниц, к которым модуль прикручен. А выводить можно по всему, кроме айдишника конечного элемента. Это дискриминация и это не логично.

Нужно мне на странице в show_block вывести три товара с ID 15, 285 и 3206. Из параметров для этой цели частично подходит только cat_id и param. Нужно получить массив, а потом уже через отдельный шаблон во вьюхе их фильтровать условием на совпадение айдишника.

Или дописывать контроллер и модель (что правильнее). Как по мне надо атрибут ID везде добавить из коробки.

Пример есть. Нажимаете на кнопку калькулятор, во всплывающее окно загружается товар по айдишнику через show-block.

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

Другой момент - публикация материалов. Если править со стороны сайта, то дата публикации появляется и правится вместе со временем. А в админке - без времени. Время надо тогда или выводить везде или убирать везде.

Дописать можно всё. Вопрос в том, что часть функций CMS работает в одном месте и отрезана/не дописана в другой. При этом есть данные в базе, есть рабочий код, который это всё выводит. Но есть не везде. Как будто в оригинальной поставке идёт Diafan LE.

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

Ох уж эти ваши сверх-способности читать исходный код серверной части по картинке.

У вас галерейная настройка в rel="PrettyPhoto" глючит. Проблема с группой фото под этим именем: gallery48shop.



Полагаю, что смена файла JS не поможет. У вас на странице стоит rel="prettyPhoto[gallery48shop]". По скриншоту видно, что проблема решаема. Копайте в эту сторону. Если не докопаетесь - смените rel="prettyPhoto[gallery48shop]" на rel="prettyPhoto" - будет показывать только то фото, по которому кликнули.

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

Смайлы и не нужно ставить, они никакой смысловой нагрузки не несут в данном случае. bb-код кастомный, оставьте кнопки оформления и всё. Кнопки обязательно нужны.

Стоило бы добавить либо информацию по адаптивности шаблонов (минимальное разрешение), либо фильтр добавить в каталог:
ПК / Планшет / Смартфон

Как у вас в галерее работ:

Присоединяюсь к поздравлениям!

Елена, название статьи и пункт в меню завязаны друг на друга только до тех пор, пока вы в модуле "Меню" не переименуете пункт, указывающий на страницу.

Т.е. переходите в модуль меню и переименовываете любые его пункты.

Я там не зарегистрирован. Но периодически почитываю. Немного некорректный обзор. Систему надо наполнить перед анализом, чтобы понимать, что в интерфейсе действительно пустует, а что просто резервируется, Виталий пояснял в этой теме. Хотя лично я бы резерв делал c height: auto и пусть себе висит, места не занимает, коли уж внутри ничего пока нет.