Если у вас вдруг появилась необходимость сохранять html код страницы/записи в админке WordPress, но вы испытываете трудность от того, что расширенный редактор вырезает определенный код из исходного при переходе на него с режим HTML, то следующий хак вам поможет это исправить :)

Честно говоря, достаточно редко такое необходимо, но тем не менее…

В общем, открываете functions.php шаблона или главный файлы своего/любого плагина и вставляете следующий код:

add_action('init', 'hack_visual_editor');
function hack_visual_editor(){
    if( is_admin() && !empty($_GET['post']) && $_GET['action'] == 'edit' ){
        $slug = get_post_field( 'post_name', $_GET['post'] );
        if( $slug == 'sitemap' ) {
            global $current_user, $wp_rich_edit;
            $current_user->data->rich_editing = 'false';
            $wp_rich_edit = false;
        }
    }else{
        return false;
    }
}

Как видите, все достаточно просто – мы обманываем WordPress, заставляя его думать, что на текущей странице (в данном случае на странице редакторования записи со слагов 'sitemap') для текущего пользователя запрещен режим Визуального редактора.

Естественно, можно запрещять по любому параметру (например, ID или названию поста), для этого вам надо отредактировать строчку if( $slug == 'sitemap' ) {.

 Работая над своим плагином BuddyPress Group Chat (BGC), я столкнулся с проблемами производительности ajax запросов – она оставляет желать лучшего. К сожалению, достаточно тяжело быстро и бесплатно внедрить технологию, которая не будет так нагружать ваш сервер, так что пришлось искать пути ускорения ajax запросов в WordPress.

Собственно, вариант, который я вам предлагаю, на самом деле известен достаточно давно, просто нигде толком не описан. Фактически у нас 2 альтернативы:

1. использование движка WP для обработки всех ajax запрос (и тут описано, как это делать правильно);
2. использование своего собственного голого php файла, в котором мы делаем все, что нам нужно.

Первый вариант хорош, когда нужно получить доступ к WordPress API (все его плагины, расширения, темы, классы – вроде $wpdb для взаимодействия с базой). Но у него огромный минус – при каждом ajax запросе вы полностью загружает весь движок – а это минимум 25Mb памяти сервера + постоянная чрезмерная (в сравнении с необходимостью) нагрузка.

Второй варинт как раз наоборот – отлично показывает себя по скорости и потребляемой памяти (все зависит от вашего кода, может быть всего несколько миллисекунд и пару килобайт соответственно). Но минус в том, что вы полностью изолированы от WP – нет ничего, что с ним связано, даже данных для коннекта к базе (по-крайней мере, получить их уже маленькая проблемка). Именно поэтому 99% всех шаблонов/плагинов используют первый вариант.

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

Что мы делаем:

1) создаем файл ajax.php (например) в нужно нам месте – если свой сайт, не плагин, то можно даже в корне сайта, если плагин – то в папке плагина было бы логично его разместить;

2) прописываем в начале этого файла:

define('SHORTINIT', 'faster');

3) далее подключаем файл wp-config.php (к примеру, указанный в пункте 1 файл у нас лежит в корне сайта):

require('./wp-config.php');

Это все. Мы загрузили WP – но далеко не весь. Из его 20 метров только 2 оказались в памяти, повторюсь – нет таксономии, почти всего из папки /wp-includes/, локализации, нет всей папки /wp-content/. Зато у нас есть и работает глобальный класс $wpdb. И некоторые другие вещи, которые можно использовать.

Вывод

Все запросы будут работать в 10 раз быстрее (проверено тестами), потребляемая память такого обрезанного WP будет на уровне 2-2,2 Mb. Что весьма неплохо, я вам скажу. И это без серверного кеширования, без кеширования php.

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

Дерзайте! И не забывайте делиться идеями и/или замечаниями!

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

Итак, перейдите на страницу /wp-admin/network/settings.php и в поле “Запрещённые домены для e-mail” введите следующее:

• 163.com
• 21cn.com
• qq.com
• sohu.com
• tom.com

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

Также советую прочитать вот эту запись – Защита от регистрации спамеров и ботов.

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

Требования:

• php (средний и выше), js (базовый и выше);
• знание WordPress не понаслышке (умение пользоваться WP хуками и фильтрами; знание, что такое Кодекс);
• неплохой разговорный/письменный только плюс, но не критично;
• проживание в Харькове, Украина, или в окрестностях или готовность переехать сюда.

Необходимые качества:

• ответственность;
• гибкость;
• внимательность;
• желание и умение учиться.

С моей стороны:

• стабильная ЗП, которая пропорциональна вашему вкладу в работу;
• разнообраные проекты (как маленькие и быстрые, так и долгосрочные);
• помощь в виде советов/подсказок;
• обучу работе с BuddyPress (также нужен BuddyPress разработчик);

Отличный коллектив, замечательный офис. ЗП по результатам собеседования. Связь со мной через страницу Контакт или skype:slaffik_ua.

Мне довольно часто приходится вставлять скриншоты сайтов к себе в записи. Чтобы это сделать, я запускаю утилиту Jing, выделяю нужную область открытой страницы и сохраняю полученный скриншот на компе, после чего загружаю его сюда и вставляю в запись. Достаточно длинная процедура, особенно если надо сделать просто скрин главной страницы сайта (или любой другой) без выделения и подсветки определенных областей.

Так вот для ускорения этой процедуры, вы можете использовать бесплатный сервис от WordPress.com. Он позволяет по ссылке передать url страницы-цели и ширину, а ответом вам будет свежий рисунок сайта. Удобно?

Пример кода:

<img class="snapshot" src="http://s.wordpress.com/mshots/v1/http%3A%2F%2Fcosydale.com%2F?w=590" alt="CosyDale.com" />

Демо:

Меняете параметры: cosydale.com, 590 и CosyDale.com на свои собственные.

Второй забавной и порой полезной штукой является возможность получить фавикон сайта “на лету”. Его можно также вставить в текст, и будет выглядить, как красивая внешняя ссылка на мой сайт CosyDale.com.

Вот код:

<img class="favicon" src="http://www.google.com/s2/favicons?domain=cosydale.com" alt="CosyDale.com" />

Меняете только путь к сайту (лучше к главной странице) и содержимое alt тега.

Глупо как-то вышло… Но я умудрился увеличить скорость загрузки сайта и уменьшить потребляемую память в разы – простой перезагрузкой сервера :)

В общем, дело было так. Когда-то я писал о том, что ставил кеш XCache на сервер себе, настроил и все такое. Но, по-видимому, я просто не перезагрузился после этого, потому что статистика главной страницы у меня была:

10 queries in 0.377 seconds and 35.56Mb

Я еще удивлялся, почему у меня так много php – ведь я кеш ставил!

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

10 queries in 0.129 seconds and 9.73Mb

По крайней мере, я его таковым считаю.

Вывод – будьте внимательными ;)

Я достаточно давно писал, что под виндой пользуюсь или Netbeans (уже 7 версия вышла) или Notepad++. В последнее время начал все больше использовать NPP – для всех видов задач, даже оптимизации кода.

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

1. пробел между определителем и открывающей фигурной скобкой
   #id .class {
2. пробел между двоеточием после свойства стиля и его значением
   #id .class{float: left}
3. точка с запятой в конце блока стилей для определителя
   #id .class{float:left;}

В итоге, вместо вот этого:

table.forum tr.sticky td {
	background: #fff9db;
	border-top: 1px solid #ffe8c4;
	border-bottom: 1px solid #ffe8c4;
}

я получал следующее:

table.forum tr.sticky td{background:#fff9db;border-top:1px solid #ffe8c4;border-bottom:1px solid #ffe8c4}

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

Но вот сегодня до меня дошло (лучше уж позже, чем никогда), что можно использовать встроенные в Notepad++ макросы. Я быстренько записал один, который делает все перечисленное выше.

Этот файл надо положить или в корень папки редактора (будет замена), или в папку C:/Document and Setings/%USERNAME%/Application Data/Notepad++/ (для Windows XP) или C:/Пользователи/%USERNAME%/AppData/Roaming/Notepad++/ (для Windows 7).
Внимание: если вы уже создавали свои макросы, то вам придется вручную объединять файлы, иначе ваши затрутся.

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

Создаете php файл и внутрь него вписываете вот этот код:

<?php
function random($length) {
    $characters = "0123456789abcdefghijklmnopqrstuvwxyz!@#$%^&*()-=+_~";
    $string = "";
    for ($x = 0; $x < $length; $x++):
        $string .= $characters[mt_rand(0, strlen($characters))];
    endfor;
    return $string;
}
echo random($_GET['n']);

После этого в строке браузера прописываете путь к этом файлу вот в таком виде: http://example.com/test/pass.php?n=10

На экране вы увидите 10 символов из набора в переменной $characters. Если вы не хотите использовать какие-то символы в генерируемой строке – просто удалите их из $characters.

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

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

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

Итак, ниже я буду публиковать процесс работы с точностью до +/- 10 минут.

16 апреля @ 18.30

1. Создаю базу данных
2. Разворачиваю локальный домен, устанавливаю последнюю версию WordPress 3.1.1 и BuddyPress 1.3 (bleeding edge).
3. BuddyPress вытягиваю из репозитория используя комманду

   svn co http://svn.buddypress.org/trunk/

16 апреля @ 18.40

1. Создаю папку /buddyshop/ и начинаю думать, что работы будет чрезвычайно много.
2. Создаю черновик записи на сайте CosyDale.com, которые в будущем буду постоянно обновлять текущим статусом.

16 апреля @ 18.55

1. Разобрался с общим оформлением этой записи.
2. Ко мне пришли с приглашением на какое-то собрание в честь рождения завтра Иисуса Христа.
3. На сайте itsworkable.com в своем аккаунте создал еще одну площадку для проектов и задач под названием BuddyShop. Там я буду записывать все, что мне надо сделать по этому плагину.

16 апреля @ 19.05

1. Создал основной файл buddyshop.php с хуками выполнения кода сразу после активации и во время своей деактивации.
2. Написал пару функций для дебуга, в частности:

    if (!function_exists('print_var')){
   	function print_var($var){
   		echo '<pre>'
   		if(!empty($var))
   			print_r($var);
   		else
   			var_dump($var);
   		echo '</pre>'
   	}
   }

   add_action('bp_adminbar_menus', 'b_shop_queries');
   function b_shop_queries(){
       echo '<li class="no-arrow"><a>'.get_num_queries() . ' queries | ';
       echo round(memory_get_usage() / 1024 / 1024, 2) . 'Mb</a></li>';
   }

16 апреля @ 19.20

1. Начал работать над админкой плагина внутри меню BuddyPress с первоначальными настройками.
2. Одновременно продумываю структуру кода и грамотное подключение файлов (по необходимости).

16 апреля @ 19.40

1. Наполняю админку минимально необходимыми опциями разного типа с последующим сохранением всего.
2. Сейчас все выглядит вот так:

16 апреля @ 20.00

1. Подключил необходимые скрипты и стили. Причем они включаются только там, где это действительно необходимо (админские файлы вообще не будут грузиться на морде сайта).
2. Внедрил и далее буду поддерживать локализацию плагина (локаль ‘b_shop’).

16 апреля @ 20.15

1. Расширил админку разными типами (потом просто буду копипастить, а не писать каждый раз заново).

16 апреля @ 20.55

1. Пытаюсь понять, почему не срабатывает шаблонизатор в версии BP 1.3.
2. Добавил пользовательское меню. На данный момент есть ссылки в профиле на статистику пользовательского магазина, собственные товары, список пожеланий и настройки.
3. Отправил запрос в репозитории на регистрацию своего плагина. Вот его будущее расположение.

16 апреля @ 21.15

1. Вы бы видели, НАСКОЛЬКО сильно изменился код в 1.3 по сравнению с 1.2. Переписано практически все… Во всех плагинах поотваливаются создаваемые ими на морде страницы. Так что не обновляйтесь недели 2 после выхода 1.3…
2. Вникаю в новое API добавления данных внутрь BuddyPress.
3. Начинаю переписывать свой же код по регистрации ссылок и шаблонов вывода.
4. Хочется пива.

16 апреля @ 22.00

1. Переписал частично плагин. Меню и ссылки загружаются по-новому. Подключение идет тоже по-новому. В целом новая система мне нравится – она единообразная. Разработчики создали единый класс, который запускает модуль или плагин, а вы уже можете его расширять, создавая нечто свое собственное.
2. Сделаю себе перерыв на полтора часа.

17 апреля @ 00.00

1. Вернулся к разработке.
2. Выясняю, как работает в BuddyPress внутренняя система подключения модулей.

17 апреля @ 00.45

1. Нашел неприятный момент внутри BP кода. Оказывается, можно с чрезвычайной легкостью загрузится до BuddyPress, используя его же классы. Логика этого решения мне непонятна.
2. В третий раз переписал основной класс компонента.
3. Название изменил с BuddyShop на ВР Shop (чтобы подстроиться к внутренней логике инклудинга файлов).
4. Зарегистрировал новое название в репозитории плагинов.

17 апреля @ 01.30

1. Окончательно разделил компонент на составляющие.
2. Ко мне пришло осознание новой архитектуры BuddyPress :) Сочувствую всем, кому придется повторять мой путь.
3. Теперь уже можно непосредственно начать писать сам компонент, а не подстраиваться под новый формат движка.

17 апреля @ 02.30

1. Добрался до фронт-энда.
2. Начинаю работать с базой данных. Хотя скорее всего, продолжу завтра.
3. Теперь добавление своих компонентов на порядок легче стало. Тут разработчики молодцы.

На данный момент столько всего надо сделать, что даже не знаю, за что хвататься…

Сейчас в разработке:

1. CD Avatar Bubble 2.0 (почти доделан, остались мелкие фиксы, весь новый функционал уже написан или админка переписана).
2. BP GTM System 1.1 (работа почему-то зависла, почти доделал загрузку файлов, исправил штук 10-15 багов, еще что-то добавлено).
3. BP Bulk Data – нужен плагин для развертывания полноценной социальной сети в один клик. Есть только идеи, работы не начинались.
4. Ну и помимо всего этого, еще моя основная работа, отнимающая 10-14 часов в сутки.

А в итоге сижу и пишу свое расширение для Google Chrome :) Оказалось достаточно занятным процессом. Почти дописал парсер RSS ленты этого сайта. Результаты выложу :) А если вы скажете, что вам понравилось, то тогда выложу в репозитарий расширений хрома.