Leaderboard

Предисловие Решил начать публиковать свои наработки по движку. Ковыряю движок совсем недавно, меньше трех недель. Но в свой проект внес уже немало улучшений, которые: а) ускоряют разработку б) уменьшают объем кода, улучшая, в то же время, его читаемость в) просто облегчают мне жизнь, как разработчику Т.к. эти мои доработки часто касаются непосредственно ядра движка, то маловероятно, что они будут просто внесены в русскую сборку ocStore. Возможно, команда, работающая над ocStore сможет донести мои идеи до основных разработчиков OpenCart, и они будут учтены в последующих версиях. Но если тут есть разработчики, которые самостоятельно активно пилят движок под свои нужды, то они могут внедрять эти фичи уже сейчас. А теперь приступаю к сути первой фичи. Меня очень удручает частая повторяемость одного и того же кода в скриптах. И я всегда стремлюсь этого избежать. И одним из самых раздражающих факторов в этом движке была необходимость языковые тексты в коде контроллера переносить в $this->data[], и только потом их юзать в шаблонах. Т.е. мы в контроллерах пишем тонны строк кода типа: $this->data['text_blablabla'] = $this->language->get('text_blablabla');и все это только для того, чтобы я мог в шаблоне обратиться к этому тексту: <?php echo $text_blablabla;?> И я сделал так: в классе Controller в метод __construct() добавил public function __construct($registry) { /* здесь имеющийся код ... */ $this->data['t'] = $this->language; } А в класс Language добавил "магический" метод __get(): public function __get($key) { if (preg_match('/^_[^_]/', $key)) return $this->get(substr($key, 1)); }И теперь мне не нужно никаких $this->data['text_blablabla']=..., я в любом шаблоне вывод текстовых строк делаю так: <?php echo $t->_text_blablabla; ?>Ну, или можно сокращенную запись использовать: <?=$t->_text_blablabla; ?> Профит, который я при этом получаю: 1) Значительно уменьшается объем кода в контроллерах и уменьшается (пусть и незначительно) объем потребляемой памяти 2) Уменьшается количество ошибок, связанных с тем, что в контроллере забыл в $this->data[] загнать какой-то текст 3) Уменьшается время на разработку - достаточно новый текст в языковом файле добавить, и сразу его можно в шаблоне юзать, в контроллере ничего менять не надо При этом все старые шаблоны работают, как прежде, можно ничего не трогать и не менять. А вот если вам приходится свои шаблоны писать или просто их править основательно, то забудьте про добавление текстов в контроллере - работайте только с файлом локализации и самим шаблоном, и будет вам щастье! :)

Движок строится на парадигме MVC, поэтому контроллер получат данные из модели, например, так: $this->model_account_address->getAddress(...);Но перед вызовом модели нам необходимо ее загрузить (зарегистрировать) в регистре: $this->load->model('account/address'); Но зачем опять городить лишний код, если такие мелочи, как загрузка нужной модели, можно делать автоматом? Что я и сделал. В классе Registry я изменил метод get(): public function get($key) { if (isset($this->data[$key])) { $obj = $this->data[$key]; } else { if (preg_match('/^model_([a-z0-9]+)_(.+)$/', $key, $matches)) { $model = $matches[1].'/'.$matches[2]; $this->get('load')->model($model); } $obj = (isset($this->data[$key]) ? $this->data[$key] : NULL); } return $obj; }И... Все! Теперь я могу не задавать явно загрузку модели вызовом $this->load->model(), а сразу обращаться в контроллере к методам модели через $this->model_account_address, и если эта модель еще не загружена, то она автоматом подгрузится в момент обращения.

Все настройки в файле admin/view/javascript/ckeditor/config.js Можно включить ресайз, закомментировав строку: config.resize_enabled = false;Если надо указать фиксированную высоту - добавь строку: config.height = '500px';

Пару багов в переводе: /admin/language/russian/setting вместо надо вместо надо Ну и для красоты можно добавить двоеточие тут: (дальше после "например" всегда : поставлено)+ правильней было бы написать SMS-гейт, SMS-уведомление (Существительные, имеющие значение одного слова и состоящие из двух самостоятельно употребляющихся существительных пишутся через дефис)

Мне нравится структурный подход. И когда несколько классов имеют повторяющийся код, то для меня это повод задуматься - а не стоит ли вынести этот код в общего родителя? И вот что я сделал. Создал класс Object (файл object.php в /system/engine): <?php abstract class Object { protected $registry; public function __construct($registry) { $this->registry = $registry; } public function __get($key) { return $this->registry->get($key); } public function __set($key, $value) { $this->registry->set($key, $value); } } // EOFИ классы Model и Controller наследовал от него: abstract class Model extends Object { } abstract class Controller extends Object { protected $id; protected $template; protected $children = array(); protected $data = array(); protected $output; public function __construct($registry) { parent::__construct($registry); $this->data['charset'] = $this->language->get('charset'); $this->data['lang'] = $this->language->get('code'); $this->data['direction'] = $this->language->get('direction'); $this->data['template'] = $this->config->get('config_template'); $this->data['store'] = $this->config->get('config_name'); $this->data['t'] = $this->language; } }По побльшому счету, на работу это никак не вдияет, но если теперь нам вдруг потребуется как-то иначе построить логику работы с регистром (т.е. как-то иначе обрабатывать геттеры и сеттеры, то мы будем менять только класс Object.

В админке "система"-"локализация"-"Состояние на складе". Хотя по-умолчанию и так на русском предзаказ. Как выделить цветом не знаю, только если для всех статусов

есть модуль для этого Header css categories , ток нажарился я с ним :) п.с.упс, ошибся это для категорий

Да, работа с базой - это отдельная тема разговора. Сейчас тут используется простейший класс. Конечно, если делать по уму - надо бы взять какую-то более-менее развитую библиотеку. Но тут опять возникает проблема совместимости. А вот и нет! При таком подходе никто не мешает использовать оба метода - старый и мой. У меня, кстати, сейчас так и работает - мне банально влом сидеть и убирать лишние строки из всех контроллеров и переделывать все шаблоны. Старые контроллеры и шаблоны работают, как есть - текстовые переменные загоняются в $this->data[], а в шаблоне юзаются по их имени. А вот новые шаблоны я уже пишу с использованием своего метода. Ведь тут фишка-то в том, что выдергивание текстов из Language происходит не заранее (на уровне контроллера, как сейчас в Opencart), а на лету - по мере обращения к ним из шаблона.Поэтому уже имеющиеся шаблоны для OpenCart (если нужные переменные добавляются в контроллере) будут работать "на ура!". Но вот шаблоны, сделанные с использованием моей методы, конечно, в стандартном OpenCart работать уже не будут. Вопрос, конечно, спорный, как чисто теоретически, так и в данном конкретном случае. :) Но холивары затевать не хотелось бы, скажу лишь, что я лично скорость разработки ставлю значительно выше экономии "на спичках". Более того, чем выше скорость разработки, тем больше (если разработчик грамотный) профита для пользователя, т.к. за тот же промежуток времени больше "плюшек" для юзера можно напечь. Но это теория.Что же касается данного случая, то при моем подходе мы даже получаем некоторую экономию памяти: 1) Вся языковая база не грузится, используется только то, что подгружено явно вызовом $this->language->load() в контроллере 2) При моем подходе в пространство имен не загружается дополнительно большое число новых переменных (при старом подходе каждый элемент текста - это создание отдельной переменной) 3) При старом подходе все загруженные тексты хранятся в двух экземплярах - в регистре и в пространстве имен. В моем случае - все хранится только в регистре, и извлекается из массива без создания доп. переменных и лишних копий. Ок, буду периодически делиться ими В таком случае, это не форк, а всего лишь локализованная сборка. Жаль :( Но я бы советовал серьезно подумать на тему создания реально своей ветки. Ведь может быть и такое условие - совместимость в одну сторону. Т.е. все, что делается для OpenCart должно работать в ocStore. А вот обратно - не обязательно. По одной простой причине - потому что ocStore лучше ;)

Ну так вырезай из дампа все таблицы форума.

Корзина действительно не нужна поисковикам, также как и поиск, личный кабинет и т.д.Я для тестов автоматом собрал и затолкал в модуль кучу пар запрос->псевдоним... А вообще каждый сам будет добавлять/удалять пары запрос->псевдоним так как сочтёт нужным.

Поковыряйтесь в настройках модулей оплаты - наверняка где-то в настройках установлен статус после оплаты "Отменен"

Ошибку нашел, исправил, но у меня уже почти готовы новые заморочки с ЧПУ... Произвольные окончания, ЧПУ на ссылки типа route=account/account, route=checkout/cart и т.д. Выкладывать исправления или новый вариант?

В итоге копаний справился сам. Немного модифицировал стандартный Каталог-Загрузки и его применил к своим целям Кому интересно может будет читайте что я сделал: 1. Сначала отредактировал admin/controller/catalog/download.php. Убираем в двух местах md5(rand()) Теперь к имени загружаемого файла не будет приписываться длинный хэш 2. catalog/model/catalog/category.php Мне надо было добавить ссылку на файл в блоке категории, поэтому именно эту модель я и отредактировал. public function getFileName($id = 1) { $result = $this->db->query("SELECT * FROM " . DB_PREFIX . "download WHERE `download_id` = '" . $id . "'")->rows; return $result[0]['filename']; } функция вернёт имя файла.3. Теперь отредактируем контроллер catalog/controller/module/category.php и сформируем путь к этому файлу: вставить это в тело функции protected function index() $this->data['price'] = HTTP_SERVER . 'download/' . $this->model_catalog_category->getFileName(1); 4. Ну и наконец вставим ссылку в представление catalog/view/theme/ваша_тема/template/module/category.tpl <a href="<?php echo $price; ?>">Скачать прайс-лист</a>

Строки в guest_step_1.php закоментили?