Dotrox

Я думаю, речь идёт об отсутствии программной логики. То есть, о том, что эта кнопка ничего не делает.

Либо можно просто заменить ColorBox на FancyBox, который из коробки отлично поддерживает адаптивность.

Ну, почти так же: RewriteRule ^(.*)/(.*)\.jpg$ /image/data/$1/$2.jpg [R=301, L] Не могу гарантировать, что это правило сразу же заработает как надо, но правки, если и потребуются, то минимальные.

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

А вообще почта из магазина отправляется? В любом случае, проблема с отправкой почты. Посмотрите. есть ли что-то в журнале ошибок.

Сделайте полній скрин заголовков (там должна біть указана причина попадания в спам). Именно скрин, а не текстовую копию. Можете там затереть название домена и первые 3 цифры ip. А пока предположительными причинами может быть то, что домен или ip попали в антиспам базы.

Да. Читайте внимательно: А чтоб и vQmod не использовать и пользователей не просить вручную вносить правки, как раз и нужна нормальная архитектура. Нет, вопрос стоит в том, что вы назвали интеграцию костыля - преимуществом двойки перед 1.5. А на счёт "горе-фреймворка", то ОК как раз в него и превращается, там даже уже есть файл с соответствующим названием (/system/framework.php) :) А о фреймворках вообще: Мадженто изначально на Zend, ПрестаШоп начал переход на Symfony. Я не сторонник этих двух фреймворков (мне больше Yii нравится), но я не считаю, что велосипед с костылями лучше, чем современные паттерны и качественное профессиональное решение как база. В 1.5 на это всё ещё можно было закрыть глаза - наследие и всё такое, но 2.0 меня убила. Собственно, не понятно зачем эту версию вообще зарелизили, то есть, зачем релиз выпустили именно в тот момент - там местами тупо не хватает целых кусков кода. Например, в вишлисте метод для удаления товара из вишлиста пустой (на самом деле, он там лишний, ибо удаление идёт через параметр, который передаётся в метод index - очередной пример гавнокода в архитектуре ОК), а в методе добавления товара в вишлист не хватает записи в базу, всё пишется только в сессию (и это уже довольно ощутимый баг, ибо убивает смысл вишлиста). Запись вишлиста в базу появилась только в 2.1. Но намёки на новую архитектуру всё же есть, например, те же события, которые пока, правда, не особо используются.

Тогда воспользуйтесь тем советом, который я уже вам дал вот здесь: https://opencartforum.com/topic/62374-%D0%BF%D0%BE%D1%87%D1%82%D0%B0-%D0%BD%D0%B5-%D0%BF%D1%80%D0%B8%D1%85%D0%BE%D0%B4%D0%B8%D1%82/?do=findComment&comment=565329

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

Otvet, и? Я не сказал, что я пишу модули при этом не используя vQmod! Я его в магазинах, которые делаю, не использовал никогда - вот о чём я говорил. А модули я вообще не пишу и именно из-за принципиального отказа от использования vQmod (а смысл делать очередной слайдер или модуль вывода товаров, где можно обойтись без vQmod - нет). У меня есть куча различных наработок, которыми я не могу поделиться именно из-за того, что все они затрагивают другие файлы, а это сейчас требует vQmod. Вот пример одной из таких наработок, которая могла бы быть бесплатным модулем: https://opencartforum.com/topic/62497-%D0%BE%D1%88%D0%B8%D0%B1%D0%BA%D0%B0-http-error-500/?do=findComment&comment=566165 И вы меняете тему! Как отсутствие сейчас в ОК возможности сделать что-то нормальное без модификаторов оправдывает то, что Дэниэль вместо создания нормальной системы расширения, просто интегрировал модификаторы?

Добавьте в файле /admin/controller/startup/error.php перед public function handler($code, $message, $file, $line) { это: public function fatalErrorShutdownHandler(){ $errTypes = array(E_ERROR, E_PARSE, E_CORE_ERROR, E_CORE_WARNING, E_COMPILE_ERROR, E_COMPILE_WARNING); $last_error = error_get_last(); if (in_array($last_error['type'], $errTypes)) { $this->handler($last_error['type'], $last_error['message'], $last_error['file'], $last_error['line']); } } А после этой строки: set_error_handler(array($this, 'handler')); добавьте это: register_shutdown_function(array($this, 'fatalErrorShutdownHandler')); И вы сможете увидеть причину проблемы в журнале ошибок.

А при чём тут данный момент? Я говорю, что вместо добавление в двойку модификатров из коробки, нужно было реализовать такую систему, ибо vQmod был просто вынужденным костылём из-за отсутствия нормальной архитектуры. А Дэниэль вместо создания нормальной архитектуры взял костыль и сделал аналог из коробки. Это, как если б в кабриолетах люди привязывали к спинке сидения зонт, чтоб от дождя защититься, а автопроизводители, посмотрев на это, вместо поднимающейся крыши сделали зонт впаянным в спинку прямо с конвеера. А вы бы ещё спросили: а как вы от дождя защититесь без этого впаянного зонта? :)

Нет, это параметр, для запроса, но он может быть как угодно видоизменён (теоретически) перед добавлением непосредственно в sql. Собственно, при текущей структуре базы ОК в запросе не может быть просто category_id - это будет ptc.category_id (и это уже задача ORM зарезолвить все связи).

olivka828, откройте файл с бекапом в текстовом редакторе и убедитесь для начала, что в нём действительно есть те данные, которые вы хотите перенести (воспользуйтесь поиском по файлу, чтоб найти, например, какой-то товар).

Только в ОК это сейчас работать не будет :) Да. Я просто показал принцип формирования запроса вообще без написания SQL кода. Так бы это выглядело, если б в ОК была нормальная ORM. Подобным образом это выглядит в Yii2.

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

Не надо ничего в ядро вносить - надо использовать инверсию зависимостей (все современные популярные фреймворки так и работают). В ocStore это и так было уже исправлено. Я в 1.5 mysqli использую уже года 3. Если вместо написания всего запроса вручную использовать объектный подход, то с этим не будет никаких проблем. Например: $query = (new Product())->findAll(); $query->addWhere(['category_id' => $id]); $results = $query->execute(); Соответственно, система триггерит стандартное событие, например, beforeQueryExecute, модуль на него подписывается и может добавить, например, ещё свои addWhere, либо любые другие модификации в таком же стили. И главное, что это не вызовет никаких конфликтов между модулями, поскольку они не влазят в код, а используют внешнее стандартизированное апи.

Если вы имеете ввиду, что у вас у каждого товара уникальный набор атрибутов, то это не создаёт никаких проблем в плане общего массива с ними. А если речь идёт о том, что, например, у вас есть два товара с атрибутами Цвет и Форма и вы хотите, чтоб у первого выводился только Цвет, а у второго - Форма, то тут уже всё сложнее: придётся помимо названий проверять и id товаров. Соответственно, и в конфиге прописывать их попарно. Если они в одной группе, то никаких счётчиков не нужно, достаточно перед строкой с <?php foreach ($attribute_group['attribute'] as $attribute) { ?> дописать это: <?php $attribute_group['attribute'] = array_slice($attribute_group['attribute'], 0, 5); ?> Это обрежет массив с атрибутами до первых пяти значений.

Она растягивается, потому что вы туда вбили одно очень длинное слово (набор символов без пробела). Поправить это можно добавив в стили вот это: #review td { word-break: break-all; -webkit-hyphens: auto; -moz-hyphens: auto; -ms-hyphens: auto; hyphens: auto; } Какая проблема?

То есть, если я никогда принципиально не использовал vQmod, то для меня никакого прироста скорости нет? И от него не отказались, а просто заменили аналогом. Не знаю, быстрее ли OCMOD работает, но получается, что конкретно для меня, который никогда vQmod не использовал, скорость наоборот стала меньше, ибо теперь модификатор из коробки. Видимо, вы пропустили часть моего сообщения: Это их общий недостаток. А недостаток конкретно OCMOD в том, что в отличии от vQmod, он навязан всем пользователям прямо из коробки.

Если все перенести для вас не проблема, то дальше тоже сложностей нет: просто при выводе атрибутов проверяете названия и выводите только необходимые. Проще всего сделать где-то отдельный конфиг с полным набором атрибутов, которые надо вывести в этом месте, а уже при выводе делать просто такую проверку: if(in_array($attribute['name'], $config)) Подобным образом можно сделать, если нужно не по отдельным атрибута фильтровать, а по их группам. А отдельный конфиг - чтоб не вписывать прямо в условие полотнище атрибутов, но если их всего несколько, то можно и вписать на месте.

Убедитесь, что у этой категории ЧПУ написано латиницей, не содержит пробелов и каких-либо символов помимо букв и цифр. И, как было сказано выше - что оно уникально в пределах магазина. Это проще всего сделать через phpMyAdmin сделав запрос с выборкой по этому ЧПУ и убедиться, что там будет только одна запись.

Это как: чем яблоко лучше груши - тем, что не груша, а яблоко. Другие - не значит лучше. Кроме того, они не другие. 2.0 вообще процентов на 90 совпадает с 1.5, а разница частично в том, что некоторые куски кода выкинули и забили дописать новые, так что там только поломали часть функционала. 2.2 уже действительно имеет местами заметные отличия, но только местами и часть из них - это задел на будущее, а пока лежит мёртвым грузом. Тоже присоединяюсь к вопросу за счёт чего? В каком смысле отдельно? Модули по прежнему размазаны по разным директориям. А это самый большой недостаток двойки, а не плюс. vQmod был уродливым костылём призванным восполнить отсутствие в архитектуре ОК нормальной возможности расширения функционала, а Дэниэль вместо того, чтоб таки добавить нормальную систему расширения тупо интегрировал клон vQmod.

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

Как угодно нельзя. Цвет шрифта и фона должны контрастировать и размер должен быть приемлемым для чтения, иначе Гугл посчитает это SEO текстом добавленным специально для него и скрытым от посетителей и будут санкции.