sitecreator
-
Posts
6,116 -
Joined
Content Type
Profiles
Forums
Marketplace
Articles
FAQ
Our New
Store
Blogs
module__dplus_manager
Everything posted by sitecreator
-
Информация устарела отчасти, т.к. используется сейчас для вывода такой формат файлов: MacBookAir-1140x380.jpg.webp dvuhpodves1-75x75.png.webp Информация годилась для старых версий модуля, когда формат был такой: MacBookAir-1140x380.webp dvuhpodves1-75x75.webp Если подойти осмысленно к информации, то можно ее применить с соответствующими изменениями. Рекомендуется как основной способ вывода webp в браузер. https://opencartforum.com/topic/89012-podderzhka-image-compressor-watermark-webp-etc/?do=findComment&comment=1315595 Все настройки сервера вы делаете на свой страх и риск, ибо обязаны их делать с пониманием, а также должны учитывать нюансы, которые могут иметь место. Не надо что-то делать чисто механически! Всегда перед изменениями делайте копии файлов. Это особенно касается файлов конфигурации. В случае проблем делайте откат, т.е. возвращайтесь к рабочей конфигурации, файл которой вы сохранили. Вот тут еще важное дополнение: Просьба воспринимать данные рекомендации как руководство к действию, а не как 100% законченную инструкцию. Вот так не должно быть: Напоминаю, что когда рассматриваете попугаев в гугле, то не смотрите тупо на баллы. Не забудьте глянуть установлено ли у вас время жизни кеша для WEBP. Не кричите сразу, что гугл не накинул баллы за WEBP. Если у вас не включено кеширование для WEBP, то гугл может еще и снизить баллы в некоторых случаях. Будьте, пожалуйста, разумны! Я уже встроил в модуль автоматическую генерацию .htaccess для случая когда апачи будет отдавать webp в браузер. И это спасает ситуацию с кешированием WEBP в 80% случаев. Но если у вас все же настроен nginx на отдачу webp в браузер, то вам нужно вручную прописать правила кеширования WEBP в конфиг nginx. Прежде чем делать вывод, что "не оптимизирует", пожалуйста, сделайте оптимизацию WEBP полностью. Модуль Компрессор не имеет возможности сделать за вас ваш конфиг nginx для WEBP.
-
будет возможно после решения более приоритетных задач. прошу заметить, что на данный момент в актуальной версии модуля создание сжатого jpeg происходит раза в три быстрее чем в версии 1.8.*. и это на лету. Т.е. нагрузка на ресурсы значительно снижена уже. -
сразу после реализации генерирования webp за счет cgi-bin скрипта. т.е. скоро. Но на практике особой пользы от работы по расписанию для создания webp не очень много если даже товаров несколько тысяч, т.к. webp создается очень быстро и так. А в модуле есть режим "щадящий на лету" для создания webp, в этом случае он не создается одновременно с jpeg чтобы не делать лишнюю нагрузку, а начинает создаваться лишь когда jpeg, png уже готов. В общем, нынешний режим работы webp почти не грузит систему. И не требует очистки кеша изображений. Системный (кешеровщика) нужно очищать.
-
по вашему скриншоту видно, что зашли вы не по правильному адресу. не надо пытаться зайти по адресу /admin/ Заходите в точности по ссылке. И если делаете скринштот, то делайте его полным вместе с адресной строкой. Вот так: Пожалуйста, будьте внимательны. Красным специально для вас обвел место, куда нужно смотреть. Все работает. И еще раз правильный адрес для входа в демку админки модуля: Демо 2 (админка): http://watermark.sitecreator.pro/admin/index.php?route=extension/module/watermark_by_sitecreator пользователь: DEMO пароль: DEMO Вы просто зашли сюда:
-
работает. просто непонятно с какой целью вы пытались что-то смотреть за пределами настройки модуля Компрессор. Там вы ничего и не увидите. У вас есть прямая ссылка для входа в админку модуля Компрессор. Демо 2 (админка): http://watermark.sitecreator.pro/admin/index.php?route=extension/module/watermark_by_sitecreator пользователь: DEMO пароль: DEMO как угодно можете сделать. без проблем. делайте непрозрачный. или прозрачный с любой степенью прозрачности. Подготавливайте водяной знак в JPEG. и накладывайте. будет непрозрачно как вам нужно. ставите параметр в 100 в модуле, и будет непрозрачный.
-
Для работы программ сжатия mozjpeg, optipng необходимы незаблокированные функции php proc_open и proc_close . (exec не нужна в новых версиях) Для webp эти функции также желательны, но с версии 1.12.0 они не являются обязательными, т.к. есть варианты работы и без них. Если у вашего хостера панель управления cPanel, то снять блокировку можно так. Заодно включите imagick. В строке запрещенных функций будут перечислены такие функции. Ваша задача - убрать из этого списка proc_open и proc_close тогда в модуле Компрессор вы увидите подтверждение:
-
Показываю часть проблем, которые не решаются просто сжатием или использованием формата WEBP. Нужно обращать внимание также на проблемы, которые напрямую связаны с версткой. Гугл снова меняет свои алгоритмы оценки. Впрочем, он это делает постоянно. Изменения незначительные. Но некоторые рекомендации гугла я не смог объяснить. Он ругается на неверно указанные размеры картинки из CSS (фоновое изображение). Картинка крохотная. Но я не смог понять, где же именно гугл увидел " Invalid image sizing information ". Возможно, что он не смог получить эту информацию из самой картинки. Т.е. она неверно прописана в файле картинки. Но это картинка из шаблона. Не я ее делал. Возможно, что еще какой-либо глюк, включая глюк самого гугла.
-
Если у кого-то нет и 4-го способа (cgi-скрипты запрещены), то будет еще 5-й способ. Самый универсальный - через cron. Т.е. охват хост-площадок приближается к 99.9%
-
Подготовлена новая версия модуля Компрессор 1.12.0 В ней есть принципиальные новшества. Возможностью создания WEBP и его вывода могут воспользоваться пользователи хостингов, у которых: 1) нет функции exec (proc_open) php. Т.е. она заблокирована и нет возможности запускать cwebp 2) нет GD с поддержкой WEBP 3) нет imagic с поддержкой WEBP Вот нет всего разом из вышеперечисленного. Т.е. нет ни одного доступного способа для генерирования WEBP. Это не является ограничением. Вот для таких пользователей хостинг-услуг я предлагаю 4-й возможный способ генерирования WEBP: 4) создание WEBP через использование возможности запуска в папке cgi-bin соответствующей программы, написанной мною на языке Си. Разумеется, что программа скомпилирована в бинарный файл. У себя в модуле Компрессор я назвал такой режим http_cwebp. обычно у хостера такая поддержка заявлена примерно так: Обычно любой из выделенных пунктов как раз и означает запуск cgi-приложений в папке cgi-bin. А вот это означает, что такой поддержки нет: В общем если у вас сейчас нет возможности использовать сжатие изображений из-за ограничений возможностей хостером, но есть возможность запуска cgi-скриптов ("скриптов"), то новая версия модуля вам может помочь. Ищу желающих предоставить мне возможность сделать тест нового метода на вашей хост-площадке. На своих серверах уже все протестировано. Сырой не могу назвать данную версию модуля, т.к. все наработки перешли из предыдущей версии + добавлен новый режим работы. Мне необходимо лишь уточнить некоторые нюансы. Новый метод работает на любой Linux с ядром от 2.6+, т.е. самые древние участвуют. Пишите в личку если есть желание.
-
Так для компьютера РК-86 комплектующие покупались мною.
-
Кстати, в СССР выпускалось очень много всяких тематических творческих наборов для детей. Например, у школьного друга был большой набор "Юный химик". После школы часто ходили химичить. Необыкновенно увлекательно было.
-
Так тоже хорошее дело. А у меня прямо по дороге из школы домой находился магазин "Юный техник". И был в нем отдел электронных комплектующих. И продавались там в том числе всевозможные неликвиды в основном с военных заводов и т.п. Просто сказочное место было для нас мальчишек. Резистор ВС (кто знает: зелененький "влагостойкий") стоил 1 (одну) копейку. Потому как неликвид, а так он стоил 3 копейки. МЛТ коричневые стоили уже 3 коп. МП42, кт315.... Для всяких поделок вроде цветомузыки и доморощенных "синтезаторов" деталей хватало. Тогда под словом "мультивибратор" понималось совсем не то, что сейчас подумали бы некоторые.
-
Кто в советском счастливом детстве собирал приемник Юность на 4-х транзисторах? Инструкция к нему - это отдельный шедевр.
-
WebP без тяжелых модулей
sitecreator replied to stickpro's topic in Opencart 2.x: Setting and optimization
у меня, к примеру, все работает в моем модуле. Совместимость продумана. И в новой версии webp создается всегда и везде у любого хостера. Даже если у хостера запрещен exec, нет GD (или imagick) с поддержкой WebP, то все равно webp может быть сгенерирован на такой хост-площадке без проблем и лишней нагрузки. Т.е. от хостера вообще ничего не требуется по большому счету. И модуль, который "рабочий на 90%" полагается лишь на софт, который предоставит хостер. А это бывает лишь в 5% случаев. В остальных случаях хостеры ничего не предоставляют. Я так понимаю, вы ищите "почти работающий" или "немного неработающий", но зато бесплатно? Работающий практически везде, но за небольшую стоимость в расчет не берете? -
шаблон и ваше ТЗ? шаблон выбираться должен по визуальным предпочтениям. А функционал уже далее добавляется согласно вашему ТЗ. способы оплаты, доставки, проверки онлайн почтовых отправлений тоже в "шаблоне" пытаетесь найти? Как и где вы пытались увидеть "реальные" магазины. И как вы пытались их оценивать7 для вас стоимость магазина == стоимости шаблона? или нет? уверены, что все необходимое? И последующая поддержка не нужна и она вам будет стоить 0 рублей в год? Может быть стоит начать с ТЗ? вы сравниваете стоимость лицензии битрикс на год (73 000) со стоимостью создания магазина? Вы же получаете просто лицензию, а не готовый магазин за 73 000 рублей на первый год. Разве не так? Вы уверены, что легко сами сделаете магазин на битриксе без дополнительных трат? И что же отключат в битриксе если мы не продлим лицензию на следующий год? Лишь малая часть процитирована: "магазин" на битриксе если не продлить лицензию будет работать без служб доставок? Вероятно, что будет если магазин ничего не доставляет почтой и т.д. вот затраты на продление:
-
Пропозиції, побажання, новий функціонал, звіти про помилки
sitecreator replied to dinox's topic in Пропозиції та побажання
ну это еще не самое страшное, что могло быть в блоге. Я бы сказал, что это относительно безобидный спам. Кто-то использует "блог" как объявление чтобы сообщить миру о своих планах на вечер или поездке куда-то там. Думаете, что это кому-то интересно и полезно? По крайней мере это безобидно. Хуже когда блог создается ради срача и кидания какашками в разработчиков, которых "блогер" "не любит". Причем, формат то великолепный! Пиши, что хочешь, а посты оппонентов можешь просто удалять если они не нравятся и мешают раскидывать говняшки на вентилятор. Гениально просто! Чтобы ни написал, то будешь прав, а если упрекнули тебя в неправоте, то можешь просто удалить пост негодника. То, что действительно интересно разработчикам, может быть вообще даже не для публики. -
Выполнение рекомендаций гугла в плане снижения веса изображений и оптимизации их загрузки не всегда равно попаданию в зеленую зону гугла. Модуль Компрессор оптимизирует вес ваших изображений. И делает это хорошо, за исключением крайне редких случаев когда есть ограничения со стороны хостера, которые невозможно обойти. В 99% случаев на хост-площадке программное обеспечение по сжатию изображений работает без проблем. Режим работы по расписанию для создания webp позволяет обойти практически любые ограничения хостеров, т.е. работа сжатых форматов доступна почти у 100% хостеров. Оптимизация в Компрессоре направлена именно на выполнение необходимых рекомендаций гугла по изображениям. Друзья, не стоит ожидать чудес от снижения веса изображений если в остальном все плохо. Снижения веса - это необходимое условие для достижения зеленой зоны, но не всегда достаточное. Причем снизить вес вы можете путем удаления картинок вообще. Но абсурдные пути мы, конечно, не будем рассматривать. Немного аналогии. Есть автомобиль с лысой резиной и убитым движком. Заказчик ставит новую шикарную резину и... остается недовольным! Почему? Говорит, что автомобиль плохо едет. А двигатель чинить не надо? Вот также и с оптимизацией изображений. Вес изображений уменьшили втрое, а автомобиль не едет гугл мало накинул баллов? А двигатель JavaScript не судьба проверить и починить? Чем я могу тут помочь заказчику? Вот у него JavaScript крутится 6 секунд, да еще 4 секунды разбирается огроменный CSS чтобы окончательно сделать рендеринг HML. Но почему-то заказчик своим долгом считает иногда упрекнуть меня, что гугл плохо реагирует на оптимизацию изображений? Плохо? Да он перестал ругаться на изображения, баллов сверху накинул, но продолжает еще ругаться на JavaScript !!! Уважаемые заказчики, а почему вы не смотрите на все рекомендации гугла, а только на конечные баллы? Должен ли я и за ваши тормозные JavaScript отвечать тоже? Призываю все же к разумному подходу, и не требовать при установке свежей резины на автомобиль превращения его в гоночный болид при том, что движок у него убит. Резина - это важно и необходимо, но этого недостаточно. Кто-то ожидает хорошей скорости на убитом двигателе, хоть и с отличной резиной? Как нам тут разогнаться с убитым двигателем тормозым JavaScript ? ============================ Могут быть также такие проблемы, которые не относятся к снижению веса изображений путем сжатия. Решаются они путем правильной верстки. (В большой степени эта проблема уже решена в версии 1.14.0+ См. ниже. В подавляющем большинстве случаев этого достаточно для оптимизации больших по ширине изображений) Пожалуйста, призываю оценивать ситуацию с позиций здравого смысла. Просто сжатие тут не поможет поскольку есть более важный фактор - ширина изображения. Если вы отдаете смартфону (экран 360 пикс) картинку шириной 1920 пикс, то, что вы ожидаете от гугла? Гугл не понимает для чего при ширине вьюпорта 360 пикс (480 пикс) загружается картинка шириной 1920 пикс. И гугл прямо говорит об этом в своих рекомендациях. Гугл намекает про то, что надо бы для разных экранов отдавать соответствующие картинки. И решается это именно версткой. В версии модуля 1.14.0+ есть решение и вопроса больших баннеров и т.п. Можно задать создание изображений уменьшенной ширины (740 пикс) специально для смартфона. Тогда вместо баннеров 1920 пикс будут загружаться баннеры 740 пикс. 740 пикс выбрано из соображений отображения картинки в пейзажном режиме на смартфоне на всю ширину. Вот так не должно быть: Напоминаю, что когда рассматриваете попугаев в гугле, то не смотрите тупо на баллы. Не забудьте глянуть установлено ли у вас время жизни кеша для WEBP. Не кричите сразу, что гугл не накинул баллы за WEBP. Если у вас не включено кеширование для WEBP, то гугл может еще и снизить баллы в некоторых случаях. Будьте, пожалуйста, разумны! Я уже встроил в модуль автоматическую генерацию .htaccess для случая когда апачи будет отдавать webp в браузер. И это спасает ситуацию с кешированием WEBP в 80% случаев. Но если у вас все же настроен nginx на отдачу webp в браузер, то вам нужно вручную прописать правила кеширования WEBP в конфиг nginx. Прежде чем делать вывод, что "не оптимизирует", пожалуйста, сделайте оптимизацию WEBP полностью. Модуль Компрессор не имеет возможности сделать за вас ваш конфиг nginx для WEBP.
-
верно. точнее, на геометрический размер (ширина, высота). Ведь нет смысла грузить баннер шириной 1900 пикс на смартфон, у которого ширина вьюпорта ("виртуальный экран") 360 или 480 пикс, например. Что же касается конкретного сайта, для которого привел выше результат, то на изображения гугл не ругается, но поскольку HTML формируется за 3 сек (перегруженность запросами в БД), то в данном конкретном случае это решает все. Если у вас будет все остальное идеально и вес всех изображений даже будет равен 0 (НУЛЮ), то при отклике в 3 сек зеленая зона (90+) пока этому сайту не светит. Но общую оценку гугла все же подняли даже при таком тупом отклике. Друзья, не стоит ожидать чудес от снижения веса изображений если в остальном все плохо. Снижения веса - это необходимое условие для достижения зеленой зоны, но недостаточное. Причем снизить вес вы можете путем удаления картинок вообще. Но абсурдные пути мы, конечно, не будем рассматривать. Немного аналогии. Есть автомобиль с лысой резиной и убитым движком. Заказчик ставит новую шикарную резину и... остается недовольным! Почему? Говорит, что автомобиль плохо едет. А двигатель чинить не надо? Вот также и с оптимизацией изображений. Вес изображений уменьшили втрое, а автомобиль не едет гугл мало накинул баллов? А двигатель JavaScript не судьба проверить и починить? Чем я могу тут помочь заказчику? Вот у него JavaScript крутится 6 секунд, да еще 4 секунды разбирается огроменный CSS чтобы окончательно сделать рендеринг HML. Но почему-то заказчик свои долгом считает иногда упрекнуть меня, что гугл плохо реагирует на оптимизацию изображений? Плохо? Да он перестал ругаться на изображения, баллов сверху накинул, но продолжает ругаться на JavaScript !!! Уважаемые заказчики, а почему вы не смотрите на все рекомендации гугла, а только на конечные баллы? Я что, должен и за ваши тормозные JavaScript отвечать тоже? Призываю все же к разумному подходу, и не требовать при установке свежей резины на автомобиль превращения его в гоночный болид при том, что движок у него убит. Резина - это важно и необходимо, но этого недостаточно. Кто-то ожидает хорошей скорости на убитом двигателе, хоть и с отличной резиной? Как нам тут разогнаться с убитым двигателем тормозым JavaScript ?
-
не стоит этому верить и, тем более, ставить приложения. шарлатанство это. можно верить рекомендациям поисковых систем (яндекс, гугл), да и то, со здоровым скептицизмом, а не воспринимать все буквально как истину в последней инстанции.
-
интересно, а где такое делают? я про проверку говорю. и вы уверены, что ваш проверяльщик сам не нуждается в устранении ошибок? Почему вы решили ему верить когда он пишет несоответствующие действительности диагнозы?
-
Разница при использовании разных способов оптимизации (сжатия). Пример использования на конкретных цифрах вполне конкретного сайта. До. Изображения не сжимались. вес 4.52 Мб До сжатия: 4.52 Мб После применения mozjpeg + optipng: 3.36 Мб WebP формат: 1.88 Мб Итого, суммарный вес уменьшился в 2.5 раза благодаря формату webp.
-
вот вам для сравнения. Видно, что в случае работы Компрессора четкость не пострадала. Особенно заметно на лице и надписях. Дотошный заказчик сразу обратит на это внимание. Работа с графикой - это сложная задача. И понимающий заказчик думает не просто о конечном весе изображений, но и беспокоится о его качестве. Ваш покорный слуга предлагает профессиональное решение, которое уже оценили заказчики, которые сами делают фотосъемку и обработку фотографий. Было потрачено огромное количество времени чтобы на выходе вы получали результат, близкий к идеальному.
-
Немного информации для тех, кто понимает и видит. Видите насколько упало качество после оптимизации за счет других решений? Прошу заметить, что модуль Компрессор не позволяет допустить такого резкого ухудшения качества картинки. Повторюсь, что это работа стороннего решения. Вот (НИЖЕ) как это делает модуль Компрессор. Сравните Качество на входе и выходе. А также размер. Изображение на входе (71К): На выходе JPEG (обычный) 21К: В виде ссылки: http://watermark.sitecreator.pro/img_test/3/barb-1280-320x490.jpg На выходе после Компрессора формат WebP (9К): В виде ссылки: http://watermark.sitecreator.pro/img_test/3/barb-1280-320x490.webp
-
1.11.3 BETA 3 Сделаны улучшения, касающиеся вывода webp.
-
Изображения в формате webp
sitecreator replied to cyberkekc's topic in Opencart 2.x: Setting and optimization
и это правильно! Тем самым избежите ненужных в ваш адрес слов в случае возникновения проблем у конечного пользователя. А экспериментируют пусть на здоровье!
