sitecreator

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

Смотрим какие заголовки отправляет браузер на сервер при ожидании документа HTML: браузер Хром: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3 а вот браузер FireFox: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Вот же ж печаль, досада! Этот браузер не отправляет при получении HTML никакой информации про webp. Он эту информацию отправляет только при запросе изображений. И что же мы тогда ищем, используя php? if( strpos( $_SERVER['HTTP_ACCEPT'], 'image/webp' ) !== false ) @stickpro , ваша же строчка? Не знали, не учли? Ну, бывает..... А в других браузерах кроме Хрома смотрели, мож там тоже какая "засада" кроется? В браузере от майкросфт тоже такой же принцип отправки запроса на сервер как у FF, но кто им пользуется то, не смотря на поддержку webp? Прошу заметить, что мы и так условно считаем, что у нас на сервере есть апачи, и именно апачи обрабатывает изображения, доступны на сервере EXEC и собран хостером cwebp, который разрешено использовать в виде короткой команды. Т.е. и так мы уже рассматриваем довольно редкую комбинацию звезд на небосклоне. Так к этому еще добавляется, что и не в любом браузере работает, который поддерживает webp? Зато бесплатно, зато без "тяжелых модулей". Честно говоря, мне сложно судить в скольких случаях из 100 решение будет работать. Я обратил ваше внимание лишь на 2 принципиальные проблемы, которые не позволяют получить результат в подавляющем большинстве случаев. Не считаю нужным смотреть в сторону мелких ошибок, которые также могут привести не к тем результатам, которые ожидались. Они, с одной стороны, мелкие, а с другой - они сводят на нет собственно функцию данного решения и приводят лишь к пустому пожиранию пространства жесткого диска или SSD без ожидаемого результата. Знаете, вспомнилась (вроде бы к месту) поговорка про соринку в чужом глазу и бревно в собственном. Вот когда сможете разобрать лесоповал и бурелом в собственном коде, то тогда, возможно, что сможете указывать другим на их песчинки. Но прежде обязательно проверьте, а не торчит ли у вас где-то бревнышко снова. Итак, каков итог? Есть код, который работает при определенных условиях на сервере и только в случае если конечный пользователь использует определенный браузер, а не любой, поддерживающий webp. Считаю, что в целом это достойный результат. Отчего ж не пользоваться?

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

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

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

не стесняйтесь, спрашивайте, что именно вам непонятно, я еще раз повторю. какое именно предложение неясно? вы не поняли про nginx? Так я поясню, не проблема. Вы не получите на общем хостинге доступ к конфигу nginx. Я вас спрашивал в надежде, что вы знаете какой-то способ обойти это ограничение. Ну, а вдруг? вам непонятно вот это утверждение в вопросительной форме? даже не знаю уместно ли спрашивать вас знакомо ли вам такое понятие как "риторический вопрос"? тут же пояснил сразу: Еще раз: способ, который вы выбрали не имеет в общем случае решения на общем хостинге из-за его особенностей. В подавляющем большинстве случаев у пользователя нет никакой возможности контролировать обработку изображений сервером. Общий случай я подробно уже описал выше (это nginx+ апачи. Статикой заведует именно nginx) Есть исключения и для таких хостеров, но это все же редкость, мы же вроде бы рассматриваем универсальный вариант.

и гугл посчитает реальное время загрузки страницы для этих устройств от Apple. А не будет обращать внимание на съэмулированные баллы. Баллы во время эмуляции - это лишь примерная первичная оценка гугла. Он всегда ориентируется в конечном счете по реальным показателям, полученным из статистики. У хостеров на общем хостинге еще бывает неприятность. Это ограничение по нодам, грубо говоря вам дают 20Гиг диска, но только 10 000 нод. Т.е. кол-во файлов у вас лимитировано. И его хватает пока у вас только JPEG, например, сжатый, а на webp уже нод не хватает. Вам ведь нужна пара файлов в таком случае. Это мне один заказчик поведал. На практике всегда не все так гладко как в теории. А потому этот заказчик сказал, что его отлично устраивает мой сжатый JPEG за счет mozjpeg.

@stickpro , интересно, в как апачи сможет отдать картинку если у вас работает, например, nginx + апачи, что бывает в 99.9% случаев на общем хостинге? У вас же ее апачи отдавать собрался? Тоже самое касается случаев чистого nginx. В 99.9% случаев именно nginx отдает картинки. Апачи даже понятия не имеет, что в природе существуют картинки. До апачи даже запрос от браузера не доходит, его обрабатывает nginx. И только nginx видит вот это: HTTP_ACCEPT: image/webp Апачи никогда его не увидит, только в случаях: 1) если у вас работает только апачи, что является крайне непроизводительной схемой работы сервера. На общем хостинге вы вряд ли такое встретите. VDS, настроенные кое-как в расчет не берем. 2) если хостер позволил вам переключить обработку статики с сервера nginx на апачи. Но таких хостеров можно по пальцам пересчитать. А во-вторых, это будет снова непроизводительная схема, т.е. заведомо понижается производительность. Т.е. улучшается одно за счет ухудшения другого. Конечно, чисто для эксперимента это годится. Кстати, открою секрет, что никакого кода php не нужно чтобы апачи отдавал webp если апачи обрабатывает статику. И вы напрасно изобретали велосипед на php. Этот код давно известен, и у меня он тоже открыто опубликован прямо здесь на форуме: # Check if browser support WebP images RewriteCond %{HTTP_ACCEPT} image/webp # Check if WebP replacement image exists RewriteCond %{DOCUMENT_ROOT}/$1.webp -f # Serve WebP image instead RewriteRule (.+)\.(jpe?g|png)$ $1.webp [T=image/webp,E=accept:1] <IfModule mod_headers.c> Header append Vary Accept env=REDIRECT_accept </IfModule> AddType image/webp .webp <FilesMatch "\.(jpg|jpeg|gif|png|ico|webp)$"> Header set Cache-Control "max-age=2592000, must-revalidate" </FilesMatch> да, в вашем случае (даже если все заработает), то гугл будет еще ругаться, что у вас изображения не кешируются в браузере, и снизит за это вам оценку. Но на такие мелочи, думаю, что не стоит даже обращать внимание. давайте будем исходить из того, что у 95% пользователей все же не VDS, а общий хостинг, и нередко с отключенным exec. Там, где VDS - там нет ограничений никаких, но это слишком малый процент пользователей. главное чтобы каждый хостер предоставил возможность пользоваться сwebp. Таймвеб уже предоставил? Помню, давеча вы таймвеб приводили в качестве примера. Можете показать как сайт на таймвебе отдает страницы с картинками в формате webp?

Вообще, взлом, порой, происходит даже с соседнего аккаунта. Скорее всего, не наш случай. Но у меня был такой опыт. Когда для вполне уважаемого хостера (и даже рекламируемого здесь) я получил root-доступ на аккаунте обычного пользователя. Разумеется, что описывать способ не буду, это вообще не для паблика. Но у этого же хостера я также получал доступ (без root) к сайтам других аккаунтов за счет не вполне грамотной настройки сервера Мемкешт. Т.е. банально мог читать (и подменять) "файлы" (в Мемкешт) на совершенно посторонних аккаунтах. Беседа с хостером на эту тему не дала результата, хостер не проникся идеей грамотного разделения доступа к серверу Мемкешт для разных пользователей (аккаунтов). В моем модуле Компрессор (https://opencartforum.com/files/file/4572-image-compressor-watermark-webp-etc/) есть контроль за мемкешт-ключами. Если вы видите левые ключи, то знайте, что это ключи другого пользователя. Т.е. вы имеете доступ к чужим ключам и, соответственно, кто-то имеет доступ к вашим. Рассказываю не как гипотетическую ситуацию, а как реальную проблему, которая приключилась с одним из заказчиков.

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

а сможете объяснить для чего это нужно? гугл, наоборот, советует удалять все метаданные, т.к. они для небольших (и не только) изображений могут занимать приличный вес. Кстати, встречал изображения размером в 10 Мег, в которых полезного веса было лишь 50К, а остальное - метаданные и прочая лабуда. Вот прямо совсем недавно с заказчиком разбирали такой феномен. Сделать можно если изложите задачу более подробно. Но дешево не обещаю индивидуальную разработку. Поэтому если ищите готовое дешевое решение, то это не ко мне. И есть сомнение, что вы его легко найдете, я не встречал, например. в принципе мог бы встроить в :

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

тут, понимаете ли, все как с учебником по высшей метаматематике. Вроде бы учебники все есть в открытом доступе, как говорится, читай и изучай сколько душе угодно, но не всем это по силам. Что толку если вы вызубрите доказательство одной теоремы, но не сможете самостоятельно доказать другую? Я, конечно, в определенной степени утрирую, но хотел бы сказать, что нет какого-то универсального рецепта, который вы быстренько выучите и вам откроется познание той же высшей математики. Тут сам предмет нужно понимать глубоко, а для этого нужно потратить немало времени на его глубокое изучение. Хотите стать экспертом в этом вопросе? Становитесь! Но просто по советам с форума вы им не станете. Возможно, что у кого-то есть пример успешного опыта без глубокого изучения вопроса и погружения в тему? Допускаю такое, но я не встречал таких людей.

а что за секретный модуль? И, таки да, в БД может также содержаться код php, который может выводиться в разных модулях. вообще, правильно это делается либо в конфиге nginx, либо в конфиге апачи (.htaccess). Как правильно сменить урл админки я тоже выше написал.

согласен. Не могу работать с маленькими мышами. А сейчас беда просто с этими мышами - сплошь и рядом "мыши для ноутбуков" (т.е. маленькие). У самого проводная Ventus Z сейчас. Под номальную мужскую ладонь. У них именно Z - большая/ Thermaltake Софт мыши неидеален. Но форма удобная, хоть и не до всех кнопок дотянуться можно без уставания пальцев. А вообще ничего лучшего не встречал чем старые версии некоторых a4techA. У меня много лет. Специально заказал новое колесико и микрики на алиэкспресс. После перепайки снова как новая. Есть также еще сейчас у меня беспроводная Logitech под хорошую мужскую ладонь и полный хват. Но мне несколько неудобна она, т.к. слишком она выпуклая вверх. В общем, мышей у меня целый зоопарк. Дорогих (по 6000 руб) хватает, но не всеми удобно пользоваться. Всегда выбираю какую-то одну, а прочие просто лежат. И цена - не показатель удобства и надежности.

способ развода. Потом придет другой другой хакер и предложит тоже самое, т.е защиту "на века" от предыдущего хакера, и так до бесконечности. работа у них такая.... Варианты вам предложили уже как обезопасить себя на будущее. Доступ только по вашему IP в админку - крайне эффективен, лучше всяких защитный капчей, переименования папки "админ" (что в корне неправильно, но есть лишь дурной совет от непрофессионала. правильно нужно делать не через переименование, если уж хочется иной адрес админки вроде site.com/secret_admin, но через символьную ссылку и закрытие доступа к папке admin через .htaccess. В таком правильном случае у вас будет обеспечена совместимость со всеми модулями, которые не ведают о вашем переименовании admin папки ). Но в совокупности с другими способами и при уверенности, что в публичной части нет заражения.

Скачиваете соответствующий файл по фтп и смотрите его свойства. Скачивать нужно обязательно НЕ из браузера, иначе легко скачаете старый закешерированный в браузере файл. Можно просто навести мышкой на файл. Если у вас windows, то вы увидите тег mozjpeg для JPEG файла.

У сжатого изображения JPEG должен быть тег mozjpeg. Если его нет, то вы не включили сжатие для JPEG или еще что-то не так сделали. Прошу обратить внимание, что достаточно навести на файл чтобы увидеть этот тег. Специально сделано для удобства чтобы не гадать сжат или не сжат? Только скачивайте изображение по фтп чтобы избежать получения старого кешированного (без mozjpeg). Тоже самое (тег) вы можете увидеть в свойствах файла.

В ближайшее время будет доступна версия модуля 1.11. Что принципиально нового? 1) Режим работы по расписанию с заданием допустимой нагрузки (картинок в минуту), что обеспечит работу без лишней нагрузки у любого хостера. Это уже реализовано, тесты успешно пройдены на разных хост-площадках. 2) Возможность вывода webp на любой хост-площадке и для любого шаблона. От заказчика не требуется никаких дополнительных знаний и не нужны правка конфигов и др. непростые для непрофессионала манипуляции . Все формируется автоматически. 3) есть возможность установки софта для генерации webp практически для любой хост-площадки без ограничений. Включая площадки с древней Linux на ядре 2.6, а такие еще встречаются как показала моя статистика. Кроме того есть возможность настраивать интересные параметры для webp. Качество webp - это не единственный параметр, который влияет на конечный вес файла. Есть еще уровень оптимизации, от которого зависит время работы по генерации webp. Если дать возможность генерировать webp несколько медленнее, то можно получить дополнительный выигрыш в весе на 10%. Не всегда имеет смысл использовать скоростной алгоритм, тем более когда есть режим работы по расписанию, то имеет смысл сжимать по максимуму - тут ведь все равно лишняя нагрузка на ресурсы не будет создаваться, а страницы будут открывать как обычно, т.е. без задержек. Для примера разница в весе файла в зависимости от уровня оптимизации. Тут у webp серьезное преимущество над mozjpeg в виде дополнительного снижения веса примерно на 10%. Кстати, мод pagespeed вам не даст такую возможность, т.к. в нем за вас решили какой уровень качества вам нужен (и решили, что не самый высокий), и алгоритм работы мода pagespeed не позволит вам использовать webp по максимуму и с полным контролем результата, в том числе по качеству! Судите сами как разнится результат при одинаковом качестве. Актуально в основном для JPEG. Сравните самый скоростной метод и самый тщательный, но относительно долгий. 27% и 46% выигрыш. При одинаковом уровне качества (80 для примера). Стоит ли этот дополнительный выигрыш тех усилий, которые положены при создании модуля Компрессор? Повторюсь, что мод pagespeed не дает вам такой возможности контроля над весом файла при создании webp, т.к. там упор в основном на на быстрое создание файла, что, впрочем, все же приводит к некоторым тормозам страницы. В модуле Компрессор если вы выбираете максимальное сжатие, то это не приводит ни к каким тормозам, т.к. режим "на лету" остался в прошлом. Впрочем, режим "на лету" вполне можно использовать для небольших (по кол-ву товаров) магазинов, до нескольких тысяч он работает без проблем. Да и новый "на лету" работает в три раза (и выше) быстрее чем в версии модуля 1.8.2. Новые метод "на лету" для webp - это даже не вполне "на лету" - это некий гибридный метод, который значительно позволяет снизить нагрузку на ресурсы хост-площадки. Поэтому я призываю всех заказчиков не использовать старые версии модуля для опенкарт 2.*, а использовать, как минимум, версию 1.9.4 и выше. Версия 1.9.4 работает "на лету" быстрее версии 1.8.2 в три раза. Именно эта версия (и более новые) позволяет на лету без проблем генерировать изображения даже для магазинов 10 000+ товаров. И бессмысленно обсуждать старую версию 1.8.2, когда много месяцев уже есть скоростная 1.9.4+ (1.10.*). Но всем заказчикам напоминаю, что здесь версия новее чем 1.8.2 не появится. Причины ниже под спойлером. Любой купивший модуль Компрессор может скачать свежую версию с сайта разработчика (вашего покорного слуги). Разработчик - это sitecreator. А "ваш покорный слуга" - это собственно я и есть. Извините, что расшифровываю банальности, но приходится после вопросов "а разве вы не разработчик?". Почему тут нет версии новее 1.8.2? (версия 1.8.2 вышла более года назад, и сильно уступает по скорости работы новым версиям) Надеюсь, что я дал исчерпывающий ответ почему новые версии есть на сайте разработчика.

это не может быть ограничением для применения чистого nginx (+ php-fpm). Уж памяти потребляет такой вариант в любом случае меньше чем nginx + апачи (+ php как модуль апачи). Возможно, что у вас очень нагруженный проект. А отсюда и потребление памяти. Как редкий вариант - утечка памяти. Но это пока лишь гадание.

Здравствуйте. Для движка опенкарт 1.5 планируется обновление, но позже. Все же для него продажи составляют < 3%. Основное внимание движку 2.*.

Скорость в данном конкретном случае - это не показатель, вот на нее в данном случае не надо обращать внимание. Время отклика должно интересовать. Чтобы измерить скорость вам нужен нормальный тест с VPS, у которого гарантирован, например, канал в 100 Мбит/сек. Я показал лишь для оценки доступа ("пинг"). Могу совершенно точно сказать, что с германских VPS получали именно заявленную 100 Мбит/сек при тесте больших файлов (от 50Мбайт), поэтому со скоростью полный порядок. Причем на одном из VPS первоначально скорость у нас была ниже заявленной раз в пять, т.е. на уровне 20 Мбит/сек, но после обращения к провайдеру скорость поднялась до 100. Сами украинские провайдеры активно пользуются возможностью перепродажи европейского хостинга (VDS), но с уже очень серьезной наценкой.

делали как-то эксперимент на юкрейн.ком У них есть площадки как в Киеве, так и в Германии (город сейчас не помню). И тестировали доступ из разных украинских городов. Разница невелика чтобы на нее обращать внимание. Иногда ее нет, а иногда, как ни странно, пинг до германского провайдера бывает короче. Вопрос цены выходит на первый план. Тест расставит все по свои местам. По хорошему надо бы взять два VDS чтобы сравнивать. Мы именно так делали. Но необязательно. В любом случае вам суперточные измерения и не нужны. Да и у украинских провайдеров между собой разница тоже может быть существенной, это тоже наблюдали. https://ping-admin.ru/free_test/ Уж на что, но на это он обратит внимание в самую последнюю очередь. Если страница откликнулась за 200 мс, то гугл считает, что это отлично. Если за 300 мс, то тоже для гугла вполне приличный результат, он, конечно же, намекнет, что неплохо бы уменьшить, но оценку практически не станет за это понижать. Вот до Германии из Украины. Правда, по IP получается Голландия для 104.81.... А вот Украина - Украина

Есть некий господин (пусть он останется инкогнито), постоянно выискивающий соринки в чужих глазах. Но вот про кейсы бревнышки собственных косяков очень не любит говорить. Может быть просто не помнит? Мало ли по какой причине... Бывает же, уйдет человек дня на 4 или 5 в состояние запойной работы и не помнит ничего, что обещал заказчику.... А как выйдет из состояния работы, то так сразу на форум! И писать писать писать! Клеймить всех негодных разработчиков! Уж, поди, и годных то не осталось... Никто не знает такого господина? Может и не было такого, но лишь показалось? И отчего этот радетель за все хорошее (для себя?) не помог в этой теме топикстартеру? Ваш покорный слуга и про тему то заказчика не забыл, подсказал в этой теме вполне конкретные шаги в решении его проблемы. Но у того самого некоего господина , как всегда, даже времени (или желания? или знаний?) не было чтобы помочь человеку, создавшему вполне конкретную тему по конкретной своей проблеме. Господин все время потратил на нравоучения в стиле "как плохо зарабатывать деньги" (другим - это плохо, себе зарабатывать - можно? ). Может я ошибаюсь? И супер-мэн (он же спаситель всего опенкарт-сообщества) уже установил топикстартеру новую ОС и панель управления, которая как в сказке все все сама собой устанавливает и настраивает? И, конечно же, бесплатно! Он же всем так делает? Думаю, что @Roumek нам непременно об этом расскажет.

да кто ж с этим спорит? Писал и про это. В итоге заминусовали репу и предложили уйти с форума чтобы сберечь свою нервную систему раз уж здесь "все меня раздражает". Также было встречное предложение ко мне все "исправить самому", мол, ничем не обязаны. Я даже здесь показывал, что именно нужно хотя бы в CSS поправить для более удобного вида. Т.е. предлагал решение. С кодом, со скриншотами. думаете кому то это нужно было? Поэтому не питайте иллюзий, что "предложения и пожелания" кто-то всерьез рассматривает. На плачевное положение с письмами в личке ответственные давно забили. Такова реальность. Что мы как разработчики можем сделать для этого? Да ничего! Предлагаешь код, который исправляет проблему, так его даже не смотрят. Сапожники без сапог, ей ей!