Кастомизируем Joomla и SugarCRM

Несомненным достоинством свободного программного обеспечения является возможность расширения функционала этого самого обеспечения. Передо мной встала задача как это сделать в Joomla и SugarCRM. Обе эти системы сейчас широко используются. Joomla как известно представляет собой систему управления контентом, а SugarCRM «на сегодняшний день самая продвинутая и простая в использовании CRM-система». Итак, мною были проделаны небольшие исследования в этой области, коими я и хочу с вами поделиться.

Как создать плагин Joomla

В Joomla присутствует великое множество типов плагинов, но среди них можно выделить несколько базовых типов:

• authentication
• content
• editors
• editors-xtd
• search
• system
• user
• xmlrpc

Рассмотрим базовые типы подробнее.

Authentication позволит Вам залогиниться в Joomla из любого места, которое вам удобно, например, используя аккаунт Google или по LDAP, а может через аккаунт Twitter, так как он имеет открытый API. По умолчанию же данные для авторизации берутся из базы данных Joomla.

Content позволяет добавлять новую функциональность для отображаемого содержимого. Например, можно настроить «невидимость» email адресов или конвертировать URL в формат SEF.

С помощью плагина Editor можно видоизменять редактор контента. Editor-XTD поможет вам добавить дополнительные кнопки в редактор контента. Например, кнопки Image, Pagebreak и Read more в стандартном редакторе Joomla — это дело рук этого плагина.

Search позволяет искать различный контент в различных компонентах. В Joomla уже реализованны поисковые плагины для компонент Articles, Contacts и Weblinks.

System — выполнение различных манипуляций с PHP кодом самой Joomla!.

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

XML-RPC — обеспечение сервиса XML-RPC.

Пишем плагин

Для создания плагина нужно создать как минимум 2 файла: один — php, второй — xml файл. В xml файле находятся мета данные, инсталляционная информация и другие параметры плагина. Эти файлы необходимо положить в каталог /plugins согласно типу плагина, если он входит в число базовых, либо в новый созданный каталог. Например, если вы хотите дополнить функциональность аутентификации, то файлы необходимо положить в /plugins/authentication/, если функциональность системы, то в /plugins/system/ и так далее.

Ограничений на имя файла нет, но имя файла накладывает ограничения на содержимое плагина. Это касается имен классов, мы рассмотрим это далее. Создадим тестовый системный плагин и назовем его Test.php.

Содержимое файла будет выглядеть примерно так:

<?php
// no direct access
defined( '_JEXEC' ) or die( 'Restricted access' );
jimport( 'joomla.plugin.plugin' );
/**
* Example system plugin
*/
class plgSystemTest extends JPlugin
{
    /**
    * Constructor
    *
    * For php4 compatibility we must not use the __constructor as a constructor for plugins
    * because func_get_args ( void ) returns a copy of all passed arguments NOT references.
    * This causes problems with cross-referencing necessary for the observer design pattern.
    *
    * @access protected
    * @param object $subject The object to observe
    * @param array $config An array that holds the plugin configuration
    * @since 1.0
    */
    function plgSystemTest( &$subject, $config )
    {
        parent::__construct( $subject, $config );
        // Do some extra initialisation in this constructor if required
    }
    /**
    * Do something onAfterInitialise
    */
    function onAfterInitialise()
    {
        // Perform some action
    }
}

Рассмотрим код поподробнее. Файл начинается с проверки defined( '_JEXEC' ) or die( 'Restricted access' ), которая предотвращает попытку запустить файл напрямую через URL. Это очень важная проверка, необходимая в целях безопасности. Так что не забудьте про неё. Далее подключаем библиотеку с помощью jimport для определения функций класса JPlugin. Сам плагин представляет собой класс, наследованный от JPlugin. Вы не можете дать классу произвольное имя, так как Joomla! имеет строгое правило, по которому формируется имя класса. Имя зависит от имени самого php файла (о чем упоминалось выше) и составляется следующим образом: plg + Имя каталога плагина с заглавной буквы + Имя файла с заглавной буквы. В нашем примере, как нетрудно догадаться, имя класса будет plgSystemTest. Далее мы видим определение методов класса. Первым идет конструктор класса. Определять его не обязательно. В нем можно описать действия, которые будут выполняться при загрузке плагина. Это гарантирует вам выполнение этих действий даже если сам плагин не запускался ни разу. Имена методов класса представляют собой имена событий (events), которые происходят в процессе работы Joomla. В нашем примере использовано событие onAfterInitialise, которое вызывается первым при старте работы Joomla. Более подробный список событий можно найти в API Execution Order на Documentation Wiki. Таким образом, те действия, которые необходимо выполнить при возникновении определенного события, должны быть описаны в методе с именем данного события. Joomla! Framework автоматически зарегистрирует все методы вашего класса. Местоположение, имя и методы плагина зависят от того, что вы хотите сделать. Следует отметить, что системные плагины (/plugins/system/) загружаются всегда при запуске Joomla! PHP, поэтому в них вы можете использовать любые возможные методы. Какие же события могут возникать при работе Joomla? Вот некоторые из них:

Authentication

• onAuthenticate

Content

• onPrepareContent
• onAfterDisplayTitle
• onBeforeDisplayContent
• onBeforeContentSave (new in 1.5.4)
• onAfterContentSave (new in 1.5.4)

Editors

• onInit
• onGetContent
• onSetContent
• onSave
• onDisplay
• onGetInsertMethod

Editors XTD (Extended)

• onDisplay

Search

• onSearch
• onSearchAreas

System

• onAfterInitialise
• onAfterRoute
• onAfterDispatch
• onAfterRender

User

• onLoginUser
• onLoginFailure
• onLogoutUser
• onLogoutFailure
• onBeforeStoreUser
• onAfterStoreUser
• onBeforeDeleteUser
• onAfterDeleteUser

XML-RPC

• onGetWebServices

Теперь переходим к xml файлу. Наш пример test.xml выглядит так:

<?xml version="1.0" encoding="utf-8"?>
    <install version="1.5.2" type="plugin" group="system" method="upgrade">
    <name>System - Test</name>
    <author>Author</author>
    <creationDate>Month 2008< /creationDate>
    <copyright>Copyright © 2008 Holder. All rights reserved.</copyright>
    <license>GNU General Public License</license>
    <authorEmail>email</authorEmail>
    <authorUrl>url</authorUrl>
    <version>1.0.1</version>
    <description>A test system plugin</description>
    <files>
        <filename plugin="example">example.php</filename>
    </files>
    <params>
        <param name="example"
            type="text"
            default=""
            label="Example"
            description="An example text parameter" />
        </params>
    </install> 

Остановимся на нескольких важных тегах.

INSTALL

Здесь необходимо указать тип «plugin», имя группы (в нашем случае «system»), метод установки (мы указали «upgrade» для того чтобы плагин устанавливался поверх старой версии).

NAME

Здесь указывается имя плагина, которое может быть каким угодно. В нашем примере, для формирования имени мы использовали имя группы и тестовое предназначение самого плагина.

FILES

Имена файлов, в которых размещается ваш плагин. Если файлы лежат в дополнительных папках, то используйте тег <folder></folder>.

PARAMS

Здесь вы указываете произвольное количество параметров для вашего плагина.

Теперь пакуем плагин. Все просто. Создаете zip архив из файлов вашего плагина (php и xml). Если использовались подкаталоги, то тоже добавляете их в архив. Плагин готов. Теперь переходим к SugarCRM.

Кастомизируем SugarCRM

На форуме разработчиков SugarCRM мною был задан вопрос, как же создать плагин для этой системы. На что мне было сказано использовать SOAP, и будет мне счастье. Итак, для того чтобы SugarCRM выполнял то, что вы хотите, вам всего лишь необходимо научится общаться с ним через SOAP. Таким образом, ваше приложение получает возможность направить работу SugarCRM в нужном вам направлении. Интеграция SugarCRM с Java приложениями В Java очень хорошо реализована поддержка SOAP. Как же включить SOAP со стороны SugarCRM? Для этого можно использовать Apache Axis. Это платформа, в которой реализован SOAP согласно рекомендациям W3C (Консорциум Всемирной паутины). Нас интересует класс WSDL2Java, который автоматически создаст для SugarCRM все необходимые классы и типы данных для работы SOAP. Итак, что нам нужно:

• JDK5 (или выше)
• SugarCRM 5
• Axis 1.4

После установки Axis необходимо перейти в каталог lib, в котором находятся все необходимые jar файлы. Далее нам нужно запустить класс «WSDL2Java» с указанием в качестве параметра уже существующего в SugarCRM wsdl файла. Допустим, что SugarCRM находится по адресу localhost/sugarcrm, тогда в Linux команды будут выглядеть так: java -cp lib/axis.jar:lib/axis-ant.jar:lib/commons-discovery-0.2.jar:lib/commons-logging-1.0.4.jar:lib/jaxrpc.jar:lib/log4j-1.2.8.jar:lib/saaj.jar:lib/wsdl4j-1.5.1.jar org.apache.axis.wsdl.WSDL2Java -o. -d Session -p org.beanizer.sugarcrm localhost/sugarcrm/soap.php?wsdl. Параметр -о определяет, куда генерируется пакет, параметр -d определяет, как будут генерироваться классы на сервере. В нашем случае Session означает, что для каждой сессии каждый раз будут создаваться новые экземпляры классов. -p, собственно, имя пакета, который будет получен на выходе. В случае успешного завершения команды в текущем каталоге должен появится пакет org.beanizer.sugarcrm, содержащий интерфейсы SOAP к SugarCRM.

Пишем Java client. Во-первых, подключаем необходимые пакеты:

    import java.security.MessageDigest;
    import org.beanizer.sugarcrm.*;

Затем необходимо открыть порт к SugarCRM:

    Sugarsoap service = new SugarsoapLocator();
    SugarsoapPortType port = service.getsugarsoapPort (new java.net.URL("http://localhost/sugarcrm/soap.php"));

Далее проходим процесс аутентификации на SugarCRM и получаем ID открытой сессии:

    User_auth userAuth = new User_auth();
    userAuth.setUser_name("myuser");
    MessageDigest md = MessageDigest.getInstance("MD5");
    String password = getHexString(md.digest("mypassword".getBytes()));
    userAuth.setPassword(password);
    userAuth.setVersion("0.1");
    Set_entry_result loginRes = port.login(userAuth, "myAppName");
    System.out.println("Error=" + loginRes.getError().getNumber());
    String sessionID = loginRes.getId();
    System.out.println("Session ID: " + sessionID);

Следует заметить, что MD5 хэш пароля должен быть в шестнадцатиричном формате. Если у нас есть ID сессии, то теперь мы можем общаться с SugarCRM. С помощью каких методов общаться можно найти в спецификации SugarCRM SOAP API.