-
Posts
6,116 -
Joined
Content Type
Profiles
Forums
Marketplace
Articles
FAQ
Our New
Store
Blogs
module__dplus_manager
Everything posted by sitecreator
-
Изображения в формате webp
sitecreator replied to cyberkekc's topic in Opencart 2.x: Setting and optimization
Ну так и я теперь обращаюсь просто к автору кода. возможно, что к неизвестному автору.- 87 replies
-
- оптимизация
- ускорение
-
(and 1 more)
Tagged with:
-
Изображения в формате webp
sitecreator replied to cyberkekc's topic in Opencart 2.x: Setting and optimization
@OCappLab , первоисточник я не смотрел, я лишь смотрел код в вашем сообщении. Спасибо за уточнение. Я вижу в нем в том числе не вполне верные решения, которые заимствованы из stackoverflow. Теперь знаю, что это не ваш код. В данном случае критика не в ваш адрес, а в сторону упрощенного взгляда на вопрос, который довольно сложен. Просто надо же как-то предупредить пользователей, что у них банально рухнет сайт от множества проблем, заложенных в коде. Я критикую именно код и подход. То, что годится для эксперимента, нужно использовать именно как эксперимент. Для боевого магазина это не годится. Просто предполагаю, что люди ждут готового бесплатного решения для боевого магазина. Не знаю откуда первоисточник, но проблемы в нем серьезные. Там в этой теме столько подводных камней.... Я даже при полном и глубоком погружении в тему до сих пор не нашел идеального решения чтобы и визуально работало отлично, и чтобы с индексацией не было проблем. В общем, если коротко. То все это работать на реальном сервере и реальном проекте просто не будет.- 87 replies
-
- оптимизация
- ускорение
-
(and 1 more)
Tagged with:
-
судя по всему, ТС использует " secretKey ", который как раз и проверяет через php, т.е. не отсылает незваного гостя с порога, а сперва пускает его в дом, просит документ показать и лишь потом выпроваживает. Это называется "настырно ломятся"? Да они уже водички попросили попить когда им дверь открыли, а не просто ломятся.
-
Белые поля в изображениях товара в каталоге
sitecreator replied to yura5s5's topic in Opencart 3.x: Setting and optimization
Могу предложить решение в качестве готового модуля. Можно как удалять белые (да и всякий другой фон, а не только белый и равномерный) поля, которые уже есть в изображениях-исходниках, так и управлять добавлением (НЕ добавлением полей) к создаваемым для кеша изображений. Если исходники разных размеров и пропорций, то можно выбрать один из вариантов адаптивного ресайза (обрезки). Т.к. в этом случае просто задание другого размера не поможет. Адаптивный ресайз можно можно применять при желании только на определенного типа страницах. Например, только для страницы Категория. Да и на разных страницах адаптивный ресайз может быть своего типа или совсем отсутствовать. -
тоже верно. все, что возможно было, уже посоветовали ТС. И решения были предложены, которые годятся в большинстве случаев. Конечно, по хорошему, блокировку по IP нужно делать в конфиге nginx, тогда до "тормозного" апачи дело даже не дойдет. nginx это делает мгновенно настолько, что апачи такое и не снилось. В случае применения грубой силы это имеет значение. Но доступ к конфигу nginx есть обычно только на VDS. А потому рецепт для апачи - нормальный вариант.
-
Это вам только так кажется. Если бы реально работало, то вы 404 не получили бы. Будете продолжать себя убеждать и дальше, что "Все это сделано и работает"? Это тупиковый путь, понимаете? да вы уже в кучу все смешали.... но к пониманию не пришли. Собственно и обсуждать то нечего далее... Вам говорят, что у вас неправильно, но вы настаиваете на своем "нет, все правильно"? Читайте мануал по nginx, апачи. Набирайтесь знаний. Или обратитесь в раздел платных решений. Правильные решения вам уже выше показали. Правда, они не во всех случаях сработают, нужно понимать еще нюансы вашего сервера.
-
Изображения в формате webp
sitecreator replied to cyberkekc's topic in Opencart 2.x: Setting and optimization
Обращаю внимание автора кода на принципиальную проблему, которую он, похоже, не видит. У автора апачи обрабатывает изображения? Это частный случай, например, годится для тестов на OpenServer с одним апачи. В 99.9% случаев на общем хостинге картинки обрабатывает nginx. Кроме того, в коде есть масса потенциальных проблем и он просто уронит очень многие сайты, на которых есть "неидеальные" изображения и/или неидеальные имена файлов. По другим причинам тоже уронит многие сайты. Часть проблем я отметил выше. Не забывайте также, что многие изображения обрабатываются и загружаются через JS. Тут автора кода также поджидают сюрпризы и неожиданности. Уверен, что автор кода еще не думал об этом. Вывод делаю на основе взгляда на код. Данное решение можно рассматривать в качестве эксперимента. Насколько я понимаю, то оно собственно так и представлено.- 87 replies
-
- оптимизация
- ускорение
-
(and 1 more)
Tagged with:
-
Изображения в формате webp
sitecreator replied to cyberkekc's topic in Opencart 2.x: Setting and optimization
Также не забывайте, что могут произойти чудеса с индексацией изображений. Вы можете потерять индексацию JPEG, PNG. К примеру, Яндекс вообще не индексирует никакие изображения если отдается на странице только webp. Гугл тут более лоялен, он проиндексирует webp, но jpeg останется не проиндексированным, что не очень то хорошо для браузеров вроде Сафари и всех остальных браузеров для iPhone, А это все Хром (от Гугла), FireFox и т.д. для iPhone. Гуглу нечего будет предложить этим браузерам кроме крохотного "снимка webp" в формате JPEG, и снимок этот будет крайне низкого качества. Нюансы и подводные камни обнаруживаются только в процессе работы на реальных сайтах. На многочисленных и разных сайтах. Вот и я раньше не знал о чудесах, которые описал выше. Я затронул лишь часть проблем, которая всплывает при работе с webp. Но их гораздо больше. На данный момент почти все проблемы с webp я решил уже в своем модуле. С учетом всевозможных багов в GD, imagick и т.д. Поверьте, что imagick существует самых разных версий, и он тоже ведет себя совершенно по-разному. И это вы еще не пробовали скормить изображения не в RGB, а в CMYK (типографский формат). И не пробовали скормить PNG, внутри которого JPEG (или наоборот). Думаете такого не бывает? Ввиду того, что многие сайты используют повально изображения от поставщиков или полученные в результате парсинга, то и не такое бывает. Работать с графикой на сервере и писать программу обработки намного сложнее чем обычную программу на php, т.к. вы должны понимать, что вы никогда заранее не угадаете какая версия графической библиотеки будет на сервере. И только наивный или неопытный человек будет полагать, что достаточно протестировать на одной машине чтобы быть уверенным, что это будет работать везде. Если вам нужно реально работающее решение, то вы знаете где его взять. И простых решений в этом вопросе не бывает. Простое может сгодиться в качестве эксперимента, но не более того. Оно не будет универсальным, а тем более не будет надежным.- 87 replies
-
- 1
-
- оптимизация
- ускорение
-
(and 1 more)
Tagged with:
-
Изображения в формате webp
sitecreator replied to cyberkekc's topic in Opencart 2.x: Setting and optimization
Вот вам еще чудеса: Попробуйте открыть эту картинку в Хроме. Она "невидимка" в Хроме. Но зато ее видит новый FireFox, также ее увидит ACDSee. http://watermark.sitecreator.pro/img_test/webp/slojprizma-1-100x100.webp Чудеса созданного webp посредством GD. Картинку Хром видит как сплошной альфа-канал. Лишь некоторые картинки так странно создает GD. На примере ниже видно, что одну нормально создал, а другую сделал "необычную". Гугл не видит ее: Но видит FireFox:- 87 replies
-
- оптимизация
- ускорение
-
(and 1 more)
Tagged with:
-
Так этого более чем достаточно. Значит, что вы сделали что-то не так. Скорее всего, вы просто думаете, что привязали, а на самом деле это никак. Скорее всего, человек просто не разбирается совсем. Ведь известно, что если заказчик, который не профи, говорит "сделал", то это часто вовсе еще ничего не означает.
-
Поскольку вывод WebP сейчас в стадии эксперимента (бета версия), то помните про возможность влиять на визуальное отображение сайта путем отключения галочки "улучшение индексации". Проверяйте отображение на смартфонах в том числе. Определенные проблемы известны, решаются они пока простым удалением этой галочки. В новых версиях будет пофиксено. Для нормальной работы вывода WebP необходимо чтобы в настройках движка не было включено "сжатие". Это в любом случае дурное дело и приводит к разным глюкам и тормозам. Сжатие HTML всегда делает сервер (у любого хостера так всегда, про кривые руки настройщиков VDS речь не идет). Не надо пытаться сжать HTML дважды. Должен быть только НОЛЬ в настройках.
-
1.11.2 BETA 2 Новая версия модуля доступна для скачивания (на сайте разработчика) и ваших тестов. Уделено особое внимание индексации изображений поисковиками. Как Гуглом, так и Яндексом. Причем упор сделан на индексации не только WebP, но и его дополняющей пары JPEG/PNG. Визуальных проблем на данный момент ни с одним шаблоном (темой) не обнаружено. Но в случае чего у вас есть возможность перейти в режим максимальной совместимости с шаблоном, при этом Гугл может не узнать о существовании JPEG/PNG на вашем сайте. Хорошо это или плохо - вопрос дискуссионный. Что касается Яндекса, то он не любит когда отдается только webp. В отличие от Гугла яндекс не желает индексировать голый webp без наличия дополняющей пары. В модуле Компрессор продумана ситуация и с Яндексом тоже. Ваш покорный слуга, выступающий разработчиком модуля Компрессор, постарался учесть все нюансы работы с изображениями Webp, а не только визуальные моменты.
-
1.11.1_BETA_1 В новой версии специально добавил предупреждение по поводу использования движка GD для генерирования изображений WebP. Даже красным цветом отметил опцию GD. В описании к данному пункту настройки также указал максимально четко на что нужно обратить внимание. =================== Но не уверен, что заказчик будет обращать на все это внимание. Заказчик же не любит читать. Но любит потом спрашивать "а почему не так работает?". Уважаемый заказчик, если вы не любите читать инструкции, но желаете чтобы настроено было все максимально грамотно, то для вас есть услуга "установка и базовая настройка". Кстати, так и не понял как заставить заказчика устанавливать актуальную версию модуля, а не годичной давности. Не хотят! Упорно ставят 1.8.2, которой уже больше года и которая сильно уступает по функционалу новым версиям, да и работает раза в 3 медленнее чем свежие версии. При получении лицензионного ключа указываю на необходимость установки свежей версии. ссылку даю на FAQ, в котором подробно указано почему тут на форуме доступна для скачивания только старая версия: Где брать НОВЫЕ ВЕРСИИ модуля Compressor & Watermark & WEbP & etc? Хочу новую быструю версию 1.9.4+ или 1.11.1+, а тут нет ее. Не действует! Упорно ставят старую версию 1.8.2. Еще и критиковать будут именно эту версию за отсутствие в ней того или этого или за не очень то быструю скорость. По скорости создания сжатых изображений данная версия, пожалуй, самая неоптимальная, т.к. в то время был сделан упор на максимальное сжатие в ущерб производительности. Это не проблема на хорошем VDS, но на слабом хостинге, да еще если исходники 3000 х 2000, это приводит к серьезным тормозам после очистки всего кеша изображений, т.к. повышаются требования к ресурсам сервера. Честно скажу, что повелся тогда на постоянные желания заказчиков "сжать еще на 200 байт", ведь им же "гугл говорил, что можно сжать еще на 200 байт". Да, тогда гугл, действительно, давал такие идиотские советы. Но после уже была выпущена сбалансированная версия 1.9.1. Смысл обсуждать древнюю версию? В настройках для PNG тоже делаю предупреждение. И заведомо отключил 6-й уровень оптимизации. Чтобы заказчик "с дуру" не положил сервер на лопатки, т.к. на этом уровне раз в 20 идет медленнее процесс. Бывает, что у заказчика в магазине все товары в формате PNG, да еще исходники 4000 х 3000. Сжатие PNG работает само по-себе очень медленно. А если этот формат преобладает на сайте, то тормоза будут присутствовать на время генерации сжатых изображений. Уважаемые заказчики, читайте пояснения к каждому пункту! И выбирайте правильную стратегию создания сжатых изображений в зависимости от вашего сервера и ваших изображений. Иначе по незнанию вы можете создать тормоза на сервере. Временные тормоза, пока будут создаваться сжатые изображения. И лучше всего выбирайте только создание WebP как самое необременительное для сервера. Да, "с дуру" можно в любом деле наломать дров. Подход должен быть разумный и внимательный. Призываю именно к такому подходу. В случае сомнений спрашивайте разработчика.
-
http://watermark.sitecreator.pro/img_test/webp/slojprizma-1-100x100.webp Чудеса созданного webp посредством GD. Картинку Хром видит как сплошной альфа-канал. Лишь некоторые картинки так странно создает GD. На примере ниже видно, что одну нормально создал, а другую сделал "необычную". Но FireFox видит отлично эту картинку:
-
1.11.1_BETA_1 Будет доступна сегодня для скачивания. Сделаны принципиальные изменения, касающиеся вывода webp в браузер. Они направлены на обеспечение совместимости с различными шаблонами ("темами"). Задача - добиться (в идеале) абсолютной совместимости с любым шаблоном.
-
Пример необычного webp: http://watermark.sitecreator.pro/img_test/webp/slojprizma-1-100x100.webp Его видит FireFox, но Хром отображает как пустоту. Сделано средствами GD. Вот такие чудеса бывают. Это иллюстрация к посту, размещенному выше.
-
Сегодня тестировали на нескольких сайтах генерирование webp различными способами (движками). Получили интересный опыт. использование GD не рекомендуется! Много глюков в webp. GD (в php 7.1) картинки webp создал без проблем. Но часть этих webp браузер Хром не видел, т.е. загружал, но показывал пустоту. В то время как FireFox их отображал все отлично! Я и раньше видел, что GD не понимает альфа-канал для webp в версии php 5.6. Вместо него создает черный фон. Переключили на движок cwebp. И все картинки Хром увидел! у нас был такой выбор: GD подвел и создал часть картинок-невидимок. Именно часть. При том, что с тестовыми JPEG он справился хорошо если не считать того, что альфа-канал превратил в черный на PNG. Разные версии GD обладают всякими глюками по работе с webp. В общем, который раз убеждаюсь, что работа с графикой на сервере - очень непростая штука. Тут масса подводных камней. И только опты работы на огромном кол-ве сайтов позволяет выявлять такие нюансы и бороться с ними. Прошу заметить, что сама выявленная проблема не связана с модулем. В общем, везде, где возможно стоит использовать самую свежую версию конвертера от Гугл cwebp. В модуле Компрессор как раз самая актуальная. На выбор две сборки: производительная (под современные сервера), универсальная, но немного помедленнее (под старые и новые сервера)
-
Прошу заметить, что модуль Компрессор грамотно отдает WebP как в браузер, так и поисковому движку. Особенно это важно для Яндекса. При неграмотной отдаче вы рискуете, что ваши изображения не будут проиндексированы Яндексом. Т.е. задача - это не просто отдать изображение и чтобы его увидел браузер, но также чтобы оно было проиндексировано поисковыми движками. Тут давеча один юноша пытался сделать какое-то простое решение на коленке по WebP. Помимо кучи сделанных им принципиальных ошибок юноша забыл, что картинки должны еще и индексироваться. Модуль Компрессор не ставит сомнительных экспериментов над сайтами заказчиков. Используются решения, которые учитывают особенности механизма индексирования картинок поисковиками.
-
Пока выбирайте режим "на лету" обязательно если желаете чтобы webp создавался. Без этой галочки создаваться не будет. Но могут выводиться ранее созданные webp.
-
Новая версия. 1.11.0_BETA_0 Вы можете увидеть webp в "Тип" (полученный файл), а также в названии файла. данный способ вывода webp работает как на VDS, так и у любого хостера на общем хостинге. Выбор разных способов (движков) для генерирования Webp обеспечивает поддержку Webp уже примерно на 98-99% различных хост-площадок.
-
1.11.0_BETA_0 Установка софта простым нажатием кнопки. Выбор софта в зависимости от вашего сервера, поддерживаются как очень старые сервера, так и современные. В случае необходимости можно отключить функцию вывода webp в браузер. Делается из админки модуля. Можно выбрать оптимальный движок для создания webp из списка доступных. Возможен предварительный тест всех движков webp . Для создания webp не надо очищать весь кеш изображений. Достаточно очистить системный кеш. В данной версии доступен режим создания webp на лету. Работает он очень быстро. В щадящем режиме webp создаются не одновременно с jpeg, png, а делается это в отложенном режиме (на 2-м проходе, т.е. при 2-м открытии страницы) чтобы снизить нагрузку на ресурсы. Если у вас есть кешер, то для обеспечения генерирования webp на 2-м проходе нужно очистить кеш кешера, обычно это системный кеш. В данной версии заложена возможность генерирования webp не на лету, а по расписанию, что обеспечивает возможность работы без лишней нагрузки правктически у любого хостера. В бете 0 пока просто отключен режим "по расписанию" чтобы сосредоточить внимание на тесте вывода webp в браузер. Как только тест по выводу в браузер будет успешно завершен, то в следующей версии я включу возможность режима создания "по расписанию". Прошу делиться вашими результатами тестов. Если возникают трудности, то вы можете откатиться на предыдущую версию модуля.
-
Новая версия. 1.11.0_BETA_0 Вывод WebP в браузер на любой хост-площадке. Также генерация и вывод WebP не только для изображений, которые находятся в кеше, но и для изображений, не обрабатываемых движком опенкарт, но вставленным по прямым ссылкам (баннеры, картинки в описаниях и т.д.) На некоторых шаблонах возможно некорректное применение стилей (CSS) к некоторым изображениям в результате вывода webp. Варианты решения данного вопроса ищутся. Самое простое - это небольшая правка CSS.
-
Сколько выдерживает опенкарт3
sitecreator replied to z0nt1k00's topic in Opencart 3.x: General questions
Начинайте волноваться когда товаров будет более 10 000 (20 000+). И просмотров 50 000+ страниц в сутки. Но это весьма и весьма приблизительно, т.к. далеко не все зависит от кол-ва товаров. да и даже на общем хостинге тариф тарифу - рознь. Вы можете уложить сервер на лопатки каким-нибудь фильтром или "очень интеллектуальным" поиском даже при относительно небольшом кол-ве товаров (меньше чем у вас) и всего нескольких одновременных пользователях, задумавших что-то искать и фильтровать. Если у вас перспектива быстрого развития и наполнения товарами в несколько десятков тысяч, то смотрите в сторону VDS. Тем более, что стоит сейчас это недорого. Зато никто вам не скажет, что вы что-то превысили и не предложит перейти на более дорогой тариф. Кстати, преимущество VDS еще состоит в том плане, что вы не ограничены в использовании софта, например, можете забыть про тормоза в плане использования поиска если установите поисковый движок Сфинкс. Но все определяется целесообразностью. -
вы их неправильно поняли. впрочем, они настолько "удачно" составлены, что это немудрено. ссылки можно и нужно давать когда хотите получить предметную помощь. но в вашем случае, действительно, нужно использовать mysqli/ Если движок 1.5 еще оправдано использовать когда есть кастомные разработки под него, то вот оправдания использования mysql не может быть. Это слишком тормозной вариант.
-
WebP без тяжелых модулей
sitecreator replied to stickpro's topic in Opencart 2.x: Setting and optimization
Вы уверены, что я писал не по теме, но вы с переживаниями по поводу "содержания ягуара" точно же по теме писали? вы найдете эту библиотеку с присутствующей функцией где-то в 5% случаев на общем хостинге. И, что неприятное еще, GD глючно работает с WEBP. Например, до определенной версии (до 7-ки) эта функция не умеет работать с PNG с альфа-каналом, вместо прозрачного фона вы получаете черный. Просто когда вы на опыте проходите многие проблемы, которые вначале вам неизвестны, то вот тогда появляется настоящее решение, учитывающее массу нюансов и проблем различных хостеров. А они, можете не сомневаться, есть. Я лишь для примера привел одну из них. Поскольку есть масса магазинов с товарами в PNG с альфой (получено от поставщика), то для них webp был бы хорошим вариантом, но с GD они получат это (см. на бабочек): Т.е. бабочка будет на черном фоне вместо прозрачного. А вот так будет на 7+: Вы уверены, что выбрали правильный тон? А где же спасибо за предложенное мною для вас решение вашей же проблемы? Или вы "не заметили" правильного готового решения в виде кода? Вы над ошибками не умеете работать? "чукча - не читатель, чукча - писатель". Это не про вас, случаем? Все же других критиковать у вас получается лучше чем самому писать код и признавать свои ошибки. Может лучше продолжить заниматься тем, что лучше получается, т.е. быть критиком?