sitecreator

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

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

создатели ioncube устранили баг в loader. Об этом они рапортовали. Исправление бага есть в версии 12.0.4 и более новых. Версия модуля 3.2.0 актуальна и работает без проблем с обновленным ионкуб loader 12-й версии. Версия модуля 5.0 способна работать и на ионкубе с багом, т.е. на 12-й до 12.0.3 и на других 12-х (от 12.0.4 и новее)

Здравствуйте. Поддержка по email. С версии 5.0.0 используется новая схема лицензирования. Старый ключ не подойдет. Автоматически лицензией поддерживаются поддомены, т.е. не нужны отдельные ключи для поддоменов. Поддержка мульти-доменов.

На фоне пока неустраненного бага в ioncube loader 12.0.2 ( релиз от 2022-09-09) компания ioncube решила поднять цены на энкодеры. Pro версия вместо $299 стоит теперь $344. На фоне обнаруженного бага неплохой коммерческий ход? Можно пока не спешить с устранением бага в ioncube loader 12, но при этом намекнуть, что баг можно обойти за счет покупки нового энкодера. Вроде как у разработчиков и выхода другого нет, так почему бы заодно и цену не поднять? Непонятно как некоторые хостеры ухитрились поставить настолько сырой и непроверенный софт? Куда и зачем они так торопились, что поставили софт, которому меньше месяца с момента самого первого релиза 12-й? Подождать несколько месяцев до стабильной (исправленной от багов) и проверенной версии никак нельзя было? Ведь понятно, что в первые месяцы после релиза нового продукта идет отлов тех самых багов. Матерые хостеры, например, никогда не торопятся. Для них важна стабильность и репутация. Я бы еще понял установку ioncube loader 12 для php 8.1, там хотя бы смысл есть. Но для предыдущих версия php нет смысла.

требования: php 5.6+ (5.6, 7.0, 7.1, 7.2, 7.3, 7.4) Ioncube Loader (версия 10+ обязательна) . Проверенные версии: 10, 11, 12. Для Ioncube Loader 12 (который содержит баг) найдено решение для обхода этого бага, и версия модуля 5.0.0 (и выше) работает стабильно. Кроме того, в Компрессор 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

После перехода некоторых хостеров на Ioncube loader 12 с 10-й или 11-й версии начали появляться чудеса в виде ошибок, которых никогда не было ранее, А именно: PHP Warning: [obfuscated](): Null byte in regex in При том, что код абсолютно валидный. И никаких проблем на 10-й или 11-й версии ioncube loader не возникало на любой версии php от 5.6. до 7.4. Откуда же взялись нулевые байты в regex? Программистам может быть интересно. Исходный код: $pattern_for_tags = ''; echo "\nЭто тоже 000 pattern_for_tags\n"; echo $pattern_for_tags; элементарнейший код. Присвоили переменной пустую строку. И сразу же вывели ее. Ожидали, что будет выведена пустая строка. Т.е. на выходе не будет ничего. а вот, что имеем на выходе с ioncube loader 12-й версии: смотрим в браузере в "исходный код". php + ионкуб превратили пустую строку в последовательность шестнадцатеричных нулей. Чудеса? Нет, это баг. Т.е. ионкуб пихает в строки последовательности нулей. И это даже будет незаметно до поры, до времени. Т.к. браузер даже не чихнет на эти лишние нули, т.к. он их просто не отобразит. И вам будет казаться, что все работает. Но как только вы такую строку захотите использовать как паттерн для регулярного выражения, то php начинает ругаться на нули, т.к. они, действительно, там появились. И впихнул их именно ioncube loader 12-й версии по одному ему ведомой прихоти. И делает он это не закономерно, т.е. в начале кода эта строка будет обработана нормально, например, но в другом месте будут подставлены нули. Т.е. тут как повезет. Проблема к коду PHP не имеет никакого отношения. Я даже посмотрел исходник на 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-й веток. Многие хостеры дают возможность выбора версии ioncube loader. Во избежание проблем выбирайте 10-ю или 11-ю версию. По идее компания ioncube старается обеспечить обратную совместимость программ (и энкодеров более ранних версий) со всеми версиями ioncube loader. Но когда это не получается у компании ioncube , то она предлагает перекодировать программы новым энкодером, т.е. энкодером 12-й версии чтобы не было проблем с ioncube loader 12-й версии. Так компания ioncube видит работу над устранением багов, порожденных самой же компанией ioncube. Чтобы устранить баг компания ioncube предлагает купить 12-й энкодер. И все могло бы быть не так страшно, но баг ioncube напоролся на признанный баг самого движка php, который описан здесь: https://bugs.php.net/bug.php?id=77726 Т.е. это поведение официально признано багом и известно разработчикам PHP. вот ссылка на фиксы данного бага: https://github.com/php/php-src/pull/8114 Но хостеры не спешат ставить обновленную версию PHP, в которой отсутствует данный баг. В принципе этот баг самого PHP и не проявился бы если бы ioncube loader не напихал нам нулевых байтов. вот тест: <?php preg_match("/a".chr(0)."bc/", 'abc'); запустите этот код. Если вы увидите сообщение об ошибке: Warning: preg_match(): Null byte in regex in ...\preg00.php on line 3 то это значит, что у вас еще версия PHP с багом. А хостер не заменил ее на версию без бага. Итого, что имеем? Удивительный случай когда баг ioncube loader встретился с багом движка PHP. При совершенно валидном изначальном коде. От аномального поведения невозможно избавиться. удаляем 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, собственно, для которой он и сделан? И, не факт, что применение 12-го энкодера позволит решить проблему. Это как лотерея. Может быть, что это неустранимый пока баг 12-й версии ioncube loader-а. ioncube репутацию свою подпортили, подложив такую свинью... Проблемный получился продукт № 12. По-хорошему нужно отказываться от применения ioncube. Тем более, что для 8-й версии PHP его нет и не будет никогда. Но есть для 8.1. Для 8-ки они вообще решили не делать. Какой-то удивительный подход у разработчиков ioncube.

От аномального поведения невозможно избавиться. удаляем 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 , вопрос, аналогичный вашему. Ничего подобного ранее не встречалось. Напишу позже, что это за полтергейст проявился. Когда разберусь.

OpenLiteSpeed - вполне достойная альтернатива Апачи (или связке Nginx+Apache или чистому Nginx). Если у вас не миллион посетителей в день, то это вполне разумный выбор, учитывая относительную простоту настройки и совместимость с конфигами Апачи. Плюсом будет то, что в OpenLiteSpeed есть нативный кеш для опенкарт. Т.е. не нужно ставить внешние костыли вроде кешировщиков, написанных на php, т.к. нативное кеширование от OpenLiteSpeed для опенкарт справляется с этим лучше. Даже если сравнивать с чистым Nginx, то OpenLiteSpeed с включенным кешированием для опенкарт будет предпочтительнее. Конечно, многое зависит от настроек и их умелого использования. Кстати, aapanel позволяет поиграться с разными webp серверами, переключать их и сравнивать результаты. aapanel тоже поддерживает OpenLiteSpeed, чистый Nginx, Apache. Т.е. можно говорить про довольно высокую гибкость в настройках и перехода с одного web-сервера на другой. CyberPanel - это детище разработчиков OpenLiteSpeed, по этой причине в ней нет выбора иного веб-сервера кроме OpenLiteSpeed. OpenLiteSpeed на практике показывается себя очень хорошо. Но если у вас есть возможность и желание добиться лучших результатов, например, на чистом Nginx, то, разумеется, вы выбираете Nginx раз вам он кажется более удобным и перспективным. Разработчики CyberPanel умело заняли свою нишу.

гадать - дело бессмысленное. В каждом конкретном случае лучше смотреть непосредственно. Указал на проблемы, которые реально встречались неоднократно. И они именно с изображениями. В каждой новой версии Модуля уделялось пристальное внимание борьбе с поврежденными изображениями и вносились средства для устранения повреждений или обхода таких повреждений. Если заказчик обратится ко мне с доступами в личку или на почту, то смогу с большой вероятностью показать эти проблемные изображения. Если актуально. это ошибки не модуля и даже не ошибки кода 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.