Проблемы OCMOD

- Posted in Uncategorized by
В этот раз сдеаю всё как положено

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

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

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

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

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

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

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

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

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

- Posted in Uncategorized by

Почитал баг 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

- Posted in Uncategorized by

Речь про версию 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-ую! Сбив меня со следа очень конкретно и уведя в совершенно неправильном направлении. Пля! Чтоб ему икалось.

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

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

- Posted in Opencart by

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

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

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

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

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

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

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

- Posted in Uncategorized by

Что-то я совсем забыл написать: у нас уже давно есть и прекрасно работает (на 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.1.1 bugfix: default language fallback

- Posted in Uncategorized by

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

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

Но всё равно не учтён один момент. Если в английском работает логика наследования строки из english/default.php (например, переводы text_continue, text_yes, text_no и т.п. не дублируются в языковых файлах модулей и компонентах движка, а берутся из default.php), то в случае точно такой же ситуации в дополнительном языке языковый ресурс выбирается по неправльной цепочке:

  • надо: ru/module -> ru/default.php -> en/default.php
  • а происходит так: ru/module -> en/module

И вуаля: в русском строки нет (т.к. её не было в оригинале), в английском нет (т.к. там оно берётся из default.php), в результате - вывод служебного ключа строки, а не правильного перевода. Вот те самые text_home, button_continue, button_ok и тому подобные.

Лечится так:

commit b08fa836f2a55eb9ef2205ce8c3491b6d00c5319
Author: Ruslan Brest <rb@labtodo.com>
Date:   Tue Jan 13 11:01:54 2015 -0500
    [!][lang] fix language fallback:
    
    if translation string not found in lang/module/submodule,
    fall back to lang/default at first, then to english/default
diff --git a/html/extensions/system/library/language.php b/html/extensions/system/library/language.php
index c8ba268..5d10d50 100644
--- a/html/extensions/system/library/language.php
+++ b/html/extensions/system/library/language.php
@@ -15,16 +15,18 @@ class Language {
    public function load($filename) {
        $_ = array();
 
-       $file = DIR_LANGUAGE . $this->default . '/' . $filename . '.php';
 
-       if (file_exists($file)) {
-           require($file);
-       }
-
-       $file = DIR_LANGUAGE . $this->directory . '/' . $filename . '.php';
-
-       if (file_exists($file)) {
-           require($file);
+       $files = array(
+           DIR_LANGUAGE . $this->default   . '/' . $filename . '.php',
+           DIR_LANGUAGE . $this->directory . '/' . 'default.php',
+           DIR_LANGUAGE . $this->directory . '/' . $filename . '.php'
+           );
+
+       foreach($files as $file)
+       {
+           if (file_exists($file)) {
+               require($file);
+           }
        }
 
        $this->data = array_merge($this->data, $_);

Процессы в мелких webdev командах

- Posted in Uncategorized by

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

Но вот увы. Теоретически очень хорошо подходит под идею. На практике - не работает. Точно так же у нас не взлетели и багтрекеры (issue tracker) в гит-репозиториях (Github, Bitbucket). Но там мне они и самому неудобны: хочется доступности в оффлайне, как весь репо с работой - рядом и перед носом. А оно где-то далеко и оторвано.

Что работает?

Сумбурные обсуждения по скайпу плюс быстрая фиксация кем-то важных огрызков разговоров в файлы - в общем репо или в соседней с репо-папкой локальной "репо.MNT" (MNT - от слова maintenance, обслуживание). Забыли оперативно записать - считай потеряли. Потом фиг найдёшь. Поиск в скайпе сделан для отъявленных мазохистов.

Ах, ну да - гит-репозитории как бы подразумеваются. Любые распределённые VCS, но мы только с гитом работаем. Возможность кипучей работы оффлайн и синхронизация с удалёнными репами -- киллерфича.

Такие дела.

На сегодня наверное всё, хотя у меня ещё есть что сказать про тудушки на flat files и "наколенных" вики на россыпях Markdown файлов. Но пусть утрясётся и проверится подольше.

Opencart 2.0.1.1 bugfix: отправление отзывов к товару

- Posted in Uncategorized by

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

В результате было непонятно, что вообще произошло, пользователи отправляли по несколько отзывов (самые прилежные), а лог ошибок опенкарта заполнялся строчками, причину и место возникновения которых хрен угадаешь:

2014-12-30 18:44:07 - PHP Warning:  html_entity_decode() expects parameter 1 to be
string, array given in /..../system/library/mail.php on line 30
2014-12-30 18:44:07 - PHP Notice:  Error: E-Mail to required!
in /..../system/library/mail.php on line 63

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

Лечится так

Простыми словами:

  • открываем catalog/model/catalog/review.php,
  • ищем строку $mail->setTo(array($this->config->get('config_email')));
  • и убираем `array(` с одной стороны и лишний `)` с другой.

Вторая добавка там же рядом, чуть ниже (см. diff) - чтобы избежать ошибок при отправке уведомлений по списку email-ов другим админам магазина. Уведомления отправляются на email владельца магазна (указывается в настройках магазина) и по списку дополнительных адресов в настройках, разделённому запятыми. Если у вас вокруг запятых затешутся пробелы - будут ошибки.

Цветными словами:

commit 870bb1469173e9ec28346408bc19838838c6fd17
Author: Ruslan Brest <rb@labtodo.com>
Date:   Sat Jan 10 20:47:00 2015 -0500
    [!] fix admin email notification sending when customer posts product review
diff --git a/catalog/model/catalog/review.php b/catalog/model/catalog/review.php
index 2eeab26..ae23828 100644
--- a/catalog/model/catalog/review.php
+++ b/catalog/model/catalog/review.php
@@ -22,7 +22,7 @@ class ModelCatalogReview extends Model {
                        $message .= $this->db->escape(strip_tags($data['text'])) . "\n\n";
 
                        $mail = new Mail($this->config->get('config_mail'));
-                       $mail->setTo(array($this->config->get('config_email')));
+                       $mail->setTo($this->config->get('config_email'));
                        $mail->setFrom($this->config->get('config_email'));
                        $mail->setSender($this->config->get('config_name'));
                        $mail->setSubject($subject);
@@ -33,6 +33,7 @@ class ModelCatalogReview extends Model {
                        $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();

Opencart 2.0.1.1 bugfix: OCMOD Multiline fix

- Posted in Uncategorized by

В OCMOD нами добавлена поддержка атрибута "quote" (bool) в режиме regex. Это позволяет делать замену не строки, а набора строк. С этим переключателем используется функция preg_quote:

preg_quote() takes str and puts a backslash in front of every character that is part of the regular expression syntax. This is useful if you have a run-time string that you need to match in some text and the string may contain special regex characters. The special regular expression characters are: . \ + * ? [ ^ ] $ ( ) { } = ! < > | : -

После этого preg позволяет многострочную замену. Обычный режим работы продолжает работать по-старому: просто добавляется опция, с которой становится возможно использовать многострочные замены в ocmod XML.

Рекомендуется всем: стандартный функционал не затрагивается, появляется новый.

Также описано на OpencartJazz: OCJ :: OCMOD Multiline fix. Там прикреплён изменённый файл, но пока его можно скачать только после регистрации и "покупки" за 0.00. Будет время - починю это неудобство.

diff --git a/admin/controller/extension/modification.php b/admin/controller/extension/modification.php
index 086a65c..7159ffb 100644
--- a/admin/controller/extension/modification.php
+++ b/admin/controller/extension/modification.php
@@ -307,12 +307,18 @@ class ControllerExtensionModification extends Controller {
 } else {                                   
    $search = $operation->getElementsByTagName('search')->item(0)->textContent;
    $limit = $operation->getElementsByTagName('search')->item(0)->getAttribute('limit');
+   $quote = $operation->getElementsByTagName('search')->item(0)->getAttribute('quote');
    $replace = $operation->getElementsByTagName('add')->item(0)->textContent;
                                        
    // Limit
    if (!$limit) {
        $limit = -1;
    }
+
+   // Quote
+   if ($quote=='true') {
+       $search = preg_quote($search);
+   }
 
    // Log
    $match = array();

Opencart 2.0.1.1 bugfix: OC2 extension installer

- Posted in Uncategorized by

Подарок тем пользователям OC2, которые ловят ошибки JSON Error при попытках использовать стандартный установщик расширений в OC2 (при правильно прописанных параметрах в настройках магазина на вкладке FTP).

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

  • Исправлена ошибка "PHP Warning: Invalid argument supplied for foreach() ... on line 333";
  • Подавление вывода предупреждений "PHP Warning: ftp_mkdir(): Create directory operation failed ... on line 338" (возникает всегда - при попытках создания существующих каталогов, таких как catalog, admin, admin/controller и т.д.);
  • включение пассивного режима FTP для устранения ошибки "PHP Warning: ftp_put(): Illegal PORT command ... on line 345"

Также описано на OpencartJazz: OCJ :: OC2 extension installer bugfix. Там прикреплён изменённый файл, но пока его можно скачать только после регистрации и "покупки" за 0.00. Будет время - починю это неудобство.

Для параноиков: мне даром не нужны ваши регистрации и личная информация. Просто мне удобно обслуживать и обновлять файлы в одном месте. И это место на данный момент -- там.
commit a60015450b6516406dcbf15f5e978b43eeee693f
Author: Ruslan Brest <rb@labtodo.com>
Date:   Thu Dec 25 20:43:39 2014 +0200
    [!] bugfix OC2 extension installer:
    
    - fix "PHP Warning:  Invalid argument supplied for foreach() ... on line 333";
    - prevent "PHP Warning:  ftp_mkdir(): Create directory operation failed ... on line 338"
      (when existing directories created: catalog, admin, admin/controller, etc.);
    - prevent "PHP Warning:  ftp_put(): Illegal PORT command ... on line 345"
diff --git a/public_html/admin/controller/extension/installer.php b/public_html/admin/controller/extension/installer.php
index 55f4517..1755cca 100644
--- a/public_html/admin/controller/extension/installer.php
+++ b/public_html/admin/controller/extension/installer.php
@@ -295,6 +295,10 @@ class ControllerExtensionInstaller extends Controller {
                $login = ftp_login($connection, $this->config->get('config_ftp_username'), $this->config->get('config_ftp_password'));
 
                if ($login) {
+
+                   // Prevent "PHP Warning:  ftp_put(): Illegal PORT command"
+                   ftp_pasv($connection, true);
+
                    if ($this->config->get('config_ftp_root')) {
                        $root = ftp_chdir($connection, $this->config->get('config_ftp_root'));
                    } else {
@@ -330,12 +334,16 @@ class ControllerExtensionInstaller extends Controller {
                                // Basename all the directories because on some servers they don't return the fulll paths.
                                $list_data = array();
                                
-                               foreach ($list as $list) {
-                                   $list_data[] = basename($list);
+                               if (FALSE !== $list) {
+                                   foreach ($list as $list_item) {
+                                       $list_data[] = basename($list_item);
+                                   }
                                }
                                                                
                                if (!in_array(basename($destination), $list_data)) {
-                                   if (!ftp_mkdir($connection, $destination)) {
+                                   // Prevent "PHP Warning:  ftp_mkdir(): Create directory operation failed" when
+                                   // existing directories created
+                                   if (!@ftp_mkdir($connection, $destination)) {
                                        $json['error'] = sprintf($this->language->get('error_ftp_directory'), $destination);
                                    }
                                }
Page 1 of 4