WordPress ➜ Статьи о WordPress
Все записи рубрики 31
- 03/03/2006 Какая должна быть CMS или почему WordPress?
- 03/03/2006 Как публиковать свои посты, чтобы читать их было удобно
- 03/03/2006 Встраивание html-счетчиков в WordPress
- 03/03/2006 Руссификация WordPress
- 03/03/2006 О кодировке WordPress
- 27/03/2006 Русский WordPress
- 01/04/2006 Проблемы кодировки trackback и ее решение
- 11/04/2006 Исправляем кодировку Ping в WordPress’е
- 20/04/2006 Проблемы русского WordPress’а
- 26/04/2006 Деление страниц в WordPress’е
- 14/05/2006 Что такое ping и traсkbaсk?
- 22/10/2006 Сайт по функциям WordPress
- 24/10/2006 Пишем в блог с помощью Google
- 25/12/2006 Каким должен быть идеальный WordPress
- 22/01/2007 Проблемы с кодировками в WordPress 2.1
- 03/02/2007 К вопросу о кодировке WordPress
- 07/04/2007 “Ускоряем” WordPress за счет постоянных страниц
- 15/04/2007 FAQ по WordPress
- 01/05/2007 Делаем выбор RSS-подписок сайта для браузера
- 24/07/2007 Анализатор кода phpXplorer
- 24/07/2007 Эксперимент с антиспам-картинкой
- 19/08/2007 Подчищаем таблицу опций
- 26/09/2007 Обновление WordPress через импорт записей
- 02/10/2007 Возвращаясь к вопросу кодировки
- 07/10/2007 Вывод последних записей
- 01/11/2007 Навеяло проделанной работой
- 23/11/2007 Как быстро настроить кодировку базы данных для WordPress’а
- 09/12/2007 Отображение виджетов в сайдбарах при разных условиях
- 23/02/2008 Форма обратной связи
- 07/08/2008 Для чего подходит и не подходит WordPress
- 21/09/2008 WordPress 2.3.3 MaxSite Edition
21 сентября 2008 г.
Я не думал, что мне придется возвращаться к этой теме, но мне чуть ли не каждый день пишут с просьбой выложить или дать ссылку на мою сборку WordPress 2.3.3. В принципе я понимаю, что в новых версиях (> 2.5) повышенное ресурсопотребление, отстутствие кэша, плохая совместимость плагинов - всё это приводит к тому, что многие жалеют о своем преходе на последние версии WordPress.
Многие обращаются сделать сайт на WordPress, но после того, как начинаем обсуждать техническое задание, выясняется, что WordPress не очень-то и подходит под поставленные задачи. Теоретически, конечно же можно построить практически любой сайт на WordPress, однако стоит ли такая стрельба из пушки по воробьям?
Популярность WordPress и незнание его особенностей создают ошибочное впечатление того, что этот «движок» можно использовать чуть ли не под любую задачу. На самом деле существует ряд серьезных ограничений.
Так уже получилось, что за последний месяц у меня было много подобных заявок и я вынужден был отговаривать людей использовать WordPress. В этой статье я хочу кратко остановиться на таких моментах.
Создание формы на самом деле совсем несложное занятие. Обычно это входит в учебники по PHP для начинающих. ;) Поэтому особо мудрить не будем, пойдем по стопам классиков.
Довольно давно столкнулся с проблемой, когда нужно выводить различные виджеты по какому-нибудь условию. Например, календарь - выводить только на главной странице.
На первый взгляд решение кажется простым - нужно зарегистрировать еще один сайдбар и выводить его только на главной (описание виджетов, продолжение). Все это безусловно хорошо, но большинство виджетов существуют только в единственном экземпляре. Существует только три стандартных виджета, для которых можно сделать несколько копий: текстовый, RSS и рубрики.
Для этого существует довольно простой и эффективный способ. Делать это лучше перед установкой WordPress'а.
За последнюю неделю сделал несколько сложных заказов. Из-за этого даже не успевал форум почитать. :-(
Зато выяснилось несколько интересных моментов.
Для вывода последних записей можно использовать виджет, а можно воспользоваться вот такой функцией. В ней можно указывать рубрики, формат ввода, количество записей. Сама функция использует кэширование.
В WordPress 2.2 появился дополнительный параметр конфигурации DB_CHARSET, который позволяет выполнить запрос «SET NAMES 'utf8'». Это отличное решение, поскольку раньше для этого необходимо было вручную править файл wp-bd.php и дописывать нужные строчки.
Основу этого способа подсказал один из моих клиентов. Он может пригодится для тех случаев, когда нужно выполнить перенос данных из одного WordPress-блога в другой.
В WordPress'е есть один не очень хорошо продуманный момент, который создает бессмысленную нагрузку на сервер. Суть проблемы в том, что таблица опций используется не только для хранения опций, но и для rss-записей, полученных скажем с официальной Планеты WordPress и других данных. С точки зрения базы данных, размер таблицы не так и велик (у меня 750Кб в дампе), во всяком случае для MySQL это ерунда. Но есть один момент, который явно влияет на производительность WordPress.
После того, как я поставил на свой блог антиспам-картинку, ту которая с новым подходом, да еще и отключил для старых записей пинги и трекбаки, количество спама резко сократилось. То есть вообще ноль.
Наверное это несколько необычно, поэтому сегодня я уж грешным делом подумал, что может быть тогда есть смысл отключить антиспам-картинку, поскольку для кого-то она оказывается сложновата. В общем, утром отключил, а сейчас зашел в админ-панель и сразу успокоился.
В своем блоге Яна (Yantar) опубликовала отличную находку для тех, кто изучает WordPress.
В своей работе я приноровился пользоваться поиском (по тексту) в Total Commander, поскольку функций WordPress'а много (2702 шт.) и часто нужно посмотреть какие у них параметры. Как оказалось, есть отличная разработка в PHPXref - phpXplorer. Эта утилита анализирует файлы в указанном каталоге или архиве и строит полную карту, включая функции, переменные, классы и т.д., и т.п. Получается очень наглядно и быстро. Лично я это сразу оценил и пишу эти строки, радуясь как ребенок. 
Если вы пользуетесь FireFox или Opera (насчет IE7 просто не в курсе), то знаете, что для сайтов, которые имеют поддержку RSS, браузер добавляет RSS-кнопку в адресной строке. Лично я уже давно привык именно через эту кнопку добавлять RSS-подписки в свой reader.
На форумах поддержки WordPress есть раздел «FAQ по WordPress». Мы решили сделать его в виде отдельного форума и это оказалось довольно удобно.
Знаю, что многие, кто занимается WordPress имеют свои готовые решения. И если хотите, то вы можете опубликовать его в этом форуме (приветствуется указание автора и ссылки на сайт).
Несколько раньше я писал, что в WordPress'е несколько неудачно реализован вызов постоянных страниц. Проблема кроется в том, что функция получения записей, формирует SQL-запрос, который возвращает для постоянных страниц все поля, начиная от ID и заканчивая текстом.
Особенность постоянных страниц в том, что они не имеют рубрик и не могут отображаться в виде ленты, как это принято для обычных записей. Поэтому постоянные страницы могут серьезно сказываться на производительности WordPress, ведь при каждой загрузке сайта автоматически будут вызываться все постоянные страницы со всеми своими данными.
Это совсем не оптимально, поскольку получение таких данных просто не нужно. Например в сайдбаре есть смысл вывести лишь заголовки страниц в виде ссылок и ничего более.
