UPDATE wp_posts SET guid = REPLACE (guid, 'olddomain.com', 'newdomain.com');
UPDATE wp_posts SET post_content = REPLACE (post_content, 'olddomain.com', 'newdomain.com');
UPDATE wp_postmeta SET meta_value = REPLACE (meta_value, 'olddomain.com','newdomain.com');
UPDATE wp_usermeta SET meta_value = replace(meta_value, 'olddomain.com', 'newdomain.com');
UPDATE wp_options SET option_value = replace(option_value, 'olddomain.com', 'newdomain.com');

Ось і все – кидаємо в улюблений блокнот, заміняємо olddomain.com на наше старе ім’я домену, newdomain.com заміняємо на наше нове доменне ім’я і тиснемо ентер в PhpMyAdmin.

Функція LOWER() допомагає боротися з записами як OldDomain.COM та їм подібними апперкейсами. Використовується таким чином: “UPDATE wp_postmeta SET meta_value = REPLACE (LOWER(meta_value), ‘olddomain.com’,’newdomain.com’)”. Але УВАГА! Всі рядки, де будуть знайдені співпадіння залоуеркейсить повністю. Це критично для UPDATE wp_posts бо всі тексти стануть ловеркейсними. Тому LOWER() треба використовувати лише у разі потреби і до тих таблиць, не не буде завдано шкоди.

Якщо у вас замість вордпреса випадково виявився OpenCart то правимо конфіги в корені і адмін та викоруємо дуже схожий SQL запит:

UPDATE oc_setting SET value = REPLACE (LOWER(value), 'olddomain.com', 'newdomain.com');

delete from wp_options where option_name like '_transient_%'

NextGen Gallery полюбляє смітити, прибираємо:

delete from wp_options where option_name like 'displayed_gallery_rendering_%'
delete from wp_options where option_name like 'displayed_galleries_%'

Далі буде…

Нам понадобиться функція:

if (!function_exists(‘http_response_code’)) {
function http_response_code($code = NULL) {

if ($code !== NULL) {
$text = ‘Not Found’;
$protocol = (isset($_SERVER['SERVER_PROTOCOL']) ? $_SERVER['SERVER_PROTOCOL'] : ‘HTTP/1.0′);
header($protocol . ‘ ‘ . $code . ‘ ‘ . $text);
$GLOBALS['http_response_code'] = $code;
} else {
$code = (isset($GLOBALS['http_response_code']) ? $GLOBALS['http_response_code'] : 200);
}
return $code;
}
}

Далі в файлі плаґіну wptsc-engine.php шукаємо рядок “@file_put_contents($chfile,$gcnt);” і заміняємо його на:

if (strpos($gcnt,’<title>Нічого не знайдено’) !== false) {
http_response_code(404);
} else { @file_put_contents($chfile,$gcnt); }

Упс, тут “<title>Нічого не знайдено” замініть на вашу унікальну ознаку 404 сторінки. Таким чином, 404 сторінка не кешуватиметься і віддаватиметься з коректним кодом 404 а не 200. Бажаєте кешувати 404ті результати? Просто допишіть @file_put_contents($chfile,$gcnt); після виклику функції http_response_code(404);

Блискавичних вордпресів!

До суті: в плаґіні є оція “Ignore Specific Url:” але вона передбачає введення адреси певної сторінки. А якби ми хотіли не кешувати цілу піддиректорію, або підзапит на приклад http://site.ua/go/ то такої можливості нема. Плаґін перевіряє лише прямі співпадіння.

Правиться це додаванням лише одного рядка

$xrurl = substr($rurl, 0, strlen($iurl));

за рядком №44. Тобто цей рядок треба додати в циклі foreach((array) $gig as $iurl) перед if($iurl == $xrurl).

Тепер в полі “Ignore Specific Url:” ми можемо ввести http://site.ua/go/ і всі запити типу http://site.ua/go/togoogle/ і йому подібні кешуватися не будуть.

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

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

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

Є кілька WordPress плаґінів, зоктема поаґін English spam та плаґін Approve only russian comments, котрі вирішують завдання.

wp_die( __( ‘Cheatin&#8217; uh?’ ) );

а причиною стає умова в попередньому рядку:

if ( isset($action) && $action == ‘edit’ && !$ID )

Не будемо вдаватися в причини, вони старі як світ. Важко сказати, хто тут більш винен, чи розробники вордпрес, чи розробники тем (шаблонів). Рішенням, як не дивно, може стати банальний апдейт вордпресу.

Якщо оновлення вордпресу не допомагає, костилем може стати банальна ремарка 126 рядка:

// wp_die( __( ‘Cheatin&#8217; uh?’ ) );

Успіхів!

Цікавий приклад: ZIPована вага сайту до плаґіна – 180Мб, а після плаґіна лише 30Мб!

В ідеальних умовах, маючи доступних 100 і більше мегабайт оперативної пам’яті, доступної для PHP, плагін працюватиме чудово. Якщо ж в наявності у PHP 64Мб або менше, то робота плаґіна перериватиметься без повідомлень про помилку. Помилки можна знайти в /wp-admin/error_log. Це будуть помилки про недостачу пам’яті при обробці великих зображень. Саме з такими монстрами ми і зібралися боротися. Для вирішення проблеми потрібні наступні танці з бубнами:

• помістити в /wp-admin файл php.ini з рядком “memory_limit = 256M”
• обов’язково перезапустити вебсервер (апач)
• якщо не допомогло – помістити згаданий php.ini в директорію плагіна, чи/і в кореневу директорію (поекспериментувати з метою отримання 256Мб в адмінці) і знову перезапустити апач

Якщо прийдеться експериментувати, то в нагоді стане невеличкий плаґін WP-Memory-Usage, котрий в трей адмінки виводить споживаний та доступний об’єми пам’яті.  Бувають випадки коли плаґін пише “null” замість окей, але при цьому файли успішно перетискає. Загалом про питання використання пам’яті і її ліміти розказано тут. Там же розписано як перезапустити апач партизанським способом, маючи лише доступ до панелі керування хостінгом (cPanel, DirectAdmin чи ISPmanager).

Скріншот сторінки налаштування:

Частина 1

Частина 2

Частина 3

Частина 4

Частина 5

Автор: AndreyMorkovin