:

<?php echo get_num_queries(); ?> queries. <?php timer_stop(1); ?> seconds.

Якщо використовується плагін для кешування SQL запитів до бази даних, то буде відображену реально здійснену кількість запитів. Тобто кешовані запити в цю цифру не попадуть.

Швидких Вордпресів!

Презентуємо авторський метод від wordpress.ukr.im.

1. Переконуємося що в корені вже існує, або створюємо новий файл .htaccess і додаємо В КІНЕЦЬ файлу наступне:

# Block access to wp-login.php file
<Files wp-login.php>
Order deny,allow
Deny from all
# whitelist IP address
# DO NOT PUT ANYTHING BELOW this line! (не вписуйте нічого нижче цієї лінії!)
</Files>

2. Переконуємося що в директорії wo-admin вже існує, або створюємо новий файл .htaccess і додаємо В КІНЕЦЬ файлу наступне:

# Block site access to all except this:
Order deny,allow
Deny from All

3. Створюємо в корені новий файл з довільною секретною назвою, на приклад get-access.php і вписуємо в нього код:

<?php
error_reporting(E_ALL | E_STRICT);
echo “Granting wp-admin… “;
$fd = fopen(‘wp-admin/.htaccess’, ‘a’);
#fseek ($fd , -60, SEEK_END);
fwrite($fd, “Allow From “.$_SERVER['REMOTE_ADDR'].”\n”);
fclose($fd);
echo “granted!”;

# now let’s allow wp-login.php access:
echo “<br>Granting wp-login… “;
$fd = fopen(‘.htaccess’, ‘r+’);

fseek ($fd, -9, SEEK_END);
fwrite($fd, “\n Allow from “.$_SERVER['REMOTE_ADDR'].”\n</Files>”);

fclose($fd);
echo “granted!”;
?>

4. Все. Відтепер всім на рівні веб-сервера заборонено доступ до директорії wp-admin та файлу wp-login.php котрі найбільше піддаються bruteforce атакам. Тепер щоб ми самі могли отримати доступ до адмінки, треба зайти за адресою /get-access.php (або як ви там обізвали секретний файлик), і відтепер з нашого поточного айпі доступ назавжди дозволено. Якщо в нас змінився айпі, або ми заходимо в адмінку з іншого місця – знову тригаємо /get-access.php.

Траблшутінг:

- при деяких конфігураціях сервера при записі в файли маємо помилку доступу. Тоді ставимо права 777 на .htaccess-и.

1. виділити текст (код) в редакторі шаблонів ВордПрес (Ctrl+A);
2. скопіювати код (Ctrl+C);
3. вставити код (Ctrl+V) на згаданій вище сторінці замінивши наявний там тестовий текст;
4. натиснути ґудзика “Remove Empty Lines”

Все готово! Тепер виділяємо та копіюємо текст назад в вікно редактора тем (чи плаґінів) WordPress.

запит http://wordpress.ukr.im/whatever/rel-nofollow-blogroll-links/wp-content/themes/aeros/images/lens.png
крім того, що відтягує час загальний на завантаження, він ще генерує помилку 404, бо УРЛ невірний. Це заставляє вордпрес двічі генерувати вивід за один запит. А якщо хибних посилань закралося N?

Ресурсам сервера прийдеться напружитися. Хтось з нас аналізує такі речі і створює якісний, оптимізований продукт, хтось не забиває собі мізки і пропонує клієнту арендувати виділений сервер, бо сайт “крутий”.

Несправедливість можна виправити плаґіном, але якщо під кожну правку ставити плаґін то “ставити” швидко закінчиться. Тому вдаємося до маленької хитрості.

Перед відкриттям сторінки з формою редагування лінка відключаємо в браузері жаваскрипт.

Вуа-ля. Заповняємо поле rel значенням nofollow і зберігаємо лінк. Не забуваємо пролінкувати wordpress.ukr.im!;)

Перед (!) директивами вордпреса в .htaccess пишемо:
ErrorDocument 404 /index.php?error=404

В редакторі поточного шаблону вичищаємо файл 404.php від будь-якого PHP коду, та пишемо туди саме те, що хочемо віддавати на сторінці 404. Можна, звичайно, використати PHP та SSI, але ж задача в нас – віддавати звичайний, прочтий, чистий, плейн HTML ;) Якщо файлу немає – створюємо!

Прес все ще буде задіяний при обробці 404, але генерації сторінки не буде. Це саме те, що потрібно щоб зняти навантаження на сервер при великих об’ємах запитів, що ведуть до 404.

php_value memory_limit 128M

в файлі .htaccess в корені сайту, але цей запис  не рідко призводить до помилки 500. Другий спосіб -  запис виду

memory_limit = 128M

в файлі php.ini. І тут головне – помістити php.ini в вірну теку. І ще головніше – перезапустити апач після розміщення файлу php.ini! До перезапуску апача, директиви з файлу php.ini  діяти не будуть. Якщо немає доступу до безпосереднього перезапуску веб-сервера, а є лише панель керування хостінгом, і чекати перезапуску веб-сервера з якоїсь причини через годину чи через день немає бажання то можна скористатися партизанським методом. Потрібно в панелі керування хостінгом (cPanel, DirectAdmin, ISPmanager) додати новий домен чи видалити існуючий, який давно пора було видалити. Тобто, стимулювати перезапуск апача шляхом опосередкованого внесення змін в конфігураційний файл апача. Теоретично, того самого можна досягти додавши аліас (припаркувати) до домена, або на приклад, додавши нове розширення до виконання PHP (не перевірено).

Для прикладу, плагін WP-Memory-Usage порадував мене цифрою 128 лиш після того, як я поклав php.ini до теки wp-admin. Можливо для деяких інших модулів знадобиться помістити php.ini у теку з відповідним скриптом.

Те саме справедливо для лімітів на максимальний розмір файлів на завантаження на сайт upload_max_filesize та ліміту запиту post_max_size. Розмір ліміту запиту post_max_size має бути трохи більшим від максимальної ваги файлів upload_max_filesize. Якщо вага становить 10 мегабайт то ліміт запиту має бути 11-12 мегабайт.

В wp-config.php в свою чергу мають бути присутні наступні записи:

ini_set(‘memory_limit’,’128M’);
define(‘WP_MEMORY_LIMIT’, ’128M’);
define(‘WP_MAX_MEMORY_LIMIT’, ’128M’);

Ну не те, що “мають”, принаймні WP_MEMORY_LIMIT, здається, є обов’язковим, все інше треба експериментувати в залежності від конфігурації сервера. Але якщо буде всі три записи, гірше точно не стане.

Щодо того, скільки пам’яті потрібно WordPress-у для роботи то тут все дуже індивідуально і повністю залежить від кількості та змісту активних плаґінів і обраної теми.