Хей, имам нещо специално за теб!
Попълни имейл адрес, на който до минута ще получиш обещаното ;)
Случвало ли ти се е да се събудиш и да откриеш имейл от хостинг компанията, на чийто сървър “живее” уеб сайта ти, гласящ нещо от рода на: “Database size limit has been reached“?
След това, влизайки в phpMyAdmin с изненада да откриеш, че базата ти е с големина на гигастична апликация с множество записи, а в действителност имаш информативен портфолио сайт с няколко страници?
Ако отговорите на тези въпроси са “да”, виж какво имам да ти споделя по-долу 😉
Отговорът на този въпрос не е еднозначен и валиден за всеки WordPress уеб сайт. Размерът на таблиците в базата данни (общо 12 таблици) зависи от използвани плъгини, тема/и, page builder-и, автоматични чернови и – ревизии. Тъкмо за тях ще ти разкажа в редовете по-долу (и видеото към тази статия), тъй като най-често неглижирането на настройките им е причината за wp_posts таблица с размер, например, 105MB.
Да загубиш последните си редакции и добавяне на съдържание, докато редактираш или публикуваш нова статия, например, е доста досадно и времеемко. За щастие, WordPress предотвратява това със своята built-in функционалност за запазване на ревизии и автоматични чернови.
Но макар и с добри намерения, ревизиите могат да доведат до буквално задръстване на една от таблиците в базата данни, което на свой ред да причини бавно зареждане на уеб сайта, натиск от страна на хостинг компанията (особено ако използваш споделен хостинг) и невъзможност за качване на ново съдържание.
ℹ️ Няма да изпадам в подробности как се работи със самите ревизии и как може да възстановиш версия на дадена публикация или страница – всичко това може да разбереш сам/а в администрацията на своя уеб сайт.
Ревизиите са функция по подразбиране в WordPress, която има предварително дефинирани настройки. WordPress ги съхранява в таблицата с публикации на своята база данни като children на конкретна публикация. Колкото повече ревизии създадеш, толкова по-тежка ще става базата данни.
Следователно управлението на ревизиите на публикации и старници чрез тяхното изтриване, ограничаване или деактивиране не е “шега работа”. Ще обясня всяко от тях, като започна с изтриването на стари ревизии в WordPress.
За напреднали – един от чистите начини да изтриеш стари ревизии е чрез достъпване на phpMyAdmin и стартиране на SQL заявка.
⚠️Внимание: важно е да внимаваш с този метод. Не са един и два snippet-ите код из форумите и социалните мрежи, които не са съвсем “качествени”. Някои от тях без проблем могат да изтрият нещо важно от сайта ти. Или по-лошо – могат да го свалят изцяло.
За безопасно изтриване на стари ревизии от базата SQL чрез заявка, влез в phpMyAdmin, избери конкретната база данни на WordPress от панела вляво, след което избери SQL от табовете горе:
След това може да въведеш команда, с която да се изпълни SQL заявката в базата данни на WordPress:
DELETE FROM wp_posts WHERE post_type="revision"; // change wp_ with your DB prefix
Тук внимавай за това какъв е prefix-a на таблиците ти (в примера е посочен wp_, но може да е всичко, например ozh_, znt_ и др). Натисни Go бутона и заявката ще се изпълни 🙂
Ако пък си опитен WordPress разработчик и използваш CLI (command-line interface), то през терминала може да въведеш следната команда (като отново съобразиш prefix-а на базата):
$ wp post delete $(wp post list --post_type="revision" --format=ids)
Имай предвид, че изтриването на стари ревизии няма да спре WordPress да генерира нови такива. Това е начин да “разчистиш” малко базата, а ако не искаш да стигаш отново до сходна ситуация, следвай стъпките по-долу.
Следващата стъпка, за да държиш базата си оптимално чиста, като едновременно с това се възползваш и от ревизии, е да ги ограничиш.
В WordPress repository-то има купища плъгини, които правят точно това, но целта на {dev} blondie; е да информира и демонстрира методи за решаване на проблеми посредством чист код 😉
В тази връзка, за да ограничиш ревизиите, отвори файловете на уеб сайта си през FTP (напр. FileZilla, Cyberduck или какъвто FTP клиент използваш) и навигирай до wp-config.php
файла. Непосредствено в началото му добави този код:
define('WP_POST_REVISIONS', 3); // define how many revisions you'd like to keep
В конкретния случай ще укажем на WordPress да съхранява последните 3 ревизии, като това число може да варира.
Има случаи, в които уеб сайта (или неговия администратор) няма нужда от ревизии. В този случай, след като всички вече налични в базата са изтрити, може да отидеш в wp-config.php
и да добавиш следния ред код:
define('WP_POST_REVISIONS', false);
Един уеб сайт впечатлява не само с дизайн и интерактивни елементи, но и с бързина на действие и реагиране. В тази връзка, оптимизираната база данни е първата стъпка към тази цел.
{dev} blondie; ти препоръчва още сега да посетиш phpMyAdmin-a си и да провериш какъв е размерът на базата данни. Ако ти се стори подозрително висок – провери wp_posts за натрупани ревизии. Оттам нататък знаеш какво да правиш 🙂
⚠️ И макар да знаеш какво правиш – един backup както на файловете, така и на базата няма да навреди 😉
Stay blond 😉