Dotrox

Можно просто открыть этот файл в SublimeText или NotePad++ и посмотреть на содержимое. Там обычный SQL код, который легко читается без каких-либо специальных средств. Ну, или создайте ещё одну базу и залейте этот дамп туда.

Я всегда использую обычный, но почти ничего не меняю в настройках, только доставляю галочки, где удаление таблиц (и всего остального) перед импортом. Да.

Если разработчик придерживался архитектурных принципов фреймворка, то любой другой разработчик достаточно знакомый с фреймворком, сможет в этом коде разобраться. И наоборот: мне не раз приходилось видеть в ОК такие самописные костыли, что знание ОК помогало только понять, что автор этого кода ОК не знал (иначе б не понаписывал такого), но не разобраться в них быстрее. Пример с WP был для иллюстрации абсурдности мысли делать на движке то, для чего он не предназначен, но никак не был реальным предложением такое делать! Ещё не современная. Или уже и ещё. В ОК - чистое ООП (именно это отличие от WP вам и бросается в глаза). Но используется оно здесь на примитивном уровне (в смысле, только самые базовые возможности). Кстати, WooCommerce тоже полностью на ООП и использует его как минимум не меньше, чем ОК. Но из-за того, что одет он на WP получается полное убожество.

А ещё можно сделать магазин на WP Если идти по принципу "выучил один движок и пытаюсь его присобачить везде". ОК - не фреймворк, а магазинный движок. Для всего остального есть свои движки, либо есть фреймворки, которые вообще для всего (и одновременно ни для чего, ибо из коробки в них ничего нет, кроме набора инструментов, которые надо применить самостоятельно). А на счёт мультивалютности и мультиязычности, то зачем их вообще выпиливать то, если можно просто держать один язык и одну валюту? Ну, мультиязык ещё можно обвинить в лишних джоинах, но мультивалюта же вообще ни на что не влияет в плане производительности.

Может, проще тогда просто взять другой движок? Есть ведь альтернативы значительно попроще, на MODX, на Yii. Функционал ОК из коробки и так беднее, чем у PrestaShop и Magento. Мультивалютность, кстати, используется довольно часто. Не в последнюю очередь из-за привязки цен к доллару. Если каждый начнёт просить выкинуть из движка то, что не нужно конкретно ему, от ОК мало что останется. Например, я периодически встречаю вопросы, как убрать из ОК корзину и всё связанное с покупкой. А ведь это довольно старая проблема - что производителей невозможно отключить, а только удалить. Но это камень прежде всего в огород Дэниэля.

А много ли в Рунете вообще мультиязычных магазинов? Так давайте тогда мультиязык выкинем совсем, так получается? Если мультиязык есть, то должен быть на всех текстах, а не по принципу "кто-то подумал, что вот там он нужен, а вот там не нужен". Дэниэль и так уже подумал, что производителям описание не нужно.

При том, что там в брендах рядом с Люминарком и Бормиоли - Украина и Китай. Есть другой пример: детские товары, в брендах - Китай, Турция, Украина, Россия (опять же, помимо обычных брендов). Но, если в более общем плане: допустим есть бренд с кириллическим названием, а у магазина есть английская версия. Кириллицей там название бренда выводить?

Значит вам не попадались сайты, где рядом с брендовым товаром (пусть даже речь о китайских брендах) продаётся полный нонейм. Пример из собственного опыта: сайт с посудой и хозтоварами, где помимо французской и итальянской брендовой посуды, был местный хендмейд (мыло, свечи, какой-то декор) и китайский нонейм. И да, сайт был мультиязычным.

https://opencartforum.com/files/file/1699-cackle-reviews/

Там используется виджет от Cackle. Модуль это или вручную добавлено тяжело сказать. Не к группам, а к аккаунтам - через них пользователь должен залогиниться прежде, чем написать отзыв. Это всё берёт на себя вижет.

Я довольно часто сталкиваюсь с тем, что в качестве производителей вписывают страны происхождения товара. И тут мультиязык будет очень кстати (если магазин вообще мультиязычный, конечно).

Но не выводилась то никакая, а проверка есть в любом случае, если хоть какая-то включена, просто разные контроллеры подключаются для валидации. Не знаю, что вы сделали, но сейчас отзывы отправляются нормально.

Кажется, я понял в чём проблема. Вероятно, в этом шаблоне отзывы ни у кого не работают (либо у вас не сработал модификатор, который должен был поправить контроллер). Автор шаблона перенёс форму отзывов из шаблона страницы товара в шаблон вывода отзывов, за заполнение которого отвечает другой метод в контроллере. Вот это $data['product_id'] = (int)$this->request->get['product_id']; должно быть в методе review, а не index. Найдите в контроллере строку public function review() { И допишите этот код сразу после неё. Не забывайте, что делать это надо в оригинальном контроллере, а не из кеша, а затем обновлять кеш модификаторов. И не забудьте в шаблоне название вернуть обратно. Кстати, для справки: что в контроллере записано так - $data['product_id'], в шаблоне выводиться так - $product_id. А всё, что в контроллере не в таком формате, как я написал, то в шаблон вообще не попадает.

В phpMyAdmin открываете базу, идёте на вкладку экспорт и генерируете там дамп. Потом этот файл можно использовать на вкладке импорт, чтоб загрузить обратно.

Эти строки там у вас уже есть. Именно их вам и надо поменять. И замена заключается просто в том, что к ним нужно дописать _test (а что в результате должно получиться я уже написал выше). Есть на форуме люди, которые заряжают меня терпимостью

Ну, не совсем так (или, скорее, совсем не так). Для этого и существует 301й редирект. Конечно, понадобиться время и, возможно, полностью позиции вернуть не получиться, но всё же это будет далеко не с нуля.

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

Лично моё мнение, что ocStore выигрывает в сравнении с любой сборкой, ибо тут есть всё самое необходимое и нет ничего лишнего (особенно ценное качество) + максимальная совместимость с модулями/шаблонами под оригинальный ОК (максимальная не в смысле 100%). Вообще, ocStore - это, скорее, не "сборка", а форк с допилами и фиксами, большинство из которых должны были бы оказаться в оригинальном ОК.

Ох. Очевидно же, что $data['product_id'] и $product_id. Я же написал, что просто добавил _test.

Нет, это то, на что надо поменять. Первое - для контроллера, второе - для шаблона. Чтоб было понятней - я просто добавил в конец к существующему названию _test. То есть, и вам надо сделать именно это.

Читайте внимательно:

Если это хостинг, то все вопросы в поддержку, сами вы всё равно ничего не сделаете. А если не хостинг, то нужно больше информации, что у вас конкретно (в том числе и версия php).

Её можно в админке выключить. Ищите соответствующий модуль.

Вот в тех двух, которые выложили, в них и поменяйте.

А конкретнее?