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

Web development

Ковыряюсь в Multimerch

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

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

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

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

Sticky-меню и sticky-footer - кошмар для мобильных пользователей

Что за тренды такие? То делают повсеместно буквы такие громадные, как будто люди без очков на Земле кончились. А те, что остались, обожают листать по 5-10 строчек текста вместо того, чтоб читать. Там, где легко 50 помещалось до того, как дизайнерам не сказали, что теперь это круто. Были палмы с экранами 160x160 и 320x320 - на них комфортно помещалось 20-25 строк текста. Теперь экраны телефонов в 3 раза больше физически, разрешение то 480 на хрен-знает-сколько, то 800x480. А количество строк текста стало не 50, а 20 или и того меньше меньше...

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

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

Желаю всем веб-мастерам поставить на sticky-menu кнопку закрытия. И отслеживать аналитику кликов по убиранию вашего мусора с наших экранов. Не нужно на экране постоянно ни меню, ни футер, ни соцкнопки. Мы прекрасно помним, где они находятся, а время нахождения на сайте эти ухищрения не увеличат. Скорее уменьшат. Видеть кусочек полезного контента сквозь крохотную оставшуюся амбразуру на весьма больших экранах мобильных устройств и одновременно радоваться такому неудобству - задачи несовместимые.

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

How to run rsync via non-standard ssh port

9 февраля 2016 г. Ruslan Brest Linux » Howto » Web developmentОбсудить

Не знали, как запустить rsync через нестандартный порт (при работе через SSH, без ответного Rsync демона на сервере)?

Теперь знайте:

rsync -avz -e "ssh -p 12345" ./public_html/ username@yourserver.com:/var/www/html/

Здесь 12345 - номер порта, username - ваш логин и yourserver.com - доменное имя или IP вашего сервера.

Пришлось немного повозиться с чтением манов и поэкспериментировать. Надеюсь, кому-то сэкономит время.

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

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

Проблемы 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

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 в описаниях товаров и категорий оказывается безболезненным. Старые описания показываются как и показывались.