Официальный форум OkayCMS

- Исправлена критическая ошибка, которая вызывалась на статических страницах (PageController)
- Исправлена ошибка, которая возникала, если у брендов в описании было записано NULL

Скачать новую версию можно по ссылке архив с изменениями по сравнению с 4.1.0 по ссылке  Также вы можете написать через раздел "Техподдержка" или через форму на странице "Поддержка" для заказа обновления силами наших специалистов. 

OkayCMS писал(а):Скачать новую версию можно по ссылкеархив с изменениями по сравнению с 4.1.0 по ссылкеТакже вы можете написать через раздел "Техподдержка" или через форму на странице "Поддержка" для заказа обновления силами наших специалистов.

Уже много версий идет копирование этой крайне небрежной фразы без знаков препинания. Неужто сами не читаете свои сообщения и не видите?

Посмотрел на количество запросов к БД, которое делается при формировании страниц.
По моим наблюдениям, на разных страницах от 40 до 80.
Стал смотреть более детально. Оказался тихий ужас, разработчики в некоторых местах устроили циклический вызов однотипных запросов. То есть база данных используется в этих местах совершенно неграмотно.

Если убрать такие нерациональные моменты, число запросов можно сократить чуть ли не вдвое...

А если еще удалить из okay_clean.sql строки 4408-48022, 49882-64134, то ... ?

Если имеете в виду объемные таблицы для Новой Почты, то, конечно, полезно было бы убрать их из установочного пакета и скачивать сразу с сайта НП. Тем более что работа с НП организована через модуль, который может быть и отключен.

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

Еще вопрос Создателю о resize. Вот простой пример по картинкам для категорий. Система создает 3 варианта картинок: 22х22 для размещения в меню каталога, 55х55 для размещения картинок в списке категорий и 300х120 в админке в самой категории. Т.е. пользователь должен создать картинку для категорий минимум 300х120, а далее система сам сделает нужный resize. Зачем эти лишние изображения на сайте? В чем нужда лицезреть картинку 300х120 в админке в категории? Резонно сделать оригинал 22х22, в служебных файлах везде указать resize 22х22. Имеем в 3 раза меньшее кол-во картинок.
А картинки товара? При отключенном webp, файла с водяным знаком и поддержке повышенного размера изображений система создает 6 файлов: 300х120, 55х55, 70х70, 60х60, плюс оригинал, плюс resize для карточки. Какой смысл в этом кол-ве разнокалиберных мелких картинках? Итого 6 файлов х 5 тыс товаров!!! И это тоже в БД. Т.е. имеем тысячи изображений сомнительной потребности в них.Где-то на форуме встречал рекомендации как удалить код resize, но для 3-ей версии.

обычно на хостингах есть ограничение по инодам

По поводу нарезок изображений.

Если в категориях хотите сэкономить на картинках 300x120, то этого легко достичь, если в backend/design/html/category.tpl заменить resize:300:120 на resize:22:22. Но, я бы сказал, по сравнению с картинками товаров экономия будет малозаметная.

Еще одно замечание. При стандартной установке создается 60 категорий товаров. А в папке files/originals/categories находится 125 файлов. То есть более половины - лишние, просто место занимают. Вот где резерв для экономии...

И такая картина - половина ненужных файлов - тянется с версии 3.0.0.

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

Но, по-моему, при современном развитии интернет-технологий обычно на изображениях не экономят...

Пропал заголовок H1 на главной странице.

Андрей писал(а):Пропал заголовок H1 на главной странице.

А он у вас заполнен? Он на главнои по умолчанию не заполнен, но есть заполнен - то выводится

Да, действительно.
Спасибо!

Добавлено спустя 15 минут 33 секунды:
Подскажите пожалуйста, какая оптимальная версия PHP для текущей версии OKAY CMS ?
У меня последние 2 обновления успешно прошли на версии PHP - 7.4

Любая седьмая версия.

Подскажите пожалуйста, Если хостинг на "Beget", то подходят ли предлагаемые хостером параметры (указаны ниже) для нормальной работы "okay-cms" (если что-то надо подправить - укажите что и где):
ОS: Ubuntu Server Edition
Apache:
MySQL:5.7.21-20-beget
Nginx:1.20.1
Perl:5.14.2
PHP:5.6 7.0 7.1 7.4
Python:2.7.3
Сервер: free25.beget.com
CPU'S:16 * Intel(R) Xeon(R) CPU E5620 @ 2.40GHz
ОЗУ свободно:8986 / 96537 Мб.

Ставил дефолтный Okay 4.0.5 на бесплатный хостинг beget. Ставил не глядя, не вникая в системные требования.
Установилось чисто, работало.

Блин, пробовал последнюю (4.1.1)- не взлетает . 4.0.5 - значит работает, а 4.1.0 - как себя ведет, и как приручить последнюю версию - как-то стремно от обновлений отказываться?

С Бегетом есть заморочки. Тоже сижу пока на 4.0.5 и не обновляюсь. На PHP7.4 вообще не заводится и откатывает до 7.2. А на 8.0 не отображается каталог меню и страницы с товарами с ошибкой 500. Может в дальнейшем разработчики решат эти проблемы и на Бегете будет все работать.

Да, действительно, Okay 4.1.1 на beget.ru не работает. Установился, но при открытии выдает http error 500.
Выбор php не помог.
Что скажет Создатель?

Тут сложный момент. Проблема на стороне бегета, в тех библиотеках, которые они подключают для РНР 7.4.
Мы с ними переписывались и будем продолжать переписываться. Но если это не поможет, то скорее всего в новои версии будем что-то менять, чтобы работало и на бегете :(

Вопрос к Создателю.
Есть ли в планах добавление в шаблон выбор способа показа товара: List или Gird.
Здесь работы немного: по нашему разумению добавить выбор в product_sort.tpl.
А система с этим прекрасно справится. Тестировал.
Для размещения товара строкой в products_content.tpl установил col-12.
Несколько мелких правок в theme.css для главной страницы и для превью на странице товара.
Работает на ура.
Размещение товара строкой подойдет для магазинов производственных организаций, торгующих сложным технических товаром, не ширпотребом.
Там посетители не любители шопинга, им нужны технические характеристики, а не фотки.
Размещение строкой позволит публиковать рядом с превью достаточное количество характеристик.

Добавлено спустя 4 часа 11 минут:
В theme.css какой-то баг.
Не устанавливается локально color для текста горизонтального меню.
Фон устанавливается см. ниже.
.header__center{
background-color: #76bd00; {*var(--okay-bg);строка центра меню*}
color: #fff; {*var(--okay-body-text);*}
padding: 1px 0;
}
Через theme-settings.css color срабатывает

По дефолту - нет.
Кому нужно, те довёртывают это как вы уже описали, добавление ещё одной тпл.
А нам в рамках дефолтной версии, которую нужно сопровождать - дополнительный функционал, который не особо расширяет возможности.

Мы оставили этот момент для индивидуальной реализации.