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

Перевод Opencart 1.5.x

Русский перевод Opencart: v1.5.0.5 - 1.5.5. Информация о других переводах (русский, украинский язык)

Quickcheckout: one-page simple checkout

Quickcheckout: one-page simple checkout

Проблемы 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. Это тоже весьма заметный такой ахтунг.

Проблемы лога ocmod.log

2 апреля 2015 г. Ruslan Brest Howto » Web development » E-commerce » OpenCart2

Речь про версию oc2011. Вышедшую 1-2 дня назад oc2020 ещё не смотрел, хотя думаю, там та же беда.

В лог "ocmod.log" я уже заглядывал в самом начале знакомства с OC2 - там страшный бардак и чёрт ногу сломит. Этот лог - не помощник в поиске ошибок, а наоборот. Штука скорее бесполезная, которую надо взять и переделать.

Единственная хоть немного полезная в быту фича - возможность поискать строки "NOT FOUND!". И если они есть, можно отмотать вверх и убедиться - в твоём модуле ошибки случились или в каком-то другом.

Пока мне этого как-то хватало. Мало OCMOD-ами занимался. Но сегодня пришлось вплотную с ним разбираться и постигать логику находящихся в ocmod.log записей. И обнаружилось что-о-о-о? Правильно: очередной фееричный трындец.

Среди прочих записей у меня была такая:

CODE: <h2><?php echo $heading_title; ?></h2>
NOT FOUND!

Она оказалась самой информативной и точной. Немного отмотав лог вверх, можно найти строку "FILE: ..." и выяснить, в каком файле надо искать проблему. К слову: в этом блоке почему-то не было строки наподобие LINE: 16, которыми обычно сопровождаются как найденные, так и ненайденные блоки кода. Но если блок не найден, то вполне логично, что и номера строки не будет: не найден же. Так я подумал и принялся разгребать лог дальше.

Дальше была такая запись об ошибке:

CODE: <div class="col-sm-2"><img src="<?php echo $thumb; ?>" alt="<?php echo $heading_title; ?>" title="<?php echo $heading_title; ?>" class="img-thumbnail" /></div>
LINE: 24
NOT FOUND!

Здесь логика сломалась. Попытка обсудить этот кусок с коллегой, больше работавшим с OCMOD, привела к быстрой поломке и его логики. Код из XML найден, строка такая-то. (Строка в XML и в исходнике совпадает полностью, это было сразу же проверено.) Но почему она NOT FOUND? Сразу после того, как была FOUND?

Бился я над этим часа два - проверял и то, и это, и концы строк, и trim="true", и настройки FTP-клиента (вдруг концы строк на лету конвертирует), и чёрт знает что ещё. В общем, 2 часа. Мучился до тех пор, пока не обратил внимание, что эта строка в исходнике - 21-я, а не 24-я. "Обана!" - подумал я. И сравнил эти строки в TPL клиента и в оригинальном файле.

И таки да - именно в этой строке был исправлен один символ. И немного дальше в нашей XML-ке были правила, касающиеся той строки, изменённой. Но какой-то, блин, гений в лог записал совершенно другую строку, а не 24-ую! Сбив меня со следа очень конкретно и уведя в совершенно неправильном направлении. Пля! Чтоб ему икалось.

Не лог, а предательство сплошное.

Две разные реализации vQmod для Opencart 2, самая распространённая несовместима и конфликтует с OCMOD

13 марта 2015 г. Ruslan Brest E-commerce » OpenCart6

На прошлой неделе пришлось разбираться с vQmod и проблемами его наличия на OC2 (Opencart второй версии). OCMOD является встроенным в OC2 аналогом vQmod с немного другим синтаксисом XML-файлов. Зачем людям vQmod на второй версии Опенкарт - не будем сейчас затрагивать этот вопрос.

vQmod / Q+J

Выяснилась очень неприятная вещь. Самый популярный вариант реализации vQmod (авторы Qphoria и Jay6390) оказался несовместим с OCMOD. То есть эта версия может быть установлена на OC2, но работает она неправильно, мешая исполняться OCMOD-расширениям.

Причина этого - независимая работа по модификациям. Оба механизма (встроенный OCMOD и vQmod/Q+J) делают свои копии кеша из оригинальных файлов. Файлы используются в системе в такой приоритетности:

  • cache vqmod
  • if not found, cache ocmod
  • if not found, original files.

Хотя поведение vQmod должно было быть таким:

  • проверяем кэш ocmod и модифицируем файл.
  • если не найден, модифицируем оригинальный файл.

vQmod / JNeuhoff

Но есть ещё одна реализация vQmod для Opencart 2. Её автор - JNeuhoff. Назовём её vQmod/JN.

Она оказалась реализованной грамотно. В этой реализации заменяются 2 файла движка OC2, после чего Опенкарт становится способным понимать как свой OCMOD синтаксис, так и синтаксис XML-файлов от vQmod. Все расширения устанавливаются через Extensions / Extension Installer и находятся затем в едином месте, где ими можно управлять: Extensions / Modifications. Все модифицированные файлы лежат в system/modifications/

При установке заменяются файлы

admin/controller/extension/installer.php

admin/controller/extension/modification.php

Резюме

Тем, кому всё-таки нужен vQmod при работе со второй версией Опенкарт, однозначно надо менять движок vQmod-а на бесконфликтную и совместимую реализацию от JNeuhoff.

Отличить неправильную версию от правильной легко: если вы используете vQmod и в корне магазина присутствует папка `vqmod` - это неправильная версия. Для её деинсталляции надо убрать vqmod-вызовы из index.php и admin.index.php или вернуть оригинальные копии этих файлов, после чего убрать из корня папку vqmod. А используемые XML-ки оттуда установить в новый vQmod/JN, правильный и бесконфликтный.

За 2 недели мы столкнулись уже с двумя проектами, где понадобилось обновить vQmod -- оба проекта живы-здоровы и рады. Чего и вам желаем.

Clipboard Catcher для линуксоидов (bash, xclip)

19 февраля 2015 г. Ruslan Brest Linux » HowtoОбсудить

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

При запущенной утилитке всё, что копируется в клипборд, дублируется в текстовый файл. Очень удобно, когда предстоит много копи-паста: позволяет избавиться от Alt-Tab, Ctrl-V, Alt-Tab после каждого Ctrl-C.

Далее...

Прикрутил Markdown Extra к Opencart 2.0.1.1

Писать описания стало в разы легче: Summernote (в Opencart 2.x), как и любой другой WYSIWYG HTML редактор (CKEditor в Опенкарт 1.5.x), мне больше мешают, чем помогают. Единственное место, где при работе над контентом изредка возникает желание переключиться с режима исходников на "кнопочки" - вставка ссылки вокруг выделенного текста и может быть ещё списки.

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

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

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

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

При этом, что очень важно, ничто не мешает использовать HTML в описаниях, если есть необходимость! То есть переезд с HTML на Markdown в описаниях товаров и категорий оказывается безболезненным. Старые описания показываются как и показывались.

OCJ: в акаунте у купленных файлов теперь видна дата последнего обновления

В магазине расширений OpencartJazz.com мелкое, но удобное улучшение: в акаунте покупателя, в "Мои заказы / Файлы для скачивания" теперь видна дата обновления файлов.

Следить за изменениями стало проще!

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

P.S. Стандартно Опенкарт выводит там никому не нужную дату первого создания файла для скачивания, которая никогда не обновляется.

Совсем забыл: Opencart SeoPro для OC2 с кешированием и мультиязыками в URL

31 января 2015 г. Ruslan Brest Web development » E-commerce » OpenCart16

Что-то я совсем забыл написать: у нас уже давно есть и прекрасно работает (на Opencart 2.0.1.1) SeoPro для OC2!

"Из коробки" есть:

  • кеширование
  • мультиязык в URL (site.com/ru/tratata/, site.com/en/tratata/)

Возможно, что-то ещё, что я уже не очень помню. Это основное. Я активно пользуюсь версией 2.0.1.1 для живого магазина, благодаря чему русский перевод и SeoPro/OC2 ежедневно тестируются и шлифуются. Перевод во многих местах вычитывается в контексте и исправляется по мелочам, сеопро уже не трогаем - работает стабильно. Хотя может ещё про дефолтный язык что-то подумаем. Позже.

Github: https://github.com/rb2/opencart-seopro

OpencartJazz: OCJ SeoPro для Опенкарт 2.0.x

Русское описание пострадало - была мешанина из английского и русского, я в процессе переделки оставил только английский в README. Русское добавлю когда-нибудь, пункт в туду записан.

Устройство Opencart 2.0 (OC2): работа инсталлятора, модификаций и модулей

27 января 2015 г. Ruslan Brest Howto » E-commerce » OpenCart2

Мда… Синтаксические ошибки на этапе формирования модификации запросто укладывают весь сайт. OCMOD формирует файл с ошибкой, дальше ВСЁ… ФИНИШ. Пока не пофискишь - не поедет. Учитывая, что синтаксическая ошибка может запросто возникнуть при конфликне модулей, система будет слабо автоматизируемой. Должен работать квалифицированный админ. Сценарий примерно такой:

Далее...

Opencart 2.0.1.1 bugfix: default language fallback

Если вы пользуетесь не только английским языком, то вам наверняка попадались отсутствующие строки наподобие text_home, button_continue, button_login.

Раньше в этом случае вообще происходила ошибка и страница "ломалась": надо было следить за соответствием переводов и добавлять отсутствующие в переводе строки или дублировать файл целиком из английской версии модуля. В версиях Opencart 2.0 отсутствие некоторых строк в переводах наконец-то более-менее исправлено. Если раньше возникала ошибка, то сейчас берётся строка из языка по умолчанию (английского).

Но всё равно не учтён один момент. Далее...