20.01.2024 в 12:01, AlexDW сказал:

внезапно

давно известна дислокация этой помойки.

вроде бы, ни для кого это секретом и не было.

еще одна ассоциированная с феофаном помойка, которая тоже упоминалась (и были разборки) тут неоднократно:
 

Регистрация у самого известного регистратора/провайдера, там же и сервера находятся. По крайней мере, пока варезники не включили cloudflare для собственной безопасности  безнаказанности, у них IP были от того же хостинг-провайдера. Казалось бы, почему не обращались напрямую с жалобой к этому провайдеру?

Да и что сейчас мешает обратиться к регистратору?

20.01.2024 в 12:01, AlexDW сказал:

и призвать его организаторов к ответу в судебном порядке

Единая юрисдикция должна бы способствовать решению вопроса.

Видимо, глюк системы, который, скорее всего, уже поправили.

На этом форуме продажи модулей авторов из РФ и РБ  приостановлены администрацией.

создатели ioncube устранили баг в loader. Об этом они рапортовали.

Исправление бага есть в версии 12.0.4 и более новых.

Версия модуля 3.2.0 актуальна и работает без проблем с обновленным ионкуб loader 12-й версии.

Версия модуля 5.0 способна работать и на ионкубе с багом, т.е. на 12-й до 12.0.3 и на других 12-х (от 12.0.4 и новее)

08.11.2022 в 12:37, olegodessa сказал:

где скачать новую версию?

Здравствуйте.

Поддержка по email.

С версии 5.0.0 используется новая схема лицензирования.

Старый ключ не подойдет.

Автоматически лицензией поддерживаются поддомены, т.е. не нужны отдельные ключи для поддоменов.

Поддержка мульти-доменов.

Версия модуля 5.0.0 beta

Модуль Image COMPRESSOR & Watermark & WebP & Lazy Load etc. by Sitecreator

готова.

Сделана с учетом имеющегося бага в ioncube loader 12-й версии.

А поэтому нормально работает совместно с ioncube loader 12-й версии.

Также работает с ioncube loader 10, 11

с версиями php:

от 5.6 до 7.4 включительно, т.е.:

php

5.6, 7.0, 7.1, 7.2, 7.3, 7.4

От аномального поведения невозможно избавиться.

удаляем NULL байты, но вместо удаления либо появляются новые, либо удаляются только конечные и начальные.

Чудеса! Точнее, это баги.

Пробовал так бороться:

$pattern_for_tags = '';

$pattern_for_tags = str_replace("\0", '', $pattern_for_tags);
echo "\nЭто тоже после удаления NULL-ей pattern_for_tags\n";
echo $pattern_for_tags;

$pattern_for_tags = trim($pattern_for_tags);
echo "\nЭто тоже после TRIM pattern_for_tags\n";
echo $pattern_for_tags;

Но, как говорится фиг вам.  php с кубом стоят на своем.

видимо, без покупки енкодера 12 удивительный баг не побороть.

Хороший маркетинговый ход у разработчиков ионкуба. Создать баг в новом loader-е, для исправления которого нужно купить новый энкодер 12-й версии за $300.

Видать, с продажами энкодера 12-го совсем плохо.

Да и зачем он нужен то?

Поддержки php 8 в нем нет и не будет. А кому нужна поддержка 8.1, собственно, для которой он и сделан?

Все, что сделано на 10-м и 11-м энкодорах работало без проблем все последние годы. И работает сейчас... пока хостер не поставит 12-й ioncube loader.

И, не факт, что применение 12-го энкодера позволит решить проблему. Это как лотерея.

Может быть, что это неустранимый баг 12-й версии ioncube loader-а.

Еще для программистов.

И все могло бы быть не так страшно, но баг ioncube напоролся на признанный баг самого движка php, который описан здесь:

https://bugs.php.net/bug.php?id=77726

Т.е. это поведение официально признано багом и известно разработчикам PHP. Проблему фиксили.

Но хостеры не спешат ставить обновленную версию PHP, в которой отсутствует данный баг.

вот ссылка на фиксы данного бага:

https://github.com/php/php-src/pull/8114

В принципе этот баг самого PHP и не проявился бы если бы ioncube loader не напихал нам нулевых байтов.

вот тест:

<?php

preg_match("/a".chr(0)."bc/", 'abc');

preg00.php

файл прилагается.

запустите этот файл. Или создайте файл сами. Если вы увидите сообщение об ошибке:

Warning: preg_match(): Null byte in regex in ...\preg00.php on line 3

то это значит, что у вас еще версия PHP с багом.  А хостер не заменил ее на версию без бага.

Итого, что имеем?

Удивительный случай когда баг ioncube loader встретился с багом движка PHP.

При совершенно валидном изначальном  коде.

preg00.zip

Программистам может быть интересно.

Исходный код:

$pattern_for_tags = '';
echo "\nЭто тоже 000 pattern_for_tags\n";
echo $pattern_for_tags;

элементарнейший код.

Присвоили переменной пустую строку. И сразу же вывели ее. Ожидали, что будет выведена пустая строка. Т.е. на выходе не будет ничего.

а вот, что имеем на выходе с ioncube loader 12-й версии:

смотрим в браузере в "исходный код".

php + ионкуб превратили пустую строку в последовательность шестнадцатеричных нулей.

Чудеса? Нет, это баг.

Т.е. ионкуб пихает в строки последовательности нулей.

И это даже будет незаметно до поры, до времени. Т.к. браузер даже не чихнет на эти лишние нули, т.к. он их просто не отобразит. И вам будет казаться, что все работает.

Но как только вы такую строку захотите использовать как паттерн для регулярного выражения, то php начинает ругаться на нули, т.к. они, действительно, там появились.  И впихнул их именно ioncube loader 12-й версии по одному ему ведомой прихоти.

И делает он это не закономерно, т.е. в начале кода эта строка будет обработана нормально, например, но в другом месте будут подставлены нули.  Т.е. тут как повезет.

Проблема к модулю не имеет никакого отношения.

Я даже посмотрел исходник на PHP в hex формате. А не затесался ли там нечитаемый символ?

Нет. Там четко есть пустая строка - это только кавычки, и больше ничего.

Думаю, что в лоб это можно попробовать вылечить используя энкодер 12-й.

PHP Warning:  [obfuscated](): Null byte in regex in 

вот такая ошибка движка PHP появляется при смене ioncube loader на 12-ю версию.

сопровождаться может также 503-й ошибкой сервера и т.д.

на деле нет никаких null byte в regex. Специально смотрел с отладкой. Чистой воды баг от ионкуба.

Если в журнале ошибок опенкарт увидите вышеприведенную ошибку (Null byte in regex), то смотрите версию ионкуба.

через phpinfo(). Ее генерирует именно 12-й ионкуб.

Версию ioncube loader меняет хостер на общем хостинге. Релиз 12-й ioncube loader стартовал в середине августа 2022-го.

Т.е. пока крайне сырая версия, но некоторые хостеры поспешили уже перейти с 11-й на 12-ю. Хотя обычно дают устаканиться сырому продукту, т.е. дожидаются когда массовые баги отловят в первые несколько месяцев. Месяц-два - это не срок чтобы такого рода продукт перестал быть сырым.

Пользователям VDS автоматический переход на 12-ю не грозит.

Не возникает проблем на любой версии PHP от 5.6 до 7.4 включительно с ioncube loader  10-й или 11-й веток.

Думаю сделать обновление модуля с учетом бага в связке php-ioncube loader 12- й версии.

Многие хостеры дают возможность выбора версии ioncube loader. Во избежание проблем выбирайте 10-ю или 11-ю версию.

По идее компания ioncube старается обеспечить обратную совместимость программ (и энкодеров более ранних версий) со всеми версиями ioncube loader.

Но когда это не получается у компании ioncube , то она предлагает перекодировать программы новым энкодером, т.е. энкодером 12-й версии чтобы не было проблем с ioncube loader 12-й версии.

Так компания ioncube видит работу над устранением багов, порожденных самой же компанией ioncube.

Чтобы устранить баг компания ioncube предлагает купить 12-й энкодер.

Вероятно, что я даже рассмотрел бы сейчас покупку ($300) 12-го энкодера чтобы решить проблему. И сделал бы обновление.

Но обновление модуля запрещено сейчас на форуме.

Никто из покупателей все равно не сможет скачать обновленную версию программы здесь.

Поддержка ограничена только текстовыми сообщениями в этой теме.

Как решить этот организационный момент я пока не знаю.

Когда появится обновление, то я сообщу в этой теме. Постараюсь закрыть этот вопрос.

Но скачать здесь вы его не сможете (см. выше)

Обратился ко мне давний заказчик с проблемой.

Модуль куплен еще в январе 2018-го.

Исправно работал почти 5 лет.

И тут вдруг очень странные ошибки...

стала непонятно откуда тянуться отладочная информация. При этом страница делает через jquery отдельный запрос страницы (самой себя) через POST и вставляет сама отладочную информацию, причем, похоже старую и закешированную где-то...

Т.е. в самом коде HTML этой информации нет.

И модуль Компрессор не делает никаких самостоятельных запросов с подкачкой страниц или их частей. В нем даже такого функционала нет.

Могу предположить, что проблема возникла не на пустом месте, а после какого-то изменения на сайте. 

Включили какой-то ускоритель/кешер и т.д. и т.п. как пример.

Хотя со всеми известными мне ускорителями проблем никогда не было.

Пока загадочное поведение, которое вызвано явно не модулем Компрессор. Ибо в течение 5 лет никаких проблем не было.

@SergL4S , вопрос, аналогичный вашему. Ничего подобного ранее не встречалось.

Напишу позже, что это за полтергейст проявился. Когда разберусь.

10.10.2022 в 10:51, Drovocek сказал:

не думаю что проблема в изображениях

гадать - дело бессмысленное. В каждом конкретном случае лучше смотреть непосредственно.

 Указал на проблемы, которые реально встречались неоднократно. И они именно с изображениями. В каждой новой версии Модуля уделялось пристальное внимание борьбе с поврежденными изображениями и вносились средства для устранения повреждений или обхода таких повреждений.

Если заказчик обратится ко мне с доступами в личку или на почту, то смогу с большой вероятностью показать эти проблемные изображения. Если актуально.

10.10.2022 в 10:51, Drovocek сказал:

ошибки были не только связаны с изображением

это ошибки не модуля и даже не ошибки кода php.

а это уже проблема конкретного движка php. Не кода php, а именно самого движка php. Она известна, хоть и очень редкая, и описывается как баг самого движка php.

Это говорит лишь о том, что идеального кода не существует и время от времени  всплывают экзотические, т.е. крайне редкие, ошибки, предсказать которые невозможно.

В таких случаях помогает смена версии php на ту, в которой данный баг устранен или его там не было изначально. Баг есть не во всех версиях php.

Этот баг в движке php устранен только в июне 2022 года в самых свежих версиях php, хотя известен с 2019-го года.

Описание именно этого бага движка php, это признано именно багом движка php (баг с конкретным номером, зафиксированным на bugs.php.net: https://bugs.php.net/bug.php?id=77726 ). Встречается крайне редко. Но баг остается багом разработчиков php.

Здравствуйте.

битый исходный файл, либо этот файл огромного размера и памяти хостинга не хватает чтобы его переварить.

НЕредкость, когда загружают исходники прямо из телефона размером по 10-15М и даже больше. На VDS в таких случаях помогает увеличение выделенной памяти для php, например128 М уже не хватит для такого файла, надо ставить 512М.

Но хостинг в принципе не рассчитан на такое, это же не фотошоп на ПК...

После парсинга могут быть битые файлы, т.к. парсинг в принципе не контролирует целостность получаемых данных, да и нередко вносит еще свои ошибки (меняет тип файла и т.д.).

Выход: удалить проблемный файл. Но для начала скачайте его и посмотрите.

Но то, что вы показываете, это не ошибка, это просто отчет о диагностике, успешный при этом.

Ошибка, видимо, ниже, ее вы уже не видите. Повторюсь, большой файл может подвесить хостинг.  И дело тут не в модуле.

12.09.2022 в 14:09, vladimirkepel сказал:

Подскажите в чем дело

Так у вас проблем миллион.

Одно выполнение JS в течение более чем 30 сек чего стоит!!!

На этом фоне отклик сервера в 2 сек кажется детским лепетом.

Надо работать с сайтом тщательно и долго.

Реально поднять скорость по версии гугла до 90+ баллов.

Пишите на почту, подскажу и помогу.

А картинки у вас оптимизированы в webp.

Но за счет моего модуля можно лучше сделать оптимизацию изображений. Гугл рекомендует:

Но, повторюсь, проблему нужно в комплексе решать.

21.07.2022 в 10:15, SergL4S сказал:

Есть список изменений в последней обнове?

В основном изменения связаны с повышением совместимости в разных специфических ситуациях, функционально это незаметно, проявляется в очень редких случаях.

4-я версия умеет работать с webp как входным форматом. Это нужно если после автоматического парсинга у вас webp оказались в папке исходников или, например, нужно когда вручную загружаются webp как исходники.

Прошу заметить, что это дополнительная платная опция, которая нужна далеко не всем.

16.07.2022 в 10:14, MrZlobnyj сказал:

opencart ухудшает качество изображений

нет, не ухудшает.

смотреть нужно на конкретных примерах.

можно с уверенностью в 100% сказать, что формат PNG невозможно ухудшить, т.к. это формат без потерь.

По JPEG нужно смотреть конкретные примеры. Выше вам верно уже заметили когда вы можете увидеть "ухудшение".

Также имеет значение то, на каком устройстве вы смотрите, точнее, какова плотность пикселей, т.к. экраны Ретина и прочие с двойной плотностью пикселей могут вводить вас в заблуждение. Это заблуждение заключается в том, что вы можете, например, смотреть картинку в прямоугольнике определенного постоянного размера, но картинка "двойной плотности" будет выглядеть в нем лучше чем картинка одинарной плотности, но это "лучше" будет вовсе не из-за того, что качество картинки "двойной плотности" будет выше, эффект будет из-за разницы в размерах картинок в пикселях по ширине и высоте.

опенкарт использует графическую библиотеку GD. Все упирается именно в нее.

imagick позволяет использовать более качественный ресайз, особенно в сторону увеличения, т.е. из маленького в большое, это по сравнению с GD.

Но imagick имеет также свои ограничения, хоть и способен делать исключительно качественный ресайз с бикубической интерполяцией, но эта возможность почти всегда отключена на общем хостинге, да и на немногих VDS она доступна из-за того, что время работы такого ресайза увеличивается на порядок, а на серверах банально нет такой мощности чтобы позволить обрабатывать подобные задачи. Тот же Фотошоп позволяет вам использовать бикубическую интерполяцию для максимально качественного ресайза, но у вас в распоряжении вся мощь целиком вашего компьютера, хостер вам выделяет лишь чуть-чуть мощности.  Для мощных "художественных" задач нужен мощный сервер соответственно. А так практически всегда вам доступна на сервере лишь билинейная интерполяция как наиболее быстрая и дающая в большинстве случаев отличную картинку.  99% пользователей вообще не заметят разницу между бикубической и билинейной  интерполяцией при ресайзе изображений.

Максимум, что можно получить для работы с изображениям в опенкарт, умеет делать модуль, ссылка ниже.

Умеет, например, создавать сжатые/преобразованные png в webp без потерь (lossless).  В этом случае даже сжатый (за счет webp) png будет выглядеть идеально, но весить значительно меньше.

10.07.2022 в 16:46, azazel7f сказал:

Работает ли с Journal 3?

не проверял. В специфике этого шаблона есть свои нестандартные особенности, поэтому всякое может быть.

Кстати, никто не смог мне для тестов предоставить официальный (легальный) дистрибутив этого шаблона.

Кстати, использовать библиотеку GD в качестве генератора webp, даже если заявлена поддержка webp - это не очень хорошая идея.

Во-первых GD очень часто не умеет работать с прозрачным фоном изображений, в итоге у вас появляются на выходе webp с черным фоном.

Во-вторых GD вплоть до довольно свежих версий выдает в огромном количестве битые webp, которые многие браузеры (в первую очередь на базе Хром) не способны отобразить, в итоге получаете картинки-невидимки.

Если коротко, то в GD реализация webp выполнена крайне глючно, это даже не бета-версия, а чаще альфа-версия, соответственно со всеми проблемами.

Поэтому с GD надо быть крайне осторожным.

Я в своем модуле Компрессор постарался нивелировать проблемы, которые создает GD.

Так, чтобы не создавался черный фон вместо прозрачного я заменяю его белым принудительно (если включить соотв.опцию).

Битые после GD файлы webp проходят в модуле доп. обработку для ремонта файла, после этого они становятся читаемые всеми браузерами, способными понимать webp.

Модуль Компрессор в принципе не зависит от графических библиотек и их возможностей, но может их использовать при вашем осознанном выборе.

И даже если хостер не предлагает никакой поддержки webp в графических библиотеках (GD, imagick), то модуль Компрессор все равно умеет создавать webp.

И умеет это делать в фоновом режиме совершенно без лишней нагрузки на сервер и без тормозов страниц в момент создания изображений.

30.06.2022 в 16:45, flaero сказал:

Есть решение по заливке фоток WebP для 2.3?

Не могу спарсить нормально товары, так как сайт-донор отдает фотки в WebP и у меня на сайте они соответственно не отображаются.

Кто может помочь с решением?

Решение есть. Правда, в базовые возможности моего модуля это не включено. Но доступно как отдельная опция. Поскольку это нужно немногим, то и сделано как доп. опция.

Модуль, который умеет все делать с webp, наверное, вы знаете:

Для уточнения нюансов можете написать мне на мою почту или в личку на крайний случай.

27.06.2022 в 22:08, Evg_Onegin сказал:

Подскажите пожалуйста, а когда выложите этот функционал?

В ближайшее время не планирую. Т.к. дистрибутив теперь будет с защитой.

Иначе нет смысла что-то делать.

23.06.2022 в 22:23, k2825435 сказал:

Доброго дня!

Здравствуйте.

Живой.

Единственное, что я не сделал пока - это не подготовил (не залил) новый дистрибутив с функционалом вставки нескольких картинок одним кликом.  Т.е. в дистрибутиве, который здесь есть, такого функционала пока нет. Пока отложил.  Остальное все работает, в том числе были обновления для поддержки php 7.4.

24.04.2022 в 14:17, iler сказал:

но есть проблема с фотками в формате webp. Товары с таким форматом фотки импортируются но без фотки.

учтите, что как только у вас появятся товары с загруженными картинками в webp, то вы получите новую проблему.

Опенкарт не умеет обрабатывать webp в качестве входного формата, т.е. он не сможет положить в папку кеша изображений картинки товара.

И на вашем сайте вы их снова не увидите.

Я сделал в своем модуле возможность работы с webp в качестве входного формата, т.е. для случаев парсинга, импорта картинок товаров и категорий в webp. Разумеется, что и вручную картинки webp могут быть загружены, а не появиться только врезультате импорта и парсинга.

Для этого есть отдельная опция при покупке модуля, если вам это необходимо, то вы выбираете это при покупке.

Вероятно , что картинки в webp у вас загрузились, но вы их не видите потому, что они не могут быть обработаны. Т.е. проблема может быть не в модуле "Диспечер XML", проверьте есть ли загруженные файлы, т.к. ваше:

24.04.2022 в 14:17, iler сказал:

но без фотки

может означать, что они не отображаются. Уточните этот момент, т.е. есть ли файлы и "фотки" не отображаются или файлов нет.

Решал подобные проблемы. И решение реализовал в своем модуле.

Аналогичная проблема.

Видимо временно (?) форум будет локальным для одной страны.

Насколько временно, думаю, что никто этого не скажет сейчас.

Однозначно, что форум выпадет из индекса Яндекса со всеми вытекающими.

Яндексу также запрещен доступ к страницам форума.

Цитата

Ответ "https://opencartforum.com" → Основной робот Яндекса

Код статуса HTTP	403 Forbidden
Время ответа сервера	104 мс
IP сайта	172.67.137.53
Кодировка	UTF-8(unicode-1-1-utf-8, UTF8)
Размер страницы	4,75 КБ

Помогу оперативно решить.

Есть огромный опыт в этом деле.

подробности можем обсудить в личке.