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

Web development

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

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

Речь про версию 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Такие дела.

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

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

12 января 2015 г. Ruslan Brest Howto » Web development » E-commerce » OpenCart9

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

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

Далее...

Opencart 2.0.1.1 bugfix: OCMOD Multiline fix

В 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

26 декабря 2014 г. Ruslan Brest Howto » Web development » E-commerce » OpenCart1

Подарок тем пользователям 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"

Далее...

[opencart][BUG] Возможно назначить для категории родителя из своей же подветки

Ой, вэй! Наткнулись на фееричный косяк. Родителем категории можно назначить какой-то из подчинённых узлов той же ветки. Например, перенести `Category` с верхнего уровня в `Category > Monitors > test1`.

Баг присутствует в oc1564 и ocs15512. Другие версии и сборки не проверялись.

(oc - Opencart, ocs - ocStore, как обычно.)

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

Будет время - допишу здесь рецепт.

Инструменты совместной работы: что использовать для обсуждений и сбора информации

У меня очередной виток переосмыслений.

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

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

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

Issues в битбакете или гитхабе и другие багтрекеры - тоже что-то не то для обсуждений и собирательства идей. В общем-то всё вроде доступно - и обсуждать, и собирать, и решать, и переносить, и назначать. И теги там есть - задачи фильтрации и категоризации с навигацией вполне решаются. Где теги, где категории, где milestones или ещё что подобное. Багтрекеры наряду с email для меня - очень ценные инструменты.

Но вот как-то не клеится у нас их активное использование. То ли сами инструменты так себе по удобству, то ли ещё что.

Надо что? Далее...