Всем привет! Сегодня на seo-mayak.com мы будем разбирать на винтики таксономии WordPress. Конечно, в создании новой категории нет ничего сложного, но вот далеко не все представляют себе анатомию сего процесса.
Т.е. мы проследим всю цепочку событий, которые происходят после нажатия кнопки «Добавить новую рубрику».
Хочу спросить новичков и не только. Вы знаете что такое «Терм»? Надеюсь, что с понятием «Таксономия» все же многое веб-мастера знакомы.
Так вот, начиная с этой статьи мы начнем знакомится с базой данных WordPress и сегодня подробно разберем несколько таблиц. Кстати у меня уже есть статья, на тему сохранения и восстановления БД и правил безопасности при работе с ней. Очень поучительная, советую обязательно ознакомиться.
Кроме того, данная статья послужит хорошей базой для последующего разбора функций WordPress, предназначенных для работы с категориями. В общем, читайте до конца, будет интересно.
В интернете много информации по данной теме, но в основном материал излагается на профессиональном языке, с применением соответствующей терминологии и понятно, что «чайникам» просто не реально в этом разобраться.
Ведь я тоже был «чайником» и в некоторых вопросах до сих пор остаюсь им быть, так что наверное, как никто другой понимаю, как надо подавать информацию, чтобы она проникла в самые дальние уголки «серого вещества» начинающих веб-мастеров и крепко там засела.
Хотя запоминать, те или иные моменты, вовсе не обязательно, ведь всегда можно воспользоваться моим блогом, как шпаргалкой.
Кстати, шпаргалки в программировании вещь не заменимая и я пользуюсь ими постоянно. И поэтому мне нужно иметь n-количество свободного пространства памяти, чтобы силком запихивать туда труднозапоминаемые выражения.
Здесь самое главное разобраться в конструкции языка и уловить смысл работы той или иной функции и если это получится, то мир программирования откроет для Вас свои поистине безграничные возможности.
Итак, давайте вернемся к тому моменту, когда создается новая рубрика. Поехали!
Как создать категорию
Еще раз повторюсь, что наверное все, даже самые зеленые веб-мастера, имеющие сайты на WordPress, знают, как создавать категории:
Можно и по-другому:
А вы задумывались, что происходит после нажатия кнопки «Добавить новую рубрику»? Понятно, что WordPress производит запись информации о категориях в базу данных. Но куда именно?
Для более глубокого понимания сего процесса, давайте зайдем на свой хостинг и перейдем на страницу управления Базами данных MySQL. Другими словами на надо войти в phpMyAdmin.
После выбора нужной БД пред нами предстанет такой список таблиц:
При девственной структуре базы данных WordPress должно отобразиться 11 таблиц.
Если же у Вас их большее количество, то винить в этом надо плагины, так как именно они зачастую создают новые таблицы под свой функционал и даже после удаления того или иного плагина, созданная им таблица не редко остается в БД. Это так, информация к размышлению!
Итак, первая таблица, в которую записывается информация о созданных категориях, называется wp-terms.
Таблица wp_terms
Двойным кликом мыши открываем таблицу wp-terms.
Таблица разделена на 4 колонки:
term_id — ID категории, метки, ссылки;
name — Название категории, метки, ссылки (Имя);
slug — Ярлык категории, метки, ссылки;
term_group — Группа категорий, меток, ссылок.
С ID категории вроде бы все понятно, но хотел отметить один момент. Присвоением ID для категорий, записей и т.д. WordPress не занимается, все эти числовые значения генерирует непосредственно сама база данных.
С name должно быть тоже все понятно, в данное поле таблицы записывается название категории, метки или ссылки, такое, какое оно есть, т.е. русскими символами.
А вот с полем slug надо разобраться. Что это за странные символы в первой строке таблицы?
%d0%91%d0%b5%d0%b7-%d1%80%d1%83%d0%b1%d1%80%d0%b8%d0%ba%d0%b8
Дело в том, что при переводе WordPress на русский язык, был переведен и ярлык категории «Без рубрики», а ярлык должен быть прописан лат. символами, поэтому получается такое безобразие.
Последняя колонка таблицы term_group всегда будет содержать нули. Как я выяснил, группировка категорий на данный момент WordPress не поддерживается.
Нам же надо найти вновь созданную категорию, поэтому спускаемся в самый низ таблицы. Если таблица разделена на несколько страниц, то можно выбрать опцию «Показать все»:
И вот, последнем поле таблицы благополучно расположилась моя тестовая рубрика с ID 45.
К чему я это все рассказываю? Просто я хочу, чтобы Вы имели представление, где находится та или иная информация, касательно категорий, и откуда в дальнейшем ее будут запрашивать различные функции. Если иметь такое представление, то будет гораздо проще понять, как WordPress взаимодействует с базой данных.
Итак, мы выяснили, что id категории, ее название (name) и ярлык (slug) записываются в таблицу wp-terms.
Возникает резонный вопрос, а куда же делось описание? Ведь при создании новой категории, это поле я тоже заполнил.
Все верно описание категории было создано, но записывается оно уже в другую таблицу, которая называется wp_term_taxonomy.
Но прежде, чем начать знакомиться с таблицей wp_term_taxonomy, давайте разберемся, почему она так называется. С wp думаю все понятно, но что это за term? И что это за taxonomy?
Несложные термины
Постараюсь объяснить на пальцах. В WordPress есть категории и есть метки. Так вот, и то и другое является таксономией. Кто-то наверное уже подумал — «Ну вот обещал без сложных терминов, а здесь на тебе пожалуйста, какая-то таксономия».
На самом деле термин таксономия существует довольно давно и изначально он применялся в биологии для классификации растений. Т.е. растение «Ромашка» относится к семейству «Астровые» и т.д. Это и есть классификация или систематизация, как хотите.
Чуть позже этот термин набрал популярность и стал использоваться не только в биологии, но и в геологии, географии, а также во многих других науках и конечно не обошел программирование.
В WordPress действует три вида таксономии:
Категории — слаг «category»,
Метки — слаг «post_tag»,
Ссылки — слаг «link_category»
Также, как в биологии есть виды и есть подвиды, в программировании таксономия может иметь древообразную структуру. Например, категории — подкатегории, а может и не иметь, конечно меток и подметок нет, также как ссылок и подссылок.
Ну вроде бы разобрались! Надеюсь, что теперь термин «Таксономия» не будет вызывать у Вас легкое недопонимание. Идем дальше.
Терм — это наверное больше математическое понятие, но точного определения я так и не нашел. Поэтому объясню значения этого термина, как я его понимаю.
Термом называется объект (например отдельная категория), который находиться в определенной таксономии (таксономия категорий). Понятно, что термом может быть и метка и ссылка.
Отдельный терм не имеет какого-либо функционального значения и может работать только в контексте своей таксономии. В свою очередь таксономия, с набором определенных термов, взаимодействует с n-количеством записей, но об этом чуть позже.
Итак, мы выяснили, что в таблицу wp_term записались данные созданной мной категории (term) с ID — 45, под названием (name) — «Новая рубрика тра ля ля» и слагом (slug) — «novaya-rubrika-tra-lya-lya».
Самое время познакомиться с таблицей wp_term_taxonomy.
Таблица wp_term_taxonomy
Таблица wp_term_taxonomy имеет 6 колонок:
term_taxonomy_id — ID терма в таблице wp_term_taxonomy,
term_id — отражает ID терма из таблицы wp_term,
taxonomy — название таксономии к которой относится терм,
description — описание терма,
parent — ID родительской рубрики (если такая есть),
count — количество записей, относящихся к определенному терму.
А теперь давайте подробней разберем каждое поле.
term_taxonomy_id — понятно, что это id категории, метки или ссылки, но ведь в прошлой таблице wp_terms этот ID тоже записывался. Смысл? А смысл раскрывается в следующем поле.
term_id — вот те раз, так поле с точно таким же названием есть в таблице wp_terms. Все правильно, именно полями term_id в прямом смысле связанны эти две таблицы. Т.е. таблица wp_term_taxonomy получает данные из таблицы wp_terms по ID терма.
taxonomy — это название таксономии, к которой относится тот или иной терм. Выше я уже приводил это названия, но давайте повторим.
category — название таксономии, относящейся к рубрикам,
post_tag — название таксономии, относящейся к меткам,
link_category — название таксономии, относящейся к ссылкам.
Но могут быть и другие названия. Если Вы еще раз взгляните на скриншот, приведенной мной выше, то в поле taxonomy вы увидите название «genre». Откуда оно взялось?
Дело в том, что в WordPress предусмотрена возможность создания своей собственной таксономии, которой можно дать какой угодно название. Я создал такую таксономию и дал ей название «genre», которое и записалось в таблицу wp_term_taxonomy.
В будущем я обязательно расскажу, как создать собственную или произвольную таксономию, так что подписывайтесь на обновления блога
description — вот и нашлось описание, которое я сделал для своей вновь испеченной категории. Теперь мы знаем, где оно храниться! В будущем я обязательно расскажу как использовать данное поле таблицы для вывода описания (description) рубрик в исходный код.
parent — как я уже сказал выше, в данное поле записывается ID родительской рубрики, если такая есть. Но у этого поля есть еще одна очень важная функция. Происходит вторая связь с таблицей wp_terms, так как именно в wp_terms хранится основная информация о терме. Ведь не важно родительская это категория или подкатегория — это терм.
count — в данное поле записывается количество записей связанных с определенным термом. Для чего это нужно? Ну например для этого:
Мы прошлись по всем полям таблицы wp_term_taxonomy и выяснили, что здесь происходит связка родительских категорий и подкатегорий, а также то, что термы привязываются к своим таксономиям и еще, что в данной таблице хранятся описания термов.
Вроде бы все понятно, но мы так и не вразумили один очень важный момент. Каким образом записи привязываются к тому или иному терму?
Чтобы получить ответ на этот вопрос придется познакомится с еще одной таблицей.
Таблица wp_term_relationships
Таблица wp_term_relationships имеет всего три колонки. Если кто не понял, под полями я подразумеваю именно колонки таблицы:
Сразу хочу отметить одну очень важную деталь. Данные моей подопытной категории еще не попали в эту таблицу, так как я не привязал к ней ни одной записи, потому что новые записи для данной категории я еще не создавал.
Получается, что таблица wp_term_relationships это последняя инстанция, в которой происходит привязка категорий к записям. Но давайте обо все по-порядку.
object_id — отражается ID записей из таблицы wp_posts, а также из wp_links (если используются ссылки),
term_taxonomy_id — отражается ID таксономии из одноименного поля таблицы wp_term_taxonomy,
term_order — последовательность, в которой термы были закреплены за записью.
object_id — как я уже сказал выше в данной таблице термы таксономий связываются, или вернее привязываются к записям. Как видите вся связь происходит по id.
Поле object_id служит каналом для перетекания данных в другие таблицы, т.е. таблица wp_posts получает нужную ей информацию о категориях или метках именно через это поле.
Кстати, я вскользь уже описывал поля таблицы wp_posts. Кому интересно, почитайте статью о цикле WordPress.
term_taxonomy_id — понятно, что через данное поле происходит связь с таблицей wp_term_taxonomy, так как в ней есть поле с точно таким же названием. Но кроме того, через это поле происходит контакт ID термов с ID записей.
Может быть такая ситуация, что к одному ID записи привязываются разные ID термов, относящихся к той или иной таксономии (term_taxonomy_id). Это происходит потому, что кроме определенной категории к записи может привязывается метка или несколько меток одновременно, которые имеют свой уникальный ID:
Может быть и обратная модель. Например, к одному term_taxonomy_id привязываются разные ID записи. Это означает, что одна и та же запись находиться одновременно в разных рубриках или одна и та же метка связывает несколько записей:
term_order — по умолчанию сортировка термов в WordPress отключена, но ее можно подключить при создании собственной, или как ее еще называют, пользовательской таксономии, определив аргумент sort = true. По умолчанию false.
На этом я хочу закончить, столь непростое для усвоения повествование, надеюсь что пытливые умы останутся довольны.
Забегая вперед скажу, что в ближайшем будущем мы будем учиться пользоваться данными, хранящимися в вышеупомянутых таблицах, так что следите за обновлениями блога.
До встречи!
С уважением, Виталий Кириллов
Статьи по теме:
Редактор для категорий (рубрик), меток и произвольных таксономий
Шаблоны для категорий WordPress. Как сделать каталог из рубрики
Title, description, keywords и h1 для категорий (рубрик) WordPress
wp_list_categories() — как выводить рубрики WordPress
Спасибо, Виталий, за подробрый обзор! Я, честно говоря, никогда не вникала в эти тонкости. Вот, благодаря Вам, начну строить базу) Жду с нетерпением следующую статью. Интересно, как эти знания можно будет применить с пользой для сайта)
Не за что Наталья! Я рад, что сей материал оказался для Вас полезным. Скажите Наталья, понятно ли я все изложил или надо еще подробней?
Виталий, очень лестно, что Вы спрашиваете моего совета) Мне кажется, кому-то будет все понятно, а для кого-то это покажется «темным лесом». Все зависит от уже имеющихся знаний. Я, например, имею представление о том, как устроена и работает база данных, но кому-то с этими ID и связями между таблицами будет сложно разобраться. А это уже отдельная и огромная тема) Но Вы постарались все очень доступно и подробно объяснить!
Но вот для меня один момент остался не ясен. В таблице wp_term_taxonomy поля term_taxonomy_id и term_id имеют одинаковые значения (по крайней мере, в моей таблице). Какой смысл иметь в таблице два поля с идентичными значениями? Смысл-то наверняка есть, но я не поняла какой))
Наталья, дело в том, что само название поля term_taxonomy_id говорит само за себя. Т.е. через данное поле можно получить данные не только о определенном терме но и, например, о виде таксономии, к которой этот терм относится. В последствии данные, содержащиеся в таблицах wp_term_taxonomy и wp_term, благодаря полю term_taxonomy_id переходят в третью таблицу wp_term_relationships.
Виталий, назначение этого поля (term_taxonomy_id) мне понятно. Но ведь аналогично использованию term_taxonomy_id можно использовать и поле term_id из той же таблицы. Их же значения абсолютно одинаковы. Зачем «засорять» таблицу двумя одинаковыми полями!? Если бы создавались какие-то условия, в результате которых значения этих полей становились различными, тогда было бы понятно. Вот я об этих условиях и спрашивала) Ну да ладно, может, с выходом следующей статьи станет понятнее)
>Если бы создавались какие-то условия, в результате которых значения этих полей становились различными, тогда было бы понятно. Вот я об этих условиях и спрашивала)
Если кого то также еще беспокоит этот вопрос, я нагуглил на форуме разработчиков вордпресс. Суть в том, что в ранних версиях была нормальная практика, когда есть один терм (напр. Ленинград со слагом liningrad) и к этой одной записи в таблице wp_term были подвязаны две записи в wp_term_taxonomy, например таксономия category Ленинград (группа) и таксономия post_tag Ленинград (город).
Этот подход себя не оправдал. Так как если вы решили переименовать тег Ленинград в Санкт-Петербург (меняется строка в wp_terms, а она у нас общая), то переименуется и категория.
Эти так называемые shared terms (термины, используемые несколькими таксономиями) уже запрещено вроде создавать, но из за обратной совместимости нельзя просто взять объединить две таблицы. Но уже в ближайших релизах я думаю мы увидим что это будет сделано: будет одна таблица wp_terms которая включает в себя поля все которые были и в wp_term и в wp_term_taxonomy).
Здравствуйте Дмитрий!
Очень интересный экскурс ранние версии WordPress и думаю Вы очень доходчиво ответили на вопрос Наталии, в отличии от меня)
Спасибо за комментарий!
Я очень далёк от этого…
Интересно…
«При девственной структуре базы данных WordPress должно отобразиться 11 таблиц.
Если же у Вас их большее количество, то винить в этом надо плагины, так как именно они зачастую создают новые таблицы под свой функционал и даже после удаления того или иного плагина, созданная им таблица не редко остается в БД. Это так, информация к размышлению!»
Заглянул в свою базу данных и насчитал там 51 таблицу О_о и это при условии, что я почти не пользуюсь плагинами и пробую новые крайне редко, стараясь по заветам кое-кого реализовывать их функционал кодом)
Наверное у тех, кто забивает сайт плагинами на всё, может быть и не одна сотня таблиц.
Вот я и заинтересовался, нагружают ли они сервер. Если просто лежат в сторонке мёртвым грузом, то не должны и наверное лишний раз в базу данных лучше не лезть, а вот если мёртвые таблицы как-то взаимодействуют с вордпрессом уже после удаления родительского плагина, то это может быть не очень хорошо, особенно со временем.
А так спасибо за наводку) Лично я как-то даже не догадывался смотреть MySQL и не работал с ней дальше периодического запускания плагина по оптимизации базы данных. Уже кое-какой мусор от мёртвых плагинов почистил.
Ещё обратил внимание, что в таблице остаются ВСЕ категории, которые когда-либо создавались, даже если в самой админке вордпреса они были давно удалены. Нашёл в базе данных все категории, которые я создавал, когда ещё только учился пользоваться вордпрессом и игрался с функционалом. Тоже надо будет почистить, когда определюсь с окончательным составом рубрик. Не думаю, что старые категории могут помешать, но вычищать грязь из кода доставляет мне определённое эстетическое удовольствие. А ещё в случае, если придётся что-то править, легче разбораться, когда перед глазами только актуальный работающий код)
Виталий, спасибо, что пишете полезные статьи)
Андрей, я хотел написать в статье, что данные об удаленных категориях, метках или ссылках остаются в БД, просто засоряя ее, но потом мне пришла мысль, что кто-то обязательно заметить мертвые ID и отметит этот момент в комментариях. Как видите, я не ошибся) А вообще, в ходе дальнейшего знакомства с базой данных WordPress я планировал выделить отдельную статью, чтобы рассказать в ней о мусоре в БД и как с ним бороться. Поверьте, кроме мертвых категорий грязи в БД предостаточно.
Здравствуйте, term — может быть сокращенно термин? терминология? Хотя суть от этого не меняется. Вот плагины да, оставляют в базе свои таблицы. Спасибо за информацию.
Здравствуйте Егор! Определение такое, term — это формальное имя объекта (Википедия). Я думаю такое определение вполне подходит.
Сложно все это очень, у обычного вебмастера вряд ли есть столько времени, чтобы вникать в такие подробности. Я просто не поняла, почему именно важно вникать в таксонометрию), если не вникать, то это очень плохо для блога?
Здравствуйте Саша! Конечно вникать не обязательно, но как сказал Андрей в комментарии выше, он был очень доволен, когда «почистил» в БД неиспользуемые теги и категории. Согласитесь, что без базовых знаний лесть в базу данных бессмысленно. Если нет времени, или желания, то рано или поздно придется платить деньги спецам.
Я полностью согласна, что нечего лезть в коды и базы данных, если ничего в этом не понимаешь). Разбираться же не всегда есть время и терпение. И еще потом поняла, что блог то ваш как раз для тех, кто хочет самостоятельно все освоить. В этом его уникальность. Сама кое-что успешно использую, спасибо) и, может, до чистки базы данных как-то дойду.
Статья очень подробная, вся доступным языком, действительно каждый «чайник» поймет) даже такой, как я ! У меня блог так же на вордпрессе, так что для меня очень актуальная информация! Спасибо автору, благодаря таким трудам есть возможность съэкономить
Спасибо Анна!
Отличная статья.
«»С wp думаю все понятно, но что это за trem?»»
По моему ошибка в последнем слове.
Спасибо, уже исправил.
Хорошая статья! Очень понравилась, все доступно, понятно и интересно. Спасибо большое.
Спасибо за статью. Все понятно даже начинающему.
Виталий, спасибо за статью!
Может вопрос немножко не в тему.
В моей БД нашёл пару непонятных таблиц, не подскажите каковы их функции, для чего они и можно ли их удалить?
1. Таблица: wp — см. скрин:
prntscr.com/a5f1m62. Таблица: wp_links_stats — см. скрин:
prntscr.com/a5f4oqСпасибо за помощь!
Виталий, я не знаю что это за таблицы, наверняка хвосты от плагинов. Сделайте копию БД и проведите эксперимент с удалением. Все станет понятно.
А мусор в БД уменьшает скорость загрузки сайта или оказывает излишнюю нагрузку на сервер? (Пишите замечательно, спасибо! Рада, что нашла ваш блог)
Безусловно!
Добрый день, нет ли какого то решения для такой ситуации:
Если у меня допустим 7 категорий с 20-30 подактегориями и в каждой подкатегорией куча товаров, допустим по 50.
Как вот это все добавить чтобы потом не «играться» с перетаскиванием?
Заранее благодарен за ответ или нужное направление действий.
Здравствуйте Ростислав. Вот здесь почитайте.
Спасио что ответили. Виталий честно говоря я не понимаю зачем статья про ссылки ЧПУ когда проблема в меню и надо добавить множество товаров.
Извините Ростислав! Делаю все на бегу, и не так Вас понял. Показалось, что вы наоборот хотите иметь возможность перетаскивать товары из рубрики в рубрику, для этого просто надо создавать определенную структуру ЧПУ. Какой у Вас движок?
Интересная статья
Ставлю жирный лайк:)) Спасибо. Доступно объяснил.