Лайфхак: как разделять разговоры по темам в Skype

- Posted in Uncategorized by

Удалось найти решение давно мучившей проблемы: как разделить разговоры в скайпе по темам, сделать подобие тредов?

Решение - создавать чаты. И если на троих и более это не проблема, то попытка создать групповой чат (Conference Call) на двоих в скайпе приводит к звонку (!). Дятлы.

Решение кроется в скрытых командах скайпа, полный список которых можно увидеть, набрав в сообщении /help. Итак, чтобы создать чат на двоих и обсуждать там вопросы только по определённой теме (проекту), надо сперва из главного меню Скайпа создать групповой чат (Conference Call) на троих участников, а затем третьего убрать командой /kick skypename.

Надеюсь, это поможет тем, у кого случаются бурные обсуждения по нескольким вопросам, после которых лог общения превращается в винегрет со спагетти.

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

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

- Posted in Uncategorized by

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

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

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

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

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

- Posted in Uncategorized by

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

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

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

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

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

Такие дела.

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

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

- Posted in Uncategorized by

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

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

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

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

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

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

Надо что? Например, идею обсудить и собрать информацию по ней. Будем делать или нет? Если будем, то что именно и нет ли сопутствующих идей? Обсуждать это всё в одном issue? Можно, делали. Как только попадается объёмная задача, которая начинает генерировать несколько связанных задач - начинаются неудобства и проблемы. Быстро перерастает она границы предназначенного ей хранилища и начинает расползаться. И опять её надо где-то снаружи собирать. То ли в вики, то ли в форуме.

Туду-листы с возможностью совместного использования? Вроде Todoist, Wunderlist и наверное ещё около десятка достойных сервисов наберётся из той же оперы. Попытки и здесь были неоднократные. Всё на уровне попыток осталось. То там неудобно, то там. Возможность обсуждения часто присутствует. Но вообще - пятьдесят на пятьдесят, иногда ориентир - простота. Удобны ли они? Не слишком, т.к. туду-листы обычно нацелены на "сделал и вычеркнул". То есть если в обсуждениях появляется что-то ценное - его надо где-то снаружи сохранить дополнительно. Иначе вычеркнется, забудется, удалится.

Более монстрообразные инструменты collaboration/groupware? Или сборник аналогичных инструментов по отдельности? Там где собраны под одной крышей проекты, клиенты, вики, таски и ещё что-нибудь? Лет 10 назад я очень активно с некоторыми их представителями пытался наладить работу для небольших групп разработчиков (от нескольких человек до нескольких десятков). Перебрал тогда штук 10-15 решений. Всё не то, косяки то там вылезут, то там. Где-то сразу, где-то после какого-то объёма внесённого контента становится очевидно, что так работать не получится. Единственным инструментом, пережившим эксперименты, можно считать наверное только Redmine. Но я и его не считаю идеальным и удобным. У него своих проблем хватает. С версиями и совместимостью, наличием модулей - в первую очередь.

В общем, сейчас для обсуждений опять пробуем вернуться к механизму форумов. После вики, issues, скайпа и email. У меня там есть Markdown и возможность редактирования постов. Чем не вики? Но в остальном форумы для обсуждений и уведомлений более приспособлены. Ах, да, теги тоже есть. Это если вдруг перерастём границы разделов и форумов - навигация по тегам поможет.

Хотел сначала какие-то плюсы и минусы отметить для каждого из озвученных решений, но теперь кажется, что это лишнее. Разве что вкратце? В нынешних вики меня очень привлекает доступ через гит и возможность работы оффлайн. Этого мне очень не хватает в issue tracker-ах (хотя для гитхаба есть пара инструментов, работает в одну сторону). В остальных местах такого способа взаимодействия очень хотелось бы, но не до состояния "надо, прям аж не могу".

Но если есть такие движки форумов, например -- подскажите.

Если ещё issue trackers с удобной работой как через Git, так и с веб-интерфейсом -- вообще было бы здорово. Именно для командной работы и кросс-платформенных применений. Потому что индивидуальные туду листы типа `gitodo` - такое, конечно, бывает. Но попользовавшись, понимаешь, что это из разряда "для поиграться" и для энтузиастов, а не серьёзной работы в команде. И интересного инструмента я пока не нашёл.

Знакомим `phpcs` (PHP CodeSniffer) и Sublime Text со стандартом оформления кода FuelPHP

- Posted in Uncategorized by

UPD: При ближайшем рассмотрении оказалось, что отличий от PSR2 больше, чем табы вместо пробелов. Чтобы сделать автоматическую проверку, надо ещё многое переделать, а где-то и дописать. Так что я поспешил: с опубликованным вариантом проверять синтаксис PHP CodeSniffer'ом на соответствие правилам пока что неудобно.


Самый простой способ - поставить в редакторе/IDE правила автоформатирования PSR-2 и заменить использование пробелов в отступах на табуляцию (этим стандарты оформления кода, принятые в FuelPHP, отличаются от PSR-2). Заодно можно включить отображение пробелов и табуляций.

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

Для автоматизации проверки кода существуют разные инструменты: примеры (и важность с удобством применения этого непосредственно в редакторах/IDE) есть в статье http://philsturgeon.co.uk/blog/2013/08/php-static-analysis-in-sublime-text.

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

Знакомим phpcs и ST3 со стандатами оформления кода FuelPHP

  • sudo apt-get install php-codesniffer
    • phpcs -i - показать список установленных стандартов. Нужен psr2 (PSR-2)
    • Если его нет - обновляем полностью CodeSniffer (просто скопировать оттуда папку с PSR2/1 стандартом недостаточно)

    • Это, конечно, грубовато - обновлять напрямую, в обход apt-get , но он считает, что установлена самая свежая версия и более правильного способа я сейчас не знаю.

      cd ~/Downloads
      wget https://github.com/squizlabs/PHP_CodeSniffer/archive/master.zip
      unzip PHP_CodeSniffer-master.zip
      cd PHP_CodeSniffer-master
      sudo cp -r --parents -t /usr/share/php/PHP/ CodeSniffer CodeSniffer.php scripts
      cd scripts
      sudo mv /usr/bin/phpcs /usr/bin/phpcs.ORIGINAL
      sudo cp -t /usr/bin/ phpcs
    • в PSR-2 используются пробелы вместо табуляций и phpcs на них ругается. Сделаем свой стандарт "FuelPHP", основанный на PSR2. Рядом с папкой PSR2 создаём FuelPHP, в которой достаточно одного файла FuelPHP/ruleset.xml :

    • <?xml version="1.0"?>
      <ruleset name="FuelPHP">
       <description>The FuelPHP coding standard.</description>
       <!-- Include the whole PSR-2 standard -->
       <rule ref="PSR2">
       <!-- Redefine 2.4 Indenting -->
       <!-- Code MUST use an indent of tabs, and MUST NOT use 4 spaces for indenting. -->
       <exclude name="Generic.WhiteSpace.DisallowTabIndent"/>
       </rule>
       <rule ref="Generic.WhiteSpace.DisallowSpaceIndent"/>
      </ruleset>

      Проверяем: phpcs -i

      The installed coding standards are Zend, FuelPHP, PHPCS, PSR2, PSR1, Squiz,
      MySource and PEAR
  • install ST3 plugin "Sublime Phpcs" http://www.soulbroken.co.uk/code/sublimephpcs/
  • check config, see HOWTO: http://philsturgeon.co.uk/blog/2013/08/php-static-analysis-in-sublime-text
    • только мы вместо "psr2" теперь напишем свой "FuelPHP" в юзеркониге:

    • Содержимое /home/rb/.config/sublime-text-3/Packages/User/phpcs.sublime-settings :

      {
          "show_debug": true,
          "phpcs_executable_path": "/usr/bin/phpcs",
          "phpcs_additional_args": {
              "--standard": "FuelPHP",
              "-n": ""
          },
      }

Автоматическая проверка в ST3 тепрь работает.

Также можно использовать отдельно: phpcs --standard=fuelphp home.php .

Что даёт установка минимальной цены расширений продавцам и покупателям

- Posted in Uncategorized by

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

  • установка нижней планки (минимальной цены шаблонов);
  • и кол-во продаж за определенный период.

Ни слова про рейтинг почему-то, хотя в теме сразу же появились логичные напоминания об этом. По крайней мере, на этот счёт можно быть спокойным.

Топикстартер выразил уверенность, что эти меры заставят "некачественных" продавцов подтягивать уровень шаблонов.

Меня это рассмешило. И вот почему.

Во-первых -- с чего бы это? Если у меня есть товар по копейке, а его надо продавать не меньше, чем за рубль, чтобы тебя пустили на базар -- я буду его по рублю продавать. Или по рубь пятьдесят: после того, как наклею на него шильдик "самое лучшее качество по беспрецедентно низкой цене". В общем, дистанцируюсь от соседей. Зачем что-то делать для реального повышения качества?

Во-вторых -- давайте пока останемся в шкуре "посредственного дизайнера, жаждущего легких денег". И подумаем, глядя на алгоритм, что надо, чтобы остаться в топе листинга при прочих неизменных условиях? Бинго! Всего-то купить у себя своих же шаблонов 5-10 раз за месяц. А там, смотришь, и ещё кто-то купит. Что теряем? 15% комиссии. При шаблонах по 100 рублей - 15 руб * 10 продаж = 150 руб. В месяц. Остановит меня это от накруток? Если в перспективе - сотня тысяч просмотров в месяц, кто-то да купит. Нет, конечно, не остановит. Буду в топе при любых раскладах. И скорей всего даже выше дорогих и качественных шаблонов автора этого предложения.

Ввод нижней планки вроде бы ставит всех в похожие условия: "дешёвкам" по идее должно стать невыгодно, а "правильным" - легче повышать цену за качество. Проверим теорию цифрами? Проверим. Минимальная цена 500 руб - затраты "накрутчика" в 5 раз больше. Но всё равно остаётся достаточно 1-2 продаж, чтобы накрутка окупилась. Всё, что надо сделать недобросовестным - не сильно выделяться на фоне более качественных работ.

Теперь перейдём к более интересному

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

Короче, каждый сам волен думать и сопоставлять свои затраты и стоимость аутсорса (покупки готового решения). Думаю, это всем очевидно, если хоть на минутку задуматься. Потратить своё время на перекрашивание кнопок в розовый с градиентом, плюс тестирование и проверку с допиливаниями -- или взять готовый шаблон без изысков. Просто тупо перекрашенный, за 3$ (100 руб). Так что любая работа может найти своего покупателя. И не обязательно покупатель - обманутый идиот, которого надо защищать.

И напоследок - самое интересное. Факты и опыт

Мой опыт основывается на расширениях Опенкарт, бесплатных и платных. Число скачиваний которых измеряется сотнями и тысячами. Некоторые - десятками тысяч. Площадка, где они продаются и раздаются бесплатно, как раз имеет ограничение, нижнюю планку на цену расширений: 10$.

Что это даёт покупателям и продавцам? Отвлечёмся пока от технических причин.

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

Продавец не может легко и просто выставить "donation-версию" своей работы рядом с бесплатной.

Это минус. Можно, конечно, озаботиться собственной площадкой для продаж, но это совсем другой разговор. Сейчас мы говорим о проходном и людном месте и желании там выставить продукт своего труда - без траты своих усилий на привлечение внимания посетителей, и их ментальных усилий на переход куда-то ещё и оплату непонятно чем.

Скажем, я бы с удовольствием раздавал свой перевод как бесплатно, так и за доллар. Как это принято в гугл-плее, апп-сторе и альтернативных мобильных маркетах. Хочешь поддержать автора материально - дай копейку. И платящему несложно, и есть надежда, что автору наберется на пропитание и развитие.

Причём это очень серьёзный минус. И (барабанная дробь!) как для продавцов, так и для покупателей. Увы.

Потому что вот что получается: продавцу рано или поздно надо есть. И он пойдёт искать себе пропитание. А куда пойдёт? В сторону своих бесплатных расширений он будет смотреть в последнюю очередь. На сторону, в общем, пойдёт, вдаль от вас. И повернется избушка к вам задом, а не передом.

Я вот поработал над переводом, который нужен был мне лично, и дал его сообществу. Написал пару несложных на мой взгляд расширений, за которые 10$ баксов просить странно (была бы возможность - выставил по 1-3$, не больше) - а они хлоп, и оказывается, нужны сотням людей делают их счастливыми, и скачиваний уже 2.5 тысячи. И за 1$ вместо бесплатного люди были бы не менее счастливыми, т.к. ценность решения для них гораздо выше озвученной цены. Я тоже, и это дало бы мне стимул и возможность поддерживать это направление.

Интересно ли мне развивать и поддерживать переводы под новые версии? Версии, которыми я вообще не пользуюсь, но о которых меня просят то справа, то слева, то напоминают - чего задерживаешься? Пытаюсь, поддерживаю, но скажу честно - неинтересно. Что-то мне предлагают сделать в бесплатном модуле доставки - а мне как-то не до него. Мне есть надо, семью кормить, жильё оплачивать. Мне эти предложения "а давайте вы сделаете ещё вот так" -- как крики клоуну с трибун "а прыгни ещё раз вот так". Сами прыгайте.

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

Если же продавец имеет возможность легко выставить свою работу за 0-1$ или около того - счастливы оказываются оба в итоге. Продавец - потому, что внезапно получает на поддержание штанов от сообщества заметную сумму, покупатель - потому, что за копейки получает гораздо более долго тянущееся удовольствие.

Вот такая экономика отношений в мире бесплатного и опенсорсного.

Как модифицируются способы оплаты для использования с QCPM.1513

- Posted in Uncategorized by
QCPM из-за необходимости изменения способов оплаты делает невозможным одновременное использование стандартной формы и QCPM: либо одна, либо другая. Поэтому обязательно храните резервные копии изменяемых стандартных файлов (точный путь указан в документации - README или INSTALL файлах).

Суть изменений проста: в TPL файлах способов оплаты содержится самая последняя кнопка подтверждения заказа, на нажатие которой обычно вешается обработчик (javascript-функция). Эта функция делает 2 вещи: окончательно подтверждает заказ (после этого он формируется и становится виден в админке) и делает что-то требуемое этому способу оплаты (переадресация на внешний сайт плат. системы или другие действия).

В стандартной форме заказа все проверки производятся до действия этой кнопки.

В QCPM - нет, поскольку всё на одной странице и эта кнопка может быть нажата сразу после загрузки, первой. Поэтому нам требуется вмешаться в стандартный процесс:

  1. Сначала произвести валидацию формы заказа;
  2. Затем сделать то, что предполагалось сделать модулем по нажатию на кнопку "Подтвердить заказ" (передать управление стандартной функции модуля оплаты)

Изменяемые файлы модулей оплаты находятся в catalog/view/theme/default/template/payment/

Теперь на примерах: alertpay.tpl

<form action="<?php echo $action; ?>" method="post">
   <input type="hidden" name="ap_merchant" value="<?php echo $ap_merchant; ?>" />
   <input type="hidden" name="ap_amount" value="<?php echo $ap_amount; ?>" />
   <input type="hidden" name="ap_currency" value="<?php echo $ap_currency; ?>" />
   <input type="hidden" name="ap_purchasetype" value="<?php echo $ap_purchasetype; ?>" />
   <input type="hidden" name="ap_itemname" value="<?php echo $ap_itemname; ?>" />
   <input type="hidden" name="ap_itemcode" value="<?php echo $ap_itemcode; ?>" />
   <input type="hidden" name="ap_returnurl" value="<?php echo $ap_returnurl; ?>" />
   <input type="hidden" name="ap_cancelurl" value="<?php echo $ap_cancelurl; ?>" />
   <div class="buttons">
     <div class="right">
       <input type="submit" value="<?php echo $button_confirm; ?>" class="button" />
     </div>
   </div>
 </form>

Что мы видим? Есть форма, по нажатию кнопки происходит отсылка данных этой формы.

Вмешиваемся в этот процесс:

1. по нажатию на кнопку делаем валидацию формы заказа (поменяли кнопку на свою):

<div class="buttons">
     <div class="right"><a onclick="validate_generate();" class="button"><span><?php echo $button_confirm; ?></span></a></div>
   </div>

2. Обеспечиваем работу того, что было предусмотрено модулем. QCPM вызывает функцию payment_confirm(), поэтому надо просто переместить предусмотренную модулем функцию по нажатию на кнопку, в функцию с таким названием:

<script type="text/javascript"><!--
 function payment_confirm()
 {
         $('#payment').submit();
 }
 //--></script>

Этот механизм переделки стандартный для всех модулей: переносим стандартную реакцию на кнопку подтверждения заказа в ф-цию payment_confirm(), а на её место ставим вызов валидации формы заказа.

Другой пример: cheque.tpl

Была кнопка

<div class="buttons">
   <div class="right">
     <input type="button" value="<?php echo $button_confirm; ?>" id="button-confirm" class="button" />
   </div>
 </div>
 <script type="text/javascript"><!--
 $('#button-confirm').bind('click', function() {
         $.ajax({ 
                 type: 'GET',
                 url: 'index.php?route=payment/cheque/confirm',
                 success: function() {
                         location = '<?php echo $continue; ?>';
                 } 
         });
 });
 //--></script>

По ID кнопки (id="button-confirm") вызывается AJAX-обработчик. Который что-то там делает.

Мы переносим этот обработчик в функцию payment_confirm(), а нажатие на кнопку заменяем на валидацию формы:

<script type="text/javascript"><!--
 $('#button-confirm').bind('click', function() {
         validate_generate();
 });
 function payment_confirm()
 {
         $.ajax({
                 type: 'GET',
                 url: 'index.php?route=payment/cheque/confirm',
                 success: function() {
                         location = '<?php echo $continue; ?>';
                 }
         });
 }
 //--></script>

Перенесли стандартный обработчик в payment_confirm и вызвали validate_generate. Те же два действия.

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

Проще всего увидеть изменения, сравнив стандартный файл и модифицированный. Программы, которые это умеют делать: TotalCommander, WinMerge.org (Windows), Meld (Linux), про MacOS не знаю.

В них всё наглядно видно.

При использовании QCPM желательно все файлы модуля держать только в теме Default и не дублировать в используемую тему - файлы будут подхватываться оттуда. Иначе сложней обслуживать и обновлять.

Quickcheckout: как сделать необязательным поле email?

- Posted in Uncategorized by

Как скрыть "Адрес доставки: Адрес (продолжение):"

открыть файл catalog/view/theme/default/template/checkout/quickcheckout.tpl

найти там:

<tr>
                        <td><?php echo $entry_address_2; ?></td>
                        <td><input type="text" name="address_2" value="<?php echo $address_2; ?>" class="large-field"/></td>
                </tr>

и первую строку (<tr>) изменить на:

<tr style="display:none;">

Как сделать ввод почтового ящика необязательным

в этом же файле найдите чуть выше строку

<td><span class="required">*</span> <?php echo $entry_email; ?></td>

из неё надо убрать звёздочку:

<td><?php echo $entry_email; ?></td>

Дальше надо найти и открыть файл catalog/controller/checkout/quickcheckout_address.php

найти там строки (#30-33)

$l = utf8_strlen($this->request->post['email']);
                                if (($l < 1) || ($l > 96) || !preg_match('/^[^\@]+@.*\.[a-z]{2,6}$/i', $this->request->post['email'])) {
                                        $json['error']['email'] = $this->language->get('error_email');
                                }

и закомментировать их. На этом изменения в модуле закончены, их должно быть достаточно.

После этого надо исправить в движке Опенкарт часть, которая отсылает письма

Надо открыть файл catalog/model/checkout/order.php

найти там строку:

// Admin Alert Mail

(у меня это строка #438)

Над ней будет блок, который выглядит так:

$mail = new Mail();
                                $mail->protocol = $this->config->get('config_mail_protocol');
                                $mail->parameter = $this->config->get('config_mail_parameter');
                                $mail->hostname = $this->config->get('config_smtp_host');
                                $mail->username = $this->config->get('config_smtp_username');
                                $mail->password = $this->config->get('config_smtp_password');
                                $mail->port = $this->config->get('config_smtp_port');
                                $mail->timeout = $this->config->get('config_smtp_timeout');
                                $mail->setTo($order_info['email']);
                                $mail->setFrom($this->config->get('config_email'));
                                $mail->setSender($order_info['store_name']);
                                $mail->setSubject($subject);
                                $mail->setHtml($html);
                                $mail->setText(html_entity_decode($text, ENT_QUOTES, 'UTF-8'));
                                $mail->addAttachment(DIR_IMAGE . $this->config->get('config_logo'), md5(basename($this->config->get('config
_logo'))));
                                $mail->send();

Его надо заменить на такой:

if( !empty($order_info['email']) )
                        {
                                $mail = new Mail();
                                $mail->protocol = $this->config->get('config_mail_protocol');
                                $mail->parameter = $this->config->get('config_mail_parameter');
                                $mail->hostname = $this->config->get('config_smtp_host');
                                $mail->username = $this->config->get('config_smtp_username');
                                $mail->password = $this->config->get('config_smtp_password');
                                $mail->port = $this->config->get('config_smtp_port');
                                $mail->timeout = $this->config->get('config_smtp_timeout');
                                $mail->setTo($order_info['email']);
                                $mail->setFrom($this->config->get('config_email'));
                                $mail->setSender($order_info['store_name']);
                                $mail->setSubject($subject);
                                $mail->setHtml($html);
                                $mail->setText(html_entity_decode($text, ENT_QUOTES, 'UTF-8'));
                                $mail->addAttachment(DIR_IMAGE . $this->config->get('config_logo'), md5(basename($this->config->get('config
_logo'))));
                                $mail->send();
                        }

то есть сверху добавится условие, снизу - закрывающая скобка.

После этого всё должно работать без обязательного заполнения покупателем поля Email.

См. также:

Добавлена поддержка Shoppica&#45;и в Quickcheckout со способами оплаты (QCPM.1513)

- Posted in Uncategorized by

На прошлой неделе обновился QC - QCPM.1513. Для работы требуется небольшая модификация используемых способов оплаты. В архив включены модифицированные TPL всех модулей, входящих в Opencart и ocStore. Остальные исправляются и добавляются в архив по мере поступления запросов.

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

Вчера добавлена поддержка темы Shoppica (QCPM.1513/Shoppica).

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

Page 1 of 2