3. Навчально методичний розділ

3.1 Методика проведення лабораторно-практичного заняття

Лабораторне заняття – форма навчального заняття, при якому студент під керівництвом викладача, особисто проводить натурні або імітаційні експерименти, чи досліди з метою практичного підтвердження окремих теоретичних положень даної навчальної дисципліни; набуває практичних навичок роботи з лабораторним устаткуванням, обладнанням, обчислювальною технікою, вимірювальною апаратурою, методикою експериментальних досліджень у конкретній предметній галузі.

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

Лабораторне заняття проводиться з студентами, кількість яких не перевищує половини академічної групи. Перелік тем лабораторних занять визначається робочою навчальною програмою дисципліни. Заміна лабораторних занять іншими видами навчальних занять, як правило, не дозволяється.

Лабораторне заняття включає проведення поточного контролю підготовленості студентів до виконання конкретної лабораторної роботи, виконання завдань теми заняття оформлення індивідуального звіту з виконаної роботи та його захист перед викладачем. Виконання лабораторної роботи оцінюється викладачем. Підсумкова оцінка виставляється в журналі обліку виконання лабораторних робіт. Підсумкові оцінки, отримані студентом за виконання лабораторних робіт, враховуються при виставленні семестрової підсумкової оцінки з даної навчальної дисципліни

Лабораторна робота № 1

Тема роботи: Створення плагіна для CMS WordPress.

Мета роботи: навчитись створювати плагіни для смs WordPress.

1. Підготовка до заняття

1.Вивчити відповідні розділи теоретичної частини та відповідного лекційного курсу.

2 Порядок виконання роботи:

• Ім’я плагіна;

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

Якщо після пошуку не було знайдено плагіна, який би задовольняв потреби користувача, то можна приступати до створення власного. Для нього потрібно обрати ім'я (бажано унікальне). Перевірте «Модулі» та інші сховища, щоб переконатися в тому, що придумане вами ім'я – унікальне. Більшість розробників плагінів вибирають імена, які відображають функціональність їх плагіна; наприклад, плагін для відображення погоди може мати у назві слово «погода». Назва може складатися з декількох слів.

• Файли плагіна;

Наступний крок – створення файлу PHP з ім'ям, похідним від назви плагіна. Наприклад, якщо ваш плагін буде називатися Fabulous Functionality, ви можете назвати ваш файл fabfunc.php. Знову ж, спробуйте створити унікальне ім'я. Люди, які встановлять ваш плагін, покладуть цей файл у свою директорію для плагінів, wp-content/plugins /, і ніяка пара використовуваних плагінів не повинна мати однакове ім'я файлу.

Інший варіант – розбити ваш плагін на декілька файлів. Ваш плагін повинен мати як мінімум один файл PHP; він також може містити файли JavaScript, CSS, зображення, мовні файли і т.п. Якщо ваш плагін складається з декількох файлів, задайте унікальне ім'я для директорії, в якій вони лежать, і для головного файлу PHP, такі як fabfunc і fabfunc.php в нашому прикладі, покладіть ваші файли в цю директорію, і дайте користувачам можливість встановлювати цілу директорію в wp-content/plugins/.

• Файл Readme;

Якщо ви хочете розмістити ваш плагін на http://wordpress.org/extend/plugins/, вам необхідно створити файл readme.txt в стандартному форматі і включити його в свій плагін. Дивіться http://wordpress.org/extend/plugins/about/readme.txt для отримання роз'яснень по формату.

• Домашня сторінка;

Також дуже зручно створити веб-сторінку, що грає роль «домашньої сторінки» вашого плагіна. Ця сторінка повинна пояснювати, як встановити плагін, що він робить, з якими версіями WordPress сумісний, що змінювалося від версії до версії вашого плагіна, і як його використовувати.

• Заголовки файлів;

Саме час внести деяку інформацію в ваш головний файл PHP.

• Стандартна інформація про плагін;

Початок вашого файлу повинен містити стандартний інформаційний заголовок. Цей заголовок дозволяє WordPress зрозуміти, що ваш плагін існує, додати його в панель управління плагінами, де він може бути активований, завантажити його і запустити його функції; без заголовка ваш плагін ніколи не буде активований і запущений. Ось формат заголовка:

<?php

/*

Plugin Name: Название плагина

Plugin URI: http://страница_с_описанием_плагина_и_его_обновлений

Description: Краткое описание плагина.

Version: Номер версии плагина, например: 1.0

Author: Имя автора плагина

Author URI: http://страница_автора_плагина

*/

?>

Мінімальна інформація, яка потрібна WordPress, щоб виявити ваш плагін - його назва (Plugin Name). Решта інформації (якщо вона є) використовується для створення таблиці плагінів на сторінці управління плагінами. Порядок рядків неважливий.

• Ліцензія;

За стандартним заголовком звичайно треба інформація про ліцензії на плагін. Більшість полігонів використовують ліцензію GPL або ліцензію, сумісну з GPL. Для вказівки ліцензії GPL додайте наступні рядки в файл вашого плагіна:

<?php

/* Copyright ГОД ИМЯ_АВТОРА_ПЛАГИНА (email: E-MAIL_АВТОРА)

This program is free software; you can redistribute it and/or modify

it under the terms of the GNU General Public License as published by

the Free Software Foundation; either version 2 of the License, or

(at your option) any later version.

This program is distributed in the hope that it will be useful,

but WITHOUT ANY WARRANTY; without even the implied warranty of

MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the

GNU General Public License for more details.

You should have received a copy of the GNU General Public License

along with this program; if not, write to the Free Software

Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA

*/

?>

• Програмування плагіна;

Тепер прийшов час змусити ваш плагін щось робити. Ця частина статті містить кілька основних ідей розробки плагінів, і пояснює, як довести до досконалості кілька завдань, які ваш плагін буде робити.

• Hook;

Отже, як же взаємодіють компоненти системи плагін + ядро ​​WordPress? Для того, щоб плагіни мали можливість впливати на роботу ядра WordPress або на кінцевий результат його дій, була придумана система так званих зачіпок (часто їх без перекладу так і називають «хуками» від англ. Hook - гачок, зачіпка). Принцип її дії полягає в тому, що кожна більш-менш важлива елементарна функція в ядрі WordPress перед тим як повернути якийсь результат своєї роботи або вчинити якесь важливе дію (наприклад вивести вміст записи на сторінці, або призвести запит до бази даних) «намагається» виконати додаткові інструкції (рядки коду) призначені саме для неї у файлах плагіна. Таку спробу вона робить за допомогою зачіпок, які прописані в тілі цієї функції. Ось приклад виклику зачіпок плагінів з ядра WordPress:

<?php

function get_the_title( $id = 0 ) {

…

…

return apply_filters( 'the_title', $title, $post->ID ); //Пример зацепки для функции get_the_title();

}

?>

Якщо в плагін існує код призначений змінити поведінку однієї зі стандартних функцій ядра, то він буде виконаний тієї функцією для якої призначався. Якщо ні - функція ядра спрацює як звичайно.

Наприклад, перед тим як WordPress додає заголовок до запису, спочатку він перевіряє, чи має який-небудь плагін зареєстровані функції для зачіпки під назвою «the_title».

<?php

…

add_filter( 'the_title', 'my_own_function_for_title' ); //Так выглядит регистрация в файле плагина новой функции my_own_function_for_title(); с дополнительным инструкциями для зацепки 'the_title'.

…

?>

Якщо текст заголовка «пропускається» через кожну таку зареєстровану функцію, і виводиться кінцевий результат.

<?php

…

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

*/

my_own_function_for_title( $title ){

$title = ucwords($title);

return $title;

}

…

?>

Таким чином, якщо ваш плагін повинен додавати певну інформацію до заголовку запису або змінювати її, в ньому повинна бути зареєстрована зачіпка-фільтр для «the_title» і в ньому повинна бути функція, яка робить всі потрібні зміни з заголовками.

Інший приклад - існує зачіпка під назвою «wp_footer». Перед кінцем HTML-сторінки, яку генерує WordPress, він перевіряє, чи мають які-небудь плагіни зареєстровану функцію для «wp_footer», і запускає її у разі виявлення такої.

Всі зачіпки в WordPress діляться на дві категорії - Фільтри та Дії. (Filters і actions відповідно). Фільтри (filters) дійсно призначені для «фільтрування» (зміни) будь-яких даних перед тим як вони будуть виведені на сторінці або додані для зберігання в базу даних. Це фільтрація спаму, помилок або просто помилкового введення у формах, звідки власне і сталося англійське назву. А друга (дії, actions) призначені для заміни різних дій ядра вашими діями (наприклад зміни рядка запиту до бази даних), у програмуванні така зміна дій базового функціоналу ще називають перевантаженням.

Ви можете дізнатися більше про те, як реєструвати функції для Фільтрів і Дій, і які дії ядра можна змінити в WordPress, в Plugin API. Якщо ви знайшли місце в коді WordPress, де ви хотіли б мати Дія або Фільтр, але в WordPress його немає, ви можете запропонувати нові зачіпки (пропозиції в основному приймаються); як це зробити, ви можете дізнатися в Reporting Bugs.

Теги шаблонів.

Інший шлях додавання функціональності за допомогою плагіна - створення тегів шаблонів. Той, хто хоче використовувати ваш плагін, може додати ці теги в свою тему, в панель, в секцію вмісту запису, або в інше відповідне місце. Наприклад, плагін, який додає географічні теги до постів, може визначити функцію тега шаблону під назвою geotag_list_states () для бічної колонки, який складає список усіх посад, помічених гео-тегами, з посиланням на архів сторінок плагіна.

• Збереження даних плагіна в базі;

Більшість полігонів одержують якусь інформацію від власника блогу або від його користувачів для використання її у фільтрах, діях, і функціях шаблонів, яку потрібно зберігати між сесіями. Ця інформація вимагає збереження в базі WordPress на тривалий час між сесіями. Ось два основних методи збереження даних в базу:

1. Використовуйте механізм налаштувань WordPress (про нього розповідається нижче). Цей метод призначений для зберігання відносно невеликої кількості іменованої статичної інформації - даних, які власник блогу вводить при першому запуску плагіна, і потім різко змінює.

2. Створіть нову окрему таблицю в базі даних. Цей метод призначений для даних, пов'язаних з певними записами, сторінками, додатками або коментарями - даних, обсяг яких зростає з плином часу, і які не мають індивідуальних імен. Дивіться Creating Tables with Plugins для отримання інформації, як створити таблицю плагіна.

• Механізм налаштування WordPress;

Інформацію про те, як створити сторінку, автоматично зберігає ваші налаштування, можна отримати у статті «Створення сторінок настройки».

WordPress має механізм для збереження, оновлення та вилучення окремих іменованих даних, що зберігаються в базі WordPress. Значення налаштувань можуть бути рядками, масивами або об'єктами PHP. Назви налаштувань - рядки, і вони повинні бути унікальними, щоб не конфліктувати з WordPress або іншими плагінами.

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

add_option($name, $value, $deprecated, $autoload);

Створює нову настройку; не робить нічого, якщо опція вже існує.

$ name

Обов’язковий (рядок). Ім'я настройки.

$ value

Необов’язковий (рядок), за замовчуванням - порожній рядок. Значення настройки.

$ deprecated

Необов’язковий (рядок), більше не використовується WordPress. Можна передати порожню рядок або null, щоб використовувати наступний за ним параметр

$ autoload

Необов’язковий, за замовчуванням - «так» (enum: «так» чи «ні»). Якщо встановлено «так», настройки автоматично витягуються функцією get_alloptions.

get_option($option);

Витягує значення налаштування з бази.

$ option

Обов’язковий (рядок). Ім'я настройки, значення якої потрібно отримати. Список налаштувань за замовчуванням, створених при установці WordPress, можна знайти в Option Reference.

update_option($option_name, $newvalue);

Оновлює або створює значення настройки в базі (примітка: можна не викликати add_option, якщо вам не потрібен параметр $ autoload).

$ option_name

Обов’язковий (рядок). Ім'я настройки для оновлення.

$ newvalue

Обов’язковий. Нове значення настройки.

• Панелі адміністрування;

За умови, що ваш плагін має якісь опції, що зберігаються в базі WordPress (див. розділ вище), ви, ймовірно, за хочете мати адміністративну панель, яка дозволить користувачам дивитися і редагувати налаштування вашого плагіна. Методи створення панелей описані в статті «Додавання адміністративних меню».

• Інтернаціоналізація плагіна;

Після того, як ви закінчили писати ваш плагін, його необхідно інтернаціоналізувати (за умови, що ви плануєте поширювати ваш плагін). Інтернаціоналізація - це процес налаштування програмного забезпечення під локалізацію; локалізація - це процес перекладу на різні мови відображуваного програмою тексту. WordPress використовується по всьому світу, і інтернаціоналізація та локалізація вбудовані в його структуру, в тому числі, і локалізація плагінів. Подробиці використання GNU gettext для локалізації WordPress можна дізнатися в Translating WordPress.

Настійно рекомендується інтернаціоналізувати ваш плагін, щоб люди з різних країн могли локалізувати його. Процес простий:

◾ Виберіть ім'я для простору перекладу вашого плагіна. Зазвичай воно таке ж, як ім'я головного файлу вашого плагіна (тільки без. Php). Ім'я повинно бути унікальним;

◾ Скрізь, де ваш плагін використовує рядки тексту, які будуть показані користувачеві (відомі як «повідомлення»), укладіть їх в одну з двох gettext-функцій WordPress. Зауважте, що у вашому плагіну ви повинні використовувати другий аргумент - ім'я простору перекладу, яке ви обрали (в ядрі WordPress аргумент $ domain залишається порожнім).

__ ($ Message, $ domain) Перекладає $ message, використовуючи поточну локаль для $ domain. Оберніть рядки, які збираєтеся використовувати в розрахунках, в цю функцію.

_e ($ message, $ domain) Перекладає $ message, використовуючи поточну локаль для $ domain, і виводить на екран. Оберніть в цю функцію рядки, які збираєтеся показувати користувачеві;

◾ Створіть для вашого плагіна файл POT (каталог перекладів для всіх перекладних повідомлень) і поширюйте його разом з плагіном. Користувачам необхідно буде покласти MO-файл перекладу в директорію вашого плагіна і назвати його domain-ll_CC.mo, де ll_CC - ім'я потрібної локалі. Для отримання інформації про файли POT, MO і локалях см. Translating WordPress;

◾ Завантажуйте переклад для поточної локалі і ваше текстове простір за допомогою функції load_plugin_textdomain до того, як викликаються функції gettext, але настільки пізно, наскільки можливо в сесії (бо деякі багатомовні плагіни змінюють локаль при завантаженні). Одна з можливих реалізацій - оголошення функції ініціалізації, яка викликається вище всіх функцій вашого плагіна. Наприклад, ваш простір тексту називається «fabfunc»:

$fabfunc_domain = 'fabfunc';

$fabfunc_is_setup = 0;

function fabfunc_setup()

{

global $fabfunc_domain, $fabfunc_is_setup;

if($fabfunc_is_setup) {

return;

}

load_plugin_textdomain($fabfunc_domain, PLUGINDIR.'/'.dirname(plugin_basename(__FILE__)));

}

Якщо ваш додаток не знаходиться у власній піддиректорії, другий аргумент функції load_plugin_textdomain можна опустити.

Якщо ви читаєте цю секцію, щоб інтернаціоналізувати тему, можна дотримуватися наведених вище рекомендацій, з деякими виключеннями:

◾ MO-файл потрібно скопіювати в каталог теми (поруч зі style.css);

◾ MO-файл потрібно назвати ll_CC.mo, де ll_CC - ім'я локалі (тобто ім'я простору не повинно бути частиною імені файлу);

◾ Щоб завантажити ім'я простору перекладу, вставте наступний код (з PHP-заголовком, якщо необхідно) у файл functions.php вашої теми:

load_theme_textdomain('имя_пространства');

• Поради до розробки плагіна:

• Код плагіна повинен відповідати стандартам розробки WordPress. Будь ласка, візьміть до уваги також стандарти Inline Documentation;

• Всі функції вашого плагіна повинні мати унікальні імена, відмінні від імен функцій ядра WordPress, інших плагінів або тем. З цієї причини, хороша ідея - використовувати унікальний префікс для імен функцій вашого плагіна. Інша можливість - оголошувати ваші функції всередині класу (який теж повинен мати унікальне ім'я);

• Не використовуйте явно префікс бази даних WordPress (зазвичай «wp_») у вашому плагіну. Замість цього використовуйте змінну $ wpdb-> prefix;

• Читання бази - легкий процес, а ось запис в базу - складний. Бази виключно хороші при складанні даних та їх видачу, ці операції зазвичай виконуються швидко. Внесення змін до бази - більш комплексний процес, отже більш ресурсномісткий. В результаті, постарайтеся зменшити кількість записів в базу;

• Вибирайте з бази за допомогою SELECT тільки те, що вам потрібно. Навіть незважаючи на те, що бази витягують дані досить швидко, ви можете зменшити навантаження на базу, вибираючи тільки ті дані, які вам потрібні. Якщо вам потрібно підрахувати кількість рядків у таблиці, не використовуйте SELECT * FROM, тому що всі дані всіх рядків будуть займати пам'ять. Подібно до цього, якщо вам потрібні тільки post_id і post_author у вашому плагіну, вибирайте за допомогою SELECT тільки ці конкретні поля, щоб зменшити навантаження. Пам'ятайте: сотні інших процесів можуть звертатися до бази одночасно з вами. База і сервер можуть тільки розподіляти ресурси між процесами. Вивчіть, як мінімізувати звернення вашого плагіна до бази, щоб гарантувати, що ваш плагін не зловживає ресурсами.

ЛІТЕРАТУРА

1. http://codex.wordpress.org;

2. http://zelgrim.ru/wordpress/wordpress-plagin-dmsguestbook.php;

3. http://www.ibm.com/developerworks/ru/library/wa-jqplugin/.