Показаны сообщения с ярлыком elgg. Показать все сообщения
Показаны сообщения с ярлыком elgg. Показать все сообщения

6 августа 2012 г.

Elgg: mod-rewrite для NGINX

Сегодня развернул Elgg на веб-сервере NGINX, и первая проблема с которой столкнулся - это небходимость замены mod-rewrite директив, которые содержатся в файле .htaccess, на соответсвующие правила для NGINX (rewrite-rules).

И первый вопрос, который у меня возник: куда нужно писать эти правила?
Rewrite-rules для Nginx указываются внутри секции server в файле настройки виртуального хоста, например /etc/nginx/sites-available/default.

Следующий вопрос был: что же туда писать?
Если подумать логически, то задача не совсем сложная, необходимо всего лишь конвертировать директивы из htaccess в соответвующие правила для nginx. Спасибо Томасу Делингу, который уже провел иследования в этом вопросе и успешно конвертировал директивы файла htaccess для Elgg 1.8.2. Все что мне осталось, это скопировать набор правил и обновить файл настройки виртуального хостинга, в результате он выглядел приблизительно так:

server {
 listen     80;
 server_name elgg.domain.com;
 root        /var/www-nginx/elgg/htdocs/;

 error_log /var/log/nginx/error.log;
 access_log /var/log/nginx/access.log;

 index         index.php index.html;
 fastcgi_index index.php;
 
 client_max_body_size      8M;
 client_body_buffer_size 256K;

 rewrite ^/pg\/([A-Za-z0-9\_\-]+)$ /engine/handlers/page_handler.php?handler=$1&$args;
 rewrite ^/pg\/([A-Za-z0-9\_\-]+)\/(.*)$ /engine/handlers/page_handler.php?handler=$1&page=$2&$args;
 rewrite ^/tag\/(.+)\/?$ /engine/handlers/page_handler.php?handler=search&page=$1;
 rewrite ^/action\/([A-Za-z0-9\_\-\/]+)$ /engine/handlers/action_handler.php?action=$1&$args;
 rewrite ^/cache\/(.*)$ /engine/handlers/cache_handler.php?request=$1&$args;
 rewrite ^/services\/api\/([A-Za-z0-9\_\-]+)\/(.*)$ /engine/handlers/service_handler.php?handler=$1&request=$2&$args;
 rewrite ^/export\/([A-Za-z]+)\/([0-9]+)\/?$ /engine/handlers/export_handler.php?view=$1&guid=$2;
 rewrite ^/export\/([A-Za-z]+)\/([0-9]+)\/([A-Za-z]+)\/([A-Za-z0-9\_]+)\/$ /engine/handlers/export_handler.php?view=$1&guid=$2&type=$3&idname=$4;
 rewrite /xml-rpc.php /engine/handlers/xml-rpc_handler.php;
 rewrite /mt/mt-xmlrpc.cgi /engine/handlers/xml-rpc_handler.php;
 rewrite ^/rewrite.php$ /install.php;
 if (!-d $request_filename){
  set $rule_11 1$rule_11;
 }
 if (!-f $request_filename){
  set $rule_11 2$rule_11;
 }
 if ($rule_11 = "21"){
  rewrite ^/([A-Za-z0-9\_\-]+)$ /engine/handlers/page_handler.php?handler=$1;
 }
 if (!-d $request_filename){
  set $rule_12 1$rule_12;
 }
 if (!-f $request_filename){
  set $rule_12 2$rule_12;
 }
 if ($rule_12 = "21"){
  rewrite ^/([A-Za-z0-9\_\-]+)\/(.*)$ /engine/handlers/page_handler.php?handler=$1&page=$2;
 }
 
 location ~ \.php$ {
  include fastcgi_params;

  # Assuming php-fastcgi running on localhost port 9000
  fastcgi_pass 127.0.0.1:9000;
  fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

  fastcgi_connect_timeout 60;
  fastcgi_send_timeout 180;
  fastcgi_read_timeout 180;
  fastcgi_buffer_size 128k;
  fastcgi_buffers 4 256k;
  fastcgi_busy_buffers_size 256k;
  fastcgi_temp_file_write_size 256k;
  fastcgi_intercept_errors on;
 }
 
 # Do not put CSS there or it will break simplecache
 location ~* \.(bmp|js|gif|ico|jpg|jpeg|png)$ {
  expires max;
  # log_not_found off;
 }
}

19 мая 2011 г.

ELGG: Создаем "скелет" плагина из коммандной строки

Для того чтобы создать в ELGG новый плагин (модуль), первым делом, необходимо создать правильную структуру директорий. Помочь в этом может разработаный Оскаром Кастро (Oscar Castro) простой bash-скрипт

#!/bin/bash 
 #name: pluginSkeleton
 #Author: @Kareste
 #Installation: Put file in mod/
 #usage ./pluginSkeleton 
 if [ $# -eq 0 ]; then
 echo "Plugin Name is Missing"
 else
 echo mkdir -p "$1/actions/$1/" | bash -x
 echo mkdir -p "$1/classes/" | bash -x
 echo mkdir -p "$1/graphics/" | bash -x
 echo mkdir -p "$1/js/" | bash -x
 echo mkdir -p "$1/languages/" | bash -x
 echo mkdir -p "$1/lib/" | bash -x
 echo mkdir -p "$1/pages/$1/" | bash -x
 echo mkdir -p "$1/vendors/" | bash -x
 echo mkdir -p "$1/views/default/$1/" | bash -x
 echo mkdir -p "$1/views/default/forms/" | bash -x
 echo mkdir -p "$1/views/default/js/" | bash -x
 echo mkdir -p "$1/views/default/object/$1" | bash -x
 echo mkdir -p "$1/views/default/plugins/$1/" | bash -x
 echo mkdir -p "$1/views/default/widgets/$1_widget/" | bash -x
 echo touch "$1/start.php" | bash -x
 echo touch "$1/manifest.xml" | bash -x
 echo -e "\n\n\tExample Manifest\n\tElgg\n\t1.0\n\tThis is a simple example of a manifest file.  In this example, there are not screenshots, dependencies, or additional information about the plugin.\n\t\n\t\telgg_version\n\t\t2011010401\n\t\n" >> "$1/manifest.xml"
 fi

Источник: http://community.elgg.org/pg/pages/view/723878/plugin-skeleton-script-bash

28 марта 2011 г.

ELGG: новые требования к структуре плагинов

Разработчики социального движка ELGG объявили новые требования к структуре плагинов. Это, по сути, и есть очередной шаг разработчиков этого проекта стандартизировать все, разрабатываемые сторонними лицами, плагины.

Итак, что же нам предлагают разработчики? Ниже приводятся требования к структуре файлов для для новой версии ELGG 1.8. Плагины, написанные для Elgg 1.7 и более ранних версий, разработчики настоятельно рекомендуют переработать под эту структуру.


Пример структуры

Приведем пример стандартной структуры плагина, назовем его example, для ELGG 1.8. Некоторые моменты будут описаны ниже.

Файлы плагина example должны размещаться в /mod/example/

actions/
    example/
        action.php
        other_action.php
classes/
    ExampleClass.php
graphics/
    example.png
js/
    example.js
languages/
    en.php
lib/
    example.php
pages/
    example/
        all.php
        owner.php
vendors/
    example_3rd_party_lib/
views/
    default/
        example/
            js.php
            css.php
        forms/
            example/
                action.php
                other_action.php
        object/
            example.php
            example/
                context1.php
                context2.php
start.php
manifest.xml
CHANGES.txt
COPYRIGHT.txt
INSTALL.txt
LICENSE.txt
README.txt

Минимальная структура

Файлы start.php и manifest.xml обязательно должны присутствовать в корне каждого плагина, для того чтобы ELGG смог его распознать. Поэтому минимальная структура плагина выглядит следующим образом:

mod/example/
    start.php
    manifest.xml

Структура каталога Actions/

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

Например, скрипт для обработки события my/example/action  будет находиться  в my_plugin/actions/my/example/action.php. Это делает очевидным, какой сценарий связан с определенным событием.

По аналогичному принципу, тело формы, которая представляет это событие, должно быть расположено в forms/my/example/action.php.

Такое размещения файлов не только позволяет облегчить работу с обработчиками событий, но также позволяет с легкостью использовать новую (по состоянию на Elgg 1,8) функцию elgg_view_form().


Текстовые файлы

В корне каталога плагина могут размещаться различные текстовые файлы *.TXT, которые в основном предоставляют дополнительную документацию к плагину:

README.txt
Должен предоставлять дополнительные сведения о плагине, может содержать информацию неопределенного характера

COPYRIGHT.txt
Должен содержать дополнительную информацию по использованию авторских прав при работе с плагином, кроме теч, что указаны в manifest.xml

LICENSE.txt
Должен содержать текст лицензии, по которой выпущен текущий плагин.

INSTALL.txt
Должен содержать дополнительные инструкции по установке плагина, например если плагин требует установки сторонних библиотек на машине, или требует приобретения ключевых API от третьего лица.

CHANGES.txt
Должен содержать список изменений плагина, список должен быть сгруппирован по номеру версии, начиная с последней версии.


Каталог Pages/

Структура каталога, в котором размещаются обработчики страниц, подобен структуре каталога для обработчиков событий. К примеру странице yoursite.com/my_handler/view/1234 соответствует обработчик в mod/my_plugin/pages/my_handler/view.php.

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


  1. Это необходимо для формирования логической связи между URL-адресами и скриптами, так чтобы человек, при рассмотрении кода, мог иметь представление как работает тот или иной обработчик, только взглянув на структуру файлов
  2.  Чтобы очистить корневую директорию, которая обычно быстро оказывается заваленной файлами дополнительных сценариев.

Каталог Classes/

Все дополнительные классы которые использует плагин должны размещаться в каталоге classes. Эта директория имеет особое значения для ELGGа. Файлы с классами, размещенные в данном каталоге загружаются автоматически, и не требуют дополнительного включения в код посредством оператора include.
  • Каждый файл должен содержать описание только одного класса.
  • Имя файла должно соответствовать названию класса (кроме суффикса .php).
Примечание: Файлы с расширением  ". class.php" НЕ будет распознан Elgg-ом


.Каталог Vendors/

Содержит библиотеки разработанные третьим лицом. К этому каталогу нет особых требований, которые бы подлежали дополнительной стандартизации.


Каталог Lib/

Содержит библиотеки с дополнительными функциями, которые используются в плагине. К этому каталогу также нет особых требований, которые бы подлежали дополнительной стандартизации.


Каталог View/

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


Использование Javascript/

Все javascript-библиотеки, которые используются в работе плагина, должны размещаться в каталоге plugin/js, и должны подключаться при помощи расширения отображения js/elgg. Больше информации о использовании Javascript читайте здесь.



18 января 2011 г.

ELGG: расширение функции поиска пользователей

Стандартная процедура поиска пользователей выдает результаты  исключительно по полям username (имя пользователя) и user (псевдоним пользователя). Для большинства проектов такого функционала не достаточно. Каждый пользователь может иметь огромное количество метаданных (например если использовать модули для увеличения количества полей в профайле).
Таким образом возникает задача поиска искомых выражений в метаданных объекта пользователя.

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

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

В системе уже зарегистрирован хук для поиска по метаданными, которые относятся к стандартным полям профиля (функция search_tags_hook). 

Регистрируем новый хук:
register_plugin_hook('search', 'tags', 
                     'mp_search_metadata_hook');

По-умолчанию, название доступных для поиска метаданных находяться в массиве $CONFIG->registered_tag_metadata_names, поэтому нам достаточно занести в этот массив имена полей метаданных, по которым необходимо совершать поиск.

Функция поиска по метаданным будет иметь следующий вид:

/**
 * Return default results for searches on metadata.
 *
 * @param unknown_type $hook
 * @param unknown_type $type
 * @param unknown_type $value
 * @param unknown_type $params
 * @return unknown_type
 */

function mp_search_metadata_hook($hook, $type, $value, $params) {
    global $CONFIG;
    $CONFIG->registered_tag_metadata_names = array("поле1","поле2",*...*);
   }

13 января 2011 г.

ELGG: проверка существует ли фото в профайле?

Вопрос: как организовать проверку - существует ли у текущего пользователя фото в профайле или еще нет?

Задал подобный вопрос на форуме сообщества ELGG и получил лаконичный но точный и весьма полезный ответ.

Когда пользователь загружает в профиль фотографию, к объекту пользователя привязывается строка метаданных icontime, которая хранит дату загрузки фотографии в формате unixtime.

Имея эту информацию организовать проверку очень просто

if (get_loggedin_user()->icontime > 0){

   // do something ....

}