Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

sitecreator

Users
  
 View Profile  See their activity

  • Posts

    6,116

  • Joined

 Content Type 

Everything posted by sitecreator

  1. sitecreator
    А в это раз то что? И недели не проработали с новым программистом? Раньше было:
  2. sitecreator
    Из своей же документации по модулю Компрессор цитирую вариант для Апачи. Для nginx+apache также годится, но только в случае если обработкой статики занимается Апачи. Обычно это делает nginx, но некоторые хостеры позволяют переключить эту обработку на apache . В коде учтено и это тоже. Достаточно инфы для полета души? Если же не справляетесь, то можно взять готовое решение для WEBP: https://opencartforum.com/files/file/4572-image-compressor-watermark-webp-lazy-load-etc-by-sitecreator/?tab=details Работает у любого хостера, даже у которого нет совершенно никакого своего софта для WEBP и/или практически все запрещено, например, exec отсутствует. Ссылку даю не для вас (вы принципиально хотите все сами, и вся инфа у вас есть теперь), а для того, кому проще использовать готовое решение чем изобретать велосипед. Также замечу, что автор Компрессора предоставляет всем желающим скидки. Поэтому далеко не всегда бывает так: Знаю - вам не нужно. Для вас бесплатная инфа выше. Дерзайте.
  3. sitecreator
    Если сложно искать, то вот тут подробно написал как: Конфиг (config) NGINX для вывода WEBP на VDS Для настройки Апачи (на общем хостинге) часть информации у меня дана в поддержке модуля, а часть - в описании модуля Компрессор. На примере хостинга www.ukraine.com.ua дан исчерпывающий пример в картинках для Апачи. В документации модуля Компрессор дан полный код для поддержки webp средствами Апачи. Впрочем, по Апачи информации полно в сети в отличие от инфы по nginx. Этой информации более чем достаточно чтобы сделать все самостоятельно и бесплатно.
  4. sitecreator
    а что вам мешает прочитать доступную в сети информацию и летать как пожелаете? Если уж решили творчеством заняться, то информации предостаточно. даже жутко представить как это "просто" происходит когда товаров 10 000, да даже если всего 500. Ведь надо сперва подготовить картинки WEBP руками на компьютере, потом закачать их в папку кеша. При этом соблюсти названия файлов, но это мелочи, раз вы знаете "как". Возможно, что вам, действительно это проще делать руками чем автоматически "перерабатывать все картинки". Только apple и не поддерживает. Если их исключить, то 80% браузеров поддерживает по статистике. Оставшимся 20% отдается привычный формат в jpeg. Решение вашего вопроса есть. Вы можете загружать руками картинки webp (все как вы хотите) и сделать самостоятельно настройки веб-сервера. И ваша задача решена. Все бесплатно как вы и хотели. И как это сделать описано в FAQ к модулю Компрессор.
  5. sitecreator
    С мааааленькой оговоркой. Все модули, авторы которых не позаботились о нормальной защите и использовали лишь "защиту от школьников" (а базовая защита ионкуба по-сути таковой и является). Защита "по-взрослому" НЕ раскубируется ни 10 евро, ни за 100 даже хакером вручную. И не просто хакером, а специалистом только и занимающимся этим делом на профессиональной, т.е. коммерческой основе. Любой автор, сумевший осилить документацию на 80 страниц (на английском языке) для ионкуба, уже никогда не будет использовать "детскую защиту". Плюс "детской защиты" в том, что нужно просто нажать одну кнопку "закубировать" и ни о чем больше не думать. Но и результат будет соответствующий. И понимающий автор не использует онлайн-кубирование, ибо это и есть та самая "детская защита", которая может быть взломана.
  6. sitecreator
    Просто бывают такие особенности, которые, вроде бы, напрямую к неприятностям версии движка не имеют отношения, но в конкретной реализации некоторых авторов подрывают авторитет этой версии. Но по большому счету тут уже заслуга писателей шаблонов/модулей.
  7. sitecreator
    а можно перефразировать? Что есть такого в 3-ке, чего нет в 2.3? Просто обычно с появлением новой версии связаны ожидания, что она будет более быстрая, более надежная, решены имеющиеся проблемы предыдущей версии, с новым функционалом. И, желательно, чтобы не возникли новые проблемы, которых не было в предыдущей версии. чем? Скажу даже больше - шаблоны (темы) пишут. Прям туда пихают целые библиотеки. Например, библиотеку по преобразованию Sass в CSS и другие. Почему? Я не знаю почему так захотелось автору. И без полного дистрибутива фиг потом восстановишь. И я наткнулся на ситуацию когда бекап файлов сайта есть, старый аккаунт у хостера уже удален и, как водится, у заказчика нет ни одного дистрибутива модулей, шаблонов потому, что "все делал исполнитель". Я могу огласить название, но разве что-то изменится? Мы же не играем в "бывает/ не бывает"? У меня было неоднократно, разов пять. Мне этого оказалось достаточно на нескольких сайтах. Не смертельно, но лишний геморрой. Большинство простых пользователей делают бекап файлов для сайта и не подозревают, что нужно еще бекапить всю папку пользователя, а потому прибывают в ложной уверенности, что у них есть полный бекап на случай экстренного восстановления.
  8. sitecreator
    И, как следствие, несовместимость с модулями от 2.3. существующие решения для одновременного использования tpl и twig шаблонов приводят зачастую к самым разным проблемам.... В общем, скорости работы магазина мы не получили с приходом 3-ки, а все наоборот. Вот такой прогресс... Хотя силы могли бы потратить именно на увеличение скорости работы, но вместо этого имеем twig и новый кривой язык псевдо-программирования.
  9. sitecreator
    тут можно с разных сторон смотреть. Ничто и раньше в принципе не мешало эту папку хранить где угодно. А защита, ради которой все эти пляски, может быть обеспечена и более удобным способом. Кстати, в чем плюс? В том, что не дает модулям сделать загрузку в нужные папки? Так модули через свой код делают такую загрузку если нужно. В плане надежности не вижу в этом улучшений. В плане неудобства - полно изменений. В итоге ломают в совсем иных местах, но не там, где упорно защищали.
  10. sitecreator
    плюсы есть чтобы переходить на 3-ку, имея в наличии стабильно работающие модули под 2-ку? Части модулей либо вообще не будет, особенно если были индивидуальные разработки, часть стоят дороже чем для 2-ки. И где, наконец, чудо ocstore стабильной версии 3.0? Это ни разу не показатель в пользу стабильной 2.3?
  11. sitecreator
    @chukcha , а плюсы у 3-ки есть? их сколько угодно. Начиная с пароноидального требования хранить папку storage за пределами сайта. В итоге многие пользователи при копировании сайта (бекап есть, но только для "сайта") теряют важную информацию, т.е. часть файлов, которые не являются кешем, т.е. не дублируются. Некоторые модули/шаблоны устанавливают часть программного кода в storage. разумеется, что все можно восстановить путем установки с нуля таких модулей (если дистрибутив есть) или созданием вообще сайта с нуля. Но геморрой то появился. Пользователь просто банально не понимает зачем что-то нужно бекапить за пределами сайта. Продолжать можно долго. В 2-ке вот таких проблем на пустом месте не возникает.
  12. sitecreator
    Зачем вам геморрой с 3.0 когда проще и надежнее сделать на самой стабильной (на сегодня) версии 2.3? Никаких плюсов у 3.0 перед 2.3 нет, изменения чисто формальные в "новой версии". Собственно 3.0 была выпущена ради создания иллюзии, что проект как-то развивается. Но кроме новых глюков и специально созданной несовместимости кода с 2.3 ничего приятного в 3.0 нет. Работать с 3-й можно, конечно, но с 2.3 намного приятнее и с меньшими сюрпризами. И "просто обновиться" с 2.0 до 3.0 невозможно никак. тут надобно изготовления с нуля, ибо практически все модули несовместимы. Да и про vqmod пора забыть - это чужой ребенок, рожденный версией 1.5.
  13. sitecreator
    А какой смысл обманывать робота если в итоге гугл делает вывод на основе реальных данных статистики в реальных браузерах пользователей? Или заказчик настолько неразбирающийся, что не понимает (и не хочет) разницы между реальной оценкой гугла на основе сбора данных по сайту и оценкой, полученной на основе виртуального теста теста? Сам гугл виртуальный тест рассматривает как предварительную оценку. Гугл в итоге будет делать ранжирование на основе реальной своей статистики. Обманывать гугл сейчас - это обманывать себя. И отдачу по фильтру "HTTP_USER_AGENT" гугл довольно неплохо распознает в автоматическом режиме. Могу судить по многолетнему опыту, что гугл подвох распознает и не покупается на уловку, например, вчера это действовало, а сегодня - нет для конкретного сайта. Делайте сайты, в конце концов, для людей, а не для гугла. Самый удачный в плане баллов будет сайт с пустой белой страницей - 100 баллов обеспечено!
  14. sitecreator
    Сегодня видел на сайте картинку фона шириной... 6000 пикселей!!! Дизайнеры-верстальщики, как говорится, "отжигают". Интересно, а на какой монитор это рассчитано? И ведь загружают ее для экрана смартфона тоже. Это тот случай когда хоть в 5 раз сожми (за счет webp, например), то все равно будет много. Причем сделано самым нелепейшим образом там, где можно было обойтись повторяющейся картинкой весом в 15 Кбайт. И картинка, безусловно, "важная и нужная" чтобы грузить лишние мегабайты. Ну как же без травки то в 6000 пикс в футере, дизайнеры-верстальщики?
  15. sitecreator
    @markimax , гребаный конвертер и кривые руки его создателя! вот понятный код PHP var thumb = "<?php if(!empty($thumb)) echo $thumb;?>"; конвертер превратил его в фиг знает что: var thumb = "{% if (thumb is not empty) %} {{ thumb }}{% endif %}"; Из-за этого нифига не работает! Он влепил лишний пробел! Какого лешего? И это очень сложно отслеживать! да только так и надо. А эти конвертеры - на помойку! Элементарные вещи преобразовать корректно не могут.
  16. sitecreator
    С глюками работает и сейчас. Не может корректный с точки зрения PHP код c else и вложенными if переложить на twig. Полный идиотизм - использование twig в опенкарт, особенно в админке. Приходится логичный и отлаженный код PHP переводить в это нелогичное чудо-юдо. И снова отлаживать. Плюсов от twig-а - ноль, зато геморроя в разработке добавляет. Все эти псевдо-языки - хрень полнейшая, в угоду чайникам...
  17. sitecreator
    да нет в этом никакого особого прока. Потому что в основном людям хоть бы что-то рабочее найти под их задачи. На куб обратят внимание в самую последнюю очередь. По фильтрации при поиске дополнений итак всяких глюков и багов хватает. Хоть бы их вылечили. А начнут добавлять новые фильтры - так поиск еще хуже, может быть, станет (по традиции), в итоге релевантность только ухудшится. даже не знаю, что вы такое ищите, что у вас появляется огромный выбор. Отсутствие или наличие куба - это еще не показатель качества вообще. Вот бы фильтр по "качество продукта" был бы...
  18. sitecreator
    Подготовил релиз 1.17.0. В скором времени будет доступно для скачивания. Lazy Load теперь работает для любых браузеров. Как для WEBP, так и для JPEG, PNG. Вы просили сделать это - я проделал работу для вас. Самый продвинутый и быстрый Lazy Load. Т.к. ни один браузер не остается без картинок. Прекрасно работает при динамическом изменении страницы (подгрузка кнопкой "показать еще" и т.п.) Можете пока протестировать здесь: http://watermark.sitecreator.pro/index.php?route=product/category&path=20 Гугл положительно оценивает производительность работы Lazy Load by Sitecreator. В планах еще добавить совместимость с одновременным использованием сторонних Lazy Load. Хоть и не приветствуется одновременно на одной странице несколько разных Lazy Load, но не каждый пользователь понимает сам как отключить другие Lazy Load. Нужды использовать сторонний Lazy Load нет никакой, просто добавлю совместимости чтобы не возникало конфликтов.
  19. sitecreator
    Здравствуйте. Правильно понимаете. Ставьте модуль Компрессор и будет все как надо. Хоть в новых браузерах, хоть в старых - в любых.
  20. sitecreator
    Вы тоже хотите такого же результата? Один JS только чего стоит. 43 скрипта JS подключено. И, конечно же, никак не обойтись без загрузки двух библиотек каруселей, взаимно несовместимых и т.д. и т.п. 29 для десктопа - это надо постараться. И 5-6 баллов для мобильного. Если есть интерес, то опыт имеется по оптимизации скорости работы в клиентской части интернет-магазина, т.е. производительности работы в браузере, а именно на это делает упор гугл, не считая скорости отдачи страницы (серверная оптимизация) и оптимизации изображений. Работа довольно сложная и не из дешевых. Не каждый сайт беру в работу, ибо нередко проще сайт создать заново чем весь геморрой лечить. Можно вот такие результаты получить для мобильного :
  21. sitecreator
    True File Manager Версия 1.1.0 Добавил совместимость для очень изощренно работающих с менеджером модулей. Нашелся один модуль, который переписывает поведение стандартного менеджера файлов, но при этом не использует свой менеджер. Организовал совместимость с подобными модулями.
  22. sitecreator
    непонятно. даже сейчас непонятно про "два варианта". Макет бывает обычно в одном варианте, но главная страница отрисовывается для разных разрешений экрана. Обычно таких разрешений 4 если делается на бутстрап. два варианта - это обычно именно два варианта дизайна (дизайн-макета), из которых заказчик выбирает лучший. В кругу дизайнеров, верстальщиков и заказчиков именно это подразумевается под словом "вариант". Но, похоже, не в вашем случае. А каким боком "чистый код" и "скрипты и их по возможности убираем во внешне файлы" связаны? У вас очень необычная трактовка чистоты. Вы какие-то критерии именно для чистоты можете назвать? Я предполагал, что для вас "чистый" - это синоним "правильный", т.е. валидный. А у вас чистота почему-то в размер превратилась. Причем, малый размер (вес) - это еще не показатель скорости работы. Крошечный, но неудачный JS способен убить легко производительность всего сайта. за верстку. я вполне четко написал. 120 000 руб. в моем понимании верстка = готовый магазин (шаблон). Но без изготовления нестандартного функционала, он либо уже должен быть, либо изготовляется позже. Т.е. ничего "натягивать" не нужно. Далее просто добавляете нужный функционал. Или можете его сперва добавить до верстки. парсить непонятно в каком размере и непонятно что и откуда - это совсем другая задача. Этим занимаются специализирующиеся на этом люди. "сайт под ключ" в понимании разработчиков никогда не связан с наполнением. Сайт может быть готов чтобы его наполняли, но само наполнение - это отдельная задача, не надо валить все в одну кучу. а что смущает то? Вы же хотите чтобы было все хорошо или почти иделаьно? В таком случае должны отдавать себе отчет, что за "все все все" стоимость в 120 тыс. руб. - это нереально при ваших требованиях. И рекомендую все же разбить ваше ТЗ на группы. Наполнение (парсинг) не надо вставлять в задание в собственно по изготовлению магазина.
  23. sitecreator
    120 000 руб за идеальную верстку с нуля. Список браузеров обговаривается отдельно. Если будет желание верстать под IE 9, то добавляем сверху. "код чистый" - тут нужно четкие критерии чистоты. Иначе может выясниться, что в природе не существую чистого кода, кроме простой белой страницы. да, и написано у вас так, что очень сложно понять, что вы имели ввиду. Т.е. либо непонятно, либо неграмотно, а потому вы можете потом требовать, что угодно на основании "я не это имел ввиду". Стоит избегать таких моментов. Совершенно непонятно как у сайта могут быть две главных страницы. Это же нонсенс. Стоит выражаться яснее.
  24. sitecreator
    Время последнего изменения файла меняется, а потому картинки для кеша в этом случае также будут создаваться заново. Правда, здесь есть одно "но"... В движке Опенкарт (Ocstore и т.п.) во всех версиях вплоть до 2.3 включительно создатель допустил очень грубую ошибку. Используется ошибочно filectime() вместо filemtime(). Из-за этой ошибки логичное поведение при обновлении файлов ломается и становится совершенно нелогичным и непредсказуемым. filectime() - это время изменения индексного дескриптора, но не содержимого файла. Странно, что Даниель это исправил лишь в 3.0 версии движка. Модуль Компрессор же использует правильную логику проверки времени изменения файлов, т.е. исправляет ошибки движка по работе с графическими файлами. И это не единственная ошибка по работе с графикой в дефолтном движке.
  25. sitecreator
    Там еще и другая беда есть очень часто. Например, формат JPEG внутри PNG. Из-за этого картинки для кеша раздуваются в размерах на пустом месте, т.к. они вынужденно становятся в формате PNG чтобы соответствовать своему расширению. Заметил, что всевозможные парсеры вообще часто не заморачиваются насчет изображений. Расширения файлам дают от балды, не обращая внимание на их mime-тип. Но для уже загруженных изображений (речь про исходники) ужималка отдельная нужна - иначе никак. Здесь я вижу два варианта. 1) Добавить такой функционал (уменьшить исходник) в модуль Компрессор: Исходник будет уменьшен в момент первого обращения к нему при создании картинок для кеша. 2) Сжимать (ресайзить) отдельной программой. Сканируем папку с исходниками, а далее по расписанию работает сжималка. У 2-го способа есть побочный эффект: после ресайза исходника он уже будет считаться другим (новым) изображением (хоть название останется прежним), а потому начнут создаваться заново для таких исходников картинки в кеше (если они уже созданы). 2-й вариант модуля у меня в принципе готовый есть, по-сути надо немного до состояния релиза довести. Не выкладывал, т.к. насчет спроса была слабая уверенность.

Покупцям

Розробникам

Корисна інформація

Останні розширення

×
×
  • Create New...

Important Information

On our site, cookies are used and personal data is processed to improve the user interface. To find out what and what personal data we are processing, please go to the link. If you click "I agree," it means that you understand and accept all the conditions specified in this Privacy Notice.

  I accept