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

Сейчас файлы обновляются полностью автоматически и обычно быстрее чем я успеваю начать работу При этом частично устраняется зависимость от интернета, т.к. файлы хранятся и на винчестере, и на серверах Dropbox'а.

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

1) Безопасность

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

Нужно четко понимать, что как только вы выкладываете файлы на какой-нибудь online хранилище, то в один «прекрасный» момент они могут оказаться доступны всем желающим. И не важно по какой причине это произойдет, из-за проблем с самим сервисом или из-за ваше халатности, решать эти проблемы в любом случае придется вам. Кстати, есть интересный пост на хабре на эту тему.

В общем, файлы с конфиденциальными данными нужно шифровать. Я для этих целей использую 2 программы: KeePass для хранения паролей и TrueCrypt для файлов.
С KeePass всё достаточно просто, сбрасываете portable версию в папку Dropbox'а и можно работать. А при использовании TrueCrypt нужно учесть, что в Dropbox вы будете хранить образ зашифрованого диска (это один файл) и этот файл будет синхронизироваться целиком после любых изменений. Поэтому не делайте его очень большим. Если файлов много, лучше создайте несколько зашифрованных дисков.

2) «Расшаривание» папок (Shared folders)

Для использования ваш коллега должен быть зарегистрирован на Dropbox'е. А расшарить папку достаточно просто, в контекстном меню для нужной папки выбираете Dropbox -> Share this folder.

Нужно будет ввести email пользователя Dropbox, которому вы хотите дать доступ к файлам.

3) Использование в качестве галереи

Если в расшареной папке есть картинки, то при просмотре через web интерфейс, Dropbox автоматически создаст галлерею. Примерно также, как это делают сервисы вроде Picasa и Яндекс.Фотки. Возможностей у последних, конечно больше, но иногда нужно показать парочку фотографий человеку, которому вы не хотите давать ссылку на ваш профиль в этих сервисах.

4) Загрузка и раздача торрентов

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

5) Использование как файлообменника

Использовать Dropbox для раздачи больших файлов не получится, во всяком случае, бесплатную версию. Вам просто не хватит места. Тем не менее, если нужно передавать файлы размером в несколько десятков или сотен мегабайт, то Dropbox подходит отлично. Копируете их в папку Public и в контекстном меню выбираете Dropbox -> Copy public link.

После этого передаете ссылку нужным людям. Главный плюс такого подхода – вашим знакомым не придётся изучать рекламные ролики файлообменников в поисках кнопки Download

6) Хранение репозиториев, настроек программ

У многих программ, особенно кроссплатформенных, настройки хранятся в виде обычных файлов, и вам ничто не мешает синхронизировать их с помощью dropbox. Сюда относятся: конфиги серверов, профили браузеров, save'ы игрушек и т.п. Конечно, могут быть нюансы. Например, если файлы должны быть расположены в строго определённой папке, которая находится за пределами папки dropbox, то их придётся копировать вручную, но, по крайней мере, удобный инструмент для создания бекапов у вас будет. И, конечно, можно довольно быстро получить нужные настройки на новом компьютере.

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

7) Восстановление файлов и просмотр изменений

Эти возможности доступны через web интерфейс. Пользоваться мне ими не приходилось и, надеюсь, не придётся Тем не менее, отображаются удалённые файлы правильно.

Альтернативные сервисы для хранения и синхронизации файлов

За последнее время отрылось три сервиса практически полностью аналогичных Dropbox. Причём, практически одновременно. Это:

1) Google Drive;
2) Яндекс.Диск;
3) SkyDrive от Microsoft.

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

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

В общем, будет интересно!

При подготовке статьи использовались:

The Cleverest Ways to Use Dropbox That You’re Not Using
4 Unique and Cool Ways To Use Dropbox
5 Creative Uses for Dropbox

Идея написать этот пост у меня появилась после выхода статьи Random Redirection In WordPress в Smashing magazine.

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

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

Для начала рассмотрим, как работает стандартный вариант.

Для этого немного перепишем функцию, приведённую в Smashing magazine.

function show_random_posts($count = 3) {
     $start = microtime(true);

     $args = array(
         'numberposts' => $count,
         'orderby' => 'rand',
         'post_type' => 'any',
     );

     $rnd_posts = get_posts( $args );

     foreach ( $rnd_posts as $post ) {
          echo '<p><a href="'.get_permalink($post->ID).'">'.$post->post_title.'</a></p>';
     }

     $stop = microtime(true);
     echo '<p>Затраченное время: '.($stop - $start).'</p>';
}

Здесь мы выбираем заданное количество случайных записей ($count) с помощью встроенной функции get_posts. Эта функция в качестве параметра получает массив с настройками поиска. В данном случае это:
numberposts – количество записей, которые должен вернуть запрос;
orderby – сортировка, в данном случае – rand – случайным образом;
post_type – типы постов – any – все.

Затем в цикле (строки 12-14) просто выводим список полученных постов.

Кроме того, в переменных $start и $stop сохраняем время начала и завершения кода.

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

Но что именно происходит при вызове get_posts?

WP делает один запрос к БД, который возвращает все необходимые данные.

SELECT   wp_posts.* FROM wp_posts  WHERE 1=1  AND wp_posts.post_type IN ('post', 'page', …) AND (wp_posts.post_status = 'publish')  ORDER BY RAND() DESC LIMIT 0, 3;

Просто и элегантно

Но известно, что функция RAND() снижает скорость запроса.

Попробуем переписать нашу функцию так, чтобы получить тот же результат, но обойтись без RAND().

У меня получился следующий код

function show_random_posts_optimized($count = 3) {
     $start = microtime(true);

     $args = array(
         'numberposts' => -1,
         'fields' => 'ids',
         'post_type' => 'any',
     );

     $random_posts_ids = get_posts($args);
     $rnd_posts = array_rand($random_posts_ids, $count);

     foreach ( $rnd_posts as $post_index ) {
          $id = (int)$random_posts_ids[$post_index];
          $post = get_post($id);
          echo '<p><a href="'.get_permalink($post->ID).'">'.$post->post_title.'</a></p>';
     }

     $stop = microtime(true);
     echo '<p>Затраченное время: '.($stop - $start).'</p>';
}

Идея следующая. Сначала получаем ID всех постов. Обратите внимание, что если вы не укажите параметр 'fields' => 'ids', WordPress "вытянет" все посты целиком. Очень неприятная ошибка, в разы увеличивает потребление памяти.

На этом этапе выполняется запрос

SELECT   wp_posts.ID FROM wp_posts  WHERE 1=1  AND wp_posts.post_type IN ('post', 'page', ...) AND (wp_posts.post_status = 'publish')  ORDER BY wp_posts.post_date DESC ;

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

И в цикле получаем данные постов с помощью get_post. На этом этапе выполняются запросы вида

SELECT * FROM wp_posts WHERE ID = 23 LIMIT 1;

Т.е. если мы выводим три случайных поста, то функция show_random_posts_optimized будет выполнять 4 запроса для получения информации о постах, а show_random_posts – всего 1.

Но проверим время выполнения.

Первый эксперимент я провел на блоге с ~40 постами.
Результаты:

show_random_posts - 0.021620035171509 с
show_random_posts_optimized - 0.0076930522918701 с

В абсолютном выражении цифры небольшие, но разница заметная – в 2.8 раза.

Теперь посмотрим, что произойдет на реальном блоге с 1700+ постами.

Результаты:

show_random_posts - 0.49169611930847 с
show_random_posts_optimized - 0.039859056472778 с

Как видите, теперь первая функция работает в 12.3 раза медленнее.

Выводы сделать несложно.

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

А найти проблемный запрос довольно просто. Установите BlackBox Debug Bar или аналогичный плагин и он вам выведет список всех выполненных запросов и затраченное на них время.

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

Happy coding

21 апреля в Москве состоится конференция для веб-разработчиков – ZFConf 2012. Как несложно догадаться из названия, мероприятие в основном будет посвящено одному из самых популярных на сегодняшний день фреймворку – Zend Framework, но также будут доклады о базах данных, архитектуре веб-приложений, очередях сообщений и деплойменте.

Среди докладчиков будут: Enrico Zimuel из Zend Framework Core Team, Виктор Фараздаги, Александр Веремьев, Алексей Качаев и другие специалисты.

Посмотреть список докладов и зарегистрироваться можно на официальном сайте конференции.

Доклады

Zend Framework 2, a quick start
Enrico Zimuel (Zend Technologies, Zend Framework Core Team)

Code Generation и Scaffolding в Zend Framework 2
Виктор Фараздаги (Simple Square, Senior Developer)

Реализация доступа к СУБД IBM DB2 посредством встраиваемого SQL
Александр Веремьев (Zend Framework contributor)

Распределенные сетевые приложения c Zend Framework 2 и ZeroMQ
Алексей Качаев (Сogniance, Senior Software Engineer)

Dependency Management в PHP и Zend Framework 2
Кирилл Чебунин (Creara, Senior PHP Developer)

Кеш без промахов средствами Zend Framework 2
Никита Грибалев (Nival, Lead PHP Developer)

Проектирование архитектуры, внедрение и организация процесса разработки на примере собственного проекта на основе ZF
Антон Великанов (Sand Sign, Founder&CEO)

Capistrano для деплоймента PHP-приложений
Роман Лапин (Evercode Lab, Senior Developer)

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

Новости о конференции вы найдете в:

• Хабраблог: habr.ru/company/wizartech/blog/
• Facebook: facebook.com/groups/143714275748061/
• ВКонтакте: vk.com/zfconf
• RSS: feeds.feedburner.com/zfconf
• Twitter: twitter.com/zfconf

В последнее время библиотеки, которые добавляют новые возможности CSS, становятся всё более популярными. Наиболее известные из них – LESS и SASS (SCSS). Какое-то время назад я пытался выбрать наиболее подходящую из них для собственных целей, но, в конечном итоге, понял, что разница минимальна и лучше потратить время на что-нибудь более полезное

Тем не менее, одно отличие между LESS и SASS всё же есть. В дистрибутиве LESS есть скрипт less.js, который преобразует .less файлы в .css прямо в браузере. Это очень удобно использовать при разработке, т.к. вам будет достаточно обновить страницу, чтобы увидеть изменения. Но для продакшена такой вариант не подходит по нескольким причинам.

Во-первых, увеличивается время загрузки страницы, т.к. посетителям будет отправляться дополнительный скрипт.
Во-вторых, на преобразование стилей уходит какое-то время, правда, less.js достаточно «умный» и кэширует стили в localStorage.
В-третьих, посетители с отключённым JavaScript вообще не увидят стилей.

Избежать всех этих проблем можно просто преобразовав файлы на сервере. В этом случае посетитель получит обычный css файл, и вообще не будет знать, что вы использовали LESS.

На официально сайте для преобразования LESS файлов предлагается использовать Node.js. Но устанавливать его только ради LESS, по-моему, перебор. Кроме того, очень удобно, когда все операции для подготовки проекта к публикации на продакшн сервере можно выполнить одной командой.

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

Среди стандартных задач Phing подходящей вы не найдете, но существует проект My Custom Phing Tasks в который входят все необходимые библиотеки.

Установка

1. Скачайте и распакуйте архив с проектом.

2. Скопируйте папку rych (из архива phing-tasks) в папку, в которую вы установили Phing.

3. Импортируйте задачу LessCompilerTask. Для этого, добавьте в ваш build файл строку

<taskdef name="lessc" classname="phing.rych.tasks.LessCompilerTask" />

Обратите внимание, что путь к файлу указывается не через слеш, а через точку, начиная с папки в которую установлен phing. Если вы ошибётесь на этом шаге, то при запуске сборки увидите сообщение о том, что файл LessCompilerTask.php не найден.

4. Создайте задачу для сжатия файлов. Для начала рассмотрим стандартный пример из описания phing-tasks.

<target name="compile-less" description="Compile LESS to CSS">
    <lessc targetdir="path/to/published/css">
        <fileset dir="path/to/less/sources">
            <include name="*.less" />
        </fileset>
    </lessc>
</target>

Как видите, для работы задачи нужно указать исходную папку, папку в которой будут размещены css файлы и шаблон для поиска less файлов. Это полностью рабочий пример, но если его немного изменить работать будет немного удобнее. Например:

<property name="LESS_DIR" value="path/to/less/sources" />
<property name="CSS_DIR" value="path/to/published/css" />

<target name="compile-less" description="Compile LESS to CSS">
    <lessc targetdir="${CSS_DIR}">
        <fileset dir="${LESS_DIR}">
            <include name="**/*.less" />
        </fileset>
    </lessc>
</target>

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

*.less – означает, что будут найдены все файлы с расширением less, которые находятся в папке, указанной в атрибуте dir тега fileset.

**/*.less – означает, что будут найдены все файлы с расширением less, которые находятся в папке, указанной в атрибуте dir тега fileset и во всех вложенных папках.

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

После этого вам достаточно просто запустить сборку проекта и phing создаст все необходимые css файлы.

Успехов!

P.S. Кстати, обратите внимание в проект My Custom Phing Tasks входит ещё одна задача, очень подходящая для следующего шага

С недавних пор этот блог опять стали одолевать спамеры. Не знаю с чем это связано, больше года всё было относительно спокойно. Проскакивало по несколько спамерских комментариев в неделю, явно написанных людьми, а не ботами, и всё. А тут по 10-20 требкеков в день. Удалить их, конечно, не сложно, но надоедает и раздражает, к тому же трекбеки явно ставились автоматически, т.е. спамер своё время на них не тратил.

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

Поэтому я решил закрыть трекбеки для всех постов старше 2-х месяцев. Ставить специальный плагин для решения этой задачи нет никакой необходимости, всё можно сделать с помощью несложного SQL запроса и cron'а.

Теория

В WordPress все посты хранятся в таблице wp_posts (префикс wp_ может быть другим). В этой таблице есть поле ping_status, которому можно присвоить одно из двух значений: «open» или «closed». Как несложно догадаться по названию, значение «closed» отключает трекбеки к данном посту.

Теперь нужно определиться с датами. MySQL поддерживает довольно много функций для работы со временем и датами. Нам потребуются:
1) CURDATE – возвращает текущую дату;
2) DATE_SUB – вычитает даты;
и выражение INTERVAL ... DAY – позволяет указать интервал с заданным количеством дней.

Дата последнего изменения поста хранится в поле post_modified (таблицы wp_posts).

Формируем запрос

UPDATE wp_posts SET ping_status="closed" WHERE post_modified < DATE_SUB(CURDATE(), INTERVAL 60 DAY)

Как видите, это обычный UPDATE запрос, который установит полю ping_status значение «closed» для всех записей у которые последний раз обновлялись более 60-ти дней назад.

Кстати, аналогичным способом можно закрыть и комментарии. Для этого нужно установить значение «closed» для поля «comment_status».

Остаётся настроить периодический запуск этого запроса

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

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

mysql --default-character-set=utf8 --user=user_name --password=user_password db_name < path_to/block_trackbacks.sql

Здесь block_trackbacks.sql – имя файла в котором записан наш запрос.

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

Результаты

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

Успехов!

Сегодня мы рассмотрим небольшой пример оформления скроллбара для браузеров на движке WebKit (Chrome, Safari).

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

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

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

Теперь рассмотрим, каким образом можно изменить внешний вид скролла

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

Как видите, все псевдоклассы имеют префикс -webkit-.
Кроме перечисленных на картинке, есть ещё два псевдокласса:
::-webkit-scrollbar-corner – отвечает за оформление квадрата в месте соприкосновения вертикального и горизонтального скролла;
::-webkit-resizer – используется для скроллбаров текстовой области, размеры которой можно изменять.

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

Обычные :enabled, :disabled, :hover и :active и специальные:

:horizontal – применяется для частей скроллбара, которые расположены горизонтально;

:vertical – применяется для частей скроллбара, которые расположены вертикально;

:decrement – применяется к участкам полосы прокрутки и кнопкам при перемещении окна просмотра вверх или влево;

:increment – применяется к участкам полосы прокрутки и кнопкам при перемещении окна просмотра вниз или вправо;

:start – применяется к кнопкам и участкам полосы прокрутки. Показывает находится ли объект выше (левее) ползунка;

:end – применяется к кнопкам и участкам полосы прокрутки. Показывает находится ли объект ниже (правее) ползунка;

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

:single-button – применяется к кнопкам и участкам полосы прокрутки. Используется для того, чтобы определить, является ли кнопка одинарной. Для полосы прокрутки этот псевдокласс показывает граничит ли она с одинарной кнопкой;

:no-button – применяется к участкам полосы прокрутки и показывает, касается ли она края скроллбара (например, если нет кнопок на краях скроллбара);

:corner-present – применяется к участкам полосы прокрутки и показывает, присутствует ли угловая область скроллбара (квадрат на стыке горизонтального и вертикального скроллбаров);

:window-inactive – применяется ко всем элементам скроллбара и показывает является ли окно к которому относится данный скроллбар активным.

Переходим к нашему примеру

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

Займёмся оформлением.

Для начала, зададим общую ширину скроллбара:

::-webkit-scrollbar{
    width:12px;
}

Теперь займёмся оформлением полосы прокрутки (светлосерый фон, серая граница, делаем границу чуть толще с левой стороны):

::-webkit-scrollbar-thumb{
    border-width:1px 1px 1px 2px;
    border-color: #777;
    background-color: #aaa;
}

При наведении курсора (:hover) на полосу прокрутки делаем её более тёмной:

::-webkit-scrollbar-thumb:hover{
    border-width: 1px 1px 1px 2px;
    border-color: #555;
    background-color: #777;
}

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

::-webkit-scrollbar-track{
    border-width:0;
}

При наведении курсора на ползунок, делаем его темнее и добавляем границу.

::-webkit-scrollbar-track:hover{
    border-left: solid 1px #aaa;
    background-color: #eee;
}

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

Успехов!

На мой взгляд, 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 – Terms Descriptions. Скачать вы её можете на отсюда. Либо, если вы уже используете этот плагин, через систему обновлений WP.

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

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

Примечание. Посмотреть описание предыдущих версий плагина можно в статье: Плагин WordPress: Terms Descriptions.

Рассмотрим по порядку все основные изменения.

Интерфейс

Переделан практически полностью. Надеюсь, будет удобнее

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

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

На первой странице (рис.1) размещена форма добавления новых терминов и таблица с уже существующими терминами.

Рис.1.

Принцип создания термина остался тем же, но форма изменилась. Во-первых, сейчас добавлена нормальная поддержка произвольных типов записей WP (custom post types). Во-вторых, для выбора записи (поста) используется поле с автокомплитом, а не выпадающий список с заголовками постов (рис. 2). Как оказалось, выпадающий список практически бесполезен, если блог содержит несколько сотен записей.

Рис. 2.

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

На второй странице находится форма со всеми основными настройками блога (рис. 3).

Рис. 3.

На третьей странице (рис. 4) – инструменты для экспорта/импорта данных плагина и для пакетной загрузки терминов.

Рис. 4.

Хранение терминов

Способ хранения и работы с терминами также был существенно переработан. Поэтому после обновления плагина в админке появится сообщение с кнопкой «Обновить БД». Я настоятельно рекомендую сделать резервную копию базы перед выполнением этой операции.

Причин для внесения этих изменений было две.

1) Оказалось, что часть пользователей создаёт большие списки терминов. И для работы с ними целесообразно создать отдельную таблицу.

2) Функция get_permalink, которая используется в WP для формирования ЧПУ, при определённых структурах ссылок оказывается довольно ресурсоемкой. Чтобы исключить её использование при формировании страниц блога, формирование ссылки теперь осуществляется один раз при создании термина. А для того, чтобы плагин правильно работал после изменения структуры URL, добавлена возможность пакетного обновления ссылок из админки. Кнопка «Обновить ссылки» находится справа над таблицей терминов (рис. 1). Т.е. если меняете структуру ЧПУ не забудьте обновить ссылки терминов.

Парсеры

Одними из самых неприятных проблем, с которыми я столкнулся при поддержке плагина, были конфликты с другими плагинами.

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

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

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

Сейчас в дистрибутиве плагина есть два парсера.

1) Простой. Ставит ссылку на текст, который полностью совпадает с одним из терминов.

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

Переключение между парсерами осуществляется на странице Термины->Настройки (рис. 3).

Пакетная загрузка терминов

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

Форма пакетной загрузки находится на странице Термины -> Инструменты.

Формат добавления терминов следующий. Каждый термин должен быть записан в отдельной строке. Можно указать несколько словоформ для терминов. Разделитель словоформ – символ |. Т.е. точно так же, как и при добавлении нового термина. Но есть важное отличие, в качестве последней словоформы нужно указать ссылку. Ссылкой может быть обычный URL (наличие http:// обязательно) или id поста (пост нужно создать до добавления терминов).

Например,

яблоко|яблоки|яблок|яблочный|http://apples.com
груша|груш|груши|24
и т.д.
здесь, 24 – id поста на который нужно поставить ссылку.

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

Заключение

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

Успехов!

Полезные ссылки.

Закажите VPS Start и выше и получите 30$ + панель ISP в подарок! Отзывы – zapili.net

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 протокол и использовать все возможности движка при удалённой публикации постов.

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

Успехов!

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

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

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

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

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

HTML разметка такой ссылки может выглядеть следующим образом.

<a class="delete" href="http://www.simplecoding.org/script.php?action=delete_object&object_id=1">Удалить</a>

Как видите, ссылка содержит два параметра (action и object_id), значения которых PHP скрипт сможет получить из массива $_GET.

Теперь, мы хотим выполнить удаление объекта с помощью AJAX запроса. Изменять ради него ссылку нет никакой необходимости. Просто назначаем обработчик для события click.

$('a.delete').click(function() {
  return false;
});

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

В обработчике события click получить значение атрибута href ссылки можно следующим образом.

$(this).attr('href')

Затем нужно найти в этой строке параметры. Тут есть два варианта.

1) Если вам достаточно параметров, указанных в атрибуте href и вы не хотите их изменять, то просто передать методам $.ajax (или $.post, или $.get) строку с параметрами запроса.

Т.е. код будет выглядеть примерно так

var params = $(this).attr('href').split('?');
$.post('ajax_delete.php', params[1], function(response) {
    console.log(response);
} );

Здесь мы с помощью метода split разбили запрос на две части (по знаку вопроса), и передали методу $.post второй элемент массива params. Для данного примера он выглядит так
action=delete_object&object_id=1

2) Если перед отправкой AJAX запроса нужно изменить/удалить/добавить какие-то параметры, то удобнее всего преобразовать строку с параметрами в хеш.

Для этих целей существует специальный плагин – parseQuery

Использовать его можно так.

var params = $.parseQuery($( this ).attr( 'href' ).split('?'));

В результате вы получите хеш

{
	action: delete_object,
	object_id: 1
}

Код отправки AJAX запроса при этом не изменяется. Точно также передаёте переменную params во втором параметре метода $.post.

В заключение посмотрите код обработчика целиком.

$(document).ready(function() {
	$('a.delete').click( function() {
		var params = $(this).attr('href').split('?');
		$.post('ajax_delete.php', params[1], function(response) {
			console.log(response);
		});
		return false;
	});
});

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

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

Успехов!

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

Платежный модуль Robokassa для Magento с поддержкой.

Нужна фотокнига? В наличие фотокниги образцы, множество видов дизайна и верстки