Ruslan Brest, rb.labtodo.com
Backend web-developer: CodeIgniter, PHP, MySQL, OpenCart, PrestaShop, MaxSite CMS

OpenCart

Минимальная цена расширений на Opencart.com теперь уже 20USD

На опенкарт.ком нововведение:

Price must be 20.00 USD or more!

Раньше нижняя планка была 10$.

И фиг теперь отредактируешь описание - надо и цену поднимать.

Ещё там после переделки есть чудесатое поле "License period" (от 1 до 12 месяцев). Причём в админке у продавцов это поле расположено в одной строке с ценой на модуль. И логика получается такая: за N баксов модуль продается и доступен 1-12 месяцев. Дальше покупай повторно.

Но! Самое интересное, что в пользовательском интерфейсе (в магазине расширений) это поле невменяемо названо не сроком лиценции, а сроком бесплатной поддержки! Офигеть. Не бесплатных обновлений (если будут появляться), не сроком доступности модуля для скачивания, а вот так в лоб: 12 Months Free Support (ну, например). То есть купил кто-то модуль на нестандартный шаблон - и ты ему целый год должен все допилы бесплатно, не говоря уже о бесплатной адаптации под нестандартный шаблон. Потому что "у тебя на сайте так написано".

Ковыряюсь в Multimerch

Ковыряюсь в Multimerch. Той версии, которая ещё бесплатной была - 6.какая-то, если правильно помню.

Люди, вы меня улыбаете. Я думал, Даниэль - один такой уникум, который даже индексы в БД расставить не может. Нет, не один.

Шаблоны в Опенкарт 2.3 переводят с PHP на движок Twig

Начиная с версии 2.3, Опенкарт переключит стандартный шаблонный движок с PHP на формат Twig-препроцессора. Обычный PHP обещают тоже оставить: если у файлов шаблонов расширение .tpl - используется PHP для рендеринга, если .twig - то шаблонный движок Twig.

Про версию 2.2

Мы начали адаптировать модули под эту версию, но стали натыкаться на кучи изменений, которые теперь возвращаются авторами опенкарт назад, на исходные позиции. Мы боремся-боремся с нововведением и глюками, а потом заглядываем в репозиторий и видим, что там это тоже обнаружили и вернули как было в 2.1.x... То есть это какая-то экспериментальная версия-выброс, решения из которой дальше не пойдут. В итоге мы решили заморозить все работы по адаптации для 2.2 в надежде дождаться нормальной версии.

Первые обзоры Opencart 2.2

Оперативненько! Появились первые годные обзоры Opencart v2.2.0.0:

С версии 2.2 опенкарт будет использовать Composer

18 января 2016 г. Ruslan Brest E-commerce » OpenCartОбсудить

Просматривал лог коммитов и случайно заметил появление и потерю папки "vendor".

Штоооооооооо? Composer в опенкарте????

И таки да, в корне есть `composer.json`:

{
    "name": "opencart/opencart",
    "type": "project",
    "description": "OpenCart",
    "keywords": ["opencart", "ecommerce", "framework", "opensource"],
    "homepage": "http://www.opencart.com",
    "license": "GPL-3.0+",
    "require": {
        "cardinity/cardinity-sdk-php": "^1.0",
        "braintree/braintree_php" : "3.2.0",
        "leafo/scssphp": "0.0.12",
        "php": ">=5.4.0"
    }
}

В `install.txt`:

COMPOSER OR NOT TO COMPOSER
From version 2.2 composer has been added to aid developers who want to use composer libraries. 2 versions of OpenCart
will become available, one compiled and one non-compiled (composer.json only - no files in vendor folder).
We STRONGLY advise leaving the vendor folder outside of the webroot - so files cannot be accessed directly.
Composer installing is extremely simple - https://getcomposer.org

Что в переводе на русский значит: начиная с версии 2.2, в опенкарт добавлен Composer для тех, кто понимает. Будет доступно 2 версии Опенкарт: одна скомпиленная (со всеми нужными либами), другая - только с composer.json (для тех, кто пользуется composer-ом).

Поразительно.

James Allsup делает своё дело. Осталось отстранить Даниэля от разработки, и будет всем счастье.

Отправка копий вопроса с сайта всем админам магазина

18 января 2016 г. Ruslan Brest Howto » E-commerce » OpenCartОбсудить

Оказалось, в Opencart 2 на странице обратной связи (information/contact) письмо отсылается только на главный email (владельцу магазина). Если какие-то адреса для дополнительных оповещений в админке заполнены - здесь они всё равно игнорируются.

Это неудивительно, поскольку в опенкарт функционал дублируется. Тупо забыли.

Чтобы исправить, надо открыть файл catalog/controller/information/contact.php. В самой первой функции этого файла (public function index()) будет виден кусок кода отправки почты:

$mail = new Mail($this->config->get('config_mail'));
                        $mail->setTo($this->config->get('config_email'));
                        $mail->setFrom($this->request->post['email']);
                        $mail->setSender($this->request->post['name']);
                        $mail->setSubject(sprintf($this->language->get('email_subject'), $this->request->post['name']));
                        $mail->setText(strip_tags($this->request->post['enquiry']));
                        $mail->send();

Сразу после него надо добавить несколько строк:

// Send additional alert emails
                        $emails = explode(',', $this->config->get('config_mail_alert'));
                        foreach ($emails as $email) {
                                $email = trim($email);
                                if ($email && preg_match('/^[^\@]+@.*.[a-z]{2,15}$/i', $email)) {
                                        $mail->setTo($email);
                                        $mail->send();
                                }
                        }

Теперь копии письма будут получать все администраторы магазина, перечисленные в поле дополнительных email-адресов (см. настройки магазина).

Совместимость

Приведённый код - из oc2011.

В oc2101/oc2102 кода чуть больше, но суть остаётся та же: добавлять после $mail->send(); и перед $this->response->....

Соответственно все версии, что между ними (oc2020, oc2031), лечатся аналогично. ocStore тоже.

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

Проблемы OCMOD

12 апреля 2015 г. Ruslan Brest Web development » E-commerce » OpenCart2
В этот раз сдеаю всё как положено

Вспомнил вчера ещё две взаимосвязанные особенности OCMOD, которые мешают жизни:

  • отсутствует механизм сортировки и выстраивания порядка исполнения модификаций (sort order). Как следствие - нет возможности гарантировать, что решённые сегодня конфликты не возникнут завтра или через неделю. Поменяется порядок исполнения двух конфликтующих модулей (второй из которых, например, был подправлен, чтобы учитывать изменения, внесённые первым) - и приплыли. Более-менее быстрым и простым способом исправить ситуацию является сортировка модификаций по полю `date_added`. Но более приемлемым для пользователей вариантом будет, конечно, ввод дополнительной колонки `sort_order` в базу и в интерфейс админки и сортировка по ней;
  • механизм обновления модификаций отсутствует: их можно только удалить и установить заново. Это меняет как положение записи в таблице БД, так и дату добавления.

В vQmod порядок исполнения модулей мог регулироваться путём переименования файлов: они выбирались и исполнялись в алфавитном порядке.

Есть и другие проблемы.

Вот довольно заметная: в OcMod XML-ки модификаций хранятся в базе. Если у вас есть конфликт модулей и надо искать причины, анализ текста модификаций затруднён. Предварительно надо извлечь все XMl-тексты модулей, чтобы получить хотя бы возможность поиска по ним в более привычной среде: IDE, текстовом редакторе, файловом менеджере, grep-ом... Механизма экспорта модулей из БД в файлы нет (может кто добрый и написал уже - не видел пока).

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

Проблемы Extension Installer (установка расширений)

  • Расширениям предоставлена возможность добавлять ИЛИ ЗАМЕНЯТЬ любые файлы движка. Файлы модуля не хранятся где-то локализовано в одной папке
  • Не предусмотрен uninstall. Надо удалить модуль? Пользователю придётся вычищать его файлы вручную

Неприятные сюрпризы Summernote и Firefox

Почитал баг opencart/opencart#2521 и его фикс. Подумал. Поэкспериментировал.

Офигеваю.

Opera (12.60 на старом движке, под линуксом) генерирует при нажатии кнопки Bold на панели Summernote семантически приятный код со strong:

test <strong>word</strong>

Как оказалось, это - подарок судьбы, а не является нормой. В других браузерах генерируемый HTML исходник может отличаться в зависимости от CSS админки. Это же полный переворот с ног на голову идей семантической вёрстки и отделения представления (внешнего вида) от смысла (чистой семантики исходного кода).

Например, Firefox (v37.0) при исправленном CSS (убранном "text-weight:500" с текста по умолчанию) генерирует

test <span style="font-weight: bold;">word</span>

Кроме мата я на это не могу ничего дипломатичного сказать. Поэтому промолчу. (Нет, ну я не могу! Спан со встроенным стилем?!?! Ну $L@#ь, ну %1z*#ц же!)

Если CSS в админке без исправлений, то на стандартном тексте кнопка Bold в Summernote в FFox нажата и генерируемый код дополняется ещё одним лишним спаном.

В общем, Firefox разочаровал по полной. Даже не Summernote, нет. Хотя теперь я многократно счастливее от того, что сразу ушёл от дурацкого WYSIWYG-а в сторону Markdown.

Если верить сказанному в багрепорте про Chrome, там такой ошибки нет. Боюсь даже Хром запускать, чтобы посмотреть, какой код генерируется.

UPD. Google Chrome: поведение кнопки Bold на панели Summernote, а также внешний вид текста в редакторе не зависит от CSS, в отличие от Firefox. Генерируемый в Хроме код - такой же, как в Firefox (спан со стилем), лишь без глюка кнопки [B] (bold/normal).

Выводы у меня такие

  1. WYSIWYG зло. Однозначно;
  2. Firefox - неприятное открытие. Для меня это событие масштаба "событие года". Совершенно неожиданно. Хотя я и не был фанатом FFox;
  3. Оперу зауважал ещё больше, хотя и думал, что дальше некуда. Старую, разумеется. Новой у линуксоидов вообще ещё нет, а по описаниям виндовс-пользователей, новую даже пробовать не хочется, настолько это не Опера, а чёрт знает что;
  4. IE11 ведёт себя так же, как FFox. (Вот уж "комплимент" для фарфокса...) Chrome - вроде бы нет;
  5. Код, генерируемый Summernote, может зависеть от CSS админки (!) и от браузера (!). У сторонников семантичекой вёрстки на этом пункте волосы шевелятся и становятся дыбом. Поведение кнопок Summernote зависит от стилей текста в CSS. Это тоже весьма заметный такой ахтунг.