Dotrox

Ну, это вопрос к хостеру, потому что проблема явно в настройках хостинга, а не ОК (до ОК запрос не доходит).

Он ни за кого никого не держит, просто это - предел его мастерства. 80% модулей под ОК написаны школотой (и это не имеет отношения к возрасту, а только к уровню интеллекта и знаний) и качество у них соответствующее. Иногда в коде встречаешь такое, что возникают сомнения, был ли вообще психически здоров автор. Ну, а проблемы с количеством - это беда ОК в принципе. Вот индексы, например, о которых выше говорилось - при нескольких сотнях товаров ОК прекрасно работает и без них, а при нескольких тысячах товаров он без них уже, можно сказать, вообще не работает. И в случае вашего гавномодуля: было б у вас всего пару сотен товаров, он бы не вызвал никаких проблем. Абсолютное большинство авторов модулей вообще не думают, как их модуль будет работать на реальных магазинах (где товаров не 2 десятка, как в демо магазине), не говоря уж про реальное тестирование.

Это что за маразм? Если это 1 в 1 рекомендация хостера, то там в поддержке работают клинические идиоты! Допустим, поддержка не знает нюансов ОК, но трижды "RewriteEngine On" - этому оправдания нет. Ну, и в плане ОК этот .htaccess должен вызвать кучу проблем. Вот правильный .htaccess: Options +FollowSymlinks RewriteEngine On RewriteBase / RewriteCond %{HTTP_HOST} ^www\.(.*)$ [NC] RewriteRule ^(.*)$ https://%1/$1 [R=301,L] RewriteCond %{SERVER_PORT} !^443$ RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301] # Редиректы ОК для сайтмапа и т.д. RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^([^?]*) index.php?_route_=$1 [L,QSA]

@Ramis05rus , это надо делать не в кеше модификаторов, а в оригинальном файле (/catalog/controller/product/product.php), иначе все правки после обновления кеша улетят в трубу. И второе: надо не дважды вызывать setDescription, а сделать все проверки до вызова и туда передать уже результат. То есть так: if (empty($product_info['meta_description'])){ $product_info['meta_description'] = $data['heading_title'] . $this->language->get('custom_meta_description'); } $this->document->setDescription($product_info['meta_description']); Ну, и обратите внимание, что empty, а не сравнение с пустой строкой и сам текст не в контроллере, а в языковом файле и подтягивается оттуда через $this->language->get

@Ramis05rus , вы идёте абсолютно не тем путём! Как уже было сказано выше, есть метод $this->document->setDescription() С помощь него вы можете установить этот метатег прямо в контроллере товара. И если вы этот контроллер откроете, то увидите, что там этот метод уже используется. Вот там и делайте свои проверки перед вызовом этого метода.

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

Вполне. https://support.google.com/webmasters/answer/139066?hl=ru

И что в этом такого?

У вас там не только эта ошибка и не только в шапке. Для начала обновите модификаторы и проверьте права на их директорию.

Вообще, на Yii2 уже есть какие-то попытки (то ли магазин, то ли CMS с магазином или плагином), но когда я последний раз смотрел, всё было ещё сырое и какая-то из реализаций вызвала у меня мысли, что писали люди, которые раньше с магазинами не особо много работали. В принципе, на Yii2 может получиться отличный магазин, но на это нужно потратить достаточно времени и уже иметь опыт с магазинами (желательно, хотя бы с двумя разными движками), чтоб представлять какие функции нужны магазину, как их обычно реализовывают и в чём недостатки существующих реализаций (или преимущества).

Никаких. Для небольшого магазина он вполне подходит. Если смотреть в сторону PrestaShop и Magento (основные конкуренты), то со старта придётся брать VDS, код сложнее, модули и шаблоны намного дороже.

А что вы ещё хотите узнать, что там не увидели? С точки зрения разработчика: куча лапши, многократное дублирование кода, при чём даже в рамках одного файла, только базовые возможности ООП и на минимальном уровне, кодовая база устарела лет на 10. Самопис, написанный одним человеком без использования фреймворков или хотя бы отдельных библиотек. Почему же такое используют: ОК простой до примитивности, после добавления недостающих индексов в базу и при отсутствии кривых модулей ОК способен выдержать первые 10 тысяч товаров и тысячу посетителей в сутки даже на среднем шареде, куча дешёвых модулей и шаблонов (модулей даже бесплатных немало). Правда, процентов 80 из модулей - это полнейший гавнокод, способный завалить магазин (побочный эффект примитивности ОК - он особо привлекателен для школоты). И можете ещё здесь почитать:

А какие у вас возникли сложности?

Легко. P.S. Какой вопрос - такой ответ.

SOLID он не переживёт. Весь ОК держится на реестре, а SOLID предполагает инверсию зависимостей, которая является противоположностью реестра. А вот DRY, который по ОК плачет ещё больше, можно было бы имплементировать достаточно безболезненно. Ну, индексы то как раз можно было бы и из коробки добавить. Тут не надо быть великим оптимизатором и они никому не мешают, чтоб так их избегать. А вот проблемы из-за их отсутствия возникают ещё далеко до того уровня, когда уже можно говорить про реальную оптимизацию чего-либо, а не просто исправление детских недоработок.

Хранит иерархию категорий.

Так а я о чём? Мы же как раз с этого и начали: я сказал, что он не подходит для крупного бизнеса - ты не согласился.

А что за модуль? Может его и не должно там быть?

Ну, так я ж и не говорил про 20 заказов в день - я говорил про крупный бизнес (а если там 20 заказов в день, то какой же он крупный?). Ну, и просто конвертировать в innodb мало, транзакции от этого не возникнут магически из ниоткуда. И заказы это просто самое критичное, но проблема эта есть во всех методах моделей со вставкой/обновлением/удалением записей. Если при добавлении товара к нему, например, опции не пропишутся - в этом тоже ничего приятного нет. Представь, если б у Розетки периодически из заказов часть данных терялась. То есть, зачем брать движок, который наполовину надо переписать, чтоб он смог работать с действительно крупным проектом? ОК живёт только за счёт того, что позволяет стартовать с минимальными затратами средств и времени. Но чем больше нужно людям от движка, тем больше сокращается разрыв с конкурентами и на каком-то этапе оказывается, что на ОК будет дольше и дороже, чем на том же Мадженто. И тут есть ещё один нюанс: ОК - самопис, при чём на уровне противоречащем здравому смыслу. Дэниэль всегда принципиально отказывался использовать хотя бы какие-то отдельные готовые библиотеки, утверждая, что его реализация вообще всего - лучше, чем в любой библиотеке и именно из-за отсутствия постороннего кода ОК такой быстрый. В результате получается: нужна какая-то мелочь, которая есть в любом фреймворке и, например, в том же Мадженто одной строчкой выдёргивалась бы из Зенда - впиливай самостоятельно. Я уж молчу о качестве реализации всего подряд одним человеком по сравнению с библиотеками и фреймворками, которые годами пиляться сообществом или профессиональными командами, а то и тем и другим сразу.

Так я ж как раз не про SELECT. Например, формирование заказа, там достаточно инсертов. И держится оно на mysqli_insert_id, который вернёт id после последнего инстерта/апдейта и есть у меня сомнения, что привязано к текущему экземпляру класса mysqli (то есть, вернёт не просто последний вставленный id, а вставленный именно здесь). Но если тут ещё вопрос (ибо точно не знаю, как оно сработает), то есть же просто множество мест, где идут последовательные запросы. Даже, опять же, формирование заказа: там куча последовательных запросов, например, тоталы, каждый из которых вставляется отдельным запросом. А вдруг какой-то сбой, половина тоталов не вставится? Ну, или сбой будет ещё на запросах записи товаров - заказ есть, а товаров в нём нет. Ну, тут ещё можно увидеть (если товаров совсем нет, а не часть потерялась), но может товар записаться, а выбранные опции - нет. И такого полно. $url = http_build_query(array_intersect_key($this->request->get, ['sort', 'order', 'limit', ...])); И вынести хотя бы в хелпер, где будут прописаны шаблоны параметров для каждого типа ссылок, чтоб можно было так сделать: $url = $this->helper->buildUrl($this->request->get, 'sort_params'); Он не только в шаблоне просится в отдельный файл, он и в контроллере просится в отдельный метод, общий для всех контроллеров.

Ну, я открыл обе ссылки в Мозилле и вижу разные meta description (хотя они и очень похожи).

А надо только рассказать как заставить ОК работать с FTP. В мастере на Гитхабе есть кое-что получше (внимание на второй параметр): public function load($filename, &$data = array()) { ... $data = array_merge($data, $this->data); return $this->data; } Но в дев ветке 3.0 предпоследней строки нет (как и в 2.3, хотя параметр есть начиная с 2.2). Так что оно может и потеряться. А на счёт лапши в целом, так она ж не только из-за языковых переменных, контроллеры - это вообще сплошная лапша. Особенно радует переменная $url, которая по 10 раз формируется полотнищами кода. Вместо этих полотнищ можно было бы просто профильтровать содержимое get на случай чего-то лишнего и склеить имплоудом. Я из собственного опыта могу сказать, что после трёх тысяч товаров магазин уже еле открывается, если не вешать индексы (речь про 1.5). А такое количество товаров даже на средний бизнес ещё не тянет абсолютно. Ну, и тормоза ж не резко выпрыгивают на каком-то числе товаров, а плавно нарастают. А крупному бизнесу ОК вообще не подойдёт, ибо нет транзакций.

Включите модуль и обновите кеш модификаторов.

Дэниэль уже писал где-то почему так: без лапши в контроллерах (школоте) будет непонятно, как оно работает. (в скобках примечание переводчика ) В текущем коде оно тянется пачками на основе роута. class ModelDesignTranslation extends Model { public function getTranslations($route) { $query = $this->db->query("SELECT * FROM " . DB_PREFIX . "translation WHERE store_id = '" . (int)$this->config->get('config_store_id') . "' AND language_id = '" . (int)$this->config->get('config_language_id') . "' AND route = '" . $this->db->escape($route) . "'"); return $query->rows; } } Правда, это пока в любом случае не используется. И бросается в глаза отсутствие фолбека на случай отсутствия для роута локализации на текущем языке. Разве что ключами будут уже не названия переменных, а сами фразы на дефолтном языке.

Посмотрел я на эти файлы в админке и возникло плохое предчувствие, что оно будет грузить из языковых файлов в базу (именно тот идиотизм, из-за которого я не перевариваю мультиязычность в Drupal и WP).