Презентуємо авторський метод від 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-и.

Перед (!) директивами вордпреса в .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-у для роботи то тут все дуже індивідуально і повністю залежить від кількості та змісту активних плаґінів і обраної теми.