Створення ctools access plugin для Panels

26.02.2014
Ctools access plugin creation for Panels
Автор:

Нещодавно ми розглядали те, як при розробці сайтів створити ctools тип контенту для модуля Panels. Цього разу прийшла черга для іншого типу плагінів для Ctools, а саме - access plugin. Плагіни цього виду є певними правилами, за якими модуль Panels вирішує, показувати чи не показувати pane (найменшу структурну одиницю панелі), який з варіантів відображення самої панелі показувати.

Для прикладу розглянемо таку задачу: є стандартна панель user_view, яка перевизначає стандартне відображення сторінки користувача в Drupal. У нас є користувач А, який переглядає профіль користувача Б. Якщо користувач А зареєстрований на сайті раніше користувача Б, то йому будемо показуватися один набір полів, якщо навпаки - інший. Завдання дещо надумане (і присутні натяки на дідівщину), але для прикладу підійде.

Насамперед, як і у випадку з ctools типом контенту, потрібно за допомогою hook_ctools_plugin_directory() оголосити, що у нас є плагіни:

 /*
 * Implements hook_ctools_plugin_directory().
 */
function access_example_ctools_plugin_directory($owner, $plugin_type) {
  if ($owner == 'ctools' && !empty($plugin_type)) {
   return "plugins/{$plugin_type}";
  }
}

Далі в папці модуля створюємо наступні папки: папку "plugins", у ній папку "access", і в ній створюємо файл плагіна - назвемо його "​​access_example_plugin.inc". У файлі плагіна описуємо правило доступу масивом:

 /**
 * Plugins are described by creating a $plugin array which will be used
 * by the system that includes this file.
 */
$plugin = array(
  // Plugin user-friendly name.
  'title' => t('Eldership rule'),
  // Plugin description.
  'description' => t('Controls access depends on eldership'),
  // Without required context plugin will now be shown in Panels UI.
  'required context' => array(new ctools_context_required(t('User'), 'user')),
  // Function which will allow or restrict access.
  'callback' => 'access_example_who_elder_access',
  // Plugin settings form.
  'settings form' => 'access_example_who_elder_access_settings_form',
  // Provides a summary descriptions depends on settings selected.
  'summary' => 'access_example_who_elder_access_summary',
);

Ми вважаємо, що коментарі до коду є досить красномовними, щоб не робити більш детальний опис :). Нам залишається написати три функції: 

Перша (ключ 'settings form' в масиві плагіна) буде описувати форму налаштувань плагіна. Тут важливо, щоб елементи форми (а за сумісництвом вони є налаштуваннями правил доступу) знаходилися в контейнері "settings". Інакше введені дані не зберігатимуться. У нашому випадку, форма налаштувань буде складатися з одного чекбокса:

 /**
 * Settings form for our access plugin.
 */
function access_example_who_elder_access_settings_form(&$form, &$form_state, $conf) {
  $form['settings']['eldership'] = array(
    '#type' => 'checkbox',
    '#title' => t('Eldership'),
    '#description' => t('Will provide access if current user has been registered before user from context'),
    '#default_value' => !empty($conf['eldership']) ? TRUE : FALSE,
  );
  return $form;
}

Форма буде виглядати приблизно так:

Друга функція (ключ "summary" в масиві плагіна) є необов'язковою при створенні плагіна, але для зручності рекомендуємо її використовувати, оскільки її наявність дозволяє, без відкриття форми налаштувань правил доступу, зрозуміти поточний його стан.

 /**
 * Provide a summary description based on selected settings.
 */
function access_example_who_elder_access_summary($conf, $context) {
  return !empty($conf['eldership']) ?
  t('Will grant access if current user has been registered earlier then context user') :
  t('Will grant access if current user has been registered later then context user');
}

Ось так виглядатиме результат роботи вищеописаної функції:

Ну і найбільш важлива функція плагіна (ключ "callback" в масиві плагіна), власне, управляє доступом. Якщо вона повертає TRUE, значить доступ дозволений, FALSE - заборонений.

 /**
 * Check for access.
 */
function access_example_who_elder_access($conf, $context) {
  global $user;
  // There should always be a context at this point, but this
  // is safe.
  if (empty($context[0]) || empty($context[0]->data)) {
    return FALSE;
  }
  // We should ignore this access rule in case user is viewing his own profile.
  if ($user->uid == $context[0]->data->uid) {
    return TRUE;
  }
  if ($user->created < $context[0]->data->created) {
    return TRUE;
  }
  return FALSE;
} 

Далі потрібно почистити кеш і новостворений плагін стане доступний в правилах вибору варіанту в панелях та в правилах доступу до окремої панелі.

У додатку до цього блогу ми прикріпили архів модуля. Завантажуйте, вивчайте та користуйтеся на здоров'я!

Голосів: 1 Рейтинг: 5

Також по темі

1

Ми підібрали золотой список найважливіших модулів для Drupal 7, які життєво необхідні для SEO-оптимізації більшості сайтів. В цьому блозі ми наводимо перелік цих модулів та розказуємо чому вони...

2

Дуже часто багато розробників стикаються з проблемою гнучкого сортування матеріалів на сайті. Одним із варіантів вирішення цієї ситуації в Drupal є модуль Radioactivity. Дізнайтеся більше про його...

3

Зміни в Drupal 8, окрім усього іншого, торкнулися процесу створення власних віджетів і форматтерів. Новий плагін API значно спрощує цю процедуру.

4

Підтримка транзакцій з'явилася вже в Drupal 7, включаючи ті бази даних, які самостійно їх не підтримують. Давайте розглянемо як правильно їх використовувати, щоб досягнути потрібного результату....

5

У своїй практиці ми досить часто використовуємо Git Flow модель роботи з репозиторієм. Схема роботи з якою більш детально описана нижче.

Subscribe to our blog updates