snastik

От композера толку 0 - так как все шаблонопейсатели будут долго переучиваться и все будет по старинке. На 1.5 магазины в рунете без адаптивного шаблона будут умирать как мухи. Все таки доля мобильных девайсов стала огромна. И если на 10% потерь трафика можно было забить, то на 50 уже не забьешь.

Очень похоже на вирусню. Попробуйте вот скрипт. <?php /* SELECT `date_check` FROM `files` GROUP BY `date_check` ORDER BY `date_check` DESC LIMIT 2 */ // Configuration require_once('config.php'); require_once(DIR_SYSTEM . 'startup.php'); $dir = (__DIR__); $files = array(); $now = time(); $db = new DB(DB_DRIVER, DB_HOSTNAME, DB_USERNAME, DB_PASSWORD, DB_DATABASE); $sql = "CREATE TABLE IF NOT EXISTS `files` ( `path` varchar(1024) NOT NULL, `filesize` int(11) NOT NULL, `date_create` int(11) NOT NULL, `date_modified` int(11) NOT NULL, `date_check` int(11) NOT NULL, `suspicion` text, KEY `path` (`path`(333)), KEY `date_check` (`date_check`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8;"; $db->query($sql); //scan function scan_dir($dir, $files) { $items = glob( $dir. "/*"); $tmp = array(); if(is_array($items)) { foreach ($items as $item) { if(is_dir($item)) { $files += scan_dir($item, $files); } else { $path_info = pathinfo($item); if ( isset($path_info['extension']) && ($path_info['extension'] == 'php')) { $suspicion = ''; $content = strtolower(file_get_contents($item)); // 'name' => $child['name'] . ($this->config->get('config_product_count') ? ' (' . $this->model_catalog_product->getTotalProducts($filter_data) . ')' : ''), $suspicion .= (substr_count($content, 'global') > 0) ? 'global|' : '' ; $suspicion .= (substr_count($content, 'eval') > 0) ? 'eval|' : '' ; $suspicion .= (substr_count($content, 'base64_decode') > 0) ? 'base64_decode|' : '' ; $suspicion .= (substr_count($content, 'gzinflate') > 0) ? 'gzinflate|' : '' ; $suspicion .= (substr_count($content, 'preg_replace') > 0) ? 'preg_replace|' : '' ; $suspicion .= (substr_count($content, 'exec') > 0) ? 'exec|' : '' ; $suspicion .= (substr_count($content, 'system') > 0) ? 'system|' : '' ; $suspicion .= (substr_count($content, 'shell_exec') > 0) ? 'shell_exec|' : '' ; $files[] = array( 'path' => $item, 'filesize' => filesize($item), 'date_create' => filectime($item), 'date_modified' => filemtime($item), 'suspicion' => $suspicion ); }; }; } } return $files; } $results = scan_dir($dir, $files); foreach ($results as $result) { extract($result); $db->query("INSERT INTO `files` (`path`, `filesize`, `date_create`, `date_modified`, `date_check`, `suspicion`) VALUES ('$path', '$filesize', '$date_create', '$date_modified', '$now', '$suspicion')"); } //report $sql = "SELECT * FROM `files` WHERE `suspicion` != '' AND date_check = $now "; $report_global = $db->query($sql)->rows; print_r($report_global); Я не успел его пока привести в "товарный вид" Но свои функции по поиску зловредов он отлично выполняет... Положите в корень в виде пхп файла и запустите. Если не найдете ничего подозрительного - нужно будет смотреть ваши логи и анализировать в чем проблема.

Да вроде пока никаких.Все заводится с полтычка - есть какие то месседжи мол не заводится vqmod.До конца непонятно куда можно залезть модификаторами, но есть надежда что наконец то можно отказаться от внедрений в index.php.Завтра - максимум послезавтра, будет пререлиз opencart.pro, с модификациями до состояния ocstore. Выложу на тесты обязательно.Если кому не терпится - то все работы ведутся на гитхабе. Можете наблюдать в режиме реалити-шоу.

Я же ответил выше. Есть глобальные архитектурные подвижки. Дальше это будет дорабатываться. Больших изменений в ветке 2.x - скорее не предвидится.

Подожди... Дай допилить. Завтра-послезавтра будет локализация. Пока что все отлично!

Ровно через две недели все разработчики прекратят что то делать под 2.1-.2.2

Вы не правы... Если взять 1.5 - то 1.5.3 - не сильно отличалась от 1.5.6. Те изменения которые произошли от 2.0 до 2.3 - если за ними наблюдать регулярно, они достаточно логичны. В общих чертах opencart пытаются донянуть хоть как то до архитектуры Magento. Сразу сделать это невозможно по двум причинам - отсутствие ресурсов. И наличие большого шлейфа магазинов с существующей архитектурой. Вот и ведется планомерная работа. На сегодня, по моему, архитектурные движения глобальные, которые могли произойти - произошли. Дальше вся система будет обрастать "Мясом" и багфиксами. Ну и я вангую, не за горами обьявление - opencart стал партнером Ebay. Или еще что то в таком духе.

2.3.0.2 - достаточно зрелая ветка...И дальше будет все в ее архитектуре. Предлагая запускаться на 2.1 - вы сразу человека угоняете в тупиковый вариант, проапдейтится с которого будет почти равносильно переезду с 1.5.x на 2.x

Только рентген и лоботомия! Причин, я навскидку могу назвать порядка 20. Варианты могут быть любые - от происков конкурентов, до неправильного robots.txt

Вы делаете ту же самую глупость, что и все фанаты чистого опенкарта.... Т.е. по вашему. масса людей. Делают локализацию - просто так от нечего делать ? Все они дилетанты и занимаются этим просто так... А не от того что чистый опенкарт - это беда с точки зрения сео ? Я уже молчу про локализации населенных пунктов, валют, модули интеграций с местными платежными системами и так далее... Если у вас есть лишняя неделя и вы уверены в своих способностях, сделать правильно локализацию и настроить красивое сео - пожалуйста. Если нет - то вникните в чем смысл русскоязычных сборок и просто сэкономьте себе время и деньги!

Из существенного - критически изменен механимз Startup. Переделана структура дополнений/модулей.

Посмотрите в Гитхаб Даниэля. 2.1 - ТУПИК!

2.1 2.2, с выходом 2.3 становятся тупиковыми, так как очень сильно поменялась архитектура. Подождите месяц, когда появятся адаптации топовых модулей под 2.3 и в бой на ней!

Нагрузка идет на сервер вот все и умирает! Какие скрипты директа ? Даже если это VPS c одним-двумя ядрами, генерация 4-5 потоков одновременно может убивать в хлам mysql и отнимать все процессорное время.

Спасибо за промоушен! Но надо было спросить кеширование чего ? Под какую версию. Сколько товаров ? Какой хостинг ? Потому что в последнее время так смешно видеть модули, которые кешируют HTML и делает типа PageSpeed 100, но на холодную и с метриками и модулями оказываются бесполезными маркетинговыми фичами.

https://github.com/vqmod/vqmod/tree/v2.6.1-opencart

С гео ip подружили - без проблем!

А кто вам сказал что это плохие боты ? Это может быть Бинг к примеру. Если не решите вопрос - пишите в личку, договоримся.

Готовые сервисы - я и имел ввиду. Иногда использование CDN под картинки, намного экономически оправдано, чем покупка большого пространства на хостинге. + более быстрая доставка контента в регионы. Чтиво - бредовое. Оптимизация базы - не должна приводить к денормализации дефолтной структуры, и вносить изменения в код базовых запросов, чтобы максимально исключить конфликты со сторонними дополнениями (больше ничего не расскажу, коммерческая информация).

карта сайта, yml, импорт товаров, массовые рассылки пользователям

Все зависит от параметров сервера и входящего трафика. кроме wait_timeout = 120 все остальные параметры настраиваются индивидуально. (я бы делал wait_timeout и вовсе 10-15 макс). Также открою секрет. Одной настройкой сервера - вы ничего не добьетесь. На простом примере, если у вас широкая ровная дорога но медленная машина - вы быстрее не поедете, чем она может. Настройка магазина под большой трафик и быструю работу - это несколько слоев оптимизации: настройка железа оптимизация базы кеширование повторяющихся блоков магазина полное кеширование html анализ и устранение узких мест в модулях устранение избыточного кеширования (например кеш сеопро на большом количестве товаров, работает на порядок медленнее чем 200-300 атомарных запросов в базу данных). А на примере 250 000 товаров и 10 000 производителях, кеш сеопро укладывает генерацию страницы секунд на 60 перенос всех повторяющихся тяжелых однотипных операций, не связаннх с фронтендом в cron. И это я говорю только о лежащих на виду мероприятиях, которые необходимо сделать для уменьшения TTFB страниц. Есть еще настройка отдачи статики. Реструктуризация подключения внешних скриптов. Реструктуризация подключения контента из CDN. Использование собственного CDN для изображений. Внедрение дополнительного слоя обработки для индексирования данных (sphinx), для быстрого релевантного поиска. Также нужно проводить аудит по используемым модулям. Есть из ряда вон выходящие примеры, отключения которых дают + (2-3 секунды) скорости загрузки, просто на голом месте практически. Типа глупо написанные модули редиректов. Или кривые формирователи сео-ссылок. Про авторов и сами модули умолчу, дабы не разводить холивар. Также во многих модулях присутствуют свои настройки кеширования, про которые многие забывают (Mega Filter Pro, SeoBlog и так далее). Если совсем глубоко занииматься тюнингом. То можно еще отключать инкрементальный счетчик просмотра товаров, слежение за покупателями, перевести весь контент изображений на фронтенде в Lazy-load. Настроить Since-modified. Вобщем если заморачиваться - можно придумать себе развлечений на пару-тройку месяцев легко.

Как правило база крашится в случаях, когда большой магазин на 30к+ товаров, пытаются крутить на бомж-сервере. На моей памяти из 500-600 магазинов, которые я видел, таблицы крашились от силы пару раз. Таблицы переводятся безболезненно - или гуглите скрипт. Или в разделе операции в phpmyadmin потаблично руками.

Сейчас имею базу в innobd пока к серваку не лез все стоково, но имею задержки 3-5 сек при обращении к странице. 1. Дальше будет только хуже. Так как базовые конфиги даже на VPS заточены под более менее быструю работу с MyIsam. 2. Если почитаете внимательно референс Mysql про типы таблиц - то там достаточно ясно написано что MyIsam намного быстрее работает с операциями чтения. А чтение - как раз узкое место базы данных в интернет-магазине. 3. Прелесть InnoDb состоит в более надежном хранении данных, за счет транзакционных блокировок. Т.е. шансов покрашиться у таблицы InnoDB меньше. Но. Для того чтобы использовался транзакционный механизм в полной мере, необходимо чтобы база изначально была спроектирована с учетом транзакционных зависимостей между полями таблиц. А есть ли такой механизм в Opencart? Правильно - нету. Сответственно использование InnoDb для Opencart - это редачйшая глупость. Большей глупостью может быть только кеширование результатов всех mysql запросов всредствами php. И еще. InnoDb не подддерживают индексы FullText, с помощью которых в Opencart реализован поиск по описаниям товаров и выборка тегов.

Посмотреть в сторону system/storage....

У меня все готово и написано, и даже больше чем у вас в тз, но в силу специфики настройки сервера и реализации подобного проекта в продаже не стоит. Готовая реализация под ключ $300. Ни один разработчик в здравом уме подобное решение не пустит в масс маркет, так как нормальный запуск и настройка поддомменов а также связка этого огорода с геоайпи - это далеко не тривиальная задача.