Предложения по усовершенствованию тем в WordPress 3.9

Дата публикации:Февраль 8, 2014

Вчера в блоге make.wordpress.org были опубликованы предложения от Чипа Беннетта, связанные с усовершенствованием WordPress-тем для версии WordPress 3.9. На данный момент все предложения находятся на стадии обсуждения. Они были разбиты на две группы: обязательные и рекомендуемые. Давайте посмотрим, что именно предложил Чип для внесения в WP 3.9.

Обязательные предложения:

  1. Темы должны корректно работать по умолчанию. Темы не должны вносить какие-либо дефолтные настройки в базу данных без явного пользовательского действия. Темы должны функционировать соответствующим образом «из коробки» без пользовательской настройки (если пользователь не вводил параметры, тема должна по-прежнему корректно работать).
  2. Тема не должна поставляться со связанными плагинами. Темы могут иметь поддержку плагинов и могут включать в себя код плагинов, однако темы не должны поставляться вместе со связанными плагинами.
  3. Темы не должны предлагать опции для добавления произвольных скриптов в хэдер/футер. Произвольные скрипты – это не связанные с темой скрипты, которые добавляются в хэдер или футер документа с целью реализации нехарактерной для тем функциональности. Эти скрипты должны быть реализованы в виде плагинов, поскольку они представляют угрозу безопасности в случае такого применения. Произвольный CSS-код приемлем, если он должным образом обработан.
  4. Темы не должны применять редиректы при активации, уведомления для администраторов и аналогичную функциональность.
  5. Темы должны размещать всю необходимую документацию в четко структурированном readme-файле. К необходимой документации следует отнести лицензию/копирайт, ограничения дизайна темы, описание нестандартной функциональности и т.д. Стандартный для плагинов файл readme.txt предпочтителен, но не является обязательным.
  6. Темы должны иметь в readme файле копирайт/лицензию для всех поставляемых вместе с темой ресурсов. Важно, чтобы пользователям не нужно было искать эту информацию по разным файлам. Разработчики смогут легко убедиться в том, что все связанные ресурсы являются GPL-совместимыми.
  7. Темы должны использовать разные ThemeURI и AuthorURI (либо использовать одно значение). Если эти адреса являются одинаковыми, то не нужно использовать сразу и ThemeURI, и AuthorURI. Достаточно будет одной ссылки. ThemeURI – это ресурс, связанный с темой. AuthorURI – ресурс, связанный с разработчиком. К примеру, магазин тем вполне может обойтись одной ссылкой ThemeURI. Некоммерческий разработчик может указать только ссылку AuthorURI. Однако если некоммерческий разработчик в качестве ThemeURI задал github.com/authorname/theme-name, а в качестве AuthorURI — exampleperson.com, то это вполне допустимо. Важно понимать, что ThemeURI сводится к получению информации о теме, а AuthorURI – к контактам с разработчиками. Отсюда и нужно исходить об уместности применения ThemeURI/AuthorURI.

Рекомендуемые предложения:

  1. Темы должны включать в себя документацию в виде readme.txt файла. Также темы должны следовать базовому стандарту встроенной документации в WordPress.
  2. Темы должны быть готовыми к переводу.
  3. Темы должны использовать произвольное навигационное меню, в котором будут находиться ссылки на социальные сервисы.
  4. Опции тем должны быть интегрированы в кастомайзер тем.

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

Источник: make.wordpress.org

Поделиться

2 комментария

  1. gOuTM says:

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

  2. Goodwin says:

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

Оставить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

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