Jump to content

sitecreator

Пользователи
  • Content Count

    5,181
  • Joined

  • Last visited

Community Reputation

938 Очень хороший

About sitecreator

  • Rank
    PageSpeed = 100. Как?

Контакты

  • MSN
    ПОЧТА: opencart@sitecreator.ru
  • Сайт
    https://sitecreator.ru
  • Skype
    sitecreator.ru (бываю не часто, пишите на ПОЧТУ или в личку)

Информация

  • Пол
    Мужчина
  • Город:
    USSR Moscow Работаю официально как ИП

Recent Profile Visitors

31,308 profile views
  1. я понял про что вы. это топикстартер нас запутал. хоть и не бывает в природе IonCube7.3, но он именно так написал. Т.е понять можно буквально, и в данном случае вы правы. После 6-й версии сразу вышла 10-я, поэтому у меня ассоциация была только с версией php. Топикстартеру пожелание писать внимательно и информативно. В любом случае тут надо к автору.
  2. уверены, что модуль совместим с этой версией php? не стоит смотреть cli. у него может быть своя конфигурация. смотрите непосредственно на сайте через обычный phpinfo(). Может быть на сайте у вас вообще другая версия php работает. включите вывод ошибок в php. Возможно, что расширений php не хватает. Может быть того же mcrypt у вас нет, т.к. он выведен из ядра, начиная с 7.2 версии. Возможно, что вы загружали софт по фтп в текстовом режиме, а не бинарном, вот и попортился код. Разумеется, что писать нужно автору. в случае 7.1-7.3 других вариантов не бывает. для более древних версий php может быть что угодно, хотя риск нарваться стремится к нулю. В этом году не встречал ни разу ioncube loader ниже 10. В прошлом году встречал еще у редких хостеров. 10-ка появилась еще в 2017-м, сейчас уже сложно представить хостера, который свой софт до сих пор не обновил бы. Но на VDS без присмотра может быть что угодно.
  3. Вот это тоже утомляет. Когда редактирую домен если покупатель не ввел его при покупке. Зачем вы просите ссылку вместе с http, а без него не принимаете домен? Хотя при заполнении во время покупки нормально принимается без http.
  4. Вот это сильно раздражает. особенно когда форум не покидал, т.е. постоянно находишься на нем, но каждый раз на странице "продажи" нужно вводить подтверждение. Неужели сложно отследить пользователя на форуме, который уже ввел это подтверждение? зачем каждый раз то просить вводить?
  5. А вот теперь нормальный хостинг с нормальной нагрузкой. 400 картинок на страницу. 0.15 - 0.18 сек без кеширования на все картинки. А вот и отдельные проблемы можно увидеть: Нет файла-исходника. И не нужно гадать а почему на странице картинка не отображается? Так для нее нет исходного файла! Любой проблеме можно найти объяснение. В том числе неотображающимся картинкам. Страница с лимитом 100 товаров без кеширования на холодной загрузке за чуть больше чем 3 сек. почти 400 изображений за 0.15 сек. Т.е. в качестве примера взят вполне реальный магазин. Поскольку владелец магазина адрес сайта здесь публиковал открыто, то я показываю пример без замазанного адреса. И никаких проблем с генерацией и выводом изображений WEBP в любом браузере! Никаких проблем с Lazy Load. И никаких проблем с совместным использованием кеширующего ускорителя (работает Jet Cache). В режиме создания по расписанию WEBP вы вообще не заметите времени создания WEBP , т.к. это на скорости загрузки страницы никак не отражается. Таково реальное положение вещей. Возможно, что в испорченном "асисяй"-телефоне Полунина может быть иначе. Если кто-то видит проблемы с изображениями на этом сайте или тормоза из-за изображений (webp в том числе) или что-то иное, возможно, что связанное с модулем Компрессор, то прошу сообщить мне и/или владельцу сайта. По поводу недостаточности попугаев говорить бессмысленно в этом конкретном случае. Достаточно посмотреть сколько времени отжирает JS самого шаблона, например. Какой JS - такие и попугаи.
  6. Информация по включенному режиму "отладка" в модуле. Можно увидеть все проблемные места если они есть. вот отладочная информация: Видно сколько времени занимает обработка одного изображения и общее время для всех изображений. Общее время: 0.003 сек на одно изображение: 0.000165 сек Это нормальная работа. На нормальном хостинге. В этом случае на одну картинку тратится 1-2 десятитысячной секунды. Вот показываю время на проблемном хостинге. Хостинг перегружен, на нем даже файловые операции медленные. Видно, что на проблемном хостинге время на одно изображение уже 0.001, а иногда даже 0.02 сек В итоге на 253 изображения потрачено времени 0.4 сек. Изображений много, хостинг ужасный, в итоге - большие потери времени. Проблемы отмечены цветом. Любые проблемы с изображениями в режиме "отладка" будут показаны если они возникнут. А не только время выполнения. Также вы можете увидеть названия файлов, в том числе проблемных. Пожалуйста, пользуйтесь на здоровье и анализируйте! К чему гадать на кофейной гуще? Перед вами объективный инструмент. Без предметного разговора с набором данных и фактов может получиться "испорченный телефон" а-ля клоунада в стиле небезызвестного Полунина. Вместо "асисяй" есть диагностика:
  7. На сайте разработчика вы всегда можете скачать свежую версию модуля независимо от того, где он был куплен.
  8. Чисто для примера что такое битое исходное изображение: Внутри файла находится только часть изображения, а после этой правильной порции байтов идет далее хаотическая комбинация. Учитывая, что многие пользуются парсерами для закачки картинок, то такая ситуация бывает нередкой. Кстати, imagick вылетает с фатальной ошибкой при попытке чтения подобных файлов. Но в модуле Компрессор сделан обход этой исключительной ситуации для возможности нормального выполнения скрипта в такой нештатной ситуации. Модулю Компрессор не страшна такая ситуация. Обычные же классические решения, которые используют imagick, заканчивают выполнение скрипта с фатальной ошибкой. Разумеется, что лишь с некоторым опытом использования я встречался с подобными редкими проблемами как битые исходники. И, соответственно, находил программные решения их устранения. В ранних версиях модуля такая проблема также могла остановить выполнение скрипта. Поэтому пользуйтесь актуальными версиями! да, и назовите хоть одного разработчика, который работает с изображениями и учитывает подобные нюансы? Я уже молчу про учет разных версий imagick (imagemagick), которые ведут себя различно. А некоторые хостеры до сих пор используют древние версии imagemagick вроде 6.* (6.3 например), в которых есть баги, давно исправленные в новых imagemagick. В общем, приходится, мне отдуваться и за хостеров, которые не следят за актуальностью софта. Но в модуле учтены особенности imagemagick различных версий 6.* и 7.*.
  9. Напоминаю, что в модуле есть отладчик. Который показывает с точностью до миллисекунды на что тратится время и что делает модуль. Может показать вам битые исходники, которые не могут быть прочитаны. Пользуйтесь! Отладчик находится в открытой части кода, а потому видно, когда начинается замер и когда он заканчивается. Вы можете увидеть подробный отчет по каждому файлу изображения. Если изображение исходника битое, то это может вызывать проблему чтения такого изображения. Отладка это покажет. Кстати, проблема битого источника будет проявляться в любой сборке opencart. Будут бесконечные попытки при очередном открытии страницы обработать такой файл. В актуальных версиях модуля Компрессор есть механизм, который не позволяет делать бесконечные попытки чтения битых файлов. Например, при создании изображений по расписанию, дается N-е количество попыток прочитать нечитаемое исходное изображение, по истечении таких попыток оно помечается как битое и дальнейшие попытки прекращаются. Используйте актуальную версию модуля Компрессор! В модуле есть медицинские средства, но которые не надо держать постоянно включенными:
  10. Специально для всех, кого волнует скорость работы модуля Компрессор. Во-первых, всегда используйте актуальную (свежая сейчас 1.17.*) версию Компрессора. Теперь про то, кто или что "не очень дружит с датами." Проблема с датами идет от Даниеля и есть во всех релизах opencart 2.* и ocstore 2.*. Она и сейчас не устранена в ocstore 2. Даниель сделал исправление лишь в опенкарт 3.0. Вот на эту проблему и я в свое время попался, "поверив" коду Даниеля, точнее, оставив часть его кода у себя в модуле. Позже я предельно внимательно анализировал данный вопрос и внес исправления в свой модуль. И эти исправления заодно решают ошибку, которую заложил создатель опенкарта Даниель. Уже много месяцев если не год как модуль Компрессор использует исправленный механизм контроля за датами файлов. Думаю, что только не отвечающий за свои слова человек будет кричать про то, что автор Компрессора не устраняет скрытые проблемы. Данная проблема была именно скрытая, т.к. проявляется только в определенных ситуациях, и, как минимум, 95% пользователей никогда с ней не столкнется даже без исправления этой ошибки. Но она давно уже исправлена. Нет этой ошибки ни в текущей версии модуля 1.14 для опенкарт 1.5, ни, тем более, в 1.17 версиях для опенкарт 2 и опенкарт 3. Предполагаю, что кто-то может еще жить в прошлом и, вероятно, находить проблемы в старых версиях модуля. Интересно, а зачем тогда автор модуля выпускает обновления? Вероятно, что с целью улучшения функционала и устранения найденных нестыковок, несовместимостей и прочих проблем? Не так ли? Обычно так работают все ответственные разработчики. Если кто-то найдет ошибку в модуле версии 1.17, то, пожалуйста, приходите с баг-репортом. Все разберем и поправим если будет, что поправить. И, господа, не будет ли странным при уже наличии версии 1.17 (и беты 1.18) пытаться искать несовершенства, баги и пр. в старых версиях вроде 1.8 или 1.9, коим уже полтора года? Любой пользователь модуля может открыть файл модуля (он не закодирован) image model for OpenCart и причитать комментарий в начале файла. class ModelToolImageBySitecreator extends Model { public function resize($filename, $width, $height, $type = '', $market = '', $text_for_market = '') { // +++++++++++++++++++++++++++++ комментарий от sitecreator.ru +++++++++++++++++++++++++++++++++++++ // Для контроля времени создания файлов // используем везде filemtime() (Возвращает время последнего изменения файла) // использование filectime() не годится, т.к. в случае изменения файла время изменения меняется, но filectime() будет возвращать // "время создания файла" (в кавычках потому, что в Linux не существует такого понятия), точнее - // возвращает время изменения индексного дескриптора файла, что обычно совпадает с временем создания файла на сервере // https://www.php.net/manual/ru/function.filectime.php // Примечание. На большинстве платформ Unix, файл считается измененным, если изменены данные его индексного дескриптора, // что включает информацию о правах на файл, о его владельце, группе и другие метаданные, содержащиеся в индексном дескрипторе. // даже при полном изменении (перезаписывании или удалении) файла filectime() возвратит точно такое же значение как до изменения файла // если не менялись данные его индексного дескриптора // filectime() - это именно время изменения индексного дескриптора, но не содержимого файла. // filectime() использовался в opencart вплоть до 2.3 версии, что является принципиальной ошибкой, порождающей иногда многократные (бесконечные) попытки // перезаписи файла в случае изменения (контента) исходного файла. // ---------------------------- комментарий от sitecreator.ru ------------------------------------------------------------------- // +++++++++ отладчик +++++++++++++++++++++++++++
  11. Уважаемые пользователи плагина, просьба оставить свой отзыв о работе плагина и его поддержке. Это поможет сделать продукт еще лучше. Отзыв можно оставить здесь: https://opencartforum.com/files/file/5408-uluchshaem-izobrazheniya-obrezka-lishnego-ishodnogo-fona-i-t-d/?tab=reviews Большинство купивших плагин купили его одновременно с модулем Компрессор: Но данный плагин, который в основном позволяет красиво избавиться от лишнего фона исходников по-сути является самостоятельным и довольно сложным решением, хоть и входящим в состав комплекта "Image COMPRESSOR & Watermark & WebP & Lazy Load etc. by Sitecreator".
  12. Возможность всегда есть. Было бы желание. Вас же не цепями к хостеру привязали? вообще то он не работает по фтп протоколу. а вы просили Практически любой менеджер файлов на php не использует FTP протокол. KodExplorer - не исключение в этом плане, нет в нем по-умолчанию ftp. Но сам менеджер весьма толковый, хоть и не всегда безопасный (уязвимости периодически обнаруживаются и устраняются)
  13. Уже почти год как браузеры FireFox и Microsoft Edge поддерживают стандарт сжатых изображений WEBP. Модуль Компрессор - это единственное решение, которое без проблем детектирует поддержку браузером WEBP. И, соответственно поставляет в браузер WEBP если он его поддерживает или JPEG, PNG если не поддерживает. Модуль не путает старый и новый FireFox, старый и новый Microsoft Edge. Даже когда нет от браузера запроса с явным указанием поддерживаемых форматов, то модуль Компрессор безошибочно распознает поддержку WEBP, и не полагается на такой запрос, который может быть либо ошибочный, либо может вообще отсутствовать, например, в случае динамической подгрузки контента. Соответственно с верным детектированием браузера с поддержкой WEBP формируется страница с WEBP-изображениями. Новый Microsoft Edge:
  14. Сделаю немного позже. Просто для 2.3 еще есть альтернатива в выборе другого редактора, а для 3-ки - нет.
  15. Версия модуля для opencart, ocstore 3.0 также приведена в актуальное состояние. новая версия 1.1.7.4 для OPENCART 3.0
×

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.