Пользовательские типы сообщений и форматы сообщений: проверка на будущее - является ли один менее "надежным", чем другой?

Почувствовал себя так, словно пробежал марафон, совершенно запыхавшись после прочтения вашего вопроса.

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

ПУНКТ 1

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

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

ПУНКТ 2

Избегайте пользовательских типов сообщений и используйте форматы сообщений! Форматы сообщений поддерживаются ядром WordPress и уже активированы в начальной теме

Как пользовательские типы сообщений, так и форматы сообщений поддерживаются core, и в обоих случаях их необходимо зарегистрировать/добавить, прежде чем их можно будет использовать. Так что этот момент полностью за бортом и даже не должен быть деабатабельным. Да, форматы сообщений уже являются частью начальной темы, но как насчет темы X, когда вы переключаетесь на тему X.

ПУНКТ 3

Пользовательские типы сообщений как есть - не имеют места ни в одной "ленте" за пределами этого сайта.

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

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

ПУНКТ 4

Мне интересно, должен ли я был просто включить 12 сценариев в голову и написать css без препроцессора?

Никогда этого не делай. Всегда используйте крючок wp_register_scripts для добавления символов и стилей в верхний и нижний колонтитулы, где это необходимо, никогда не кодируйте их напрямую в голове ( или нижнем колонтитуле ). Я также никогда не был большим поклонником манипулирования импотентными функциями с помощью языки и платформы на стороне клиента. Проблема в том, что все, что зависит от клиентских функций, может быть обработано конечным пользователем. Кроссбраузерная совместимость также всегда является проблемой. Используйте JS и CSS только для управления номинальной стоимостью сайта ( внешний вид ), никогда не позволяйте ему контролировать работу сайта. Используйте языки на стороне сервера, такие как PHP, для управления этим.

ПУНКТ 5

Действительно ли есть шанс, что пользовательские типы сообщений исчезнут?

Существует определенная вероятность 0%, что пользовательские типы сообщений и/или форматы сообщений когда-либо будут удалены из ядра. Так же, как дополнительная точка, register_post_type() используется для регистрации типов записей по умолчанию post и page и register_taxonomy() используется для регистрации таксономий по умолчанию category, post_tag, post_format и link_category.

Очень редко что-либо удаляется из ядра, амортизация происходит регулярно, но удаление почти никогда. Возьмем, к примеру, все еще разумно используемые параметры caller_get_posts и showposts. Они больше не должны использоваться с версии 3.0, но люди все еще используют их. ( включите отладку, и вы получите четкое уведомление об этом ). Представьте, что разработчики ядра просто удаляют это из ядра.

Ядро Wordpress полностью ориентировано на обратную совместимость (, особенно если функция получает огромное обновление и резко меняется или функция обесценивается ), что является довольно большим преимуществом для не разработчиков. Как разработчик, уведомления добавляются в устаревшие функции/аргументы/и т.д., Поэтому всегда рекомендуется включать отладку при разработке.

Чтобы вернуться к исходной точке, вам никогда не нужно беспокоиться о том, что пользовательские типы записей или форматы записей когда-либо будут удалены из ядра

ПУНКТ 6

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

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

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

ПУНКТ 7

Форматы постов предназначены для оформления постов в определенных сценариях и для микроблогов, когда вам нужны разные категории постов в ленте.

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

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

Неправда. Да, в некотором смысле это группы данных, поскольку для выполнения jus9t используются пользовательские типы записей это, но неверно говорить, что это не посты. Страницы тоже являются сообщениями, как и обычные сообщения, так и сообщения любого пользовательского типа. Ко всем им относятся совершенно одинаково, единственное реальное различие - это иерархия. Сообщения неиерархического типа сообщений (, такие как тип записи "сборка" post) не может быть дочерних записей при иерархических типах записей (, таких как тип записи build in page) могут иметь дочерние сообщения

ЗАКЛЮЧЕНИЕ

Пользовательские типы сообщений ( и, если на то пошло пользовательские таксономии) и форматы сообщений останутся здесь навсегда. То, какой из них использовать, зависит от текущего проекта и от того, что вам удобно. Это требует тщательного планирования заранее. Также очень важно знать, как и где вы должны регистрировать/добавлять функциональные возможности, чтобы сохранить совместимость и удобство использования при изменении тем и т. Д.

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

Удачи в вашем проекте