Yoda

Покурите мануал по suhosin - он очень много чего еще режет. Чтобы не было мучительно больно.

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

1 max input vars не может быть больше 10 000 2 вы уверены что это именно suhosin 3 даже если это он - смотрите в сторону suhosin.get.max_value_length

Нет. Сын путаете с opcache.

Попробуйте перенести его в футер.

Это профилактические методы, топик стартеру они не помогут. Да и использование системы контроля версий автоматически удорожает стоимость разработки. В данном случае необходима чистка системы, смена всех паролей и для пущей уверенности в спокойном сне крайне желательно поставить suhosin на сервер

На бегете отличные серваки. Но это как жить в красивом крепком доме вместе с табором цыган. Какой бы дом красивый и крепкий ни был туалет всегда будет занят, в гостиной всегда горит костёр и бродят медведи. Любой впс будет не сильно быстрее свежего шареда на бегете. Но ни один шаред не даёт возможности тонкой настройки системы и неограниченных ресурсов здесь и сейчас. Равно как ни один впс не работает быстро как дедик потому что даже если kvm все немного оверселлят и используют hyper threading, который гасит наглухо производительность процессора.

За коммит на Гите? Который фиксит системный баг? Вряд-ли.

Почему?

Пройдите в гитхаб сходите внимательно просмотрите. Ещё раз повторяю. Есть баг. Багу нужен фикс. Болтать не мешки ворочать. Хотите помочь? Оформите код и сделайте коммит. Это самый быстрый способ.

Ой ой ой. Гитхаб коммит - это не барское дело? По остальным багам. Добро пожаловать на гит, там очень много рефакторинга. Всё в ваших руках. Любые инициативы приветствуются.

Ну для того зачем я все время напрягаюсь. Чтобы донести какую то культуру отношения к сообществу и немного пересечь потреблядство. Меня аж выворачивает от этого всего. Мы такие умные. Мы тут баг нашли. Как можно. Нам же теперь чтобы наживать. Надо код переписывать. А то что никто из этих персонажей для развития темы пальцем не пошевелил. Так это же пусть лохи парятся. Мы гавномодулей напишем и будет нам покушать.

1 смотрим в гит сюда: https://github.com/opencart/opencart/blob/master/upload/catalog/controller/startup/seo_url.php строка 26. Даниэль Керр знать не знает ни про какие массивы. 2. Следим за руками... // Decode URL if (isset($this->request->get['_route_'])) { $parts = explode('/', $this->request->get['_route_']); //seopro prepare route if($this->config->get('config_seo_pro')){ $parts = $this->seo_pro->prepareRoute($parts); } В контроллер seo_url попадает не параметр $_GET а строка $this->request->get['_route_'], которая в нативном классе превращается в одномерный массив $parts. Который в свою очередь в seo_pro уже обрабатывается методом baseRewrite, в котором для каждого строковой части урла, разбитого на куски через разделитель '/' ищутся соответствия, в базе, которые могут указывать на тот или иной роут, соответствующий урлу. В каком месте туда может попасть массив? 3. С каких пор opencart стал YII и в CodeStyle стало принято передавать post-get данные многомерными массивами? 4. Если вы такие умные-кричащие, где вы уже два года с вашими коммитами на GIT? 5. Даже если вы отошли от принятого CodeStyle - кто мешает вам сделать исключения для ваших поделок в код ? 6. Смотрим в сео про 1.5 public function __construct($registry) { parent::__construct($registry); $this->cache_data = $this->cache->get('seo_pro'); if (!$this->cache_data) { $query = $this->db->query("SELECT LOWER(`keyword`) as 'keyword', `query` FROM " . DB_PREFIX . "url_alias"); $this->cache_data = array(); foreach ($query->rows as $row) { $this->cache_data['keywords'][$row['keyword']] = $row['query']; $this->cache_data['queries'][$row['query']] = $row['keyword']; } $this->cache->set('seo_pro', $this->cache_data); } } Смотрим в 2.3 public function __construct($registry) { parent::__construct($registry); $this->cache_data = $this->cache->get('seo_pro'); if (!$this->cache_data) { $query = $this->db->query("SELECT LOWER(`keyword`) as 'keyword', `query` FROM " . DB_PREFIX . "url_alias ORDER BY url_alias_id"); $this->cache_data = array(); foreach ($query->rows as $row) { if (isset($this->cache_data['keywords'][$row['keyword']])){ $this->cache_data['keywords'][$row['query']] = $this->cache_data['keywords'][$row['keyword']]; continue; } $this->cache_data['keywords'][$row['keyword']] = $row['query']; $this->cache_data['queries'][$row['query']] = $row['keyword']; } $this->cache->set('seo_pro', $this->cache_data); } } Как то вы оба два не очень замечали, что здесь тоже про ваши массивы ни слова. Какая то печаль беда... Вместо того чтобы приносить пользу коммьюнити, только вопли. Стыдно господа должно быть.

Может и не только это.

КЭП. Я же не просил погуглить за меня, как базу сконвертировать. Я спрашивал нет ли готовой-рабочей.

90% да. Все остальное необходимо фиксить. Но в целом, проблем не так много как кажется. В основном более строгая типизация дат. В целом, очень много от pg уже есть в mysql8 как-то JSON поддержка, работа innodb и full-text индксов. Но остаются ништяки которых нет, это объектная модель, физическая а не бинарная репликация, вычисляемые индексы ..... ну и параллелизм. Так как по сути опенкарту никаких кроваво-энтерпрайзных технологий не требутся (да я в курсе, что pg - это opensource), а для сохранения целостности, по большому счету достаточно innodb и регулярного копирования, единственный ништяк, но очень весомый - это способность из коробки выполнять один запрос несколькими ядрами без танцев с бубном. Вот этого mysql не умеет и в ближайшее время научиться не планирует. Поэтому у меня пока что эксперимент - что дороже: воротить какое-то базовое шардирование и поднимать несколько баз, либо же ставить pg и дружить его со структурой запросов OC.

Че, как друзья товарищи, никто не пробовал сделать миграцию? Если вдруг кто делал, поделитесь дампом голой базы, все остальное у меня готово. Предвосхищая холивар - зачем? Отвечу одним словом - параллелизм.

Везде и всегда я все время всем талдычу, бекапы, бекапы, делайте бекапы. Потеря вашего бизнеса стоит намного дороже чем потраченного времени на настройку, проверку, покупку места для хранения и регулярное копирование. Произошла недавно с моим товарищем очень казусная ситуация. В сонном состоянии он удалил несколько сот тысяч товаров из базы, думая, что удаляет дубли, которые неудачно импортирровались в момент последней заливки. Со спокойной душой он пошел спать, зная что резервное копирование у нас настроено, бекап-спейс на хецнере куплен, и даже какие то резервные копии там есть. Когда же он попытался восстановить базу, оказалось, что последняя копия за месяц назад (позже выяснилось, что саппорт пытался выполнить тикет по настройке сервера, позже чем мы это сделали сами и поменял хранилище на свое собственное ограниченное по размеру). В итоге ситуация: есть актуальная база со всеми данными (заказы, категории, статьи) но без товаров, случайно есть живой тестовый сфинкс-индекс на стороннем сервере, в котором есть все актуальные данные о товарах кроме опций и совершенно случайно у меня оказался недокачанный почти актуальный дамп базы, без таблиц oc_product_to_category (видимо при экспорте я встрял в timelimit php или wait_timeout базы или в какое еще ограничение, вобщем большие базы из phpmyadmin экспортить-импортить - зло. Консоль и mysqldump - наше все). Сейчас это звучит спокойно и обнадеживающе. В момент, когда этот триллер происходил - звучало не очень. Перед глазами маячила перспектива обречь моего товарища на полную перезаливку всех его сотен тысяч товаров, что по факту откатывало его стартап на пару месяцев назад в будущее. Как мы вышли из ситуации. 1 - сохранили на всякий случай оставшуюся базу без товаров. 2 - подняли рядом мой недокачанный дамп трехдневной несвежести. 3 - убили все таблицы связанные с товарами из актуальной базы 4 - экспортировали в отдельный sql-файл эти же таблицы из моего дампа (без таблиц product_to_category, product_to_layout и product_to_store). 5 - на сервере, на котором болтался тестовый индекс сфинкса (тут просто повезло потому как таким способом мы тестировали свежеприобретенный сервер нашего товарища) сделали скрипт, который выдрал из сфинкса весь набор связей товаров с категориями, и залил его в рабочую базу. 6 - тупыми запросами создали product_to_layout и product_to_store. Благо у нас один магазин и один айди схемы товаров. И казалось бы можно радоваться все завелось. Но не тут то было. Работало ровно то, что уже было в базе а вот добавить мы не могли ни опцию, ни товар, ни атрибут.... Вопрос знатокам: почему, и как с этим бороться?

Данные пункты напрямую противоречат пункту: 6.2.3.1. Компания предоставляет публичную систему отзывов в рамках Платформы, как средства, через которые Пользователи могут делится своими мнениями публично, и Компания не контролирует и не есть цензором таких мнений. Компания обычно не расследует какие-либо отзывы, которые оставлены Пользователями на предмет их точности или надежности. И в данном случае у вас присутствует две правовых коллизии. Первая - в юридической практике нет такого понятия "по какой-либо причине", так как любая фабула действия подразумевает всегда корректный перечень оснований, для любых действий сторон, которые тем или иным образом описаны в предмете договора. Вторая - нет перечня явных и косвенных признаков, по которым тот или иной отзыв является дискриминирующим и обидным? Или по вашему называть плагиат с пруфами плагиатом, илишелл, который вы не даже сами не смогли найти шеллом - это оскорбительно или обидно? Так что артем, изучите внимательно оферту и не нарушайте обязанности компании по пункту 6.2.3.1

Подскажите, на основании какого пункта правил или публичной оферты вы будете это делать, а также укажите явно, где здесь разборки и переходы на личности?

1 - заэскейпить ввод!

Постучался несколько дней назад один уважаемый форумчанин, с просьбой посмотреть на его подопечного, которого взломали и удалили целиком весь магазин. Устали они восстанавливать все из бекапа. При этом человек, который обратился, достаточно грамотный, для того чтобы закрыть все известные публичные уязвимости, и настроить безопасность окружения. Все равно сносят магазин подчистую. Начали смотреть и обнаружили в корне вот такой интересный, и казалось бы безобидный код: <?php if (isset($_GET['name']) || isset($_POST['name'])) { header('Content-Type: image/jpeg'); header('Content-Disposition: attachment; filename="'.htmlspecialchars($_GET['name']).'"'); header('Cache-Control: no-cache'); header('Content-Transfer-Encoding: chunked'); readfile($_GET['name']); } else { echo 'Access Denied!'; } ?> Причем этот код - это часть функционала сайта, который в карточке товара с подстановкой урла изображения товара, позволял его скачать по клику на ссылку. как то типа... https://site.com/?name=https://site.com/image/some_pic.jpg Ничего казалось бы страшного, если не присмотреться ближе. Вместо some_pic.jpg достаточно было вставить ./config.php и привет пароли к базе. Реально и смех и грех. Этот код был написан лет наверное шесть назад, когда мой товарищ только-только начал заниматься сайтостроением и у него не было ни единой мысли, о том что такое уязвимости или "а что так можно было?"... Но времена меняются, хакеры не спят, и реально я наблюдаю в последнее время просто эпидемию заражений и взломов. Будьте аккуратны при написании подобных скриптов, фильтруйте данные! Всегда фильтруйте данные!

Так. Все равно непонятно. Какое отношение пейсатель сайтов имеет к продажнику, и зачем ему стресс тест по программированию, если он должен продавать?

Я наверное ничего не понимаю. Но предположим, взяли вы на работу @chukcha, а он возьми и окажись и программистом не с помойки и продажником неплохим, но продажником лучше чем программистом, вы я так понимаю собираетесь делать сайты. А сайты у вас делает @n3bo, который волочет но не очень. Вот взял продажник, напродавал так напродавал. А реализовать вы не можете... Я все к чему, зачем вам продажник со скиллом, если у вас нет прогаммиста судя по всему, который не может сформулировать требования к знаниям сейла?

Вы меня извините. Но дружища, у вас в подьезде... В таком тоне - говорите с ними. А если вы не понимаете, что у вас не быстрый магазин, а мифическое решение, которое можно реализовать бесплатно с помощью вот этого модуля: https://github.com/budgetneon/v2pagecache, то мне откровенно вас жалко. К сожалению вот из-за таких фанатов сказок как вы, которые некомпетентно хвалят бесполезные решения, многие и многие владельцы магазинов гробят свой бизнес. И если вы не профи, к чему эти "советы", это как гемморой огурцом лечить посоветовать. Тоже ведь кому-то помогает. И все таки я просил показать хотя бы 20 000 товаров в категории с фильтром - не увидел. На данный момент у нас есть проект в котором 570 000 товаров в одной категории с фильтром с 20 параметрами, с временем генерации без кеша менее полутора секунд. Как вы считаете, я тоже не профи?