Постепенно, с развитием сайта, в нём накапливаются неактуальные произвольные поля. Или требуется изменить какое-то название на более подходящее. Для этих целей, в phpMyAdmin воспользуемся SQL запросами.

Как переименовать произвольное поле

Как удалить произвольное поле

В phpMyAdmin выбираем нужную базу данных, затем заходим во вкладку SQL и там вводим данные:

Например, вводим следующие данные, чтобы создать таблицу в которой будут храниться комментарии пользователей (тип табличных данных и названия подсмотрены из WordPress таблицы комментариев):

Пояснение к перечисленным данным. Инструкции для создания строк таблицы вводятся через запятую. В одной инструкции (создание одной строки) такой порядок:

1. Название
2. Тип табличных данных (в скобках, указать значение, если оно требуется)
3. Дополнительно указываются необходимые атрибуты (через пробел, может быть несколько)

Какие типы и за что отвечают можно найти в специализированной литературе по MySQL.

В результате работы команды выше получим такую таблицу:

Зачем может понадобиться смена формата таблиц?

У каждой из таблиц есть свои преимущества и недостатки. В целом считается, что InnoDB более надежная база для больших структур, чем MyISAM.

Однако на деле, в привычной жизни рядового вебмастера таблицы с InnoDB приносят больше проблем, чем MyISAM. Потому что последние чинить гораздо проще.

Ниже ошибка в базе данных InnoDB, которая не чинится встроенными инструментами SQL, phpMyAdmin или WordPress.

Вы будете получать уведомления:

Также в логах можно увидеть ошибки от InnoDB такого рода:

Для починки таких ошибок нужно заходить через SHH, создавать DUMP InnoDB и затем его восстанавливать. А это несколько замороченее, чем починка таблиц MyISAM.

Переводим таблицы из InnoDB в MyISAM

К тому же таблицах в таблицах InnoDB полноценные текстовой поиск не работает (хотя в последних версиях вроде как заявлена). Это приводит к тому, что некоторые плагины поиска на WordPress либо просят перевести таблицу в другой формат либо ищут некачественно.

Команда перевода основных таблиц WordPress из InnoDB в MyISAM:

Команды нужно вводить в phpMyAdmin или в программах работающих с базами данных удалённо, например, Sequel Pro.

При работе сайта так или иначе иногда в базе данных таблицы «крошатся». Сайт при этом может и дальше работать. Хотя о стабильности в этом случае говорить не приходится. Запросто может остановится служба MySQL, а в результате сайты будут простаивать в нерабочем состоянии. Так что лучше сломанный таблицы чинить.

Логи записей с испорченными таблицами могут выглядеть так:

Для починки таких таблицы обычно достаточно запустить в phpMyAdmin команду Repair:

Или воспользоваться встроенными в WordPress инструментами починки базы данных.

Открываем файл wp-config.php и записываем туда:

Затем переходим по ссылке:

^^^
адрес сайта указываем свой. И попадаем на страницу ремонта баз данных от WordPress:

MSQL Error: Can’t Create new tempfile

Такая ошибка в MyISAM не исправляется инструкциями выше, зато её легко можно поправить через командную строку (SSH). Для починки требуется ввести:

Не важно какую программу вы будете использовать для подключения к базе данных сайта. В любом случае она окажется удобнее, чем заходить через браузер. Особенно, если требуется работа с несколькими базами данных.

Ошибки и недостатки phpMyAdmin

Недостатки интерфейса и оболочки phpMyAdmin заключаются в том, что связь с базой данных периодически обрывается. Время сессии быстро заканчивается, после некоторого отсутствия активности во вкладке, надо заново перелогиниваться.

Бывает с первого раза не получается войти в phpMyAdmin. Отчего-то не работают сохраненные пароли в браузерах: после нажатия отправить, страница снова перезагружается с предложением вновь «залогиниться». Для решения этой проблемы в форму надо вставлять пароли из вне.

Иногда после авторизации в phpMyAdmin перекидывает на несуществующие страницы. Связано это со всякими сертификатами и защитами, которые выставлены у разных хостеров. Надо снова возвращаться на предыдущую страницу и только тогда ты попадаешь в интерфейса базы данных. Вообщем недостатков phpMyAdmin огромное количество. Можно сказать, я даже не начинал перечисления.

А часто требуется работать сразу с несколькими базами данных MySQL различных сайтов. И это гораздо проще сделать через отдельную программу. Программу всегда проще запустить.

В данной статье я затрону программу Sequel Pro на Mac OS. Она бесплатная, но разработчики просят пожертвовать, если она окажется полезной. Это отличная программа, но она не уникальная. Есть похожие программы для разных операционных систем.

Программа Sequel Pro

В начале работы с программой заполняем данные для соединения с MySQL. Для сохранения нужно нажать «сохранить». Если забыть это сделать, то при повторном подключении придется заново их вводить.

Я рекомендую подключаться через SSH, таким образом сохраняется конфиденциальность работы с удаленной базой данных.

Если сайтов несколько, то легко переключаться между ними через вкладки. Они по умолчанию выключены. Включить их можно через меню.

Ошибка выглядела следующим способом:

Ошибка возникла при переносе базы данных с одного VPS хостинга на другой. PhpMyAdmin ругался на таблицу wp_posts, в частности на строчку crp_related, которая относится к плагину Contextual Related Posts.

Причина была в том, что таблица wp_posts имела тип таблиц InnoDB, а для корректного импорта (и видимо работы) тип таблиц должен был быть MyISAM. Понятия не имею почему вдруг wp_posts заимел иной тип таблиц. Может быть причиной являлся плагин Contextual Related Posts.

Решение оказалось простым. На старом хостинге в базе данных через phpMyAdmin поменял в wp_posts тип таблиц. После чего заново экспортировал уже правильную базу данных и импорт на новом сервере прошел успешно.

Для смены типа таблиц в phpMyAdmin надо было выбрать таблицу wp_posts. В ней вкладку «Операции». Там выбрать тип таблиц MyISAM, отметить галочкой Change all column collations и нажать вперед.

Сложно ли очистить MySQL от мусора

Когда в самый первый раз заходишь в phpMyAdmin для работы с базой данных MySQL, обилие непонятных табличных данных вызывает ужас. Я особо никогда не изучал MySQL, но когда постоянно там что-то правишь, постепенно начинаешь понимать её структуру. И оказывается всё не так сложно.

Зачем чистить базу MySQL

База данных MySQL это такая же система захламления, как и реестр в Windows. Те кто обладают Mac-ами часто даже не подозревают насколько им повезло, что в MacOS вместо табличного сохранения данных используется файловое.

В базу данных MySQL записывается разного рода информация, в том числе от установленных на сайт плагинов. Иногда в поисках нужного плагина приходится устанавливать много других. Потом эти плагины удаляешь, а они свои данные оставляют в MySQL. Так постепенно база данных захламляется ненужного рода информацией.

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

Старые табличные данные иногда при экспорте-импорте могут вызывать ошибки. Кроме того они же могут вызывать проблемы при взаимодействии с другими плагинами.

Конечно, можно жить без оптимизации таблиц, часто пустые табличные данные ни на что не влияют, как можно и не убирать пыль под диваном. И пока не загляните, не испугаетесь. Но это уже выбор каждого отдельного человека.

MySQL таблицы в WordPress по умолчанию

Долгое время чистая установка WordPress создавала в MySQL всего 11 таблиц. Затем добавили ещё одну таблицу wp_termmeta.

Начиная с WordPress 4.4 в базе данных создаётся 12 таблиц:

1. wp_commentmeta
2. wp_comments
3. wp_links
4. wp_options
5. wp_postmeta
6. wp_posts
7. wp_terms
8. wp_termmeta
9. wp_term_relationships
10. wp_term_taxonomy
11. wp_usermeta
12. wp_users

Что будем чистить?

Для примера я взял один из самых старых моих сайтов, которому уже стукнуло 8 лет. Я никогда раньше не разбирался с таблицами на этом сайте, потому что чего я только туда за время его работы не устанавливал. Но недавно я переделал сайт и удалил из него всё что не использовалось и понял, что пора и базу данных MySQL тоже почистить.

Только вдумайтесь, 91 таблица (одну успел удалить, перед тем как создал скриншот)! Когда WordPress устанавливает всего 12.

Как понять что удалять, а что нет?

По большинству таблиц можно узнать, удалены ли плагины с WordPress или нет. Рабочие таблицы, особенно если сайт работает давно, занимают определенное место, исчисляемое в Kib или Mib, тоже самое что и Кбайт и Мбайт, только по названию двоичной системы.

Если таблица содержит в колонке Rows значение 0 или в колонке Size значение 1 Kib (1 Кбайт), скорее всего эти таблицы для работы сайта не нужны.

За исключением тех таблиц, которые устанавливаются самим WordPress. Их лучше не трогать, даже если они пустые. Например, мало кто сегодня пользуется отдельным разделом ссылок на сайте, за который отвечает wp_links. В результате таблица пустая, но удалять её нежелательно.

В табличном имени используется сокращенный префикс от плагина. Иногда по нему можно понять, какой плагин создал эту таблицу. Если не знаете, что за таблица, то Google в помощь.

Начнем разбираться с моими 91 таблицами. Не буду приводить все что я удаляю, но в качестве примера приведу достаточно. Итак, поехали…

Таблица wp_nggcf_fields

Таблицы относятся к плагину NextGEN Custom Fields Plugin. Уже и не помню когда я его устанавливал и для чего мне понадобились произвольные поля для отдельного плагина. Сам плагин уже как 3 года не обновляется. Удаляем таблицу без сожалений:

wp_bp

Это же остатки от таблиц Body Press. Где-то в далёком 2012 году я его устанавливал, экспериментировал, а потом удалил. Таблицу он за собой оставил. Удаляем и её.

wp_cimy

Удаляю таблицы данных для плагина Cimy User Extra Fields:

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

wp_gdsr

Таблица относится к плагину GD Rating System. Его я устанавливал еще в 2009 году. С тех пор этого плагина нет, а «могилка» в табличке осталась. То что данные старые и не используются можно понять, если зайти внутрь таблицы и посмотреть на даты:

Плагин GD Rating System насоздавал мне аж 12 таблиц. Вот зачем ему столько?

Когда-то давно я искал плагин рейтингов и перебирал разные. Остановился на WP-PostRatings, который и использую до сих пор. Вот он создал мне в базе данных всего 1 таблицу:

И почему другие авторы не желают придерживаться такого же минимализма? Или хотя бы убирали за собой.

wp_wangguard

Относится к плагину WangGuard. Сегодня не использую. Тоже насоздавал таблиц, которые я удалил:

table sam_errors

Остатки от плагина Simple Ads Manager, который помогал вставлять рекламу на сайте. Сейчас предпочитаю это делать непосредственно в шаблонах сайта.

Удаляем:

wp_xmasb_quotes

Остатки от плагина цитат. Удалил.

wp_voting_record

Также удалил остатки плагина Voting Record, который сам по себе перестал обновляться еще 8 лет назад.

wp_pollsa

Уничтожаем таблицы оставшиеся от плагина голосований:

wp_interlinker

Остатки от плагина Cross-Linker. Плагин помогающий внедрять ссылки в контекст сайта. Сегодня предпочитаю делать это либо вручную либо через базу данных MySQL. Иначе это напрасная нагрузка на сайт.

wp_navigation

Удалил остатки плагина WP-PageNavi. Опять же сегодня навигация работает без сторонних плагинов.

wp_people

Избавился от таблицы плагина WP People.

wp_authors / wp_authors_stats

Плагин Authors Page, список авторов WordPress. Тоже не использую.

wp_sabre_table

Таблицы оставшиеся от Simple Anti Bot Registration.

wp_statpress

Плагин WP Statistics. Удаляем:

wp_sk2_logs

Таблица ещё от одного древнего плагина Spam Karma 2 Blacklist Ban.

wp_shortcodes

Вероятно от плагина Shortcodes Ultimate. Удалил.

wp_relatedposts

Непонятная таблица, похожая на таблицу от плагина WordPress Related Posts, но у него есть другая таблица, которую он использует: wp_wp_rp_tags. Может быть та таблица была старой и автор потом заменил её название. Вообщем, рискнул удалить.

Таблицы wp_es

Плагин Email Subscribers & Newsletters также насоздавал кучу таблиц. На том сайте я его уже не использую, потому удалил:

wp_options

Эта таблица, которую создает сам WordPress. С ней надо быть осторожнее и не удалить лишнее. Но некоторые плагины любят занести мусор и в таблицы по умолчанию. Например, плагин Antispam Bee оставил строчку за собой, которую я тоже удалил:

Результаты очистки MySQL

Хаос из 91 таблицы, большая часть которых осталась в наследство от давно удалённых плагинов, превратился в 17 необходимых таблиц на сайте:

Меня самого впечатлило, сколько накопилось мусора за время работы того сайта. Сейчас на нём 27 активных плагинов (не считая те, что были написаны мной и не учитываются в общем списке). При этом им достаточно всего 17 таблиц, 12 из которых были созданы самой WordPress.

Что касается размера базы данных, то она уменьшилась всего на какие-то 500 кб и это совсем не существенный размер. Однако в первую очередь цель была направлена именно на очистку неиспользуемых таблиц, а не на уменьшение объёма базы данных.

Для уменьшения размера базы данных обычно достаточно удалить старые ревизии.

Ссылка на phpMyAdmin находится по такому пути:

Данные для входа используются те же самые, которые были при создании любой из баз данных.

Ссылка приведенная на скриншоте выше выедет на сайт URL следующего типа:

На этой странице не всегда получается зайти в phpMyAdmin. После ввода и отправки данных страница просто перезагружается. Для исправления такой ситуации, вместо адреса сайта надо использовать IP адрес:

Последняя статья по редиректам.

Смотрите также статью получение бесплатного SSL сертификата. А если у вас панель Vesta, то установка сертификата ещё проще.

Отправляем весь трафик с http на https

Первая проблема, которая возникнет после установки сертификата – отсутствие замочка в адресе сайта, при заходе на него через https. Это происходит из-за того, что изображения, стили и скрипты продолжают подключаться через обычный протокол http.

А если заглянуть в код сайта через инспектор браузера, то там возле таких элементов, можно заметить сообщения с предупреждением, что данные передаются незашифровано.

Для начала я думал проблема в подключении файлов через:

И если её заменить на:

то всё должно заработать. Из WordPress документации следует, что get_bloginfo отдаёт адрес сайта без шифрования, в то время как get_template_directory_uri вставляет сразу с https. Но это проблемы не решило. Можно пути не менять.

Также в Интернете встречаются рекомендации внести в файл wp-config.php следующие параметры:

Однако, если точно следовать статье по получению сертификата SSL и дальнейшей настройки описанной в текущей статье, то это тоже не нужно.

Меняем адреса в MySQL

Заходим в phpMyAdmin. Сначала обязательно делаем резервную копию, а затем выполняем команды MySQL по замене старого URL http на новые https:

В коде выше замените адрес сайта на свой.

Я учел все данные с http в своей базе. Возможно в вашем случае поменяется не все URL адреса. Для проверки заходим в поиск и вводим свой сайт:

Смотрим результаты:

Видим, что сайтов с http:// больше нигде нет, кроме одного значения. Заходим внутрь и исправляем. У вас могут быть значения указаны в других местах.

При замене адреса http на https в MySQL могут полететь какие-нибудь настройки плагинов. У меня так произошло с плагином Contextual Related Posts. В этом случае, заново придётся настроить плагин.

Встречающиеся ошибки

Не получается войти в панель администратора wp-login.php или /wp-admin/. Прежде всего надо почистить cookie.

Файл .htaccess

Можно также попробовать перевести сайт на зашифрованный трафик через .htaccess:

Но иногда из-за этого можно получить ошибки, браузер будет ругаться на превышение редиректов:

И страница открываться не будет.

Рабочая настройка для дружелюбных ссылок на WordPress в файле htaccess выглядет так:

Ошибка выглядела следующим образом:

В phpMyAdmin таблица указана была как используется.

Попробовал починить таблицу консольными командами и через SQL запросы в phpMyAdmin, но ничего не вышло.

Для починки таблицы через консольную команду (может кому-нибудь поможет и такой способ), сначала нужно зайти на сервер через Терминал.

Теперь заходим в свою базу данных:

Если вводите команду и получаете ошибку:

Значит вводите неправильные «имя базы данных», «имя пользователя базы данных» или «пароль к базе данных».

При успешном соединении будет так:

Мне починить не удалось, возникли такие ошибки:

Тогда я попробовал провести починку через SQL запросы в phpMyAdmin, тоже не помогло. Возможно вводил неверные команды, потому что получал следующие сообщения:

Исправление ошибки 144

Решение оказалось куда более простым. У меня была сохраненная правильная резервная копия базы данных. Таблица wp_post_views_history не являлась для меня ключевой и её более ранняя копия мне вполне подходила.

Я импортировал старую базу данных через phpMyAdmin в отдельную базу данных. Затем выделил таблицу wp_post_views_history и экспортировал её отдельно.

После чего в базе данных, где возникала ошибка, я выделил сломанную таблицу и очистил её. Затем удалил. Именно в таком порядке, иначе таблица не удалялась.

Последним действием импортировал рабочую таблицу wp_post_views_history и всё стало работать.

Вот почему важно делать резервные копии.

Команда замены в таблицах MySQL

Универсальный пример

Массовая замена текста в записях (статьях) WordPress

Пример. Как-то мне понадобилось заменить во всех текстах тег blockquote на теги div. Для этого потребовалось ввести следующую команду.

Замена путей для изображений в MySQL

Массовая замена (изменение) имени автора в WordPress

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

Замена произвольных полей в MySQL

Для замены произвольного поля ‘premiere_ru’ в таблице wp_postmeta, где значения «—» нужно поменять на пустые:

Как сделать выборку незаполненных произвольных полей

Это удобно делать, когда нужно массово заполнить произвольные поля к разным записям одновременно.

В примере ниже выведем в таблице wp_postmeta, произвольное поле premiere, которое является пустым.

Скриншот из программы Sequel Pro при подобной выборке:

Разновидность запроса, которая также выведет незаполненные поля:

Как вывести пустое значение произвольного поля, если оно не задано вообще, я пока не понял, но можно использовать запрос wp_query для вывода постов.

Массовая замена URL сайта на WordPress

Полезные команды, когда нужно сменить адрес сайта на WordPress в базе данных MySQL. Обычно пригождается, когда переносится база данных с тестового сайта на рабочий URL.

Замена URL сайта для WordPress на localhost

В обратном случае, при переносе сайта с удаленного сервера на локальный веб-сервер:

Вместо моего сайта поставьте свой.

Замена старых URL на новые

Меняем старые ссылки в записях, в комментариях и настройках. В результате старый URL останется только в таблице wp_postmeta поля meta_key в качестве старого слага (_wp_old_slug). Пусть хранится на всякий случай, это никак не мешает работе сайта. Наоборот, будет переадресация в случае чего.

Очистка WordPress от ревизий

И полезная команда по очистке лишних ревизий в WordPress.

Не работают запросы SQL

Бывает, вы вводите правильные запросы SQL, запускаете их и ничего не меняется. Результат пишется, что изменено 0 строк. В этом случае попробуйте переписать под копирку запросы на клавиатуре. По каким-то причинам в результате копирования иногда запросы могут не работать. Возможно вставляется не тот апостроф или может какой ещё невидимый атрибут/символ.

При переносе базы данных WordPress с одного хостинга на другой возникла ошибка:

В целом сообщение об ошибке было таким:

Причина оказалась в том, что таблица в базе данных MySQL плагина Subscribe To Comments Reloaded находилась в кодировке utf8mb4_unicode_520_ci. А для верной работы необходима кодировка utf8mb4_unicode_ci.

Ошибка Unknown utf8mb4_unicode_520 может возникнуть из-за неверного формата таблицы любого другого плагина. Например, в одном из случаев, у меня такая ошибка возникала сразу во многих других таблицах (не только относящихся к плагинам), например:

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

Если ИМЕЕТСЯ доступ к базе данных старого хостинга

Заходим в эту базу через phpMyAdmin.

В колонке слева выбираем таблицу wp_subscribe_reloaded_subscribers. Сверху панели выбираем вкладку «Структура».

Нажимаем изменить и меняем сравнение utf8mb4_unicode_520_ci на utf8mb4_unicode_ci.

Затем выбираем вкладку «Операции», снова выбираем кодировку utf8mb4_unicode_ci, отмечаем галочку Change all column collations. Нажимаем вперед, подтверждаем, что хотим выполнить эту операцию.

После этого можно экспортировать свою базу данных и импортировать на новый хостинг. На этот раз всё должно пройти гладко.

Если доступа к базе данных старого хостинга НЕТ

В этом случае надо открыть базу данных через специализированные программы, например, Notepad++ или Transmit в Mac OS. Там найти строчки utf8mb4_unicode_520_ci и заменить их на utf8mb4_unicode_ci. Сохранить и дальше импортировать к себе на хостинг.

Если ошибку вызывает другой плагин, не обязательно wp_subscribe_reloaded_subscribers или какая иная таблица, то действовать нужно по аналогии с этой инструкцией, но уже для другой таблицы.

Панель управления сайтами Vesta мне понравилась с первого раза. Бесплатная и ничего лишнего, очень минималистично и при этом функционально. Однако уже не первая ошибка в «Весте», которая заставила меня поломать голову. На этот раз проблема касалась upload_max_filesize. Значения никак не хотели меняться. Но давайте по порядку:

Если значения upload_max_filesize поддаются изменению

Ошибка в базе данных на английском:

Для исправления надо перейти во вкладку Server. Дальше навести мышку на httpd, выбрать CONFIGURE. Перейти во вкладку HTTPD CONFIGURE PHP.INI.

И здесь поменять значение upload_max_filesize.

Если значения upload_max_filesize не изменяются

Вообще-то по-умолчанию значения должны меняться через панель, но это у меня не всегда происходило. Сам файл конфигурации в панели однажды оказался пустым.

Изменение в его значениях ни к чему не приводили.

Пришлось менять всё вручную. Сначала я нашел все файлы php.ini у себя на сервере:

Было не мало файлов:

Из них данные были только в файлах /etc/php.ini и в /tmp/. Остальные оказались пустыми. В поисках решения я даже удалил все файлы и тоже ничего не изменилось.

Решение как изменить значение upload_max_filesize в панели Vesta (CentOS) я всё-таки обнаружил. Значения хоть и изменились, но MySQL по-прежнему не хотел импортировать файл в 3 мб, ругаясь на размер файла.

Как изменить upload_max_filesize в файле php.ini панели управления Vesta (CentOS)

Создаем файл на сервере:

Заходим в него через адресную строку браузера:

Находим строчку:

Смотрим значение справа (у меня это было):

Значит сервер использует конфигурацию PHP по адресу — /etc/php56/php.ini

Копируем в этот файл конфигурацию по-умолчанию:

Правим сам файл /etc/php56/php.ini, изменяем значение upload_max_filesize на 30М.

Перезагружаем сервер

Теперь в файле info.php отображается правильный upload_max_filesize.

Однако это не помогло импортировать базу данных MySQL. PhpMyAdmin всё также ругался на размер файла. Потому пришлось импортировать его через терминал.

Импорт базы данных MySQL через SSH

Если предыдущие способы не помогли импортировать базу данных MySQL, остаётся способ воспользоваться импортом через консоль.

Кладем файл в любую папку на сервере. При этом файл базы данных должен быть разархивированным. Затем воспользуемся командой:

После ввода этой команды появится требование ввести пароль от базы данных. Вводим пароль и база будет импортирована.

Путь должен быть абсолютным, от корня главного раздела, например: