Модуль Image COMPRESSOR & Watermark & WebP & Lazy Load etc. by Sitecreator [Поддержка]

[sitecreator]

@23keks23 , здравствуйте.

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

 

9 минут назад, 23keks23 сказал:

почему

 

смотреть нужно конкретно.

 

10 минут назад, 23keks23 сказал:

вся верстка ломается.

 

ни у кого не ломается. К каждому пункту настроек дано подробное описание. Читайте внимательно.

 

12 минут назад, 23keks23 сказал:

Это можно как-то поправить?

 

Можно. Читайте внимательно описание настроек.

Модуль делает все в точности так, как вы задали настройками.

[sitecreator]

Уважаемые господа, любители связки vqmod + ocmod!

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

Если вы используете такую связку, да еще в версии опенкарт 2.3, то не используйте установку модуля Компрессор версии 1.17.3.

Нужно использовать 1.17.4+ (она совместима с vqmod + ocmod)

 

Есть стандарт для опенкарт - это OCMOD, который тоже не без греха, но хотя бы стандарт. Что делает vqmod на 2.3 я не понимаю вообще. Можно понять vqmod на версии 2.0.0, в крайнем случае на 2.1.  Но на 2.3 - это бессмысленная штука, и по-сути - зло. Т.е. реальной причины использовать vqmod  на 2.3 нет, т.к. все модули для 2.3 позволяют использовать именно ocmod при необходимости.

 

Также прошу заметить, что не стоит переходить на 1.17 владельцам мультимагазина (один магазин на нескольких доменах), оставайтесь на 1.16.5 для сохранения работоспособности webp.   Таких пользователей единицы, специально для них, вероятно, потом сделаю доработку.

 

=================

Как исправить.

Но если все же установили 1.17.3 и получили ошибку, белый экран и т.д. и т.п.

То идете в папку system. Удаляете там все OCMOD-файлы от модуля.

Далее вручную из папки /system/storage/modification/  удаляете все файлы кроме index.html

Заходите в админку и обновляете модификаторы, а также системный кеш на всякий случай.

Ошибка пропала. Можете установить заново через ocmod-установщик модуль версии 1.16.5 или 1.17.4

[sitecreator]

Доступна для скачивания

новая версия 1.1.7.4

По функционалу ничем не отличается от 1.17.3, но добавлена совместимость для случая использования vqmod + ocmod.

[sitecreator]

Версия модуля для opencart, ocstore 3.0 также приведена в актуальное состояние.

новая версия 1.1.7.4 для OPENCART 3.0

 

 

 

[sitecreator]

Уже почти год как браузеры FireFox и Microsoft Edge поддерживают стандарт сжатых изображений WEBP.

 

Модуль Компрессор - это единственное решение, которое без проблем детектирует поддержку браузером WEBP. И, соответственно поставляет в браузер WEBP если он его поддерживает или JPEG, PNG если не поддерживает.

 

Модуль не путает старый и новый FireFox, старый и новый Microsoft Edge.

 

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

 

Соответственно с верным детектированием браузера с поддержкой WEBP формируется страница с WEBP-изображениями.

 

Новый Microsoft Edge:

 

[yastman]

Хочу выразить благодарность @sitecreator за помощь в настройке генерацию webp по крону,на хостинге Ukraine.com.ua

Место 15 минут , делительная переписка с тп хостинга,кучу костылей и лишь терпение автора помогло решить эту проблему. 

Змінено 18 листопада 2019 користувачем yastman

[sitecreator]

Специально для всех, кого волнует скорость работы модуля Компрессор.

Во-первых, всегда используйте актуальную (свежая сейчас 1.17.*) версию Компрессора.

 

Теперь про то, кто или что "не очень дружит с датами."   Проблема с датами идет от Даниеля и есть во всех релизах opencart 2.* и ocstore 2.*.

Она и сейчас не устранена в ocstore 2.   Даниель сделал исправление лишь в опенкарт 3.0.

Вот на эту проблему и я в свое время попался, "поверив" коду Даниеля, точнее, оставив часть его кода у себя в модуле.

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

Уже много месяцев если не год как модуль Компрессор использует исправленный механизм контроля за датами файлов.

 

Думаю, что только не отвечающий за свои слова человек будет кричать про то, что автор Компрессора не устраняет скрытые проблемы.  Данная проблема была именно скрытая, т.к. проявляется только в определенных ситуациях, и, как минимум, 95% пользователей никогда с ней не столкнется даже без исправления этой ошибки.

Но она давно уже исправлена.

 

Нет этой ошибки ни в текущей версии модуля 1.14 для опенкарт 1.5, ни, тем более, в 1.17 версиях для опенкарт 2 и опенкарт 3.

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

 

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

И, господа, не будет ли странным при уже наличии версии 1.17 (и беты 1.18) пытаться искать несовершенства, баги и пр. в старых версиях вроде 1.8 или 1.9, коим уже полтора года?

 

Любой пользователь модуля может открыть файл модуля (он не закодирован)

image model for OpenCart

и причитать комментарий в начале файла.

 

class ModelToolImageBySitecreator extends Model {

  public function resize($filename, $width, $height, $type = '', $market = '', $text_for_market = '') {

    // +++++++++++++++++++++++++++++ комментарий от sitecreator.ru +++++++++++++++++++++++++++++++++++++
    // Для контроля времени создания файлов
    // используем везде filemtime() (Возвращает время последнего изменения файла)
    // использование filectime() не годится, т.к. в случае изменения файла время изменения меняется, но filectime() будет возвращать
    // "время создания файла" (в кавычках потому, что в Linux не существует такого понятия), точнее -
    // возвращает время изменения индексного дескриптора файла, что обычно совпадает с временем создания файла на сервере

    // https://www.php.net/manual/ru/function.filectime.php
    // Примечание. На большинстве платформ Unix, файл считается измененным, если изменены данные его индексного дескриптора,
    // что включает информацию о правах на файл, о его владельце, группе и другие метаданные, содержащиеся в индексном дескрипторе.

    // даже при полном изменении (перезаписывании или удалении) файла filectime() возвратит точно такое же значение как до изменения файла
    // если не менялись данные его индексного дескриптора
    // filectime() - это именно время изменения индексного дескриптора, но не содержимого файла.
    // filectime() использовался в opencart вплоть до 2.3 версии, что является принципиальной ошибкой, порождающей иногда многократные (бесконечные) попытки
    // перезаписи  файла в случае изменения (контента) исходного файла.
    // ---------------------------- комментарий от sitecreator.ru -------------------------------------------------------------------


    // +++++++++ отладчик +++++++++++++++++++++++++++

 

[sitecreator]

Напоминаю, что в модуле есть отладчик.

Который показывает с точностью до миллисекунды на что тратится время и что делает модуль.

Может показать вам битые исходники, которые не могут быть прочитаны.

Пользуйтесь!

 

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

 

Вы можете увидеть подробный отчет по каждому файлу изображения.

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

 

Кстати, проблема битого источника будет проявляться в любой сборке opencart. Будут бесконечные попытки при очередном открытии страницы обработать такой файл.

В актуальных версиях модуля Компрессор есть механизм, который не позволяет делать бесконечные попытки чтения битых файлов.

Например, при создании  изображений по расписанию, дается N-е количество попыток прочитать нечитаемое исходное изображение, по истечении таких попыток оно помечается как битое и дальнейшие попытки прекращаются.

 

Используйте актуальную версию модуля Компрессор!

 

 

 

 

В модуле есть медицинские средства, но которые не надо держать постоянно включенными:

 

[sitecreator]

Чисто для примера что такое битое исходное  изображение:

 

 

 

Внутри файла находится только часть изображения, а после этой правильной порции байтов идет далее хаотическая комбинация.

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

 

Кстати, imagick вылетает с фатальной ошибкой при попытке чтения подобных файлов.

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

Модулю Компрессор не страшна такая ситуация.

Обычные же классические решения, которые используют imagick, заканчивают выполнение скрипта с фатальной ошибкой.

 

Разумеется, что лишь с некоторым опытом использования я встречался с подобными редкими проблемами как битые исходники. И, соответственно, находил программные решения их устранения.

В ранних версиях модуля такая проблема также могла остановить выполнение скрипта.

Поэтому пользуйтесь актуальными версиями!

 

да, и назовите хоть одного разработчика, который работает с изображениями и учитывает подобные нюансы?

Я уже молчу про учет разных версий imagick (imagemagick), которые ведут себя различно. А некоторые хостеры до сих пор используют древние версии imagemagick вроде 6.* (6.3 например), в которых есть баги, давно исправленные в новых imagemagick.

В общем, приходится, мне отдуваться и за хостеров, которые не следят за актуальностью софта.

Но в модуле учтены особенности imagemagick различных версий 6.* и 7.*.

[sitecreator]

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

 

[sitecreator]

Информация по включенному режиму "отладка" в модуле.

Можно увидеть все проблемные места если они есть.

 

вот отладочная информация:

 

 

Видно сколько времени занимает обработка одного изображения и общее время для всех изображений.

Общее время: 0.003 сек

на одно изображение: 0.000165 сек

Это нормальная работа. На нормальном хостинге.

В этом случае на одну картинку тратится 1-2 десятитысячной секунды.

 

 

Вот показываю время на проблемном хостинге. Хостинг перегружен, на нем даже файловые операции медленные.

 

 

 

 

 

Видно, что на проблемном хостинге время на одно изображение уже 0.001, а иногда даже 0.02 сек

В итоге на 253 изображения потрачено времени 0.4 сек.

Изображений много, хостинг ужасный, в итоге - большие потери времени.

Проблемы отмечены цветом.

 

Любые проблемы с изображениями в режиме "отладка" будут показаны если они возникнут. А не только время выполнения.

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

 

Пожалуйста, пользуйтесь на здоровье и анализируйте!

К чему гадать на кофейной гуще? Перед вами объективный инструмент.

 

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

 

 

 

Вместо "асисяй" есть диагностика:

 

[sitecreator]

А вот теперь нормальный хостинг с нормальной нагрузкой.

400 картинок на страницу.

0.15 - 0.18 сек без кеширования на все картинки.

 

 

 

А вот и отдельные проблемы можно увидеть:

 

 

 

 

Нет файла-исходника.

И не нужно гадать а почему на странице картинка не отображается?

Так для нее нет исходного файла!

 

Любой проблеме можно найти объяснение. В том числе неотображающимся картинкам.

 

Страница с лимитом 100 товаров без кеширования на холодной загрузке за чуть больше чем 3 сек.

почти 400 изображений за 0.15 сек.

 

 

 

 

 

 

Т.е. в качестве примера взят вполне реальный магазин.

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

 

И никаких проблем с генерацией и выводом изображений WEBP в любом браузере!

Никаких проблем с Lazy Load.

И никаких проблем с совместным использованием кеширующего ускорителя (работает Jet Cache).

В режиме создания по расписанию WEBP вы вообще не заметите времени создания WEBP , т.к. это на скорости загрузки страницы никак не отражается.

 

Таково реальное положение вещей.

Возможно, что в испорченном "асисяй"-телефоне Полунина может быть иначе.

 

Если кто-то видит проблемы с изображениями на этом сайте или тормоза из-за изображений (webp в том числе) или что-то иное, возможно, что связанное с модулем Компрессор, то прошу сообщить мне и/или владельцу сайта.

 

По поводу недостаточности попугаев говорить бессмысленно в этом конкретном случае. Достаточно посмотреть сколько времени отжирает JS самого шаблона, например.  Какой JS - такие и попугаи.
 

Спойлер

 

 

[sitecreator]

Господа, нужна ли такая фишка как возможность задавать цвет полей для заливки, отличный от белого?

Например, на темных шаблонах черный цвет будет более уместный чем белый, который как бельмо выглядит.

 

 

 

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

 

 

 

 

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

[sitecreator]

В 1.18-й  версии будет много изменений.

 

 

 

 

Можно будет для JavaScript-ов, содержащих непосредственные данные об изображениях, также делать замену на webp вместо jpeg, png для вывода.

Столкнулся на одном из сайтов с довольно неуклюже написанном скриптом JS, который часть данных берет из картинок непосредственно, а часть записывает в свои переменные, т.е. в код на странице.  Такой программистский подход нельзя назвать удачным, а потому только замена webp в элементах DOM приводит несколько не к тому результату, который ожидался. Но модификация переменных в JS исправляет ситуацию.

 

В общем, модуль проводит намного более тщательный анализ изображений в самых разных местах, включая стили. Т.е. если используются в CSS заливки изображениями, то они также корректно обрабатываются и выводятся в webp (это работает дано уже).

 

Будет также добавлена возможность отключать вывод (и обработку) webp на конкретных страницах. На некоторых динамических она и так отключена, страница оплаты и т.п.

[sitecreator]

1.14.5 для Opencart 1.5

новая версия

[Anton4e]

Добрый день. Хотел бы прикупить на черную пятницу. Сейчас это цена со скидкой?

[sitecreator]

@Anton4e , здравствуйте. Пишите, пожалуйста, в личку по поводу скидки.

Проверьте свою личку.

[sitecreator]

Для Opencart 3.0 и Opencart 2.*

С поддержкой WEBP, Lazy Load и др.

Дистрибутив теперь универсальный (он один) для движка 2-й и 3-й версий.

Начиная с версии 1.18.3

 

Новая версия доступна для скачивания у разработчика.

сайт разработчика совпадает с ником разработчика:

 

 

 

Как скачать новую версию написано в FAQ модуля:

 

Где брать НОВЫЕ ВЕРСИИ модуля Compressor & Watermark & WEbP & etc?

[sitecreator]

Не имеет значения где вы купили модуль и для какой версии.

Вам будут доступны все дистрибутивы. Т.е. для движков опенкарт 1.5, 2.*, 3.0

 

 

Начиная с версии модуля 2.0  дистрибутив будет одинаковый для всех версий движков: 1.5, 2.*, 3.0

 

Сейчас два дистрибутива:

1) для opencart 2.* и opencart 3.0 единый дистрибутив начиная с версии модуля 1.18.*

2) отдельный дистрибутив для опенкарт 1.5

[sitecreator]

Сегодня столкнулся с ошибкой на одном из сайтов.  Белая страница или фатальная ошибка.

 

Цитата

Fatal error: Allowed memory size of 16777216 bytes exhausted...

 

что видим?

 

 

Памяти 16М?

Я меньше 128М не встречал за последние годы ни у одного хостера.

Катастрофически мало выделили.

[mcreper]

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

[sitecreator]

15 минут назад, mcreper сказал:

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

 

15 минут назад, mcreper сказал:

Добрый вечер.

 

Добрый!

А зачем нужно несколько разных кешей?

Если вы используете сжатие mozjpeg, например, то количество файлов в кеше будет не больше прежнего, может и меньше быть, но общий вес может снизиться процентов на 30%-40%, нередко на 50%. Совершенно точно, что суммарный вес будет существенно ниже.

 

будет сформирован новый кеш вместо старого.

В таком случае вам webp использовать не стоит, раз у вас " лимиты на inod ".

Правда, обычно меняют тариф или хостера подходя к такому пределу.

 

mozjpeg - это выход в вашем случае.

[mcreper]

Спасибо за быстрый ответ. Просто для себя еще хочу понять. Почему

Цитата

В таком случае вам webp использовать не стоит, раз у вас " лимиты на inod ".

 

Цитата

mozjpeg - это выход в вашем случае.

 

То есть mozjpeg перезапишет полностью кэш своим сжатым форматом, поэтому количество файлов не увеличится.
А если использовать webp, то кроме кэша с jpg создастся кэш с webp - я правильно понимаю?

[sitecreator]

15 минут назад, mcreper сказал:

То есть mozjpeg перезапишет полностью кэш своим сжатым форматом, поэтому количество файлов не увеличится.
А если использовать webp, то кроме кэша с jpg создастся кэш с webp - я правильно понимаю?

 

Совершенно верно.

И вы вправе выбирать сами необходимую вам стратегию создания сжатых изображений.

 

WEBP рекомендуется как основной вариант. Mozjpeg - как запасной.

Можно использовать также совместно Mozjpeg + WEBP в случае если мощности позволяют. Просто WEBP  в плане создания нагрузки на сервер в момент создания сжатого изображения имеет большой плюс в сравнении с Mozjpeg - это время создания, т.к. WEBP  работает раза в три быстрее при одинаковой эффективности (по сжатию) в сравнении с Mozjpeg.

 

У Mozjpeg тоже есть свои преимущества. У нас есть пока единственный современный браузер (точнее - система, а еще точнее - движок браузера), который не поддерживает WEBP. Это Сафари.   Вот ради него и нужны дубли картинок в JPG, PNG. Сжатый JPG (за счет Mozjpeg) тут будет кстати как раз. Вообще, apple из-за странной конкурентной политики лишает своих пользователей многих передовых технологий.

[splka]

Приветствую.
Вопрос - google search console вывалила ошибку для амр страниц:

Страница AMP - Нельзя использовать собственный код JavaScript

Когда я начинаю проверять чему именно плохо нахожу блок кода модуля ватермарка:
http://prntscr.com/q4cwxt
И по спеке амр страниц действительно нельзя использовать свой код js, только подключаемый с их сервера.

Модуль ватермарка вносит изменения во все шаблоны ../catalog/product/
Что делать в данном случае?
Я предполагаю фичареквест на вот такое поле:
http://prntscr.com/q4d06d