Пришлось мне недавно писать модуль платежной системы для разных CMS.
Bitrix, UMI CMS, NetCat, Drupal (6 и 7), HostCMS и WordPress. В этом посте хочу провести легкий сравнительный анализ по сложности интеграции платежной системы в разных CMS.
Пишу с точки зрения разработчика, которому пришлось окунуться в незнакомые CMS. Я их не знаю, и знать не хочу. Постараюсь избежать предвзятости.
NetCat
Начну с плохого.
Первое что требуется сделать для установки это выполнить огромный и жуткий SQL запрос.

А теперь зайти в админку и разобраться там. Мое сверхконсервативное воспитание не позволяет мне ругаться матом тут, но это ад. Какие-то системные переменные, не системные переменные. Интерфейс разработчика и пользователя, в которых не ясно в чем разница.
Потратил очень много времени только на поиск в админке нужных функций, а потом еще на отладку. После уведомления от ПС о платеже в админке статус выставляется «оплачен», а в пользовательской части — нет. Оказалось, что баг в стандартном шаблоне NetCat.
В общем, отвратительная CMS. Первый опыт был и никому не посоветую.
Из плюсов могу ответить, что достаточно одного php файла для обработки всех действий и более-менее понятную логику класса Payment.
UMI CMS
Нужно выполнить еще страшнее SQL запрос.

Тут примерно 1/3 всего запроса видна.
Но это далеко не самое страшное.
Во-первых, нужно делать шаблоны для двух версий xslt и tpl, что уже немного усложняет процесс.
А самое интересное начинается при интеграции платежной системы.
Нужно модифицировать системный файл __payment.php
Можно его сразу сделать и сказать пользователю просто заменить его при установке, но если у него там уже были кастомные ПС, то они перестанут работать. Так что приходится объяснять пользователю, как его модифицировать. И писать что-то типа: в файле __payment.php примерно в 140 строке напишите:
Тут мы по переменным в запросе должны как-то однозначно идентифицировать платежную систему.
Из плюсов стоит отметить очень простой код и реализацию класс payment.
Легко найти ПС в админке и настроить даже неподготовленному пользователю.
HostCMS
Для установки модуля ПС в HostCMS нам уже не нужно делать SQL запросы. Отлично.
Но требуется от пользователя редактировать достаточно громоздкие и страшные файлы с PHP. При этом, таких файла два.
Также пользователю нужно «увидеть» ID новой ПС и добавить его в название класса. Еще к минусам можно отнести средней грязности код в реализации класса Shop_Payment_System_Handler.
Из плюсов нужно отметить приятную админку. Какая-то она теплая и ламповая. Но сначала очень непривычная. К ней нужно привыкать, но пользоваться ей можно. Найти нужные разделы не так уж сложно, но сложнее, чем в UMI.
Потратил не мало времени на отладку. Хоть и застрял на очевидных вещах.
Drupal
Тут очень кратко напишу:
— отвратительная установка Drupal;
— отвратительная установка Ubercart;
— ужасный код с реализацией платежной системы;
Провел очень много времени в отладке.
Из плюсов только отличная документация на русском языке.
WordPress
А он мне понравился. Всего один файл. Никаких SQL запросов для установки.
Не понравился слегка грязный код в классе платежной системы. Необходимость прямых запросов в БД для изменения статуса и формирование формы настроек в админке на HTML.
С одной стороны последний пункт это минус, но с другой это позволяет нам сделать интерфейс нашей ПС любым.
Bitrix
Тут стоит сказать, что с Битриксом я знаком и делал уже не раз модули платежных систем.
Сложно быть объективным, но попробую.
Из плюсов:
1. Пользователю нужно только скопировать папку с модулем в корень сайта и модуль работает.
2. Отдельно настройки интерфейса администратора, платежной формы и обработчика. Удобно и все на своих местах.
3. Никаких прямых запросов к БД в классе ПС. Оплата успешна?
Ок.
Из минусов могу сказать только про привычно у Битрикс. Мне она просто не пригодилась.
Сложность по 5 балльной шкале. Больше = хуже.
Bitrix, UMI CMS, NetCat, Drupal (6 и 7), HostCMS и WordPress. В этом посте хочу провести легкий сравнительный анализ по сложности интеграции платежной системы в разных CMS.
Пишу с точки зрения разработчика, которому пришлось окунуться в незнакомые CMS. Я их не знаю, и знать не хочу. Постараюсь избежать предвзятости.
NetCat
Начну с плохого.
Первое что требуется сделать для установки это выполнить огромный и жуткий SQL запрос.

А теперь зайти в админку и разобраться там. Мое сверхконсервативное воспитание не позволяет мне ругаться матом тут, но это ад. Какие-то системные переменные, не системные переменные. Интерфейс разработчика и пользователя, в которых не ясно в чем разница.
Потратил очень много времени только на поиск в админке нужных функций, а потом еще на отладку. После уведомления от ПС о платеже в админке статус выставляется «оплачен», а в пользовательской части — нет. Оказалось, что баг в стандартном шаблоне NetCat.
В общем, отвратительная CMS. Первый опыт был и никому не посоветую.
Из плюсов могу ответить, что достаточно одного php файла для обработки всех действий и более-менее понятную логику класса Payment.
UMI CMS
Нужно выполнить еще страшнее SQL запрос.

Тут примерно 1/3 всего запроса видна.
Но это далеко не самое страшное.
Во-первых, нужно делать шаблоны для двух версий xslt и tpl, что уже немного усложняет процесс.
А самое интересное начинается при интеграции платежной системы.
Нужно модифицировать системный файл __payment.php
Можно его сразу сделать и сказать пользователю просто заменить его при установке, но если у него там уже были кастомные ПС, то они перестанут работать. Так что приходится объяснять пользователю, как его модифицировать. И писать что-то типа: в файле __payment.php примерно в 140 строке напишите:
if(!$orderId) $orderId = (int) getRequest('orderid'); |
Тут мы по переменным в запросе должны как-то однозначно идентифицировать платежную систему.
Из плюсов стоит отметить очень простой код и реализацию класс payment.
Легко найти ПС в админке и настроить даже неподготовленному пользователю.
HostCMS
Для установки модуля ПС в HostCMS нам уже не нужно делать SQL запросы. Отлично.
Но требуется от пользователя редактировать достаточно громоздкие и страшные файлы с PHP. При этом, таких файла два.
Также пользователю нужно «увидеть» ID новой ПС и добавить его в название класса. Еще к минусам можно отнести средней грязности код в реализации класса Shop_Payment_System_Handler.
Из плюсов нужно отметить приятную админку. Какая-то она теплая и ламповая. Но сначала очень непривычная. К ней нужно привыкать, но пользоваться ей можно. Найти нужные разделы не так уж сложно, но сложнее, чем в UMI.
Потратил не мало времени на отладку. Хоть и застрял на очевидных вещах.
Drupal
Тут очень кратко напишу:
— отвратительная установка Drupal;
— отвратительная установка Ubercart;
— ужасный код с реализацией платежной системы;
Провел очень много времени в отладке.
Из плюсов только отличная документация на русском языке.
WordPress
А он мне понравился. Всего один файл. Никаких SQL запросов для установки.
Не понравился слегка грязный код в классе платежной системы. Необходимость прямых запросов в БД для изменения статуса и формирование формы настроек в админке на HTML.
С одной стороны последний пункт это минус, но с другой это позволяет нам сделать интерфейс нашей ПС любым.
Bitrix
Тут стоит сказать, что с Битриксом я знаком и делал уже не раз модули платежных систем.
Сложно быть объективным, но попробую.
Из плюсов:
1. Пользователю нужно только скопировать папку с модулем в корень сайта и модуль работает.
2. Отдельно настройки интерфейса администратора, платежной формы и обработчика. Удобно и все на своих местах.
3. Никаких прямых запросов к БД в классе ПС. Оплата успешна?
Ок.
CSaleOrder::PayOrder($arOrder["ID"], "Y"); |
Из минусов могу сказать только про привычно у Битрикс. Мне она просто не пригодилась.
Сложность по 5 балльной шкале. Больше = хуже.
| NetCat | UMI | HostCMS | DRUPAL | WordPress | Bitrix | |
| Для разработчика | 5 | 4 | 3 | 5 | 3 | 3 |
| Для пользователя | 5 | 4 | 4 | 5 | 3 | 1 |
вряд ли будет уместно рассказывать об API других систем на блоге битрикса. Пусть читатель просто имеет ввиду, что всё не так плохо.