На мой взгляд, XML-RPC протокол является одним из наиболее удобных способов передачи данных между Интернет-ресурсами. Можно, конечно, поспорить, но на изучение XML-RPC требуется минимальное количество времени, есть множество готовых библиотек, да и используется он очень широко. Поэтому я никогда не понимал, почему разработчики отличного фреймворка Yii решили не включать библиотеку для работы с XML-RPC в дистрибутив. Хотя, возможно, это вопрос времени

Тем не менее, работать нужно уже сейчас, и в этой статье мы разберём, как решить проблему с помощью сторонних библиотек.

Примечание. Если вас интересует создание XML-RPC клиента, почитайте статью XML-RPC и Yii фреймворк.

Немного теории.

Мы можем использовать два основных подхода при создании XML-RPC сервера.

1) Отдельный скрипт. В этом случае создаём файл с именем вроде xmlrpc.php и помещаем его в корень сайта. В нём будет находиться код обработки XML-RPC запросов. Такой подход используется, например, в WordPress. Достоинство в том, что вам не нужно вносить никаких изменений в код вашего проекта, т.е. XML-RPC интерфейс получается независимым. С другой стороны, независимость приводит к тому, что вам будет гораздо сложнее работать со встроенными библиотеками фреймворка.

2) Использование действий контроллера. Этот вариант гораздо интереснее. Во-первых, вы автоматически получаете доступ ко всем возможностям Yii. Во-вторых, в этом случае XML-RPC методы можно разделить по модулям. Т.е. подключение / отключение модуля будет автоматически подключать / отключать соответствующие XML-RPC методы.

Т.к. реализация первого подхода никакой сложности не представляет (фактически вы можете использовать примеры из документации к вашей библиотеке для работы с XML-RPC), мы рассмотрим второй вариант.

Какие библиотеки можно использовать?

По большому счёту – любые, т.к. подключение сторонних библиотек к Yii выполняется без особых проблем. Я обычно использую библиотеку Incutio XML-RPC Library. Она достаточно простая, работает без проблем и, кроме того, используется в WordPress, а эта CMS используется очень часто.

Переходим к практике.

Шаг 1. Подключаем библиотеку.

Для этого скачиваем библиотеку и сохраняем файл IXR_Library.php в папку protected/vendors. Теперь подключить библиотеку можно так:

Yii::import('application.vendors.*');
require_once ('IXR_Library.php');

Этот код можно добавить в любое действие (action) контроллера.

Шаг 2. Создаём точку входа.

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

class MyController extends Controller {
	...
	public function actionXmlrpc() {
		Yii::import('application.vendors.*');
		require_once ('IXR_Library.php');

		$server = new IXR_Server(array(
			'my.hello' => array($this,'hello'),
		));
	}
	...
}

В этом методе мы просто создаём объект типа IXR_Server, конструктору которого нужно передать массив с названиями XML-RPC методов. В данном случае в массиве только один элемент. Ключ этого элемента является названием XML-RPC метода, а значение – именем функции, которую нужно вызвать.

array($this,'hello') означает, что будет вызван метод hello данного контроллера.

Тут нужно помнить об одном нюансе. Обычно в XML-RPC запросах не передаются данные сессий. Логин и пароль отправляются в каждом запросе в качестве параметров. Поэтому необходимо, обеспечить доступ к методу actionXmlrpc() без авторизации. Для этого немного изменим метод accessRules

public function accessRules() {
	return array(
		array('allow',  // allow all users to perform 'index' and 'view' actions
			'actions'=>array('index','view','xmlrpc'),
			'users'=>array('*'),
		),
		…,
	);
}

Шаг 3. Добавляем методы.

Теоретически, можно ограничиться просто добавлением метода hello, который просто вернет «Hello, world!».

public function hello($args) {
	return 'Hello, world!';
}

Но в 99% нужно аутентифицировать пользователя. Добавим метод

protected function xmlrpcLogin($username, $password) {
	$identity = new UserIdentity($username, $password);
	$identity->authenticate();
	if ($identity->errorCode === UserIdentity::ERROR_NONE) {
		Yii::app()->user->login($identity, 0);
		return true;
	}
	else {
		return false;
	}
}

Здесь мы используем класс UserIdentity, который автоматически создаётся фреймворком Yii при создании приложения. В параметрах этого метода нужно передать логин и пароль. В случае успешной аутентификации метод вернёт TRUE, в противном случае – FALSE. Кроме того, данные пользователя будут доступны через Yii::app()->user, т.е. точно также как и при обычной работе с фреймворком.

Теперь перепишем код метода hello.

public function hello($args) {
	if (!$this->xmlrpcLogin($args[0], $args[1])) {
		return new IXR_Error(-1, 'You did not provide the correct password');
	}
return 'Hello, world!';
}

Здесь предполагается, что логин и пароль будут переданы в первом и втором параметрах XML-RPC запроса.

Шаг 4. Проверяем работу.

Для проверки достаточно создать обычный PHP скрипт со следующим кодом.

require_once ('IXR_Library.php');

$client = new IXR_Client('http://my_site.domen/my/xmlrpc');
$client->debug = true;

$args = array();
$args[0] = 'login';
$args[1] = 'password';

if (!$client->query('my.hello', $args)) {
    die('Something went wrong - '.$client->getErrorCode().' : '.$client->getErrorMessage());
}
echo $client->getResponse();

Как видите, создание XML-RPC сервера особой сложности не представляет. Конечно, самая сложная работа – это написание самих методов. Но не забывайте, что если у вас уже готов web интерфейс и логика по максимуму вынесена в модели, то вы сможете спокойно использовать её и в XML-RPC методах.

Успехов!

Полезная информация

Новогодний подарок от Inferno Solutions – всем новым клиентам панель ISP бесплатно и 30$ в подарок при заказе VPS в Германии, Украине или Голландии! Укажите при заказе в примечании ISP+30.

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

Одной из возможностей, которая почему-то по возможностям постоянно отстаёт от остальной части движка, является XML-RPC. На сегодняшний день этот протокол является основным средством удалённой публикации постов. И, при этом, он фактически бесполезен если вы используете произвольные типы записей (custom post types) и таксономии (custom taxonomies). Ни один XML-RPC метод публикации постов в WP 3.2.1 их не поддерживает.

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

Рассмотрим небольшой пример.

Допустим, нам нужно публиковать посты произвольного типа через XML-RPC и связывать их с таксономиями. При этом, таксономии могут быть как иерархическими, так и плоскими.

Примечание. Подробнее о типах постов и таксономиях рассказано в статьях: WordPress: вывод записей произвольных типов (Custom Post Types) и Управление контентом в WordPress CMS: ситуация на сегодня и ближайшая перспектива.

Немного теории

В WordPress предусмотрен фильтр (xmlrpc_methods), позволяющий добавлять новые методы во встроенный XML-RPC сервер. Делается это следующим образом:

add_filter('xmlrpc_methods', 'add_xml_rpc_methods');

Во втором параметре фильтра указываем имя функции, которая создаст запись в глобальном массиве XML-RPC методов.

function add_xml_rpc_methods($methods) {
	$methods['my.my_method_name'] = 'my_method_name';
	return $methods;
}

function my_method_name($args) {
//обработка XML-RPC запроса и отправка ответа
}

Чтобы создать XML-RPC метод нужно добавить новый элемент в массив $methods. Ключ этого элемента является именем метода, а значение – именем функции, которая выполняет обработку XML-RPC запроса и формирует ответ.

Реализация: XML-RPC клиент

Начнём с кода, который отправляет XML-RPC запрос. В данном случае будем использовать библиотеку The Incutio XML-RPC Library (она же используется и в WordPress).

require_once ('IXR_Library.php');

$client = new IXR_Client('http://my_blog.com/xmlrpc.php');
$client->timeout = 60000;

$requestData[0] = 0; //id блога
$requestData[1] = 'admin'; //имя пользователя
$requestData[2] = 'pass'; //пароль

$post = array();

$post['post_title'] = 'New Post';
$post['post_excerpt'] = 'Short description';
$post['post_content'] = 'This story about ...';
$post['post_status'] = 'draft';
$post['post_type'] = 'my_custom_post_type'; //тип поста
$post['post_date'] = date('Y-m-d H:i:s');
$post['post_modified'] = date('Y-m-d H:i:s');

//формируем массив с терминами таксономий
$terms = array();
$terms['taxonomy_1'][] = (int)$term['term_id_1'];
$terms['taxonomy_1'][] = (int)$term['term_id_2'];
$terms['taxonomy_2'][] = (int)$term['term_id_3'];
$terms['taxonomy_3'][] = (int)$term['term_id_4'];

$post['tax_input'] = $terms;

$requestData[3] = $post;

if (!$client->query('my.publish_post', $requestData)) {
	echo 'Publish Post error: '.$client->getErrorMessage();
	return;
}

$publishedPost = $client->getResponse();

Прежде всего, создаём объект IXR_Client, конструктору которого передаём адрес скрипт, который выполняет обработку XML-RPC запросов (xmlrpc.php).

Затем формируем массив с данными для публикации поста. В первых трёх элементах указываем: id блога (на данный момент не используется), логин и пароль. В четвертом элементе – массив с данными нового поста.

Чтобы сократить количество кода на стороне XML-RPC сервера, названия полей этого массива должны совпадать с полями массива, который передаётся функции wp_insert_post. Кстати, большинство ключей элементов этого массива совпадает с именами полей таблицы posts базы данных.

Обратите внимание на параметр

$post['post_type'] = 'my_custom_post_type'; //тип поста

В нём указан тип поста, который мы хотим создать. Естественно, этот тип должен быть заранее создан.

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

WordPress поддерживает таксономии 2-х типов: иерархические и плоские. Чтобы связать пост с терминами таксономий нужно перечислить их в элементе tax_input массива, который передаётся функции wp_insert_post. Например, так:

'tax_input' => array('taxonomy_1' => array('term', 'term2', 'term3'), 'taxonomy_2' => array('term1', 'term2'))

Здесь taxonomy_1, taxonomy_2 – имена таксономий, а term, term1 и т.д. – имена терминов.

Но здесь есть нюансы. Если публикуется «плоская» таксономия, то можно указать, либо имя термина, либо его id. При этом, id должен иметь тип int, если id сохранён в виде строки, то WordPress просто создаст новый термин. Для иерархических таксономий можно использовать только id термина (при этом нет ограничения на тип значения, оно будет автоматически приведено к типу int).

Т.е. универсальный вариант установки таксономий выглядит так:

$terms['taxonomy_1'][] = (int)$term['term_id_1'];
$terms['taxonomy_1'][] = (int)$term['term_id_2'];
$terms['taxonomy_2'][] = (int)$term['term_id_3'];
$terms['taxonomy_3'][] = (int)$term['term_id_4'];

Отправка запроса выполняется с помощью метода query, а прочитать результат можно используя getResponse.

XML-RPC сервер

На серверной стороне нужно зарегистрировать новый XML-RPC метод и написать функцию, которая будет обрабатывать запрос, и возвращать результат.

Примечание. Следующий код можно добавить в плагин или в файл functions.php темы.

add_filter('xmlrpc_methods', 'add_xml_rpc_methods' );

function add_xml_rpc_methods($methods) {
	$methods['my.publish_post'] = 'my_publish_post';
	return $methods;
}

function my_publish_post($args) {
	$blog_id = (int) $args[0];
	$username = $args[1];
	$password = $args[2];
	$post_data  = $args[3];

	if ( !get_option( 'enable_xmlrpc' ) ) {
		return new IXR_Error( 405, sprintf( __( 'XML-RPC services are disabled on this site.  An admin user can enable them at %s'),  admin_url('options-writing.php') ) );
	}

	$user = wp_authenticate($username, $password);

	if (is_wp_error($user)) {
		return new IXR_Error(403, __('Bad login/pass combination.'));
	}

	wp_set_current_user( $user->ID );

	if ( !current_user_can( 'edit_private_posts' ) ) {
		return new IXR_Error( 401, __( 'Sorry, you cannot edit private posts.' ) );
	}

	if (!is_array($post_data)) {
		return new IXR_Error( 401, __( 'Sorry, no post data not found.' ) );
	}

	$id = wp_insert_post( $post_data );

	if ($id === 0) {
		return new IXR_Error( 401, __( 'Post save error.' ) );
	}

	$post = array();
	$post['id'] = $id;
	$post['permalink'] = get_permalink($id);

	return $post;
}

Здесь мы регистрируем XML-RPC метод my.publish_post и указываем, что при обращении к нему WordPress должен вызвать функцию my_publish_post.

Большая часть кода в этой функции совпадает с большинством обработчиков стандартных XML-RPC методов WP. Собственно он оттуда и скопирован . Этот код проверяет, разрешен ли XML-RPC для данного блога (строки 14-16, кстати, не забудьте его включить в админке на странице Settings -> Writing), аутентифицирует пользователя и проверяет, достаточно ли у него прав для публикации поста.

Сама публикация выполняется с помощью всего одной функции wp_insert_post (строка 34).

Клиенту возвращаем id созданного поста и постоянную ссылку на него (формируем с помощью функции get_permalink).

Заключение

Как видите, принцип достаточно простой. Любую встроенную функцию WP можно вызвать через XML-RPC протокол и использовать все возможности движка при удалённой публикации постов.

Если есть вопросы или замечания, пишите, постараюсь ответить.

Успехов!

Интересные ссылки

Закажите печать фотокниг тремя способами: онлайн, в офисе или вип

Приветствую всех!

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

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

Загрузку файлов с локального компьютера трогать пока не будем, я планирую опубликовать отдельный пост на эту тему, разберем загрузку с удалённого сервера.

Проблемы начинаются с первого же шага. Даже если вы четко понимаете, где искать URL и хорошо умеете пользоваться инструментами вроде firebug, то всё равно потребуется несколько кликов мышкой чтобы получить нужный адрес. Было бы гораздо удобнее просто перетянуть нужную картинку из одного окна браузера в другое.

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

Обратите внимание! Данный пример работает только в браузере Google Chrome. По-идее, поддержка всех необходимых технологий есть в Firefox и Safari, но с ними я пока не разбирался.
В качестве объектов для «перетягивания» я брал в основном картинки с википедии. Было замечено несколько проблем связанных с не латинскими символами в URL картинок, но чтобы не перегружать пример проверками и преобразованиями я их оставил как есть.

Принцип работы

Стандарт HTML5 предусматривает поддержку «перетягивания» объектов страницы (Drag and Drop). Кстати, пример простейшей реализации D&D я уже показывал – Drag & Drop с использованием HTML5. И, кроме того, есть довольно много JavaScript библиотек, реализующих поддержку D&D.

Но тут важно понимать, что если необходимо «перетягивать» картинки со сторонних ресурсов, то использовать библиотеки не получится. Т.к. вы не сможете добавить свой JS код на чужую страницу. А для того, чтобы загрузить картинку, нам нужно получить её URL, т.е. браузер должен вместе с перетягиваемым объектом передавать и его параметры (например, атрибут src картинки или весь тег img).

В этом случае мы можем создать на своей странице «приёмник» картинок. Это будет обычный div которому назначен обработчик события drop. Если пользователь «сбросит» картинку над этим div'ом, то будет вызван обработчик и в первом параметре он получит объект, содержащий информацию о перетягиваемой картинке.

Дальше всё достаточно просто. Если мы получили нужный URL, то можно отправить AJAX-запрос серверному скрипту, который выполнит загрузку файла.

Реализация

Начнём со страницы нашего приложения.

<!DOCTYPE html>
<html>
    <head>
        <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
        <title>Images Upload</title>
		<link rel="stylesheet" type="text/css" href="styles.css" />
    </head>
    <body>
		<div id="images"></div>
		<div id="img_target"></div>
		<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.6.2/jquery.min.js"></script>
		<script src="main.js"></script>
    </body>
</html>

На ней размещены два блока: images – здесь будем показывать загруженные изображения и img_target – на этот блок нужно перетягивать картинки.

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

Рассмотрим main.js

$(function() {
    $('#img_target')
        .bind('dragenter', function(event) {
            $(this).addClass('drop_here');
            return false;
        })
        .bind('dragleave', function(event) {
            $(this).removeClass('drop_here');
            return false;
        })
        .bind('dragover', function(event) {
            return false;
        })
        .bind('drop', function(event) {
            $(this).removeClass('drop_here');
			var srcRegex = /src=\"([^\s]+)\"/ig;
            var data = event.originalEvent.dataTransfer.getData('text/html');
			var img_data = srcRegex.exec(data);
			$.post('upload.php', {'file_url':img_data[1]}, function(res) {
				var response = eval('(' + res + ')');
				$('#images').append($('<img src="' + response.file_url + '" />'));
			});
            return true;
        });
});

Здесь мы назначаем обработчики событиям dragenter, dragleave и dragover. Все они должны просто возвращать false и, чтобы как-то проинформировать пользователя о том, что можно «сбрасывать» картинку, в обработчике dragenter устанавливаем CSS класс drop_here для блока-приёмника.

Основная часть работы выполняется в обработчике события drop. При возникновении этого события мы читаем информацию о «сброшенном» объекте и «вырезаем» значение атрибута src, т.е. URL картинки (строки 16-18). Информация передается в объекте event.originalEvent.dataTransfer (строка 17).

Затем формируем обычный AJAX запрос и в качестве параметра передаём ему найденный URL.

Серверный скрипт (upload.php) получит URL изображения на удалённом сервере и загрузит его. А в ответе на AJAX запрос он отправит новый URL загруженной картинки.

В свою очередь, обработчик AJAX-запроса создаст тег img и вставит его в блок images. Таким образом, загруженные картинки будут появляться над полем загрузки.

Рассмотрим upload.php

<?php

define('BASE_URL', 'http://localhost/tests/images-upload/');

function upload_from_url($file_url) {
	$url_segments = explode('/', $file_url);
	$file_name = urldecode(end($url_segments));
	if (false !== $file_name) {
		$file_name_parts = explode('.', $file_name);
		if (in_array(strtolower(end($file_name_parts)), array('jpeg','jpg','png','gif'))) {
			$destination=fopen("upload/".$file_name,"w");
			$source=fopen($file_url,"r");
			$maxsize=300*1024;
			$length=0;
			while (($a=fread($source,1024))&&($length<$maxsize)) {
				$length=$length+1024;
				fwrite($destination,$a);
			}
			fclose($source);
			fclose($destination);
		}
	}
	$new_file_url = BASE_URL.'upload/'.$file_name;
	return $new_file_url;
}

$res = array('err' => 'Не указан URL файла');

if (isset($_POST['file_url'])) {
	$new_url = upload_from_url($_POST['file_url']);
	$res = array('file_url' => $new_url);
}

echo json_encode($res);

Принцип работы следующий. Читаем URL картинки и пытаемся её загрузить (строки 29-32).

Если картинка загружена, сохраняем её в папку upload. Получение картинки с удалённого сервера осуществляется с помощью функций fread. Файл читаем блоками по 1кБ (строки 15-18). Такой подход позволяет прервать загрузку файла, если его размер превышает заданный предел (в данном случае 300кБ).

После загрузки файла формируем для него URL и отправляем браузеру в формате JSON.

Как видите, реализовать такой загрузчик несложно. И пользоваться им достаточно удобно. Естественно, основным недостатком является поддержка HTML5 браузерами, точнее её отсутствие

Тем не менее, если вы создаёте интерфейс для сотрудников какой-нибудь компании, и можете оговорить тип браузера, то HTML5 вполне можно использовать.

Успехов!

Интересно почитать.

Фотокнига — фантастический сюрприз для любимого мужчины. Попробуйте сами!

Правильно подготовим 3-ндфл при покупке квартиры за 2011 год, дадим инструкции для получения вычета

Нужно распарсить сайт? Интересный пример как написан парсер на php. Можно даже скачать скрипт парсера.

Основные подготовительные работы по конференции закончены. Доклады сформированы. Среди спикеров представители KnpLabs, Magento, JetBrains, Sphinx и других известных компаний.

Открыта финальная регистрация!

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

Пожалуйста, обратите внимание на то, что изменилось место проведения! Мероприятие будет проходить на прошлогодней площадке — в актовом зале ЛГТЦ (Ленгипротранс-Центр), по адресу: Московский пр., 143, ст. м. «Электросила». Кофе-брейки и обсуждения на флипчартах будут проходить в фойе.

Cписок докладов:

Гибкая архитектура Zend Framework приложений с использованием Dependency Injection

Алексей Качаев (Сogniance, Senior PHP Developer)

Воюем за ресурсы: Повышение производительности Zend Framework приложения с помощью phpDaemon, Varnish и ESI

Алексей Качаев (Сogniance, Senior PHP Developer)

Behavior Driven Development в PHP и Zend Framework

Константин Кудряшов (KnpLabs, Senior Web Developer)

Разделение труда: Организация многозадачной, распределенной системы в Zend Framework с помощью Job Queue

Александр Готгельф (Magento, PHP-разработчик)

Как может помочь среда разработки при написании приложения на Zend Framework?

Николай Матвеев (JetBrains, разработчик)

Создание REST-API для сторонних разработчиков и мобильных устройств с авторизацией по протоколу OAuth 1.0

Дмитрий Чижевский (Дзен-мани, разработчик)

Толстая модель: История разработки собственного ORM

Михаил Шамин (Геометрия, ведущий разработчик)

Что такое Sphinx, зачем он вообще нужен и как его использовать с PHP (от простого индекса до поискового кластера)

Владимир Федорков (Sphinx, Director of Professional Services)

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

Торопитесь, количество мест ограничено!

Обязательно следите за последними новостями:
RSS-канал: feeds.feedburner.com/zfconf
Twitter: @zfconf
Группа ВКонтакте: vkontakte.ru/club14951507

Организатор: компания Wizartech
Партнеры: сообщество zendframework.ru и конференция ZFConf Ukraine

На сегодняшний день движок WordPress довольно интенсивно развивается. Во всяком случае изменения в версиях с 2.8 по 3.1 добавляют WP возможности полноценных CMS. Большинство из этих возможностей должны быть активированы на уровне темы (или плагина), поэтому сразу после установки WP вы работаете с ним как с обычным блоговым движком.

Вроде бы все правильно. Если какие-то возможности вам не нужны, вы их не используете. Но при этом возникает серьёзная проблема с документацией. Дело в том, большинство примеров и в Кодексе, и в других источниках, ориентированы на самый простой случай – дефолтную инсталляцию WP. Как только вы активируете дополнительные возможности ко многим рекомендациям нужно относится очень аккуратно.

Об одном из таких примеров я хочу рассказать в этой статье.

Предположим, вы решили использовать произвольные типы записей (custom post types). Создать их достаточно просто и на эту тему есть масса статей, поэтому подробно останавливаться на этом моменте не будем.

В большинстве случаев достаточно добавить следующий код в файл functions.php вашей темы.

register_post_type('gadgets',
	array(
		'labels' => array(
			'name' => __('Gadgets'),
			'singular_name' => __('Gadget'),
			//остальные переводы
		),
		'public' => true,
		'publicly_queryable' => true,
		'query_var' => true,
		'taxonomies' => array('category','post_tag'),
		'supports' => array('title','editor','author','thumbnail','excerpt','comments'),
		'rewrite' => array('slug' => 'gadgets'),
		//другие настройки
	)
);

После этого вы сможете создавать записи данного типа в админке и WordPress автоматически сформирует страницу с лентой из этих записей. Адрес у этой страницы будет следующим.

http://blog.url/gadgets

Теперь обратите внимание, что для этого типа записей мы используем такие же категории, как и для типа Post (строка 11).

Очевидно, что на странице категории мы захотим увидеть записи всех типов, но WordPress покажет только тип Post.

Происходит это потому что WP при формировании запроса к базе данных явно указывает тип поста. И по-умолчанию этот тип – post.

К сожалению, в подобных случаях не все авторы тем хотят вникать в нюансы работы движка и просто используют функцию query_posts. Я понимаю, что примеры её использования приведены в статье The Loop, но там предполагается, что вам нужно создать дополнительный цикл на странице. Т.е., например, вывести основной список записей и ещё какой-нибудь дополнительный список, с фильтрацией по определённым условиям.

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

Решается задача достаточно просто.

function prefix_pre_get_posts($query) {
     if ($query->is_category) {
          $query->set('post_type', 'any');
     }
     return $query;
}

add_action('pre_get_posts', 'prefix_pre_get_posts');

Здесь мы назначаем собственный обработчик события (action) pre_get_posts. Как следует из названия, это событие возникает непосредственно перед отправкой запроса к БД. В первом параметре обработчик получает объект типа WP_Query, который формирует запрос к базе.

Прежде всего, мы проверяем, что в данный момент создаётся страница категории (строка 2). А затем изменяем атрибут post_type. По-умолчанию он равен post. Не забывайте, что обработчик обязательно должен вернуть изменённый (или неизменённый) объект WP_Query.

Вообще, если вы планируете работать с новыми возможностями WP (произвольными типами записей, таксономиями, форматами записей), то научиться работать с WP_Query нужно обязательно. Встроенными функциями движка здесь вы не обойдетесь.

В целом, этого и следовало ожидать, чем больше возможностей у движка, тем больше времени придётся потратить на его изучение

Успехов!

Интересно почитать

Если самостоятельно учиться тяжело, то курсы программирования Киев помогут приобрести необходимые знания.

Приветствую всех! В этот раз поговорим о нынешних и будущих возможностях одного из самых популярных блоговых движков – WordPress. И заодно обсудим, корректно ли вообще называть его «блоговым».

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

И ещё одно замечание. Под «работой с контентом» я имею в виду не работу редактора, который форматирует текст с помощью TinyMCE, а работу web мастера, т.е. группировку записей по определённым признакам, их индивидуальное оформление, создание страниц архивов, навигацию и т.п.

Начнем с возможностей, которые предоставляет последний стабильный релиз WordPress (на данный момент это версия 3.0.5).

Таксономии (Custom Taxonomies)

Если верить википедии, таксономия – это учение о принципах и практике классификации и систематизации. В системах управления контентом (CMS), таксономиями называют различные инструменты для группировки информации.

И обычно их используют для группировки записей по каким-нибудь признакам. Если проводить аналогию с русским языком, то таксономии в WP можно считать прилагательными (отвечают на вопрос «какой? какая?»), т.е. они так или иначе характеризуют запись.

По-умолчанию, WordPress предоставляет три таксономии – категории, теги и ссылки. Но, начиная с версии 2.3 появилась возможность создавать собственные таксономии, правда на все 100% она не используется до сих пор (об этом чуть ниже).

Создать новую таксономию можно с помощью функции register_taxonomy. Для её вызова обычно используется событие (action) init.

Например, если вы создаёте группу записей о каких-то товарах и хотите группировать их по цвету, то можно использовать следующий код.

function color_init() {
	register_taxonomy(
		'color',
		'post',
		array(
			'label' => __('Color'),
			'labels'=>array(
				'name'=>__('Colors'),
				'singular_name'=>__('Color'),
				...
			),
			'sort' => true,
			'args' => array('orderby' => 'term_order'),
			'public'=>true,
			'show_in_nav_menus'=>true,
			'show_ui'=>true,
			'show_tagcloud'=>true,
			'hierarchical'=>true,
			'rewrite' => array('slug' => 'color'),
		)
	);
}
add_action( 'init', 'color_init' );

Добавить этот код можно в файл functions.php темы или вызвать из плагина.

Как видите, большинство параметров у функции register_taxonomy – это различные настройки. Если хотите, можете почитать их подробное описание.

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

Если таксономия иерархическая, то выглядеть он будет так:

а если таксономия обычная, то так:

Кроме того, в левом меню в группе Post появится ссылка на страницу редактирования таксономии.

Как видите, возможности у ваших таксономий будут точно такие же как и у стандартных тегов и категорий.

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

Примечание. Вместо текста, выделенного красным, нужно подставить название соответствующей таксономии.

Поддержка такой иерархии шаблонов движком позволяет избавиться от длинных оператов switch в теме.

Также существует API для работы с таксономиями. Например, вы можете создать облако тегов с помощью функции wp_tag_cloud, вывести список терминов с помощью the_terms или использовать таксономии для фильтрации записей (функция query_posts).

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

Лучше рассмотрим ограничения, которые имеет система таксономий в WordPress.

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

Т.е. в этом случае придется отказаться от использования стандартного интерфейса, создать свой meta-box (функция add_meta_box) и выводить в нём группу радиокнопок с терминами.

Ещё одна проблема связана с тем, что таксономии не всегда являются очевидным способом группировки контента.

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

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

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

Типы записей (Custom Post Types)

Эта возможность появилась в версии 3.0. По большому счёту её можно тоже считать таксономией, но и с точки зрения пользователя, и с точки зрения разработчика реализация этой возможности отличается от таксономий, поэтому не будем их путать.

Создать новый тип записи не сложнее чем таксономию. Используется функция register_post_type.

add_action('init', 'create_post_type');

function create_post_type() {
	register_post_type('video',
		array(
			'labels' => array(
				'name' => __('Videos'),
				'singular_name' => __('Videos'),
				...
			),
			'public' => true,
			'publicly_queryable' => true,
			'show_ui' => true,
			'query_var' => true,
			'capability_type' => 'post',
			'hierarchical' => false,
			'menu_position' => null,
			'taxonomies' => array('category','post_tag'),
			'supports' => array('title','editor','author','thumbnail','excerpt','comments'),
		)
	);
}

Как видите, используется событие (action) init, а в параметрах задаются основные настройки нового типа записей. Например, перечень полей в форме создания записи (supports), список таксономий (taxonomies) и т.д.

После создания нового типа записей в левом меню админки появится новая группа ссылок для управления записями данного типа.

Обратите внимание, вы можете «привязывать» любые таксономии к любым типам записей.

Точно также как и в случае с таксономиями, WordPress имеет поддержку типов записей как на уровне темы, так и на уровне API.

Порядок использования шаблонов темы выглядит следующим образом.

А примеры работы с типов записей и перечень соответствующих функций вы найдете на этой странице.

В каких случаях лучше использовать типы записей, а не таксономии?

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

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

Тем не менее, появление и широкое использование этих возможностей создало дополнительную проблему.

Давайте вспомним, почему WordPress пользуется такой популярностью?

Правильно, из-за большого количества практически бесплатных тем и плагинов.

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

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

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

Речь, конечно, о форматах записей (Post Formats).

Форматы записей (Post Formats)

Эта возможность появится в версии 3.1. На данный момент чтобы её потестировать вам нужно скачать development версию WordPress. Я использовал 3.1-RC4-17441.

Рассмотрим, что они из себя представляют.

Одно из их отличий от таксономий постов и типов записей заключается в том, что форматы не нужно создавать. Нужно просто включить их поддержку (используется функция add_theme_support).

add_action('after_setup_theme', 'add_post_formats');
function add_post_formats() {
	add_theme_support( 'post-formats', array( 'aside', 'gallery', 'quote' ) );
}

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

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

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

Для этого нужно будет зарегистрировать таксономию с названием post_format и добавить в неё термины вида post-format-название_формата (например, post-format-aside). Для добавления термина используется функция wp_insert_term.

Естественно, в теме вы сможете определить формат текущей записи и соответствующим образом изменить её вид.

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

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

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

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

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

Поэтому, хочу пожелать его авторам удачи!

Интересно почитать

Хотите научиться делать красивые сайты? Курсы flash дадут знания для начала работы.

Подготовка 3 ндфл за обучение для получения социального вычета в кратчайшие сроки

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

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

Прежде всего, разберемся, о каких именно стилях идет речь.

Вообще содержимое виджета и его разметка определяются разработчиком. Но для того, чтобы виджеты красиво вписывались в дизайн темы предусмотрены 4 параметра, которые должны использовать разработчики виджетов (по крайней мере в теории ).

Эти параметры задаются разработчиком темы при создании сайдбара. Например, так:

register_sidebar(array(
	...,
	 'before_widget' => '<li id="%1$s" class="widget %2$s">',
	 'after_widget'  => '</li>',
	 'before_title'  => '<h2 class="widgettitle">',
	 'after_title'   => '</h2>'
));

Разработчики виджетов обычно используют их внутри метода widget. Взгляните на фрагмент примера из кодекса.

class My_Widget extends WP_Widget {
...
	function widget($args, $instance) {
		extract( $args );
		$title = apply_filters('widget_title', $instance['title']);
		?>
		<?php echo $before_widget; ?>
			  <?php if ( $title )
				echo $before_title . $title . $after_title; ?>
			  Hello, World!
		  <?php echo $after_widget; ?>
		<?php
	}
}

Как видите, в параметре before_widget использованы две переменные: %1$s и %2$s (их значения подставляются с помощью функции sprintf). В результате для текстового виджета получим что-то вроде.

<li id="text-3" class="widget widget_text">

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

Использовать параметр id для этих целей вряд ли получится. Он создается при вставке виджета в сайдбар и не изменяется при перемещении виджета.

Решение довольно простое.

Добавьте в файл functions.php следующий код.

function custom_widget_counter($params) {
	global $widget_counter;

	if ($params[0]['id'] == 'my_sidebar') {
		$widget_counter++;
		If ($widget_counter % 2 == 0) {
			$params[0]['before_title'] = '<h2 class="even">';
		}
		else {
			$params[0]['before_title'] = '<h2 class="odd">';
		}
	}
	return $params;
}

add_filter('dynamic_sidebar_params','custom_widget_counter');

«Фокус» заключается в использовании фильтра dynamic_sidebar_params, который позволяет изменять параметры, указанные при создании сайдбара (функция register_sidebar).

Установка атрибута class выполняется функцией custom_widget_counter (её имя мы указываем при добавлении фильтра). В первом параметре эта функция получает массив с текущими настройками.

Затем мы объявляем глобальную переменную $widget_counter, которая используется в качестве счетчика виджетов в сайдбаре.

Учитывая, что сайдбаров может быть несколько, проверяем id сайдбара и если он равен my_sidebar, устанавливаем параметр before_title. Для этого достаточно просто присвоить соответствующему элементу массива новое значение.

Если текущий виджет четный, устанавливаем <h2 class="even">, в противном случае – <h2 class="odd">.

И, самое главное, нужно обязательно вернуть (return) изменённый массив, иначе наши изменения применены не будут.

После этого остаётся только добавить соответствующие CSS правила в таблицу стилей.

И ещё раз хочу обратить ваше внимание. Этот метод будет работать для виджетов, которые разработаны в соответствии с рекомендациями кодекса (используются переменные before_widget, before_title и т.д. в разметке виджета).

Если есть вопросы или замечания пишите, буду рад обсудить

До встречи!

Интересно почитать

Нужно продвижение ресторана? Попробуйте муляжи блюд от японских дизайнеров

Качественные и удобные промо сумки на заказ от швейного цеха

Приветствую!

Сегодня выложил очередное обновление WordPress плагина Terms Descriptions.

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

Т.е. принцип довольно простой и поставленная задача решается в полном объеме. Но предусмотреть всё практически не возможно, и пользователи постоянно предлагают хорошие идеи.

Последнее усовершенствование предложил Андрей Х.

Идея заключается в добавлении атрибута class ссылкам, которые создаёт плагин.

Что это даёт?

1) Возможность выделить ссылки с помощью CSS стилей.

2) Возможность обеспечить единый внешний вид ссылок, если для остальных ссылок уже установлен атрибут class.

Добавить атрибут несложно.

Обновите плагин, в админке появится дополнительное поле.

Значение атрибута нужно указать в поле "Атрибут Class для ссылок".

После этого, ссылки будут выглядеть так.

<a href="http://site.domain" class="ext_link">Текст ссылки</a>

Не хотите пользоваться этой возможность, просто оставьте поле пустым.

Ещё одно изменение касается русской локализации. За это отдельное спасибо Андрей Х, который не поленился и исправил мои ошибки.

Кстати, если есть желание и возможность, вы можете перевести этот плагин на свой язык. Много времени это не займет. Плагин содержит менее 40 текстовых фраз. Для перевода удобнее всего использовать программу Poedit. Затем просто пришлите файл переводов мне.

Надеюсь, нововведения будут вам полезны.

Удачи!

Приветствую всех читателей!

Сегодня хочу просто поделиться хорошей новостью.

27 ноября (суббота) в Киеве пройдет совместная конференция ZFConf Ukraine & MageConf.

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

Тут нужно отдать должное организаторам. Я не знаю как они уговаривали спонсоров и искали докладчиков, но, думаю, это было непросто

Конференция будет длиться один день и пройдет в три потока: Zend Framework, PHP, Magento.

Доклады будут на следующие темы.

1. Встречайте Zend Framework 2.0
Александр Веремьев / Zend Framework Core команда (Zend Technologies)

2. Эволюция ZF: архитектура, шаблоны, рефакторинг
Виктор Фараздаги / Component Maintainer и Contributor ZF 2.0 (4C)

3. Юнит тестирование в Zend Framework 2.0
Ростислав Михайлив / Chief Developer / Software Architect (Gadu-Gadu)

4. Хранение, обработка и отдача статики с использованием \Zend \File. Опыт социальной сети starlook.ru
Кирилл Мокевнин / Senior developer (undev)

5. Чуть сложнее чем Singleton: аннотации, IOC, АОП
Кирилл Чебунин / Senior PHP Developer (Альпари)

6. Doctrine 2
Валерий Рабиевский / Team leader (stfalcon.com)

Насколько я понял, список докладов не окончательный, и будет дополняться.

Для участия в конференции достаточно зарегистрироваться.

В общем, событие обещает быть интересным.

До встречи!

Приветствую всех!

Я всё-таки собрался и доделал плагин Terms Descriptions

Изменений в новой версии не много, но об одном из них меня просили уже несколько раз.

Речь о поддержке словоформ, т.е. нескольких вариантов написания одного и того же термина.

Например, так яблоко|яблоки|яблок и т.д.

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

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

Поэтому не лишним будет использовать настройку "Преобразовывать первые … терминов".

Обратите внимание, что все словоформы считаются одним термином. Т.е. жесткий диск|винчестер|HDD – один термин. И если в настройках указать "Преобразовывать первые 2 термина", то плагин поставит только две ссылки (на те словоформы, которые встретятся первыми в тексте поста).

Важно!

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

Ещё одна новость касается размещения плагина.

Я перенёс его на официальный сайт WordPress. Так что теперь будут работать автоматические обновления.

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

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

Удачного обновления!

Интересно почитать

Шьем сумки из хлопка и ПВХ, цены – фантастика