wordpress.ukr.im » WordPress http://wordpress.ukr.im Просто ще один раз про WordPress ;) Tue, 04 Dec 2018 14:05:50 +0000 uk hourly 1 https://wordpress.org/?v=3.9.40 Заміна домена wordpress – SQL MySQL PhpMyAdmin http://wordpress.ukr.im/kvik-fiks/zamina-domena-wordpress-sql-mysql-phpmyadmin/ http://wordpress.ukr.im/kvik-fiks/zamina-domena-wordpress-sql-mysql-phpmyadmin/#comments Mon, 09 Mar 2015 21:44:36 +0000 http://wordpress.ukr.im/?p=216 Коли ми заміняємо домен з старого на новий не достатньо просто замінити домен і налаштуванні WordPress. Тобто достатньо, але щоб зробити це якісно та для СЕО, то доведеться “підчистити хвости”. Для чистки хвостів вордпресу є кілька SQL команд:

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');
]]>
http://wordpress.ukr.im/kvik-fiks/zamina-domena-wordpress-sql-mysql-phpmyadmin/feed/ 0
Відображення кількості SQL запитів та часу виконання WordPress http://wordpress.ukr.im/whatever/sql-zapyt-chas-vykonannya-wordpress/ http://wordpress.ukr.im/whatever/sql-zapyt-chas-vykonannya-wordpress/#comments Wed, 11 Feb 2015 23:44:58 +0000 http://wordpress.ukr.im/?p=218 Колись просто цікаво, а іноді необхідно побачити чи показати кількість SQL запитів здійснених для генерації сторінки на WordPress, та час виконання скрипта. Для цього нам навіть не потрібно буде створювати жодних таймерів. Довтатньо в потрібному місці вставити наступний PHP код

:

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

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

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

]]>
http://wordpress.ukr.im/whatever/sql-zapyt-chas-vykonannya-wordpress/feed/ 0
Оптимізовуємо базу даних WordPress http://wordpress.ukr.im/kvik-fiks/optymizovujemo-bazu-danyh-wordpress/ http://wordpress.ukr.im/kvik-fiks/optymizovujemo-bazu-danyh-wordpress/#comments Mon, 26 Jan 2015 13:02:32 +0000 http://wordpress.ukr.im/?p=202 У базі даних вордпресу часом накопичується різноманітне сміття. На приклад, записи _transient_ в таблиці wp_options. Чистимо їх наступним чином:

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_%'

Далі буде…

]]>
http://wordpress.ukr.im/kvik-fiks/optymizovujemo-bazu-danyh-wordpress/feed/ 0
Коректний 404 у WordPress Tiniest Super Cache http://wordpress.ukr.im/kvik-fiks/korektnyj-404-u-wordpress-tiniest-super-cache/ http://wordpress.ukr.im/kvik-fiks/korektnyj-404-u-wordpress-tiniest-super-cache/#comments Sat, 22 Nov 2014 14:04:18 +0000 http://wordpress.ukr.im/?p=205 Чудовий кешуючий плаґін WordPress Tiniest Super Cache чудовий тим що швидкий як блискавка. Недоліків маса – виправляємо. Одигнм з недоліків є некоректна обробка 404 сторінок. А точніше, 404 сторінку, яку згенерував вордпрес, плагін кешує і віддає з кодом 200. Одним словом – бардак.

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

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);

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

]]>
http://wordpress.ukr.im/kvik-fiks/korektnyj-404-u-wordpress-tiniest-super-cache/feed/ 0
Наш wp-admin – наша фортеця! http://wordpress.ukr.im/whatever/nash-wp-admin-nasha-fortetsya/ http://wordpress.ukr.im/whatever/nash-wp-admin-nasha-fortetsya/#comments Sat, 29 Mar 2014 17:26:43 +0000 http://wordpress.ukr.im/?p=183 Причини для  захисту адмінки вордпресу здебільшого дві – безпека сайту та продуктивність серверу. Якщо з безпекою сайту все зрозуміло, то не всі знають, що сайти на WordPress постійно атакують недохакери підбираючи паролі. Часто такий перебір іде через ботнет або тор. Це означає що чи не за кожним запитом – новий айпі. Тому стандартний захист через плагіни мало того що не знімає питання навантаження на процесор, він просто не спрацює.

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

]]>
http://wordpress.ukr.im/whatever/nash-wp-admin-nasha-fortetsya/feed/ 1
Якщо суто український сайт, то латиниця – СПАМ http://wordpress.ukr.im/boremo-spam/yakscho-suto-ukrajinskyj-sajt-to-latynytsya-spam/ http://wordpress.ukr.im/boremo-spam/yakscho-suto-ukrajinskyj-sajt-to-latynytsya-spam/#comments Wed, 08 Jan 2014 18:28:16 +0000 http://wordpress.ukr.im/?p=198 Для виключно кирилічних сайтів, котрі працюють на вордпрес потерпають від заморського слова СПАМ є метода його відсіювання шляхом недопущення кирилічних коментарів. Адже мало ймовірно, що хтось лишить коментар на українському сайті англійською мовою чи транслітом. А для тих то збирається так зробити варто підписати попередження біля форми коментування типу “Допускається лише кирилиця”.

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

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

]]>
http://wordpress.ukr.im/boremo-spam/yakscho-suto-ukrajinskyj-sajt-to-latynytsya-spam/feed/ 0
Cheatin Uh? Мухлюєш, а?! http://wordpress.ukr.im/kvik-fiks/cheatin-uh-muhlyujesh-a/ http://wordpress.ukr.im/kvik-fiks/cheatin-uh-muhlyujesh-a/#comments Fri, 27 Dec 2013 11:17:57 +0000 http://wordpress.ukr.im/?p=179 Дуже чудово отримати на екрані “інформативне” повідомлення “Мухлюєш, а?!”. Англійською воно сформульоване як “Cheatin Uh?”. Тобто це не українські перекладачі вбили інформативність повідомлення. Це розробники вирішили не заморочуватися з арґументацією КРИТИЧНОЇ помилки. При чому, критичною вона стає саме з подачі розробників WordPress в 126 рядку (дійсно для WordPress версій 3.8) файлу /wp-admin/media-upload.php:

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

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

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

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

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

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

Успіхів!

]]>
http://wordpress.ukr.im/kvik-fiks/cheatin-uh-muhlyujesh-a/feed/ 1
Позбавитися порожніх рядків в редакторі WordPress http://wordpress.ukr.im/whatever/remove-empty-lines-wordpress/ http://wordpress.ukr.im/whatever/remove-empty-lines-wordpress/#comments Mon, 01 Oct 2012 14:23:47 +0000 http://wordpress.ukr.im/?p=127 Не заглиблюючись в причини їхньої появи, позбавляємося від небажаних порожніх рядків редактора шаблонів WordPress. Загалом, звичайно, можна скористатися улюбленим текстовим редактором, якщо він має таку функцію. Інакше нам допоможе онлайн сервіс ТекстМеханік: http://textmechanic.com/Remove-Empty-Lines.html. Там є також інші цікаві текстові утиліти. Потрібно:

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

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

]]>
http://wordpress.ukr.im/whatever/remove-empty-lines-wordpress/feed/ 0
Imsanity http://wordpress.ukr.im/must-have-plugins/imsanity/ http://wordpress.ukr.im/must-have-plugins/imsanity/#comments Fri, 28 Sep 2012 02:17:27 +0000 http://wordpress.ukr.im/?p=119 Imsanity – типу ґлузд. Назвою автор явно сказав, що зберігати в директорії uploads вордпресу оригінали завантажуваних зображень гігантських розмірів – безґлуздо. Встановивши ґлузд ви позбавитесь безґлуздя wordpress. Плаґін автоматично перезжимає оригінали до встановленого вами розміру та ступеня стиснення жипег. Також є каток, який з задоволенням прокатає ваші вже існуючі гігантські фото.
Ясно, що самостійно ставлячи публікації і маючи ґлузд, плаґін лишній. Але якщо на сайті новини ставлять журналісти без ґлузду – плаґін “маєш мати”!

Цікавий приклад: 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).

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

]]>
http://wordpress.ukr.im/must-have-plugins/imsanity/feed/ 0
Створення плаґіна WordPress. Відеокурс. http://wordpress.ukr.im/video-kurs/stvorennya-plagina-wordpress-videokurs/ http://wordpress.ukr.im/video-kurs/stvorennya-plagina-wordpress-videokurs/#comments Wed, 26 Sep 2012 05:33:13 +0000 http://wordpress.ukr.im/?p=111 Відеокурс з 5ти уроків в середньому по 20 хвилин по створенню кастомного плаґіна для Вордпреса.

Частина 1

Частина 2

Частина 3

Частина 4

Частина 5

Автор: AndreyMorkovin

]]>
http://wordpress.ukr.im/video-kurs/stvorennya-plagina-wordpress-videokurs/feed/ 0