Yoda

На бегете отличные серваки. Но это как жить в красивом крепком доме вместе с табором цыган. Какой бы дом красивый и крепкий ни был туалет всегда будет занят, в гостиной всегда горит костёр и бродят медведи. Любой впс будет не сильно быстрее свежего шареда на бегете. Но ни один шаред не даёт возможности тонкой настройки системы и неограниченных ресурсов здесь и сейчас. Равно как ни один впс не работает быстро как дедик потому что даже если 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 параметрами, с временем генерации без кеша менее полутора секунд. Как вы считаете, я тоже не профи?

Вооот. А я говорил. Сейчас будет рекламная акция волшебной мази. Как обычно сплошное введение в заблуждение. Попробую на пальцах открыть фокусы фокуснкиков: 2-3-4к товаров в категории - это не нагрузка, так как все запросы в таблицы товаров сегментированы по id категории и представляют из себя небольшой набор. Тем более у @SooR для версии 2.3 отличный фильтр который отлично переваривает за счет использования сводных таблиц подобные задачи. Это же так просто тыкнуть носом пользователя. С текстом - делай разделение. Почему то все упускают из виду, что каждый дополнительный уровень вложенности катастрофически уменьшает конверсию и ухудшает навигацию. Но как я выше писал, даже 20к товаров в категории никто не показывает, на общем количестве товаров хотя бы овер 100 к, при том что в таких сегментах, как плитка, обои, сантхеника, люстры нормальная навигация - мастхев. Что касается ддоса. Что же это за такой супер-быстрый магазин, оптимизированный, который ложится просто от нажатия f5 в браузере. Как он может держать како-то разумное минимальное количество посетителей. И самое потрясающее передергивание - это рассказывать про то что летает на "шареде". Как известно у beget под базы данных как раз на шареде стоят отдельные оооооочень мощные сервера, судя по всему с огромным количеством памяти. Это позволяет показывать одномоментные очень быстрые результаты. Но шаред он и в африке шаред. И балансировщики ресурсов не спят. Поэтому ни на одном шареде невозможно построить стабильную быструю нагруженную систему. Вобщем друзья мои, не все то золото, что блестит.

На самом деле, судя по всему, вас так же как и многих ввели в заблуждение волшебными способностями чудо-модулей. Вы показываете не реальную работу магазина, а скорость отдачи сервером готовых html-страниц. Если у вас дай бог, когда нибудь появится 20-30 посетитилей онлайн, у вас все ляжет, так как скорость генерации страниц без кеша у вас далеко не фонтан. Сколько ресурсов вы тратите на прогрев, и есть ли у вас возможность оперативно актуализировать каталог - это тоже открытый вопрос, о котором вы умалчиваете. И к этому ко всему у вас только на четвертом уровне появляются где-то там, очень узенько сегментированные товары. Вместо того чтобы дать возможность покупателям иметь нормальную навигацию в общих категориях (плитка, ламинат), вы заставляете его делать несколько лишних действий и теряете до половины посетителей. Ну и с такой мелкой сегментацией, ваш магазин ни чем не отличается от магазина на 3000 товаров.

Круто летает! Научите меня?

Загляну. 1. От 100к товаров по хорошему нужен дедик. Так как ВПСы не справляются ни с io операциями диска, ни с быстрой обработкой mysql-запросов, которая упирается и в io и в скорость ядер. А тут даже не ВПС а опять же облако с непонятной системой виртуализации, с диким оверселингом с HyperThreadingом и так далее. Вобщем это первая печаль. И не говорите мне, что нет трафика. БОТЫ ВЕЗДЕСУЩИ. 2. 2 гб памяти... Ну ок. Скорее всего там стоит 512мб а то и гиг на поток-php (ведь товары откуда то взялись, их парсили, а парсеры прожорливые до памяти). Даже если 512мб, куда то надо еще деть системные ресурсы. В итоге у нас есть ресурсов на 3 паралельных http-потока для клиентов. А от ботов запросов я думаю больше (см п.1) 3. Ладно, допустим, нет проблем с io, есть ресурс процессора, и есть в достатке память. Скорее всего есть большие категории, овер 10к товаров, в которых getProducts и getProductTotal выполняются 2-3-5 сек каждый. А если еще открыта пагинация для индексирования, то на крайних лимитах, на порядок дольше, так как чем больше лимит с сортировкой, тем больше базе приходится сканить данных из таблицы. И у нас уже даже не 3 потока в секунду может отработать система, а 1. Когда на web-сервер приходит очередь запросов, они в нее стали и выели все реусрсы процессора. А еще у нас же есть всякие update в таблицу product. Продолжать могу бесконечно... Хочется конечно поглумиться, и посоветовать поставить один супер-пупер "авторский" "уникальный" кеширующий модуль, либо же обратиться к специалистам оптимизаторам. В какую нить очень честную студию. Но чет я ни у кого из этих специалистов не видел живого магазина с фильтром, который тащит от 100 к товаров в принципе, не то что в одной категории. Так что если вдруг никто не поможет, стучите, полечим беду.

А что там разбираться то... Посмотрите в htaccess, что происходит здесь? RewriteRule ^([^?]*) index.php?_route_=$1 [L,QSA] По моему ясно же, что весь "хвост" запроса уходит в обработчик php с ключом _route_. Т.е. это внешний набор данных, который пришел "из мира" в котором содержится полная информация о запрашиваемых данных, который потом разбирается на части сео-классом: // Decode URL if (isset($this->request->get['_route_'])) { $parts = explode('/', $this->request->get['_route_']); а "route" - это системный указатель, который определяет какой контроллер системы должен обрабатывать ваш запрос. // Router if (isset($request->get['route'])) { $action = new Action($request->get['route']); } else { $action = new Action('common/home'); } В случае использования ЧПУ, у нас в строке запроса нет явно указанных параметров, какой контоллер должен обрабатывать ту или иную ссылку, а есть только что-то вида site.com/product_url. Для того чтобы движок понял, чему этот product_url соответствует ему надо из _route_ разобрать данные, постучаться в базу получить соответствия, типа product_id = 234234, определить по типу сущности, что это товар, выставить соответствующий системный route = product/poduct и отработать при помощи нужного контроллера ваши данные. Ничего военного и тайного в этом нет. Но все таки я поддержу чукчу, если данный механизм непонятен "как есть", а он достаточно логичен и интуитивен, лучше не лезть, потому что можно нахомутать.

Хм, а чего ж вы самого автора не спросите?