Параметры объекта поста WP_Post в базе данных MySQL

ID — (целое число) ID поста

post_author — (целое число) ID автора поста

post_date — (строка) дата и время публикации поста в формате YYYY-MM-DD HH: MM: SS

post_date_gmt — (строка) дата и время (GMT) публикации поста в формате YYYY-MM-DD HH: MM: SS

post_content — (строка) контент (содержимое) поста

post_title — (строка) заголовок

post_category — (строка) по идее это ID рубрики, к которой относится пост, однако с версии WordPress 2.1 всегда равно 0, чтобы определить рубрики, воспользуйтесь функцией get_the_category().

post_excerpt — (строка) содержимое поля «Цитата»

post_status — (строка) статус поста

comment_status — (строка) настройки комментирования

ping_status — (строка) разрешены ли трэкбэки и пингбэки

post_password — (строка) пароль к посту

post_name — (строка) ярлык поста

to_ping — (строка) URL для пинга

pinged — (строка) URL, которые уже пингнуты

post_modified — (строка) дата и время последнего обновления(редактирования) поста в формате YYYY-MM-DD HH: MM: SS

post_modified_gmt — (строка) дата и время GMT последнего обновления(редактирования) поста в формате YYYY-MM-DD HH: MM: SS

post_content_filtered — (строка)

post_parent — (целое число) ID родительского поста (например для вложений или страниц)

guid — (строка) ссылка на пост вида https://misha. blog/?p=8542

menu_order — (целое число)

post_type — (строка) тип поста

post_mime_type ` — (строка) MIME тип (для вложений)

comment_count — (целое число) количество комментариев к посту

8 лайфхаков для базы данных WordPress

1. Создание бэкапа вашей базы

Проблема. Хотя советы в этой статье были проверены, вам не стоит их применять на практике до создания резервной копии вашей базы MySQL (мало ли что…)

Решение. Чтобы создать вручную резервную копию вашей базы, следуйте за этими простыми шагами:

1. Для начала надо залогиниться в phpMyAdmin и выбрать там свою базу WordPress.

2. Кликните на кнопке «Экспорт» (Export), которая находится в горизонтальном меню.

3. Выберите метод сжатия данных (лично я использую gzip) и нажмите на кнопочку «Пошёл» (Execute).

4. Ваш браузер спросит хотите ли вы скачать бэкап. Разумеется скажите ему твёрдое Да и сохраните файл куда-нибудь на свой компьютер.

Примечание. Учтите, что создание резервных копий базы WordPress гораздо удобнее делать с помощью специального плагина WP-DB-Backup. Пользователи WordPress могут не задумываясь, прямо сейчас установить себе этот плагин если по каким-то причинам всё ещё этого не сделали.

2. Пакетное удаление ревизий записей

Проблема. Ревизии записей — это новая фишка WordPress начиная с версии 2.6. Она может быть очень полезной, а может также увеличить размер базы MySQL. Разумеется, вы можете вручную удалять ревизии постов с админки. Но это очень долго и нудно. Есть решение получше.

Решение. А решение проблемы очень простое: мы пакетно, то бишь всё одним махом, удаляем ревизии постов используя простой SQL-запрос. Результат может быть потрясающим, если у вас много записей. Ваша база данных может похудеть вдвое!

1. Надо залогиниться в phpMyAdmin и выбрать там свою базу WordPress.

2. Потом нажать на кнопочку «SQL». Появится окошко, в которое надо вставить следующий запрос:

DELETE FROM wp_posts WHERE post_type = "revision";

3. Вот и всё! В зависимости от количества записей, вы сэкономили кучу драгоценного времени и почистили базу.

Объяснение кода. В таблице wp_posts есть поле под названием post_type. Это поле может иметь множество значений, таких как post, page или revision. Когда мы хотим избавиться от ревизий записей, то просто запускаем команду, чтобы та удалила все значения в таблице wp_posts, в поле post_type которой стоит значение revision. Вот как.

3. Удаляем 5000 спаммерских комментариев за одну секунду

Проблема. Правдивая история: мой друг недавно открыл свой собственный блог и начал активно его пиарить по всему интернету. Через несколько недель интенсивной работы он провёл пару дней в отпуске, без сети.

Когда он вернулся домой и заглянул в свой блог… то увидел больше 5000 сообщений, которые ожидали модерации! Как быть?

Решение. К своему счастью, мой друг рассказал мне о своей проблеме с долбаными спамерами. Он уже успел потратить 45 минут на ручную проверку и удаление спама, как я показал ему очень полезный трюк:

1. Логинимся в phpMyAdmin и выбираем там свою базу WordPress.

2. Нажимаем на кнопочку «SQL». Появится окошко, в которое надо вставить следующий запрос:

DELETE from wp_comments WHERE comment_approved = '0';

3. И прощайте спамеры! Наслаждаемся чистотой и уютом…

Объяснение. В таблице wp_comments содержится поле comment_approved, в котором хранится булевое значение (1 или 0). Утверждённые комментарии имеют значение 1, а комментарии, которые ожидают модерации — 0. Вышеуказанная команда просто удаляет неутверждённые комментарии. Всё просто.

Но будьте осторожными! Хотя это решение офигенно удобное для автоматического удаления миллионов спамерских комментариев, но оно также удаляет и нормальные неутверждённые комментарии. Если вы всё ещё не используете плагин вроде Akismet, то самое время начать, чтобы предотвратить заспамление блога.

4. Как изменить атрибут записи

Проблема. Когда вы устанавливаете WordPress, создаётся аккаунт «admin» по-умолчанию. Некоторые блоггеры делают ошибку, используя этот аккаунт для создания своих записей, пока они не понимают, что это как-то безлико.

Решение. Модификация атрибута автора для каждой записи занимает туеву хучу времени. К счастью, SQL может нам помочь:

1. Логинимся в phpMyAdmin и выбираем там свою базу WordPress.

2. Для начала нам надо определить правильные ID пользователей. Так что нажимаем на кнопочку «SQL». Появится окошко, в которое надо вставить следующий запрос:

SELECT ID, display_name FROM wp_users;

3. phpMyAdmin отобразит список «айдишников», которые привязаны к пользователям WordPress. К слову, NEW_AUTHOR_ID это ID самого свежесозданного автора, а OLD_AUTHOR_ID это ID оригинального админского аккаунта.

4. После того как вы определили «айдишники» NEW_AUTHOR_ID и OLD_AUTHOR_ID, выполните следующую команду:

UPDATE wp_posts SET post_author=NEW_AUTHOR_ID WHERE post_author=OLD_AUTHOR_ID;

5. Это всё. Все записи, которые были привязаны к аккаунту admin теперь будут собственностью того пользователя, которого вы выбрали.

5. Сброс пароля

Проблема. Чтобы защитить свои блоги, люди часто выбирают сильные пароли, такие как 7*KoF5i8_. Это, конечно, похвально, но все слышали множество историй о том как админы забывают свои пароли 🙂

Решение. Когда вы забываете свой пароль, WordPress может отправить вам ссылку для его сброса на email. Но если у вас нет доступа к мылу, которое указано в базе WordPress, или если вы считаете, что вопрос можно решить как-то иначе, то вот вам способ «взлома»:

1. Логинимся в phpMyAdmin, выбираем там свою базу WordPress и открываем окно SQL.

2. Вводим следующую команду (с учётом, что вашим логином был «admin»):

UPDATE 'wp_users' SET 'user_pass' = MD5('PASSWORD') WHERE 'wp_users'.'user_login' = 'admin' LIMIT 1;

3. Ну вот, собственно, и всё. Ваш пароль успешно обновится на тот, что вы указали в месте, помеченном как «PASSWORD».

Объяснение. Пароли пользователей хранятся в таблице wp_users. Разумеется используется хэш MD5, чтобы защитить их от просмотра.

Мы отправили SQL-запрос «UPDATE» и использовали встроенную функцию MySQL — MD5(), чтобы конвертировать наш пароль в MD5 и обновить его. Использование «WHERE» гарантирует, что мы обновили только пароль администратора. Тот же запрос, но без использования параметра «WHERE» обновит все пароли в базе!

6. Изменение вашего доменного имени

Проблема. Хотя это и не рекомендуется, но вы можете в какой-то момент захотеть изменить доменное имя вашего блога и при этом сохранить все его данные. Так как WordPress хранит доменное имя в базе, вам придётся немного изменить базу, чтобы связать ваш новый домен и блог WordPress.

Решение.

1. Как вы уже могли догадаться: логинимся в phpMyAdmin, выбираем там свою базу WordPress и открываем окно SQL

2. Чтобы изменить URL Вордпресса, запускаем вот такую команду:

UPDATE wp_options SET option_value = replace(option_value, 'http://www.oldsite.com', 'http://www.newsite.com') WHERE option_name = 'home' OR option_name = 'siteurl';

3. Потом нам нужно заменить относительный URL (GUID) для каждой записи. Следующая команда сделает это за вас:

UPDATE wp_posts SET guid = replace(guid, 'http://www.oldsite.com','http://www.newsite.com');

4. Это почти конец. Осталось только найти и заменить абсолютные URL в таблице wp_posts table для убедительного финала:

UPDATE wp_posts SET post_content = replace(post_content, 'http://www.oldsite.com', 'http://www.newsite.com');

5. А вот это уже конец. Можете зайти в админку своего блога используя новый урл.

7. Отображение количества SQL-запросов вашего блога.

Проблема. Когда пытаешься оптимизировать время загрузки блога, знание количества запросов к базе данных весьма помогает. Для того чтобы уменьшить количество запросов, первым делом надо узнать сколько запросов происходит на какой-либо странице.

Решение. Прикол: нам не надо заходить в phpMyAdmin 🙂 Надо только открыть на редактирование файл footer.php (он точно есть в вашей теме) и добавить туда вот такие строки кода:

<?php if (is_user_logged_in()) { ?>
<?php echo get_num_queries(); ?> запросов за <?php timer_stop(1); ?> секунд.
<?php } ?>


Сохраните файл и посетите свой блог. В «подвале» вы увидите количество запросов к базе Вордпресса и время, затраченное на их создание.

Примечание. Сложилось впечатление, что многие пользователи WordPress не в курсе это чудесной возможности. Функция get_num_queries() возвращает количество созданных запросов во время загрузки страницы.

Учтите, что код, приведённый выше, отображает количество запросов только залогиненым пользователям, так как гости блога и поисковые боты не обязаны знать эту информацию. Но вы можете сделать отображение публичным, просто убрав условный оператор if (is_user_logged_in()) с кода.

8. Восстановление вашей базы данных

Проблема. Скажем… по некоторым причинам, таким как взлом или проблема с обновлением, вы можете потерять данные вашего блога или обнаружить их безнадёжно испорченными. Так что если у вас есть резервная копия (правда же есть, да?), вам необходимо импортировать её в свою базу Вордпресса. И тогда всё будет хорошо. Скорее всего.

Решение.

1. Логинимся в phpMyAdmin, выбираем там свою базу WordPress.

2. Жмём на кнопку «Импорт» (Import) в горизонтальном меню.

3. Нажмите кнопку «Открыть» (Browse) и выберите самую свежую копию базы со своего диска.

4. Жмём на кнопку «Пошёл» (Execute). Если всё пройдёт удачно и боги на вашей стороне, база данных будет снова полностью функциональна.

Как отключить ревизии WordPress (Дополнительный вариант)

Последний вариант ― это просто отключить ревизии (редакции) WordPress. Наиболее часто используемым методом обычно является второй вариант, о котором упоминалось выше. Однако, если вы являетесь единственным автором, то вы можете просто полностью избавиться от ревизий.

Помните, что система все равно сохранит черновик, просто у вас уже не будет точек для восстановления редакции.

Шаг 1
Откройте файл wp-config.php. Вам нужно будет добавить код. Обычно он находится в основной папке вашего сайта WordPress, и вы можете получить к нему доступ через FTP.

Шаг 2
Строчку кода необходимо вставить над «ABSPATH».

define('WP_POST_REVISIONS', false);

Как ограничить количество ревизий WordPress

Возможно, вы хотите сохранить 3 ревизии.

WordPress сохранит этот номер и удалит все предыдущие. Вы также можете использовать wp-revisions-cli для очистки последующих ревизий на основе номера, указанного вами ниже.

Шаг 1
Алгоритм действий такой же, как и при ограничении количества ревизий (см. выше). Откройте файл wp-config.php.

Шаг 2
Строчку кода необходимо вставить так же над «ABSPATH».

define ('WP_POST_REVISIONS', 3);

Вот и все!

Scroll to top