sitecreator
-
Posts
6,116 -
Joined
Content Type
Profiles
Forums
Marketplace
Articles
FAQ
Our New
Store
Blogs
module__dplus_manager
Everything posted by sitecreator
-
Итак, если у вас есть в кеше битые изображения, то модуль Компрессор способен в автоматическом режиме восстановить такие изображения. Модуль восстановит JPEG, PNG, а после сделает WEBP. Было вот так: А стало так: Модуль информирует о своей попытке: Данная возможность восстановления битых изображений доступна в версии модуля 1.12.11. Для ее корректной работы нужно на время отключить кешер (ускоритель). -
Я понял почему в моем случае webp получился "удачно" из битого PNG. Я использовал cwebp для Linux 3.10. В нем свежие библиотеки png, jpeg, которые умеют даже битые файлы перерабатывать. А у вас сервер старенький Linux 2.6, поэтому установленный cwebp (под старый Linux) не может переварить битый файл. И вообще не в состоянии записать файл. Кстати, GD и imagick тоже не могут записать WEBP. Но для них я уже сделал решение, которое позволяет избежать проблем с производительностью из-за этого. Да, реальная работа с графикой крайне сложна, учитывая огромный зоопарк всевозможных графических библиотек. Это вам не на php писать, где все предсказуемо. А тут даже cwebp одной версии, но под разные Linux, работает в случае исключительных ситуаций по-разному. Просто для cwebp 1.0.2 под Linux 2.6 используется библиотека libpng 6-й версии. Она и не умеет с битыми обходиться. А той же версии cwebp 1.0.2 под Linux 3.1 использует библиотеку libpng 8-й или 9-й версии. Вот тут и получается обходить проблему с битыми картинками более успешно. Сейчас придумаю решение. Хорошо когда все идеально. Написал короткий код строчек на 200, и все работает. Но как только встречаются реальные проблемные изображения, то код уже разрастается на 1000 -2000 строк. Только тот, кто работает с реальными сайтами, понимает насколько сложна задача в действительности.
-
Подумал, а не сделать ли учет битых и "кривых" изображений? Т.е. записывать информацию о них в БД чтобы потом заказчик мог просмотреть ее в админке и принять меры к исправлению. Но решил, что не буду этого делать. И так идут постоянные вопли, что модуль, мол, дорогой и т.д. и т.п. Словно никто не замечает насколько он усложнился и усовершенствовался. Разработка крайне сложная и дорогая получается. Не сравнить ни с каким иным модулем просто на php. Поэтому в случае битых файлов чтобы не генерировать постоянных ошибок и не пытаться многократно из битого сделать нормальный, файл (webp ) будет помечен как битый и дальнейшие попытки сделать из него нормальный webp будут прекращены. Остановился на таком (проверенном в более ранних версиях модуля в похожих ситуациях) варианте для битых файлов.
-
Модуль Компрессор в. 1.12.10 переварил нормально битый PNG и превратил его в такой же "недоделанный" WEBP. У меня ошибки при этом не возникло. Но тут уже возникают нюансы на стороне конечного движка, который создает WEBP. движок cwebp (под Windows) нормально переварил этот глюкнутый исходный (для создания WEBP) файл. А вот движок imagick (для WEBP) не смог это сделать и вывалился с ошибкой. Аналогично и GD не справился с битым входным файлом.
-
@yastman , пожалуйста, не цитируйте пост целиком. Читать проблематично когда идет повтор большого поста. Цитируйте нужное предложение.
-
я так и предполагал. вижу просто эпидемию таких неправильных файлов. Наблюдаю уже больше года. Проблему надо решать по-хорошему на стороне этого стороннего модуля импорта. Я в своем модуле не могу менять расширение файла, но могу сделать для него правильный тип (mime-type), что, собственно и делает модуль. Т.е. он делает из неправильного PNG правильный PNG в кеше. Только тут возникает проблема, что мы на пустом месте вынуждены превратить JPEG в PNG, и, тем самым, раздули в несколько раз вес файла. Сменить то расширение на jpeg, например, нельзя, т.к. название файла (хоть и с неправильным расширением) прописано в БД во множестве мест. Поэтому я могу лишь привести в соответствие расширение и внутренний тип. Это вынужденное увеличение веса потом компенсируется форматом WEBP. Но все же получается пустая трата ресурсов на голом месте. Сначала мы вынужденно превращаем JPEG в PNG огромного размера (а он всегда в несколько раз больше JPEG ). Потом вы еще этот PNG решите прогнать через optipng, который работает крайне медленно, но другой оптимизации для PNG не существует. И далее идет уже превращение PNG в WEBP, что тоже работает существенно медленнее чем JPEG -> WEBP. Т.е. видите, как на пустом месте вы нагружаете сервер дурной работой? А потом говорят, что модуль тормозит сайт? Может быть, не модуль, а тормозят дурные условия, в которые поставили модуль Компрессор? Просто иллюстрация как зависит время создания WEBP от формата и уровня оптимизации: Для PNG стоит защита "от дурака", 6-й уровень я не разрешаю включать для него. Всегда 4-й стоит, не более.
-
@yastman , проблемы начинаются вот с этого: Т.е. изначально ваш исходник формата JPEG, но расширение имеет PNG. Я с этим определенно борюсь, и успешно. Но местами выскакивают из-за этого глюки. Например, такой файл нельзя подсовывать программе optipng, ибо результат непредсказуем. Стараюсь на всех этапах это отслеживать. Не знаю откуда такая эпидемия пошла с исходниками. Почему они имеют расширение PNG? У вас есть объяснение на этот счет? Я думал, что это какая-то программа импорта делает такую гадость. Вы сами фотосъемку делаете или тоже импортируете извне? Легко делать софт из предположения, что все идеально.... Но такой софт не сможет работать в реальном мире. Реальные изображения полны неожиданностей и могут содержать в себе, что угодно. Встречал изображение, внутри которого была программа, объемом с "Война и мир".
-
лучше в личке решать. я посмотрю. Похоже, что какой-то файл не может быть прочитан. я вижу и такое тоже: Частная проблема. нужно разобраться, что именно с этим файлом. посмотрел. дело вот в чем: битый входной файл. об этом у вас и сообщение идет: Пока не удаляйте такой файл. Ранее я ставил защиту от подобного при создании JPEG. Было подобное когда исходники были битые. Добавлю и для webp тоже защиту от подобного. Кстати, модуль Компрессор, пожалуй, единственный, который учитывает проблемы реального мира, а не пытается решать задачи на идеальном сайте. За последнюю неделю решал массу проблем, например, когда HTML невалидный, в котором может быть несколько <body> или теги вроде <div> могут располагаться за пределами <body>/ В общем, в данном конкретном случае это не проблема модуля, но я ее решу.
-
Новая версия 1.12.10 основные изменения связаны с улучшением поддержки WEBP и Lazy Load.
-
Несовместимых я пока не встречал. Просто есть некоторые слайдшоу, к которым нельзя применить webp lazy load, а потому для них просто нужно прописывать отдельно исключение в коде JS. Большинство слайдшоу работают нормально с webp lazy load, но есть исключения, поэтому поступаем так: вся страница работает с lazy load, ну а для таких особенных слайдшоу просто грузим картинки сразу.
-
здравствуйте. Ответил, но спасибо глюкам форума, что ответ не дошел. Хоть форум и сохранил это сообщение. Переправил его вам в личку.
-
отличный хостер. а вы точно понимаете про что идет речь? про какое кеширование идет речь понимаете? и чем оно вредно понимаете? Сервер кеширует изображения. Какой в этом прок? А никакого, т.к. вес изображений от этого не уменьшается, а только нередко увеличивается (если оно было сжато уже за счет mozjpeg ) или остается прежним. Это в сравнении, например, сжатого JPEG за счет mozjpeg и отдаваемого сервером закешированного изображения. Увеличение веса (т.е. ухудшение характеристик изображения) есть в прежних версиях pagespeed, в актуальных пофиксили, т.е. хотя бы вреда нет от такого "кеширования". Но вы не можете заранее знать насколько свежий софт будет именно на вашей хост-площадке. дело в том, что сервер пытается сам улучшить уже улучшенные (за счет mozjpeg ) изображения, но не может этого сделать лучше чем сделал уже модуль Компрессор. Идет, в лучшем случае, пустая трата ресурсов сервера. Раньше в серверной части pagespeed была существенная ошибка, и за счет "кеширования" размер файла не уменьшался, а наоборот, увеличивался из оптимально сделанного за счет mozjpeg . В новых версиях этот баг пофиксили. Но размер за счет такого "кеширования" уже невозможно еще сильнее уменьшить. Вот это по сути лишь вводит в заблуждение, т.к. включается не кеширование в браузере (а оно и так работает), а включается алгоритм pagespeed, который куда хуже обрабатывает изображения чем это делает модуль Компрессор. Похоже, что у хостера какой-то глюк, но эта галочка включает оптимизацию за счет pagespeed. Спрашивается, а зачем вам нужен заведомо худший алгоритм? Почему при наличии гораздо более продвинутого алгоритма вы боитесь отключить заведомо худший? Плюсов от подобного "кеширования" при установленном Компрессоре вы не получите, но ничего и не потеряете. Остальные плюсы сделает модуль Компрессор.
-
Здравствуйте. Если подгрузка идет не в формате HTML, а, например, в JSON и потом добавляются новые элементы за счет JS, то тут ничто не поможет без адаптации кода шаблона. Но нужно заметить, что, как минимум, 90% шаблонов и модулей делают подгрузку именно в HTML, тут проблем не возникает. Т.е. webp lazy load совмстим с такими шаблонами сразу. Знаю авторов, которые используют ajax + json, с некоторыми достигнута договоренность о достижении максимальной совместимости. без правки кода шаблона/модуля тут никак не обойтись. Могу, конечно, со своей стороны делать ocmod для разных шаблонов. Но это большие затраты труда и мало кто сможет оценить полезность. Ведь как оценивают пользу в первую очередь? По поднятию баллов в гугул пейдж спид. А поскольку подгрузку гугл не делает, то большинство пользователей никак не оценят lazy load на подгружаемом контенте. Они будут упорно твердит, что "гугл не накинул баллы". Т.е. большинство заказчиков не смотрят на реальные удобства для пользователей, а смотрят лишь на баллы в момент эмуляции гугла загрузки на смартфоне. @SunnRi , можете скинуть в личку доступы. Я посмотрю. Сделать то можно все. Про то, что большинство это не оценят я написал выше. А если кому-то, действительно, нужна максимально возможная совместимость, то я готов сделать доработку. Вы можете доработать модуль "Image Compressor &..."под мои задачи? Сколько стоит?
-
здравствуйте. Это будет самый худший вариант. Надо только в одном месте включать, иначе возможны тормоза и не вполне предсказуемое поведение страницы в плане отображения изображений. умеет работать с обычным форматом (jpeg, png), не уверен, что сработает с webp. нужно проверить чисто экспериментом. Оставьте в модуле включенным вывод webp, но не включайте webp lazy load. И посмотрите как будет загружаться webp с "серверным " lazyload. По идее должно работать, но только при правильно настроенном сервере. webp lazy load, формируемый модулем, пока в стадии эксперимента. Чисто технически (визуально и т.д.) он работает, но сейчас идет работа по оптимизации скорости работы этого механизма. Пока просто вижу, что на разных шаблонах эффект различный с точки оценки гугла. Хотя выигрыш в весе всегда есть, и он очень хороший. Но у гугла также есть еще собственные заскоки в оценке lazy load, он и на собственные алгоритмы оптимизации нередко реагирует неоднозначно. Вы можете поэкспериментировать. Но одновременно включать не нужно. Я сам на данный момент экспериментирую с разными вариантами webp lazy load, т.к. по скорости работы они ведут себя различно на разных шаблонах, особенно учитывая шаблоны с подгрузкой данных (по скроллу, фильтру и т.д.). Ищу наиболее оптимальный и универсальный вариант. О ваших результатах экспериментов можете уведомить меня в личке. экспериментируйте на актуальной версии модуля. Сейчас доступна для скачивания 1.12.8.
-
Для пользователей модуля на Opencart 1.5.*. Возможна адаптация под движок 1.5 версии модуля 1.12.9+. Напомню, что сейчас самая свежая версия для 1.5 движка - это 1.8.7. В будущей (1.12.9+) версии для движка 1.5 возможно создание webp разными способами и его вывод средствами модуля, а также webp lazy load и т.д. В виду того, что на 450+ покупок доля покупок для 1.5 слишком низкая (было куплено около 15 лицензий за все время). А потому развивать модуль для 1.5 нет смысла, т.к. потраченное время никак не окупается. Но если у пользователей модуля для опенкрат 1.5 есть желание использовать версию модуля 1.12.9+, то требуется поддержка пользователей. Достаточно набрать сумму 6000 р (суммарно)., тогда я смогу потратить время на адаптацию под 1.5. Либо 2000 р. для индивидуальной (для одного заказчика) доработки версии модуля 1.12.9+ под опенкарт 1.5 . Если у вас есть иные предложения, которые могут побудить меня продолжить развитие модуля для движка 1.5, то готов их выслушать. Пока же развитие модуля для этой ветки не планируется, причины написал выше.
-
@VolodymyrHoshko , уже установлено.
-
Не волнуйтесь. все будет в порядке. Просто очередь из таких же желающих как и вы.
-
а это уже ваши настройки хромают. Некоторые у вас отдаются по http. Но тут webp никак не виноват, у вас с jpeg такая же ситуация. Вы это можете легко увидеть в старом браузере, например, в FF < 65, который не понимает webp . Также еще есть у вас проблема с установкой типа файла для webp. Нужно сделать правильные настройки на сервере самостоятельно или попросить хостера.
-
Пропозиції, побажання, новий функціонал, звіти про помилки
sitecreator replied to dinox's topic in Пропозиції та побажання
была такая возможность. недолго. и не во всех (???) разделах. но потом исчезла как и много чего другое хорошее. Вероятно, что эту фичу посчитали багом. Впрочем, тут легко запутаться, где баг, а где фича. -
в данном случае не это главное, а то, что файл отсутствует. а уж как там настроено для выдачи (апачи ли заведует или ngnix) - это имеет второстепенное значение, точнее, вообще не важно в данном конкретном вопросе. Но, по хорошему, nginx под webp в данном случае не настроен, что, конечно же, не есть хорошо. Т.е. работать то будет, но до определенной степени. Случай из разряда "и так сойдет, ведь работает же". Но тут возникает уже проблема со скоростью, что для больших проектов важно. И проблема с выставлением времени жизни кеша для webp. Это, похоже, не сделано на данном проекте.
-
Это другое дело. Но с webp он не связан. И если товаров много (а у вас их более 50 000+), то лучше дать сперва сформироваться кешу изображений, а потом уже включать создание webp. Так вы распределяете нагрузку равномерно во времени и избегаете ненужного всплеска. А ответ вполне очевиден почему не создается webp. Ни одного движка не было. Создавать то нечем было. Красным отмечено. Надо было всего навсего нажать одну кнопочку. И радоваться появившимся бабочкам: WEBP будет постепенно создан. На странице не сразу все изображения будут заменены на webp.
-
А кеш то зачем чистили? Чем вас он не устраивал? Вы же про кеш изображений говорите? Это ведь создание лишней и ненужной нагрузки на сервер. Потом кто-то жалуется, что сайт начал тормозить.... А крайне не рекомендую чистить кеш изображений если изображения в нем вас устраивают по качеству и т.п.. значит, были в чем-то невнимательны, скорее всего. От вас очень мало информации пока Пишите в личку сразу с доступами. Я покажу в каком месте вы ошиблись. Или в каком месте я ошибся. Пока я лишь вижу, что webp у вас не создается, т.е. самих изображений нет, а потому и выводить нечего. Вероятно, что не включили создание webp. Его же надо создать прежде того чтобы он "появился" в браузере. Вывод у вас включен. Проверяется, например, так: https://greenagri.ru/image/cache/catalog/import_files/cf/b18d5a74a6bac15e54d4bf40cc12007c-250x250.webp Отсутствует! Или посмотрите в папке с файлами изображений. А есть ли там WEBP? Если не появились, то и выводить нечего. Вот это у вас включено? И тесты движка webp пройдены успешно? Я не знаю как еще обратить внимание заказчиков на необходимость внимательно читать текст.
-
могу предложить вариант когда не нужно думать о кеше вообще. При этом будет наиболее продвинутый (ничто другое так не оптимизирует вес файла) формат WEBP, причем как для картинок в кеше, так и для картинок без кеша. Никакой ручной работы и перекачивания туда-сюда. Получите WEBP Lazy Load в придачу, гугл очень часто ставит это в приоритетные рекомендации по оптимизации изображений.
-
Новая версия 1.12.7. основные изменения связаны с улучшением поддержки WEBP и Lazy Load. WebP Lazy Load без проблем работает если у вас используется, например, бесконечная прокрутка. А также если ваш фильтр использует js ajax для подгрузки результатов выдачи, т.е. без перезагрузки страницы. Это довольно непростая задача как в плане формирования WEBP, так и его правильной выдачи в правильный браузер (в "неправильные", т.е. без поддержки webp мы отдаем jpeg/png). Особенно если учитывать, что могут использоваться ускорители (кешеры). Модуль компрессор успешно справляется с этой задачей и позволяет фильтру подгружать результаты (товары) на страницу, и при этом отдает WEBP с успешным использованием Lazy Load. Можно сказать, что существующие сторонние решения полностью проваливают данные задачи и неспособны выдавать и подгружать WEBP по мере необходимости, кроме того они легко могут оставить браузер вообще без изображений. Тут как-то интересовались чем же мое решение по WEBP лучше существующих? Ответ простой - модуль Компрессор просто работает, а сторонние решения - нет. По возможностям, а главное - по работоспособности WEBP почти на любом хостинге, с почти любым шаблоном и в любом браузере альтернативы просто нет. Задача полностью решена если подгрузка идет в формате HTML. Тут и совместимость с ускорителями. Если подгрузка товаров на страницу идет в формате JSON, то тут есть пока сложности с универсальным решением. Оно возможно если не используется ускоритель (кешеровщик). В противном случае (если работает кешеровщик) надо делать конкретную адаптацию под определенный шаблон. Никаких фатальных проблем нет, просто при подгрузке товаров в формате JSON средствами шаблона (а это уже совершенно нестандартно по отношению к движку) изображения подгружаются не в WEBP (как хотелось бы), а в JPEG/PNG. Пользователей VDS это не касается, у них никаких проблем вообще нет. Речь только про общий хостинг. Думаю, что с подгрузкой в JSON что-то придумаю. Один из вариантов (не универсальный) - это делать модификаторы под конкретный шаблон. Справедливости ради нужно сказать, что подгрузка в JSON - это довольно нечастое явление. И, повторюсь, что визуально никаких проблем не возникает. тут мультик в 10М показывающий работу WEBP Lazy Load в случае бесконечной подгрузки. Заказчики, хоть немного разбирающиеся в этих технологиях меня поймут. Ну а юношам, мнящим себя программистами, думаю, что это будет очень сложно для понимания.
-
Новая версия 1.12.6 доступна для скачивания. Из полезного: Вы можете выбирать кроме параметра Качество еще и уровень оптимизации если используете для создания WEBP движок cwebp (http_cwebp). Данный движок (для создания WEBP ) вы легко установите нажатием одной кнопки в модуле Компрессор, работает под любой версией Linux. И это возможно примерно на 97% хост-площадок (везде, где есть функция proc_open php). оставшиеся 3% пользователей могут использовать для WEBP библиотеку GD или imagick, или движок http_cwebp (работает везде, где разрешены cgi-скрипты). движок http_cwebp будет добавлен немного позже. Разница в весе файлов между самым быстрым (0) и самым медленным (6) способом создания WEBP составляет в среднем 30% для JPEG. Модуль Компрессор дает вам возможность гибко учитывать ваши потребности и возможности (мощность сервера). Вы можете при нехватке мощности очень сильно уменьшать время генерирования WEBP раза в два и больше. А если мощности достаточно, то можете выжать из формата WEBP все по-максимуму! Ни одно решение не обладает такой гибкостью, какую предлагает модуль Компрессор. Главное - это разумный, а не бездумный подход.
