Необходимо добавить в Joomla дополнительную группу пользователей, которая обладала бы следующими правами:
Доступ к административной панели
Доступ к заданному компоненту (для простоты выберем компонент Remository)
Не имела бы доступа к остальным разделам административной панели Joomla

Как мы видим, наиболее похожая группа пользователей это Manager, так как в ней есть и доступ в административную панель Joomla, и нет доступа к большинству административных функций (управление пользователями, расширениями и т.д.). Чего же нам нехватает? Да, в принципе, самой малости:
Нет доступа к компоненту Remository)
Есть доступ к Медиа менеджеру, Меню и Материалам

Для решения нашей задачи можно пойти двумя путями: изменить права группы Manager и добавить новую группу, похожую частично на Manager, но с урезанными правами. Первая задача достаточно простая, но не столь интересная в реализации. Эту тему уже не раз обсуждали на форуме, и решения найти не проблема. Я же хочу рассказать о том, как создать дополнительную группу, и как ее наделить нужными правами для решения нашей задачи.

Перед началом модификаций рекомендую создать резервную копию изменяемых файлов и базы данных. Если у вас вдруг что-то не получится наличие резервной копии позволит вам откатить изменения и восстановить работоспособность сайта.
Добавление новой группы пользователей Joomla

Как известно, в Joomla существует следующая иерархия пользователей:
ROOT
| – USERS
| — PublicFrontend
| – - – Registered
| – - – - Author
| – - – - – Editor
| – - – - – - Publisher
| – - Public Backend
| – - – Manager
| – - – - Administrator
| – - – - – Super Administrator

Таким образом, нам надо добавить группу пользователей (назовем ее DownloadsManager) в качестве дочерней для Public Backend, чтобы дерево групп пользователей приняло вид:
ROOT
| – USERS
| — PublicFrontend
| – - – Registered
| – - – - Author
| – - – - – Editor
| – - – - – - Publisher
| – - Public Backend
| – - – Manager
| – - – - Administrator
| – - – - – Super Administrator
| – - – DownloadsManager

Информация о существующих группах пользователей и их иерархии располагается в таблице jos_core_acl_aro_groups. Я не буду серьезно вдаваться в подробности технической реализации хранения данных в этой таблице, ограничусь готовым SQL-запросом, который позволит нам добавить нужную группу:
SET @parent_name = ‘Public Backend’;
SET @new_name = ‘DownloadsManager’;

SELECT @ins_id := group_id, @ins_lft := lft, @ins_rgt := rgt
FROM jos_core_acl_aro_groups
WHERE name = @parent_name;

SELECT @new_id := MAX(group_id) + 1 FROM jos_core_acl_aro_groups;

UPDATE jos_core_acl_aro_groups SET rgt=rgt+2 WHERE rgt>=@ins_rgt;
UPDATE jos_core_acl_aro_groups SET lft=lft+2 WHERE lft>@ins_rgt;

INSERT INTO jos_core_acl_aro_groups (group_id,parent_id,name,lft,rgt)
VALUES (@new_id,@ins_id,@new_name,@ins_rgt,@ins_rgt+1);

После выполнения данного запроса в списке доступных групп пользователей появится DownloadsManager. Однако, если мы в Менеджере пользователей попробуем создать пользователя с такой группой, мы гарантированно получим ошибку: «You cannot create a user with this user Group level, only Super Administrators have this ability». Это означает, что текущий пользователь не может создать пользователя с группой, которая не является дочерней, по отношению к группе текущего пользователя. Это ограничение было введено для того, чтобы пользователи группы Администратор не могли создавать Суперадминистраторов.

В нашем случае, созданная группа DownloadsManager не является дочерней даже для Суперадминистратора, поэтому создать такого пользователя не получается. Чтобы это разрешить, мы сделаем небольшую модификацию, которая на безопасность не особо повлияет:
Откроем файл /administrator/components/com_user/admin.user.php
Найдем в нем строчку:
if (!in_array($row->gid,getGIDSChildren($my->gid))) {
и заменим ее на:
if ($my->gid != 25 && !in_array($row->gid,getGIDSChildren($my->gid))) {

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

Однако, создать группу и получить возможность добавлять в нее пользователей это ползадачи. Нам нужно теперь настроить права этой группы: возможность авторизации в административной панели Joomla, доступ к компоненту Remository и запретить доступ к материалам сайта.
Предоставление доступа в административную панель Joomla

Права групп пользователей прописаны статически в файле /includes/gacl.class.php. Для того, чтобы наша группа пользователей имела право на авторизацию в административной панели Joomla необходимо в этом файле, после строчки:
$this->_mos_add_acl( ‘administration’, ‘login’, ‘users’, ‘manager’, null, null );

добавить еще одну:
$this->_mos_add_acl( ‘administration’, ‘login’, ‘users’, ‘downloadsmanager’, null, null );

Так, теперь пользователи этой группы могут беспрепятственно входить в административную панель Joomla и фактически равны по правам пользователям группы Manager, однако пока не имеют доступа к компоненту Remository и могут редактировать материалы сайта.
Предоставление доступа к компоненту Remository

Для того, чтобы пользователи группы DownloadsManager могли работать с компонентом Remository необходимо, чтобы во-первых пользователи этой группы видели меню Компоненты и, во-вторых, чтобы они имели доступ к самому компоненту.

Для начала, добавим в /includes/gacl.class.php права на компонент. Для этого найдем строчку:
$this->_mos_add_acl( ‘administration’, ‘edit’, ‘users’, ‘manager’, ‘components’, ‘com_media’ );

и добавим после нее:
$this->_mos_add_acl( ‘administration’, ‘edit’, ‘users’, ‘downloadsmanager’, ‘components’, ‘com_remository’ );

Все, пользователи группы DownloadsManager будут иметь доступ к компоненту Remository. Займемся теперь доступностью пункта меню Компоненты
Настройка видимости пунктов меню административной панели Joomla

Главное меню административной панели Joomla выводится модулем mod_fullmenu, расположенном в папке /administrator/modules. Его мы и будем править, чтобы настроить видимость пунктов в зависимости от прав пользователя.

В файле /administrator/modules/mod_fullmenu.php находим строчку:
$canManageUsers = $acl->acl_check( ‘administration’, ‘manage’, ‘users’, $usertype, ‘components’, ‘com_users’ );
и добавляем после нее:
$canEditRemository = $acl->acl_check( ‘administration’, ‘edit’, ‘users’, $usertype, ‘components’, ‘com_remository’ );
$canEditContent = $acl->acl_check( ‘administration’, ‘edit’, ‘users’, $usertype, ‘components’, ‘com_content’ );
$canEditMenus = $acl->acl_check( ‘administration’, ‘edit’, ‘users’, $usertype, ‘components’, ‘com_menus’ );

Затем чуть ниже заменяем
if ($installComponents) {
на
if ($installComponents || $canEditRemository) {

Далее после строчки
// Content Sub-Menu
добавляем
if ($canEditContent) {
и чуть ниже, перед строчкой
// Components Sub-Menu
вставляем
}

И теперь отключим отображение пункта меню Медиа-менеджер. Заменяем строчку:
['<img src="../includes/js/ThemeOffice/media.png" />','Media Manager','index2.php?option=com_media',null,'Manage Media Files'],
на
<?php if ($canEditMenus) { ?>
['<img src="../includes/js/ThemeOffice/media.png" />','Media Manager','index2.php?option=com_media',null,'Manage Media Files'],
<?php } ?>

Чтобы скрыть лишние пункты меню сделаем еще несколько модификаций данного модуля. После строчки:
$manageMenuMan = $acl->acl_check( ‘administration’, ‘manage’, ‘users’, $usertype, ‘components’, ‘com_menumanager’ );

добавим:
$manageMenu = $acl->acl_check( ‘administration’, ‘manage’, ‘users’, $usertype, ‘components’, ‘com_menus’ );

Все, теперь пользователей группы DownloadsManager станет доступно меню Компоненты, в котором будет только один подпункт — Remository. Другие компоненты будут недоступны (за исключением com_content, com_menus и com_typedcontent).

Мы уже очень близки к поставленной цели: у нас есть новая группа, пользователи этой группы имеют доступ к административной панели Joomla и в ней могут работать с административной частью компонента Remostitory. Кроме того, пользователь уже не видит лишних пунктов меню (Медиа-менеджер, Меню, Материалы). Дело за малым: закрыть реальный доступ к редактированию меню и материалов сайта.
Запрет группе доступа к редактированию меню и материалов
Сначала немного расширим список прав групп, чтобы явно предоставить права на Меню и Материалы пользователям групп Manager, Administrator и Super administrator. Для этого в файле /includes/gacl.class.php после строчки:
//array( ‘administration’, ‘edit’, ‘users’, ‘manager’, ‘modules’, ‘all’ );

добавим:
// access to com_menus
$this->_mos_add_acl( ‘administration’, ‘edit’, ‘users’, ‘super administrator’, ‘components’, ‘com_menus’ );
$this->_mos_add_acl( ‘administration’, ‘edit’, ‘users’, ‘administrator’, ‘components’, ‘com_menus’ );
$this->_mos_add_acl( ‘administration’, ‘edit’, ‘users’, ‘manager’, ‘components’, ‘com_menus’ );

// access to com_content
$this->_mos_add_acl( ‘administration’, ‘edit’, ‘users’, ‘super administrator’, ‘components’, ‘com_content’ );
$this->_mos_add_acl( ‘administration’, ‘edit’, ‘users’, ‘administrator’, ‘components’, ‘com_content’ );
$this->_mos_add_acl( ‘administration’, ‘edit’, ‘users’, ‘manager’, ‘components’, ‘com_content’ );

// access to com_typecontent
$this->_mos_add_acl( ‘administration’, ‘edit’, ‘users’, ‘super administrator’, ‘components’, ‘com_typedcontent’ );
$this->_mos_add_acl( ‘administration’, ‘edit’, ‘users’, ‘administrator’, ‘components’, ‘com_typedcontent’ );
$this->_mos_add_acl( ‘administration’, ‘edit’, ‘users’, ‘manager’, ‘components’, ‘com_typedcontent’ );

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

Открываем файл /administrator/components/com_menus/admin.menus.php и сразу после строчки:
defined( ‘_VALID_MOS’ ) or die( ‘Restricted access’ );

добавляем проверку прав:
if (!($acl->acl_check( ‘administration’, ‘edit’, ‘users’, $my->usertype, ‘components’, ‘all’ )
| $acl->acl_check( ‘administration’, ‘edit’, ‘users’, $my->usertype, ‘components’, ‘com_menus’ ))) {
mosRedirect( ‘index2.php’, _NOT_AUTH );
}

Открываем файл /administrator/components/com_content/admin.content.php и сразу после строчки:
defined( ‘_VALID_MOS’ ) or die( ‘Restricted access’ );

добавляем проверку прав:
if (!($acl->acl_check( ‘administration’, ‘edit’, ‘users’, $my->usertype, ‘components’, ‘all’ )
| $acl->acl_check( ‘administration’, ‘edit’, ‘users’, $my->usertype, ‘components’, ‘com_content’ ))) {
mosRedirect( ‘index2.php’, _NOT_AUTH );
}

Открываем файл /administrator/components/com_typedcontent/admin.typedcontent.php и сразу после строчки:
defined( ‘_VALID_MOS’ ) or die( ‘Restricted access’ );

добавляем проверку прав:
if (!($acl->acl_check( ‘administration’, ‘edit’, ‘users’, $my->usertype, ‘components’, ‘all’ )
| $acl->acl_check( ‘administration’, ‘edit’, ‘users’, $my->usertype, ‘components’, ‘com_typedcontent’ ))) {
mosRedirect( ‘index2.php’, _NOT_AUTH );
}

Все! После вставки данных проверок, пользователи группы DownloadsManager гарантированно получат отказ при попытке редактирования материалов сайта из административной панели Joomla.
Заключение

Давайте подведем итоги. В этой статье мы добавили новую группу пользователей Joomla, предоставили ей доступ к компоненту Remository и запретили изменять меню и материалы сайта. Таким образом мы получили группу менеджеров файлового архива, которые могут беспрепятственно заходить в административную панели и управлять файловым архивом, реализованным посредством компонента Remository.

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

Николай, приветствую! Расскажи, как всё начиналось и как вылилось в проект Joostina?

Началось всё в 2005 году, именно тогда я впервые узнал о Joomla и получил приглашение вступить в ряды команды joom.ru. Тогда мы занимались локализацией свежей версии Joomla. Через пару лет локализация окрепла и у команды набралось большое число правок, делавших оригинальную Joomla более удобной. С другой стороны команда joomlaportal.ru помимо увеличения удобства еще и накопила большое число идей по доработке системы под русские реалии. Сам проект вырос из желания собрать все правки в одном месте и сделать систему более удобной, безопасной и быстрой.

Расскажи о команде Joostina и текущем положении дел.

Сейчас непосредственно внутри команды более 20 человек, правки ядра осуществляют 4 человека. Остальные тестируют промежуточные версии, собирают и адаптируют расширения. Joostina из увлечения одного человека стала интересным продуктом: поисковые системы выдают тысячи упоминаний системы на внешних сайтах. Внесённые в ядро правки позволяют создавать на Joostina разнотипные сайты, от небольших визиток и блогов, до высоконагруженных порталов с полумиллионным трафиком. Во главе проекта стоит Чернова Ирина, известная так же как ZaiSL или PbICb, я занимаюсь только сбором предложений и правкой ядра, в свободное время помогаю на форуме и немного адаптирую устаревшие расширения для новой версии системы.

Не секрет, что большая часть западных разработчиков отказалась от поддержки Joomla 1.0 и, следовательно, возникает резонный вопрос развития новых расширений под Joostina. Скажи, пожалуйста, какие ведутся в этом направлении работы и что предлагается конечному пользователю?

Отказались – ну и правильно. Первая версия Joomla собрала тысячи расширений, часть из которых мигрировала еще с CMS Mambo. Какие-то расширения были уникальными, но большинство – старые переделки и модификации, не все из которых отличались качеством и безопасностью. То, что многие разработчики отказались от поддержки расширений пошло нам на руку – многие из расширений не просто ушли в свободное плаванье, а стали полностью бесплатными. Например: прекрасное расширение JPromouter, которое раньше было платным, а сейчас уже прекрасно адаптировано для новой версии Joostina. Кроме того авторы этого расширения пошли на встречу нашему проекту, что не исключает взаимовыгодного сотрудничества и выигрыша конечных пользователей в том числе. Сейчас команда в полузакрытом режиме адаптирует лучшие расширения от Joomla, выбранные сами ми же пользователями, почти готов к запуску каталог расширений.

Другими словами, Joostina скорее платформа полузакрытого типа, предназначенная прежде всего для разработчиков, имеющих солидный багаж опыта для Joomla 1.0, чем для обычного пользователя? Если это не так, то каким образом планируете привлекать «свежую кровь»?

Как раз наоборот! Полузакрыта только та часть, в которой варится внутренняя каша; всё, что внутри команды проверяется и одобряется – сразу становится доступно любому желающему, как через анонс на joomlaforum.ru, так и через наш официальный блог – blog.joostina.ru. По уровню вхождения Joomla 1.0.x проще чем 1.5.х, а по скорости и безпроблемности принятия патчей и модификаций системы – Joostina вообще не обогнать. Joomla разрабатывается в закрытом кругу, Joostina же наоборот – с радостью принимает все пожелания пользователей. Свежая кровь – понятие растяжимое, мы просто делаем то, что нам нравится и если наша работа понравится пользователям, то кровь прильётся сама.

Как известно, общий недостаток Joomla обеих линеек – отсутствие реализации полноценного CCK и ACL, что являлось плюсом конкурирующей системы WordPress. Будет ли что-либо предложено пользователям Joostina в этом отношении?

Вот это на самом деле большой минус и Joomla и Joostina. К сожалению, на данном этапе все силы сконцентрированы на выпуск новой версии Joostina 1.3.0 и на создание расширений типа CCK и ACL – сил не остаётся. Но в таком важном и звучном вопросе мы не оставим своих пользователей – как появятся свежие силы или освободятся имеющиеся, они сразу будут брошены на разработку всех недостающих расширений.

Известная проблема Joomla 1.0 – табличный вывод контента. Несомненно, огромный плюс Joomla 1.5 заключается в том, что шаблонизация модулей и com_content реализована на уровне самого шаблона – можно «подкрасить» вывод без вмешательства в core составляющие движка. Однако исключение табличной доминанты приведёт к ещё большему отходу от совместимости с шаблонами и компонентами, заточенными под линейку 1.0. Планируется ли реализовать выбор способа отображения контента? (стандартный табличный, на div)

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

Известно, что главный козырь Joostina – производительность. Высокая производительность платформы позволяет разворачивать крупные проекты с посещаемостью в несколько сотен тысяч посетителей в сутки (!), что, несомненно, может явиться определяющим фактором для разработчика при выборе платформы. Можно ли услышать некоторую статистику и если возможно, представить сравнительную таблицу производительности Joomla 1.5 и Joostina 1.2.x/1.3 с равным функционалом и количеством посещений?

Нет, таких сравнений не делал, а у сторонних разработчиков не встречал. Если увидишь где – дай знать, самому интересно. Скажу только, что в Joostina 1.3.0 добавили несколько интересных решений, которые позволят более тонко настраивать и кэширование и производительность сайта. По версии1.2.0 могу сказать, что зная конечную цель создаваемого сайта, можно с правильными настройками и минимальными правками получить до 800 000 трафика в сутки не теряя динамичности и не тратя на сервер много средств.

boston, как ты оцениваешь «геополитическую» расстановку в мире Joomla? Сейчас как грибы после дождя стали появлятся нехватающие CCK расширения для Joomla 1.5, публично выходит альфа-версия Joomla 1.6… Линейка 1.5 по сути, является переходным этапом к более совершенной CMS Joomla 1.6, но опять же возникает заминка с написанием расширений. Но поскольку Joomla 1.6 наберёт обороты, возникает серьезная угроза для Joostina в плане привлекательности платформы в целом. Какие можно назвать плюсы твоей системы по сравнению с многообещающей 1.6?

Joomla 1.6.x интересна и мне, как плане архитектуры, так и в плане запланированных решений. Но мне бы не хотелось сравнивать какая система лучше, или какая более привлекательна – они уже слишком разные. Joostina и сейчас и потом будет строиться на 3х ключах – производительности, удобстве, и гибкости. Joostina хоть и приобретает свойства многоязычности, но всё равно более ориентирована на русскоязычный рынок, который Joomla намного сложнее завоевать.

Николай, мне известно, что тобой ведутся работы в плане обеспечения совместимости с расширениями Joomla 1.5 в legacy режиме. Скажи, на что ориентироваться конечному пользователю в плане изучения документации? Означает ли, что с выходом Joomla 1.6, вы плавно перейдёте к смене идеологии проекта, ориентируясь на новую архитектуру, что выльется в переписывание документации и т.п?

Нет, это не так. Мы не ведём абсолютно никаких разработок для совместимости с Joomla 1.5.x и не планируем перейти на ядро Joomla 1.6.x. То, что сейчас уже сделано – слишком много и дорого как команде, так и мне лично. Выбрасывать все наработки или наращивать костыли для запуска расширений полностью другой версии Joomla – это неинтересно. Можно сделать прослойку и дописать тысячи функций, но мы не выиграем ничего – расширения хоть и запустятся, но не будут выполнять свои функции лучше, чем на оригинальной Joomla. Зато потеряем имеющуюся гибкость и производительность.

Говоря о Joomla, не могу, к сожалению, не отметить ужасное состояние Joomla Extensions Directory, где размещают всё подряд, превратив официальный каталог расширений в подобие мусорки (в этом плане заметно выделяется платформа Drupal, проводящая качественную оценку расширений). Я так понимаю, Joostina есть что сказать в этом плане?

О, да, полностью согласен по поводу текущего положения дел в JED. У нас подходит к завершению создание каталога расширений Joostina и в нём мы постарались избавиться и заранее запланировать удобную навигацию и разделение расширений. Но всё, конечно, узнаем после запуска – если каталог не понравится, и поступят предложения по его улучшению – сразу доработаем и учтём все пожелания.

Использование кодировки UTF8 в версии Joostina 1.3 наталкивает на мысль, что все расширения, которые планируется размещать на репозитории Joostina, будут заточены уже с учётом использования UTF8 в новой версии CMS?

Да, почти все расширения, которые будут описаны в каталоге, сразу адаптированы для версии 1.3.0. Для 1.2.0 подходят почти все расширения первой линейки Joomla. Мы не собираемся превращать каталог в свалку расширений разных версий и качества.

Не боишься, что Joostina может пойти путём греческой CMS Elxis (которая в своё время тоже вышла из Joomla), замкнувшись в рамках небольшой аудитории?

Нет, не боюсь. Не знаю, что именно случилось с Elxis, но для Joostina уже на пару лет вперёд распланированы и доработки, и методы завоевания доверия пользователей.

И ещё такой вопрос: почему везде, во всех файлах, удалены копирайты Joomla? Вроде бы это действие противоречит GPL лицензии…

Ну копирайтов Mambo в файлах Joomla тоже нету, всё собранно в отдельном файле – в Joostina полностью аналогично: Мы не отрекаемся и не присваиваем себе чужие разработки. В каждом файле есть сноска «Для получения информации об используемых расширениях и замечаний об авторском праве, смотрите файл help/copyright.php.», а в самом файле copyright.php уже собраны все авторы, авторы модификаций, ссылки на проекты, даже на графические значки прописаны копирайты. Из файлов всё это вынесено только с целью сократить величину и уменьшить запутанность файлов.

Планируется ли аналог моста JFusion под Joostina? (возможность интеграции с рядом популярных скриптов форумов и eCommerce)

Да, планируется. Так же планируется возможность интеграции нескольких сайтов на самой Joostina, и в этом направлении уже достигнут определённый результат.

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

Скажу так – активность волнообразна. В некоторые моменты кажется, что это всё вообще никому не надо, а в другие не успеваю отвечать на письма и принимать разработки. Сообщество мне нравится, иногда даже пятиминутное общение с новым человеком вносит очень существенные коррективы в систему. Общественность, как и в других вопросах надо заинтересовывать, тогда и отчетов о тестировании больше, и предложения конкретнее. Мне нравится команда, нравятся посетители и администрация joomlaforum, нравятся просто пользователи, которые говорят что им кажется неудобным в системе и предлагают свои идеи. Вклад пользователей в развитие Joostina – 80%, остальные 20% – это личные амбиции и идеи команды.

Работы много. Какая помощь более всего нужна вашей команде на данный момент? Может ли любой желающий внести свой вклад в общее дело и что нужно для этого сделать такому человеку?

Документация. Это наше самое слабое место. Система постоянно модифицируется, и старые описания Joomla 1.0.x уже не подходят, а создать новые – не получается. На wiki.joostina.ru есть небольшой список статей, которые составили бы базовое описание системы и принципов работы с ней, если бы несколько пользователей смогли просто и доступно описать эти моменты – было бы уже хорошо. Второй момент – сбор и адаптация расширений. Для новой системы нужны новые и главное качественные расширения, в блоге и на форуме есть темы по сбору расширений, туда может любой желающий написать те расширения, которые считает лучшими в своём классе. Потом эти расширения подвергнутся коренному просмотру и доработки для Joostina 1.3.0 и будут внесены в каталог. Работа тоже по своей сути не сложная, но выделив 15 минут на описание одного расширения, любой пользователь сможет сильно помочь как новичкам в выборе, так и самой Joostina в популяризации и расширяемости.

Говоря о java script фреймворке, следует отметить, что разработчики Joomla сделали выбор в пользу Mootools (хотя, на мой взгляд, JQuery является более интересным фреймворком). У Joostina есть своя библиотека – Fullajax. Расскажи о её преимуществах. Чем она лучше вышеназванных фреймворков?

У Joostina есть и Fullajax и Jquery. Fullajax это разработка уважаемого друга системы – Руслана Синицкого, чем лично горжусь. Библиотека позволяет более гибко и полно контролировать ajax – процессы в системе, делая это просто и гибко. Jquery – это библиотека более широкого действия, через неё и добавляются эффекты, и расширяются возможности Fullajax.

Как же быть разработчику сайтов? Цеплять Jquery или изучать документацию по FullAjax?

Тут зависит от задач, если нужна бесконечная расширяемость и разнообразные эффекты – стоит брать Jquery. Если надо без лишних вопросов встроить ajax в приложение – выбирайте Fullajax. Не склоняю к выбору одного конкретного решения, кому что удобнее, то и можно использовать.

boston, поделись, какие у тебя планы на текущий год и к чему стремишься в идеале? Есть ли шанс у Joostina со временем выбиться в «большие» CMS, заявив о себе на ряде конкурсов?

Из планов на этот год – завершить разработку версии 1.3.0, запустить обновлённую серию сайтов *.joostina.ru, заняться написанием документации и как раз заявлении о себе как «большой» CMS. Шансы есть, но раскрывать всех карт не буду – очень, очень и очень рано.

На официальном сайте Joostina есть информация о том, что вы призываете Joomla core team официально передать эстафету Joomla 1.0 в руки разработчиков Joostina, подарив таким образом, Joomla 1.0 вторую жизнь. Достигли ли в этом направлении каких-либо успехов? Планируется ли организовать массовое обращение пользователей и т.д.?

Да уж, достигли…. Получили от ворот поворот и замечание что Joomla зарегистрировали всё что с ними связано, начиная от слово Joomla и цветовой символики, заканчивая буквой J в любом названии: В их предложении было сказано, что нужно поддерживать именно Joomla 1.0.x.., а не развивать свою версию системы, даже если она и выигрывает по ряду показателей. В общем, мы к ним обратились и получили отказ.

Какие работы ведутся в области интеграции Joostina за пределы СНГ? Будет ли Joostina открыта для пользователей и разработчиков из др. концов планеты, не говорящих по-русски?

Да, 1.3.0 версия поддерживает возможность многоязычности интерфейса, но тут опять же всё зависит от самих пользователей – мы только пойдём на встречу, если найдутся люди желающие перевести Joostina на свой родной язык.

Интервью подошло к концу. Благодарю тебя, Николай, за потраченное время и интересную беседу. Последнее слово оставляю за тобой.:)

Спасибо тебе, отвечать было интересно, часть вопросов прямо в те области, которые обычно умалчиваются или раскрываются не полно. Надеюсь, интервью будет интересно не только нам с тобой, но и всем читателям. Благодарю за интересные вопросы, а устоявшимся и новым пользователям Joostina скажу: «Оставайтесь с нами, всё самое интересное – только начинается! ».

В XML файле модуля все необходимые параметры помещаются между тегами <params></params>, в виде списка.
Каждый параметр может быть прописан в XML файле различными способами. Все зависит от того, что это за параметр, как мы хотим использовать его в дальнейшем, в каком виде он должен быть представлен пользователю в административной части и т.д. Пример описания простейшего параметра:
<param name=»items» type=»text» default=»" label=»Количество объектов» description=»Количество показываемых объектов» />

В ряде случаев, параметр может быть прописан так, что его выходные данные смогут принять только какое-то одно фиксированное значение. Это делается с помощью «радио-кнопок» или выпадающих списков. Конструкция описания параметра при этом сильно видоизменяется, а сами фиксированные значения прописываются в тегах «option». Например:
<param name=»item_title» type=»list» default=»0″ label=»Заголовок объекта» description=»Показывать или нет заголовок объекта»>
<option value=»0″>Нет</option>
<option value=»1″>Да</option>
</param>

В данном примере, пользователь сможет задать параметру «item_title» только одно из двух, заранее определенных разработчиком модуля значений – 0 или 1. Свойству «default» в такой конструкции необходимо присвоить одно из опциональных значений «value». В приведенном примере default=»0″, значит при первом пуске административной части модуля, указатель «option» будет установлен в положение «Нет».

Каждый параметр модуля должен иметь обязательное свойство «name», которое служит идентификатором этого параметра. Значение этого свойства должно быть уникальным. Так же параметр должен быть дополнительно описан с помощью ряда свойств, таких как «type» – тип, «default» – значение параметра по умолчанию, «label» – наименование параметра и «description» – описание параметра.

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

Пример использования дополнительных параметров в XML файле модуля:
<param name=»sometext» type=»textarea» cols=»80″ rows=»5″ default=»" label=»Текст» description=»Обычный текст или текст в формате HTML, который будет выводиться в блоке модуля.» />

Здесь свойства «cols» и «rows» определяют только ширину и высоту многострочного поля для ввода текста – «textarea» в административной части модуля.

Теперь давайте рассмотрим, какие свойства можно задавать параметрам в XML файле.
Свойство «name» – имя параметра.

Как уже говорилось, свойство «name» это идентификатор параметра, с помощью которого мы можем получить его значение в процессе выполнения скрипта модуля.
Имена для параметров модуля устанавливает разработчик в процессе его создания. Однако существуют еще зарезервированный CMS Joomla список имен параметров, которые служат для строго определенных целей. Это имена системных параметров.

moduleclass_sfx – это суффикс, который будет автоматически присоединен Joomla (Джумлой) ко всем CSS классам данного модуля, при его выводе на страницу сайта.

Пример использования параметра moduleclass_sfx в XML файле модуля:
<param name=»moduleclass_sfx» type=»text» default=»" label=»CSS-cуффикс класса модуля» description=»Суффикс, который будет использован в описании класса (table.moduletable) таблицы стилей (CSS) модуля. Это позволяет использовать индивидуальный стиль модуля.» />

сache – позволяет принудительно включить/отключить кэширование модуля.

Пример использования параметра cache в XML файле модуля:
<param name=»cache» type=»radio» default=»0″ label=»Разрешить кэширование» description=»Выберите, кэшировать ли содержимое этого модуля»>
<option value=»0″>Нет</option>
<option value=»1″>Да</option>
</param>

Чтобы ответить на эти вопросы, вебмастер должен четко представлять, что он хочет получить от сайта и каким он видит себе свой сайт. Тут стоит немного подумать и, в свою очередь, ответить для себя на несколько вопросов.
Вопрос № 1. Нужно ли будет отображать статью на главной странице?

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

Если такие варианты не приемлемы, а статья обязана быть на главной странице, тогда придется создавать раздел и категорию, а уже в категории создать Объект содержимого.
Вопрос № 2. Какое количество статей будет размещено на сайте?

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

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

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

Если же объединить такие статьи в один раздел или категорию, например, «Разные статьи», то ссылки-переходы на страницы этого раздела будут формироваться CMS Joomla автоматически. Что это за переходы? Это вкратце: ссылки «Далее…», ссылки со страницы сформированной как «Таблица – Содержимое категории», постраничная навигация «Пред. След.».
Вопрос № 3. Будет ли задействован модуль «Разделы»?

Само название говорит, что модуль будет отображать только разделы сайта. Никакого Статичного содержимого он отображать не будет.
Вопрос № 4. Будет ли задействован модуль «Краткие новости»?

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

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

Чтобы было еще более понятно, давайте разберем небольшой пример.

Итак, приступим.
Настройка глобальной конфигурации сайта под CMS Joomla.

Перед началом оптимизации сайта нам необходимо подобрать список ключевых слов.

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

Прописываем тег «title».

Заходим в глобальную конфигурацию и переходим на закладку «Сайт».

Здесь в поле «Название сайта» прописываем название нашего сайта. Какое название будет у Вас, это решать Вам. В приведенном примере, это «Joomla для всех».

Текст, прописанный в этом поле, будет присутствовать в каждой странице сайта Joomla в теге «title».

При переходе на различные страницы сайта к этому тексту будет автоматически добавлена конструкция « – » (пробел тире пробел), поэтому никаких пробелов и знаков препинания в конце «Название сайта» ставить не надо.

После этой конструкции, CMS Joomla будет добавлять:
Если страница формируется компонентом – название пункта меню, ведущее к этому компоненту. Например, к компоненту поиска по сайту адресуется пункт меню «Поиск», тег «title» для этой страницы будет выглядеть: «Joomla для всех – Поиск». И так далее.
Не забываем о базовом компоненте com_content. Он формирует страницы типа «Блог – Содержимое категории», «Таблица – Содержимое раздела» и тому подобное. Для него справедливо все описанное выше.
Примечание. Еще раз повторю – сейчас рассматривается работа базовых компонентов. При работе компонентов сторонних разработчиков, формирование тега «title», это забота и обязанность самого разработчика, и содержание этого тега будет зависеть только от его грамотности и знания работы CMS Joomla, то есть профессионализма.
Если на страницу выводится текст «Статичное содержимое» или «Объект содержимого», – полное название статьи.

С тегом «title» разобрались, идем дальше.
Прописываем метатеги.

Метатег «description».

Кликаем на закладку «Метаданные».

Текст, введенный в первое поле «Описание сайта, которое индексируется поисковиками» будет выводиться в каждой странице сайта Jooma в метатеге «description».

При этом, если на страницу будут выводиться, либо полный текст статьи («Статичное содержимое» или «Объект содержимого»), либо «Вводный Текст» этих статей (компонент главной страницы и все страницы формируемые как «Блог»), в метатег «description» будет добавляться текст из поля «Описание (Description)» (об этом поле далее) каждой статьи, через запятую.

В остальных случаях метатеге «description» будет содержать только текст, прописанный в первом поле этой закладки. Это конечно не есть хорошо, но ничего не поделаешь – так сделали разработчики CMS Joomla.

В конце текста этого поля никаких пробелов ни знаков препинания ставить не надо.

Метатег «keywords».

Содержание второго текстового поля «Ключевые слова сайта» будет выводиться в каждой странице сайта Joomla в метатеге «keywords». Это поле должно содержать одно-два ключевых слова или фразы, которые однозначно будут присутствовать на каждой странице Вашего сайта.

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

Подобно тому, как формируется для каждой страницы метатег «description», формируется и метатег «keywords». То есть, если на страницу будут выводиться, либо полные тексты статей, либо вводный текст этих статей к нему после запятой будет добавляться содержимое поля «Ключевые слова (Keywords)» из каждой статьи (об этом далее).

В принципе, о ключевых словах этого поля можно сказать, что это должны быть слова поисковых запросов, по которым собственно и производится оптимизация сайта CMS Joomla, то есть они обязательно должны присутствовать на каждой странице сайта! Как это сделать на практически пустой странице «Поиск»? Подумайте, пофантазируйте. Сделайте, например, модуль опросов с включением таких слов или опубликуйте модуль вывода кратких новостей, а в них добавьте ключевые слова и т.д.

Дополнительные настройки.

Если в поле «Показывать мета-тег title» установить «Да», то CMS Jomla будет формировать метатег «title» на страницах, которые выводят тексты статей «Статичное содержимое» или «Объект содержимого». Причем метатег title будет содержать только тот текст, который прописан в поле «Описание (Description)» (об этом далее) для этой статьи. Этим мета-тег «title» сайта на CMS Joomla отличается от тега «title».

Истинного назначения именно метатега «title» я не знаю, поэтому нужно ли ставить здесь «Да» или нет, точного ответа я не дам. Возможно, этот метатег просто дублирует тег «title» и сам по себе особого значения не имеет.

По моему опыту, основные поисковые системы при индексации сайта используют значение именно тега «title», но лично я всегда указываю в данном поле «Да» – на всякий случай .

Если в поле «Показывать мета-тег author:» установить «Да», то CMS Jomla будет формировать метатег «author» на страницах, которые выводят тексты статей «Статичное содержимое» или «Объект содержимого».

Значение этого метатега берется из поля «Автор» выводимой статьи. Причем наличие этого метатега не зависит ни от глобальных, ни от локальных настроек «Показать/Скрыть Имена авторов».

Я посоветую в этом поле указать «Да», так как некоторые поисковые системы учитывают этот тег.

Настройки ядра CMS Joomla.

Теперь переходим на закладку «SEO». Здесь в поле «Дружественные для поисковых систем URL-ы (SEF)» ставим «Да». Такая установка преобразует ссылки на страницы Вашего сайта. Например, вот такая ссылка

http://joomla4all.ru/index.php?option=com_content&task=view&id=27&Itemid=1,

теперь будет иметь вид:

http://joomla4all. ru/content/view/28/1/
Не забудьте после этого переименовать файл «htaccess.txt», расположенный в корневой директории Вашего сайта в файл «.htaccess».

В поле «Динамические заголовки страниц (теги title)» ставим «Да». Если этого не сделать, то тег «title» будет содержать только то, что прописано в поле «Название сайта» (об этом поле рассказывалось ранее), а это неприемлемо.

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