sv2109

Конкретная задача? Да сколько угодно! Берем любой модуль, у которого какой-то функционал реализован через vqmod (а таких процентов наверное 80), нужно реализовать этот функционал без использования vqmoda и правки кода движка. Например, нужно добавить с помощью своего модуля новый пункт меню.

Кстати, еще один пример, сейчас как раз читаю как круто это все реализовали в Симфони с помощью паттерна Наблюдатель. Статья на Хабре часть1, часть2

Что есть код движка? system/* или все файлы оригинального openCart? Добавил свой контроллер, который наследует существующий контроллер и можно в теме URLы поправить

Тут вопрос не в том чтобы сделать так, чтоб работало.. Это можно.. создать кучу своих классов, которые унаследуют существующие, поменять кучу кода движка и все заработает. Вопрос сделать это красиво без изменения кода движка. Причем нужна возможность делать это с помощью модулей. Нужен функционал, который даст модулю возможность без изменения стороннего кода и без использования vqmod и прочих костылей менять логику работы сайта.

Нет нормального способа вести разработку своих модулей параллельно и независимо от разработки основного движка.

Я уже неоднократно наводил пример - Друпал. Там с помощью хуков можно изменить почти все. Причем Друпал это не какая-то левая система, а цмс мирового масштаба, на которой работает огромное количество сайтов.

Я не говорю о том чтобы сделать из опенкарта Друпал. Я говорю о том что в опенкарте ну просто очень слабая и недоделанная система модулей. И что-то с этим нужно делать.

Мне кажется, что проблема OpenCart отчасти в том, что слишком много логики перенесено в шаблоны. Из-за этого создание темы слишком сложная штука для рядового верстальщика, да и изменения приходится делать часто какими-то vQmod.

Почти все изменения в логике можно сделать наследованием, тем более, что все там на MVC - проще некуда.

Да.. вроде все на классах, а как переопределить какой-то класс? Например какой-то контроллер или модель? Причем сделать это без правки кода движка?

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

Ну а что мешает в своем модуле не создавать какой-то там preRender, а взять и переопределить render можно с вызовом родительского класса?

Проблема в том, что render нашего модуля будет работать только с данными контроллера этого модуля, а нам нужно изменить данные прежде всего других классов. Тут нужно или как-то переопределить главный контроллер или добавить пре рендер. Другого пути я не вижу.

Такой подход позволит просто менять лишь представление данных, либо менять сами данные. Но не позволит менять поведение. И по сути от vqmod не отличается.

А как быть, если несколько изменений последовательно перехватывают рендер? Те же гоабли, что и vQmod, только менее гибкий, поскольку опять же влияет лишь на данные, а не на логику.

Невозможно один хуком поменять и данные и события и вообще все.. В Друпале используется целая система из нескольких десятков хуков, тут же привел пример всего одного, с помощью которого можно поменять все данный в шаблоне, по-моему неплохо как для 20 строк кода.

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

Насчет того, что несколько модулей могут менять одни данные. Во-первых это не так критично как изменение кода движка, так как меняются только данные и не затрагивается код. Во-вторых можно как-то присвоить приоритет каждому модулю. Можно даже дать пользователю возможность из админки выставлять эти приоритеты для модулей, как сейчас сделан "Порядок сортировки" для модулей.. итд. вариантов масса. Я не привел окончательную реализацию всего механизма, а лишь показал тестовый пример.

вот тут предлагают еще одно решение, посмотри :) может заинтересует

http://www.opencart....icense=0&page=5

мне кажется не решено здравого смысла :)

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

Бегло просмотрел код. Там вводится еще один слой абстракции - фабрика, с помощью которой можно переопределять методы других классов. Правда переопределяется все через какой-то variable stream, пока не разобрался с этим.

Шаблоны переопределяются через хелпер modifier или через str_replace, короче тот же vqmod только с другой реализацией..

Плюс еще один слой, который серьезно усложняет логику и может конкретно увеличить скорость загрузки страницы.

Короче пока двойственные чувства. С одной стороны классно, то что нужно, с другой слишком сложно и тяжело и местами ничем не отличается от vqmod-a.

Приветствую всех. Я занимаюсь опенкартом относительно недавно, до этого работал с Друпалом. Весь Друпал построен на системе хуков (крючков). С помощью которых один модуль может внести изменения в работу другого. Например один модуль может создать меню, а другой добавить к этому меню новый пункт. Или один модуль может создать тип материала, например Товар с полями Название, Описание, Цена, а другой модуль к этому типу добавить свое поле Производитель. Всего есть десятки хуков с помощью которых можно переопределить почти все - меню, типы материалов, пользователей.. можно добавить свой код например после создания нового материала или при запуске крона итд. В результате получается очень гибкая система, в которой с помощью нескольких строк кода без изменения кода ядра можно сделать что угодно.

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

Изучив код опенкарта я понял, что весь рендеринг происходит через метод render класса Controller. До рендерига в массив $data собираются данные для каждого шаблона. То есть если перед ренедерингом дать возможность модулям менять массив $data.. то это даст очень мощный инструмент, с помощью которого можно было бы без изменения кода ядра и использования vqmod менять (добавлять, удалять) очень много всего - меню, ссылки, хлебные крошки, информацию о товарах, категориях.. вообще любую переменную шаблона!

Накинул примерную реализацию:

В методе render() класса Controller:

перед

extract($this->data);

добавить

$this->hookPreRender();

Добавить метод hookPreRender():

	protected function hookPreRender() {
	  $extensions = $this->model_setting_extension->getExtensions('module');

	  foreach ($extensions as $extension) {
		$action = new Action('module/' . $extension['code']);
		$file = $action->getFile();
		$class = $action->getClass();
		$method = 'preRender';
		$action = NULL;
		if (file_exists($file)) {
		  require_once($file);		  
		  $controller = new $class($this->registry);
		  if (is_callable(array($controller, $method))) {		  
			$template = strpos($this->template, $this->config->get('config_template')) !== FALSE ? $this->config->get('config_template') : 'default';
			$template = str_replace(array($template . '/template/', '.tpl'), '', $this->template);
			call_user_func_array(array($controller, $method), array(&$this->data, $template));
		  }
		}
	  }
	}

Все, всего несколько строк кода..

Теперь в своем модуле можно создать метод контроллера

public function preRender(&$data, $template)

например:

public function preRender(&$data, $template) {
	if ($template == 'common/footer' && isset($data['informations'])) {
	  unset($data['informations'][0]);
	}
  }

Этот код удалит первый элемент массива статей в шаблоне футера.

Хочется услышать мнение сообщества насчет подобной инновации. Если вещь стоящая то можно подумать как оптимизировать код и предложить добавить это в оф. релиз движка.

На OpenCart 1.5.3.1 установил, активировал модуль. Но ничего не появляется в Атрибутах. Что не так?

Должен появиться селект после выбора определенного атрибута, если у этого атрибута есть значения.

Если этого не произошло то возможно то возможно вы что-то неправильно установили или у вас не установлен или установлен не правильно vqmod или у вас есть другие модули которые тоже используют vqmod для изменения тех самых файлов и происходит конфликт.. причин может быть много. Если не разберетесь можете дать доступ в админку вашего сайта посмотрю.

sv2109

Как хорошо, когда все делается чужими руками, да? Чтобы все исправить, надо ТЕСТИРОВАТЬ, надо отправлять БАГ-репорты, а не тупо ждать. Тогда и исправят быстрее!

Согласен. С радостью бы помог. Для меня основная проблема это английский.. если баг репорт я напишу на русском или с помощью переводчика боюсь его никто не поймет..

Было бы неплохо если бы в разработке оф. версий участвовало русское сообщество, тогда можно было бы что-то делать и общаться на русском.

есть где-то график (хотя бы приблизительный) выхода новых версий? киньте плиз ссылку.

Установил только что 1.5.5, потыкал мышкой.. куча ошибок, категории нормально не работают, фильтры тоже. Фильтры ИМХО нужно к атрибутам привязывать и не создавать лишнюю сущность, да большая гибкость но и трудозатраты при создании товара (особенно если в товаре штук 20 атрибутов) возрастают очень сильно.

Так что пока 1.5.5 еще вообще не рабочая и когда ее допилят, протестируют и зарелизят неизвестно.

Идем в админ панель - продажи - покупатели - группы покупателей - Default - изменить. Ставим Нет напротив "Display Company No." и "Display Tax ID"

Насчет премодерации. Как я уже писал выше, до 95% ошибок возникают не из-за багов модуля, а из-за внешних факторов - другая версия движка, другие модули, темы, браузеры, кривые руки пользователей итд. И эта премодерация почти ничего не решит! Потому что ни один тестер не может проверить работу модуля во всех возможных конфигурациях.. Да и кто этим всем будет заниматься и брать на себя ответственность?

Мне кажется, нужно просто наладить систему жалоб и не выплачивать деньги разработчику сразу. Если модуль реально не рабочий и разработчик пропал или отказывается его исправлять то 1. Пожаловаться администрации 2. Получить назад свои деньги 3. Заблокировать модуль и как-то наказать разработчика, например баном на время.

Кстати, как вариант, идея для создателей этого форума - сделать как например на фрилансе.ру возможность оставлять отзывы об исполнителе (напр. так https://www.free-lance.ru/users/nid/opinions/?from=users#op_head) . Это бы и облегчило поиск исполнителя и самих исполнителей бы заставляло более ответственно относиться к работе.

не важно сколько стоит модуль. заявленный функционал должен работать

Конечно, я и не писал обратного. Я писал о несовместимости модуля через внешние факторы и о строках исправления багов.

Покупателям хочу сказать следующее - в 95% случаев модуль не работает не из-за того, что там какие-то баги, а из-за внешних факторов таких как другая версия движка, другие модули, настройки сервера, другая тема, устаревший браузер итд. Честь и хвала тому разработчику который продав вам модуль за 100 рублей соглашается после этого бесплатно со всем этим венегретом разбираться.

В остальных 5% просто смотрите на рейтинг разработчика, на к-во скачиваний и на отзывы в теме поддержки (для этого она и создана!) если все нормально то скорее всего модуль будет рабочий. Ну не может же 20 человек скачать нерабочий модуль и ничего не отписать в теме.

Так же не стоит ожидать, что заплатив 100 рублей за модуль, вам в случае какой-то проблемы молниеносно ее исправят. Думаю строк в 1-3 рабочих дня вполне нормальный для исправления бага. Если разработчик не реагирует больше то нужно наверное писать администрации и конечно писать в теме модуля чтобы предупредить о возможном баге других покупателей.

Написал модуль Он дает возможность устанавливать разные цены для разных групп пользователей. Но он не выводит несколько цен на страницу. Цена показывается только одна, минимальная для данной группы.

Еще вопрос а обновлять все эти цены вы как думаете? Будет у вас 10 групп, у каждого товара соответственно 10 цен, а товаров например 10000? Вручную вводить не вариант. Использовать готовые модули импорта-экспорта не получится так как они работают со своими полями.

Как вариант цену формировать с использованием процентов. Например есть розничная цена. Но для группы Оптовики цена -5%, группа крупный опт цена -10% итд. Тогда 1. загружать прайс вы будете так как и загружали 2. цены на все товары для групп меняются в 2 клика. НО имеем меньшую гибкость так как не будет возможности установить конкретную цену для конкретной группы

Еще одна сложность. Нужно поменять вывод ВСЕХ цен (вместе с налогами, скидками, опциями итд) - страница товаров, каталог, страница заказов, корзина вообще все где встречается цена, а она встречается почти везде, это же магазин :) То есть нужно изменить кучу файлов. А если завтра вы установите какой-то модуль напр. "последние товары" то возможно придется менять и его код так как он может цену брать напрямую запросом из базы.

Не совсем понял зачем пользователю показывать все цены втч. оптовые.

И зачем указывать в админке где какую цену указывать. Какой смысл на странице товара указать одну цену а напр. в каталоге другую? Если пользователь с группы опт зашел на сайт он должен эту оптовую цену видеть везде. Мне так кажется.

Написать модуль можно, но сначала нужно хорошо продумать логику его работы.

можно так попробовать

.product-info .option br {
  display: none;
}
.product-info .option-image {
  width: 100px;
  float: left;
}
.product-info .option-image:last-child {
  float: none;
}

+ можно вместо .product-info .option-image указать конкретные опции через айди напр. .product-info #option-361, ...

.product-info .option {

clear: both;

}

.product-info .option br {

display: none;

}

.product-info .option-image {

width: 100px;

float: left;

}

Ссылку киньте на эту страницу. Там скорее всего флоат нужно очистить для названий опций ну и разные верхние отступы если есть убрать.

А вам товары импортировать нужно только 1 раз при начальной загрузке или постоянно обрабатывать такие объемы?

Если первый вариант то можно сделать так:

- качаем скрипт импорта-експорта Sypex Dumper - бесплатный скрипт, очень быстрый. Идеально подходит для создания бекапов, умеет даже по крону работать.

- делаем ним дамп базы на рабочем сервере

- переносим все (сайт+базу) на локалхост

- устанавливаем на локалхосте время работы php скриптов на максимум (у себя можно и 2 часа поставить)

- импортируем товары

- создаем дамп на локалхосте

- загружаем этот дамп на рабочем сервере

- профит

что насчет 1.5.3.1? Не хочется покупать, не зная- заработает или нет

Так в описании же написано:

Версии на которой тестировался модуль:

OCStore 1.5.3.1

OCStore 1.5.2.1

OCStore 1.5.1.3

А без минусов оффтоперы будут проживать жизнь в уверенности, что они приятные люди.

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