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

sitecreator

Users
  
  • Posts

    6,116
  • Joined

Technical support

  • Holidays
    Сб
    Вс
  • Other
    Работаю со всеми без ограничений

Information

  • Gender
    Мужчина
  • City:
    Москва
  • Interests
    программист

Recent Profile Visitors

62,281 profile views

sitecreator's Achievements

Grand Master

Grand Master (14/14)

  • Dedicated Rare
  • First Post
  • Collaborator
  • Posting Machine Rare
  • Reacting Well Rare

Recent Badges

1.2k

Reputation

  1. давно известна дислокация этой помойки. вроде бы, ни для кого это секретом и не было. еще одна ассоциированная с феофаном помойка, которая тоже упоминалась (и были разборки) тут неоднократно: Регистрация у самого известного регистратора/провайдера, там же и сервера находятся. По крайней мере, пока варезники не включили cloudflare для собственной безопасности безнаказанности, у них IP были от того же хостинг-провайдера. Казалось бы, почему не обращались напрямую с жалобой к этому провайдеру? Да и что сейчас мешает обратиться к регистратору? Единая юрисдикция должна бы способствовать решению вопроса.
  2. Видимо, глюк системы, который, скорее всего, уже поправили. На этом форуме продажи модулей авторов из РФ и РБ приостановлены администрацией.
  3. создатели ioncube устранили баг в loader. Об этом они рапортовали. Исправление бага есть в версии 12.0.4 и более новых. Версия модуля 3.2.0 актуальна и работает без проблем с обновленным ионкуб loader 12-й версии. Версия модуля 5.0 способна работать и на ионкубе с багом, т.е. на 12-й до 12.0.3 и на других 12-х (от 12.0.4 и новее)
  4. Здравствуйте. Поддержка по email. С версии 5.0.0 используется новая схема лицензирования. Старый ключ не подойдет. Автоматически лицензией поддерживаются поддомены, т.е. не нужны отдельные ключи для поддоменов. Поддержка мульти-доменов.
  5. На фоне пока неустраненного бага в ioncube loader 12.0.2 ( релиз от 2022-09-09) компания ioncube решила поднять цены на энкодеры. Pro версия вместо $299 стоит теперь $344. На фоне обнаруженного бага неплохой коммерческий ход? Можно пока не спешить с устранением бага в ioncube loader 12, но при этом намекнуть, что баг можно обойти за счет покупки нового энкодера. Вроде как у разработчиков и выхода другого нет, так почему бы заодно и цену не поднять? Непонятно как некоторые хостеры ухитрились поставить настолько сырой и непроверенный софт? Куда и зачем они так торопились, что поставили софт, которому меньше месяца с момента самого первого релиза 12-й? Подождать несколько месяцев до стабильной (исправленной от багов) и проверенной версии никак нельзя было? Ведь понятно, что в первые месяцы после релиза нового продукта идет отлов тех самых багов. Матерые хостеры, например, никогда не торопятся. Для них важна стабильность и репутация. Я бы еще понял установку ioncube loader 12 для php 8.1, там хотя бы смысл есть. Но для предыдущих версия php нет смысла.
  6. требования: 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 добавлена поддержка лицензирования мультимагазинов на разных доменах. Т.е. это могут быть не только разные поддомены на основном одном домене, но и совершенно разные домены в принципе.
  7. Версия модуля 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
  8. После перехода некоторых хостеров на 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.
  9. От аномального поведения невозможно избавиться. удаляем 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-а.
  10. Еще для программистов. И все могло бы быть не так страшно, но баг 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
  11. Программистам может быть интересно. Исходный код: $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-й.
  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-го энкодера чтобы решить проблему. И сделал бы обновление. Но обновление модуля запрещено сейчас на форуме. Никто из покупателей все равно не сможет скачать обновленную версию программы здесь. Поддержка ограничена только текстовыми сообщениями в этой теме. Как решить этот организационный момент я пока не знаю. Когда появится обновление, то я сообщу в этой теме. Постараюсь закрыть этот вопрос. Но скачать здесь вы его не сможете (см. выше)
  13. Обратился ко мне давний заказчик с проблемой. Модуль куплен еще в январе 2018-го. Исправно работал почти 5 лет. И тут вдруг очень странные ошибки... стала непонятно откуда тянуться отладочная информация. При этом страница делает через jquery отдельный запрос страницы (самой себя) через POST и вставляет сама отладочную информацию, причем, похоже старую и закешированную где-то... Т.е. в самом коде HTML этой информации нет. И модуль Компрессор не делает никаких самостоятельных запросов с подкачкой страниц или их частей. В нем даже такого функционала нет. Могу предположить, что проблема возникла не на пустом месте, а после какого-то изменения на сайте. Включили какой-то ускоритель/кешер и т.д. и т.п. как пример. Хотя со всеми известными мне ускорителями проблем никогда не было. Пока загадочное поведение, которое вызвано явно не модулем Компрессор. Ибо в течение 5 лет никаких проблем не было. @SergL4S , вопрос, аналогичный вашему. Ничего подобного ранее не встречалось. Напишу позже, что это за полтергейст проявился. Когда разберусь.
  14. OpenLiteSpeed - вполне достойная альтернатива Апачи (или связке Nginx+Apache или чистому Nginx). Если у вас не миллион посетителей в день, то это вполне разумный выбор, учитывая относительную простоту настройки и совместимость с конфигами Апачи. Плюсом будет то, что в OpenLiteSpeed есть нативный кеш для опенкарт. Т.е. не нужно ставить внешние костыли вроде кешировщиков, написанных на php, т.к. нативное кеширование от OpenLiteSpeed для опенкарт справляется с этим лучше. Даже если сравнивать с чистым Nginx, то OpenLiteSpeed с включенным кешированием для опенкарт будет предпочтительнее. Конечно, многое зависит от настроек и их умелого использования. Кстати, aapanel позволяет поиграться с разными webp серверами, переключать их и сравнивать результаты. aapanel тоже поддерживает OpenLiteSpeed, чистый Nginx, Apache. Т.е. можно говорить про довольно высокую гибкость в настройках и перехода с одного web-сервера на другой. CyberPanel - это детище разработчиков OpenLiteSpeed, по этой причине в ней нет выбора иного веб-сервера кроме OpenLiteSpeed. OpenLiteSpeed на практике показывается себя очень хорошо. Но если у вас есть возможность и желание добиться лучших результатов, например, на чистом Nginx, то, разумеется, вы выбираете Nginx раз вам он кажется более удобным и перспективным. Разработчики CyberPanel умело заняли свою нишу.
  15. гадать - дело бессмысленное. В каждом конкретном случае лучше смотреть непосредственно. Указал на проблемы, которые реально встречались неоднократно. И они именно с изображениями. В каждой новой версии Модуля уделялось пристальное внимание борьбе с поврежденными изображениями и вносились средства для устранения повреждений или обхода таких повреждений. Если заказчик обратится ко мне с доступами в личку или на почту, то смогу с большой вероятностью показать эти проблемные изображения. Если актуально. это ошибки не модуля и даже не ошибки кода 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.
×
×
  • 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.