Руководство по стандартам кодирования WordPress

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

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

Дальнейшее чтение на SmashingMag:

Форматирование кода

PARser PHP не волнует, как вы форматируете свой код, так почему вы должны? На самом деле, формат вашего кода имеет огромное значение во всех возможностях.

Почему код Форматирование вопросы

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

Вот лишь несколько причин обратить внимание на формат кода:

Хорошо сформировавшийся код легче в обслуживании. Вы можете знать, что происходит сегодня, но как насчет через год? Принимая время, чтобы дать структуру вашей работы сэкономит вам эоны времени позже (… Ну, может быть, не эоны).
Другие разработчики не разделяют ваш мозг, поэтому они не поймут ваш хаотический код, или им потребуется много времени, чтобы распутать его. Обеспечение как можно меньше трения в общении в интересах проекта, и этому может способствовать форматирование стандартов.
Чуть менее важно, кто-то, кто учится программировать должны иметь возможность посетить веб-сайт и узнать что-то, глядя на исходный код. Стандарты, как правило, имеют неотъемлемую логику, так что зрителя смогут выяснить, что происходит. Придерживаться стандартов может помочь многим начинающим разработчикам научиться программировать правильно с первого дня.
Во многих случаях хорошее форматирование помогает поддерживать. Многие стандарты требуют, чтобы пространство if из заявлений и других блоков кода. Не скученность кода вместе сделает сообщение «Ошибка на линии 267» гораздо проще исправить.

PHP в WordPress

Разрывы линий

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

$my_value = 'Me';
$your_value = 'You';
$their_value = 'Them';

if ( $my_value == 'You' ) {
  echo 'It seems like you are mixed up with me';
}

Отступ

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

$arguments = array(
    'mythoughts' => array(
    'guitars' => 'I love guitars',
    'applepie' => 'Apple Pie is awesome'
  ),
    'yourthoughts' => array(
    'guitars' => 'Meh',
    'applepie' => 'Love it!'
  )
);

if ( have_posts() ) {
  while ( have_posts() ) {
    get_template_part( 'template', 'blogpost' );
  }
}

Использование пространства

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

$number = (integer) $_GET['number'];
if ( $number === 4 ) {
  echo 'You asked for a four!';
}

Котировки

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

$name = 'Daniel';
$hello = "My name is '$name'";

Брекеты

Самый простой способ заключается в том, чтобы всегда использовать скобки. Стандарты позволяют бездействие скобки для однострочных if заявлений, но только если нет многолинейных блоков в той же логической структуре. Однако для однолинейных петель не допускается опущение брекетов. Я считаю, этот стандарт слишком запутанной — просто всегда требующих скобки будет гораздо проще. Кроме того, стандарты диктуют, что открытие скобки должны быть поставлены на той же линии, как первоначальное заявление, а не на линии ниже (как указано в документации PHP).

// The usual style
if ( have_posts() ) {
  the_post();
  the_content();
}
else {
  echo 'Steal ALL the posts!';
}

// Leaving out braces in this case is allowed.
if ( ! has_post_thumbnail() )
  echo 'This post does not have a featured image';

// But putting them in looks nicer and is more consistent.

if ( has_post_thumbnail() ) {
  the_post_thumbnail();
}

Форматирование запросов S’L

Ключевые слова запроса S’L должны быть капитализированы, а сложные запросы должны быть разбиты на несколько строк. Нужно знать много о запросах, прежде чем использовать их, особенно в отношении их безопасности; Мы прикроем их дальше.

$simple_query = "SELECT * FROM $wpdb->posts WHERE comment_count > 3 LIMIT 0, 10";

$complex_query = "
SELECT * FROM $wpdb->posts WHERE
post_status = publish AND
comment_count > 5 AND
post_type = 'post' AND
ID IN ( SELECT object_id FROM $wpdb->term_relationships WHERE
term_taxonomy_id = 4 )
";

Конвенции о наименовании

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

Имена файлов должны быть в нижнем регистре, с дефисами, разделяющими части имени. Если файл содержит один класс, назовите его по имени класса, прикреплительного. class-

Используйте значения строк для аргументов функции, а не booleans, чтобы сделать ваш код более очевидным.

$event = new My_Event();
$event->save_event_to_file( 'event-file.txt', 'noformatting' );

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

Сравнительные заявления

Одна большая практика, и не только для WordPress, это всегда писать переменную в сравнении на правой стороне. Таким образом, если вы забыли равный знак, парсер будет бросать ошибку вместо оценки true .

if ( 3 == $my_number ) {
  echo 'BINGO!';
}

Если вы предпочитаете использовать ternary операторов, стандарты позволяют сделать это, но советуют, что вы всегда проверить на правду, чтобы сделать вещи яснее. Одно из упомянутых исключений при проверке непустых ! empty() переменных, .

Обзор

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

Форматирование HTML

Кодекс WordPress гласит, что весь HTML-код должен быть проверен с помощью w3C Validator. Позаботьтесь, потому что действительный код не обязательно хороший код, хотя есть определенная корреляция.

Doctype

WordPress основан на спецификации XHTML 1.0, которую W3C рекомендовал еще в 2000 году.

Беглый взгляд на тему Двадцать одиннадцать показывает, что, несмотря на рекомендацию W3C, WordPress использует HTML5 для этой темы по умолчанию. Там, кажется, конфликт здесь, но на самом деле нет. HTML5 включает в себя раздел о сериализации XML, что фактически означает, что «XHTML5» может быть использован.

Использование кавычек

Цитаты в основном используются при размещении атрибутов и их значений. Вы можете использовать одиночные или двойные котировки. Будьте последовательны, однако. Хотя я предпочитаю внешний вид двойных котировок (хотя я понятия не имею, почему), я использую одиночные цитаты, где это возможно в HTML. Моя аргументация заключается в том, что, поскольку отдельные котировки необходимы в PHP, я мог бы также последовать их примеру в HTML.

Следуя этой методологии, я могу видеть, происходит ли что-то «специальное» в строке, просто глядя на котировки.

Теги закрытия

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

Отступ

Правила для отступа HTML соответствуют правилам для отступов PHP. Стремитесь к логической структуре с вашим отступом. При смешивании PHP и HTML блоки PHP должны быть отступом в соответствии с нормальным потоком отступов.

<div class='<?php post_class() ?>'>
<h1><?php the_title() ?></h1>
<?php if ( has_post_thumbnail() ) : ?>
<strong>Featured Image</strong>
<?php the_post_thumbnail() ?>
<?php endif ?>
</div>

Форматирование CSS

Последовательный стиль так же важен в CSS, как и в PHP и HTML. Когда пользователь хочет изменить небольшую деталь в вашей теме, он неизбежно окажется в файле CSS. Таким образом, CSS может быть наиболее заметным кодом, который вы пишете. Документ«CsS Standards»— это «грубый проект». Большая часть того, что есть, вероятно, там, чтобы остаться, но, как указано на самой странице, все это может быть изменено.

Следуйте проекту внимательно. Если что-то изменится, вы все равно будете в курсе большинства руководящих принципов; и если существующий код CSS не придерживается его 100%, причина будет понятна.

Отступы и структура

Ваш CSS должен следовать этой грубой схеме:

CSSselector {
  property: value;
  property: value;
}
selector,
selector,
selector {
  property: value;
  property: value;
}

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

Конвенции о наименовании

Используйте только символы нижнего регистра.
Отдельные слова в селектора с дефисом.
Дайте селекторам читаемые имена.

Свойства и ценности

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

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

.button {
  background: #34c1ff;
  -moz-border-radius: 5px;
  -webkit-border-radius: 5px;
  border-radius: 5px;
  color: #fff;
  margin: 11px;
  position:relative;
  left:5px;
  top: 5px;
  width:120px;
  height:22px;
}

Комментируя

CSS поддерживает только один тип комментариев — стиль блока; он не имеет отдельной обозначения для внеочередных комментариев. Напишите короткие комментарии на одной строке, без разрыва строки ниже. Для комментариев, охватывающих несколько строк, вставьте разрыв строки сразу после синтаксиса открытия и разрыв строки непосредственно перед закрытием синтаксиса.

/* Default link style /*
a {
  color: #ff9900;
}

/*
Some other quick link styles
so that users can easily use
whatever they need
*/

a.prominent {…

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

a {
  background: #efefef;
}
*/ Post Content Styling
--------------------------------------------------- */

.post-content {
  padding: 22px;
}

Использование препроцессоров CSS

Использование препроцессоров CSS, таких как SASS и Less, делает нашу жизнь как разработчиков намного проще, но они не лишены недостатков. Код, производимый этими инструментами, обычно действителен, но нельзя сказать, что он очень чистый. Лист стиля, произведенный вручную (и вдумчиво), будет гораздо более читаемым, чем лист, автоматически произведенный Less.

Это зависит от того, что вы делаете. Если ваш продукт является коммерческим, то конечной целью является хороший пользовательский опыт, с действительным и оптимизированным кодом. В этом случае используйте выход препроцессора в качестве основного CSS, но включите исходный файл для разработчиков. Хотя ваш CSS не будет соответствовать стандартам WordPress, в том числе оригинальный файл мосты разрыв несколько, пока WordPress занимает официальную позицию.

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

Другие языки

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

Общие руководящие принципы развития

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

Информация и документация

Темы и плагины, так поставляются с кучей информации. Проект обычно содержит четыре типа информации:

Информация о теме или самом плагине;
Дополнительная информация, которую автор хочет поделиться о проекте или о себе;
Внее кодовая документация (кодекс имеет руководство для этого);
Отдельная документация для конечных пользователей.

Использование крючков

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

Чаще всего, достижение чего-то в WordPress чувствует себя труднее, чем это должно быть. Хотите изменить длину отрывка? Посмотри на excerpt_more крючок. Хотите изменить содержимое письма, которое пользователи получают, когда забывают свой пароль? Проверь retrieve_password_message крючок.

Всякий раз, когда вы работаете на что-то, сделать быстрый поиск Google или сканирование АдамА Брауна крючки базы данных для соответствующего крючка.

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

Для обширного обзора, посмотрите на наш«Полное руководство wordPress Крючки«. И в разделе о плагинах и темы ниже, мы рассмотрим еще несколько советов по конкретным крючки.

Безопасности

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

Используйте nonces для проверки личности пользователя и намерения.
Побег и подготовить заявления S’L.
Санитизация и проверка пользовательского ввода.
Используйте роли и возможности, чтобы убедиться, что пользователи могут делать то, что они делают.
Воронка AJAX ajax-admin.php просит, и использовать крючки для обработки этих запросов.

Чтобы узнать больше о WordPress безопасности в целом, посмотрите на «Обеспечение вашего WordPress веб-сайт«.

Чтобы узнать больше о безопасности базы данных и о том, чтобы ваши запросы S’L были герметичными, дайте«Взаимодействие с базой данных WordPress»читать.

Конфиденциальности

Всегда уважайте конфиденциальность пользователей. WordPress не позволяет создавать расширения, которые «телефон домой». Если вы хотите собрать информацию о пользователе, то вы должны использовать метод выбора в котором пользователи осведомлены о том, что происходит, и явно дать вам разрешение. Руководящие принципы не позволяют для каких-либо hotlinking в комплекте ресурсов. Любой ресурс, который вы используете, должен быть в комплекте с вашим продуктом. Однако вызовы типа API являются приемлемыми.

Играя Ницца с другими

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

Не пишите свой собственный код pagination; WordPress имеет совершенно хорошую paginate_links() функциональность, доступную в . Не используйте отдельную или кровоточащую версию j’ury, когда один wp_enqueue_script() уже доступен в WordPress, окаймая его с .

Тестирования

Надежность вашего продукта является вашей ответственностью. Ваш код должен пройти тщательное тестирование, по крайней мере себя (чем больше, тем лучше, хотя). Многие разработчики следят за разработкой, управляемой тестами (TDD), целью которой является минимизация количества всплывающих ошибок. Посмотрите на «Написание единицы испытаний для WordPress Плагины» для подробного учебника о том, как начать.

Обслуживания

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

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

Лицензирования

Лицензия, которая требуется использовать, зависит от типа разрабатываемого продукта. Чтобы отправить тему или плагин в репозиторий WordPress, необходимо использовать лицензию, совместимую с GPL. Это фактически означает, что ваша работа должна быть свободной, потому что все несвободные лицензии автоматически не GPL. Не забудьте четко указать лицензию в вашем продукте.

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

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

Если вы ищете некоторые GPL-совместимые наборы значков, «Тема Обзор» документ ссылки на изрядное количество из них.

Лучшие практики развития темы

Существует длинный список правил, руководящих принципов и передовой практики, которые необходимо придерживаться при разработке темы WordPress. Большинство из них логичны, и все служат своей цели. Мы рассмотрим наиболее важные биты ниже, и полный список можно найти в «Тема Обзор» документ. Вы можете оценить соблюдение вашей темы к большинству из этих правил с плагином проверки темы.

Ошибки и функциональность

Ваша тема должна пройти пять уровней правил и руководящих принципов:

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

Включены функции

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

Необходимые функции:

Автоматические каналы ссылки
Виджеты
Комментарии

Рекомендуемые функции:

Меню навигации
Опубликовать эскизы
Пользовательский заголовок
Пользовательский фон
Индивидуальный стиль визуального редактора

Дополнительные функции:

Интернационализации

Каждая функция выше имеет одну или несколько функций, которые ваша тема должна содержать. Для просмотра полного списка, см.

Крючки и шаблон теги

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

wp_head()
body_class()
$content_width
post_class()
wp_link_pages()
paginate_comments_linkили previous_comments_link() иnext_comments_link()
posts_nav_link()или previous_posts_link() и next_posts_link() илиpaginate_link()
wp_footer()

Примерно в 90% случаев я видел, плагин не будет работать с темой, потому что тема отсутствует wp_head() или wp_footer() крючок.

Включая файлы и ресурсы

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

Звоните header.php сget_header()
Звоните footer.php сget_footer()
Звоните sidebar.php сget_sidebar()
Звоните comments.php сcomments_template()
Звоните searchform.php сget_search_form()

Если вы создаете дополнительные шаблоны для вашей темы, то вы должны позвонить им с помощью get_template_part() или locate_template() функций (последний лучше всего использовать с детьми темы).

При включении стилей и скриптов необходимо использовать wp_enqueue_style() wp_enqueue_script() и, вместо жесткого кодирования их. Единственным исключением является тематический лист, style.css который может быть добавлен к главе документа.

WordPress-определенные CSS классы

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

Классы выравнивания:

.alignleft
.alignright
.aligncenter

Классы подписей:

.wp-caption
.wp-caption-text
.gallery-caption

Почтовые классы:

.sticky

Классы комментариев:

.bypostauthor

Если вы не намерены стиль их по-разному, то .sticky и .bypostauthor классы могут быть оставлены пустыми, но они должны существовать в стиле листа, тем не менее. Этот список, вероятно, откормить с течением времени для учета меняющиеся требования.

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

Тематические файлы

Количество файлов в вашей теме может сильно варьироваться, в зависимости от того, насколько сложна тема. Он также может работать отлично только с простым index.php файлом. Выбор за вами. «Тема Обзор» предлагает следующие руководящие принципы.

Требуемые файлы:

index.php
comments.php
screenshot.png
style.css

Рекомендуемые файлы:

404.php
archive.php
page.php
search.php
header.php
footer.php
sidebar.php

Дополнительные файлы:

attachment.php
author.php
category.php
date.php
editor-style.php
image.php
tag.php

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

Например, не создавайте файл для page-about.php включения где-нибудь, потому что, с тем, как шаблоны обрабатываются, если пользователь создает страницу под названием «О», то page-about.php будет использоваться для его отображения.

Тематические варианты

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

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

Имена тем

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

Слово «WordPress»;
Слово «тема», или любое связанное с ним слово, такое как «блог», «шаблон» или «кожа»;
Термины, связанные с версиями или разметкой (HTML5, CSS3 и так далее);
Кредит вкладчику;
Любое ключевое слово спам.

Тема Кредиты

Мы все хотим, чтобы наше имя написано огромным жирным текстом в заголовке веб-сайта, но это (к счастью) не так, как WordPress или с открытым исходным кодом сообщество работает. Кредит может быть предоставлен, конечно. Вот что вы можете сделать:

Вы можете использовать author строку URI в файле style.css для ссылки на ваш личный или профессиональный веб-сайт.
Вы можете использовать theme строку URI в style.css файле для ссылки на демонстрацию темы.
Вы можете включить одну ссылку в колонтитул темы. Это должен быть либо автор URI или тема URI, которую вы определили в style.css файле.
Вы также можете иметь более сложный раздел или модуль для саморекламы, но это должно быть opt-in.
Вы не можете запретить пользователям удалять эти ссылки.
Прежде всего, вы не можете использовать любой из них для спама или для саморекламы, не связанных с данным продуктом.

Документации

Существуют различные способы справиться с этим, но ваша тема должна иметь какую-то документацию. Рекомендуемый метод заключается в включении readme.txt файла в тему, которая охватывает всю информацию, которую пользователь должен знать. Это должно быть в формате Markdown, что readme.txt файлы для использования плагинов. Я также рекомендую создавать более удобную документацию в виде веб-сайта, файла PDF или т.п. Я предпочитаю автономную документацию, такую как файл PDF, потому что он останется доступным для пользователя, несмотря ни на что.

Для большой учебник, читать«Как улучшить ваш WordPress Plugin’s Readme.txt.» Статья относится к плагинам, но формат Markdown и общая идея одинаковы для тем.

Лучшие практики разработки плагинов

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

Из-за этого, стандарты и лучшие практики для плагинов разбросаны по многим страницам WordPress Codex и веб-сайты разработчиков. Хорошее место для начала является«Плагин ресурсов»,где вы найдете информацию для наиболее распространенных случаев и несколько необычных из них.

Плагин Именование

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

Файлы плагинов

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

Информация о вашем плагине

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

/*
Plugin Name: The Missing Task Manager
Plugin URI: http://tmtm.com
Description: A simple task manager for your WordPress website
Version: 1.2
Author: Good Guy Greg
Author URI: http://imtheauthor.com
License: GPL2
*/

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

Использование крючков

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

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

Разработчики, как правило, упускают из виду три крючка, в частности, что позволит им добавить большую функциональность их плагина. Вот они ниже.

Безопасности

Используйте nonces для проверки личности пользователя и намерения.
Побег и подготовить заявления S’L.
Санитизация и проверка пользовательского ввода.
Используйте роли и возможности, чтобы убедиться, что пользователи могут делать то, что они делают.
Воронка AJAX ajax-admin.php просит, и использовать крючки для обработки этих запросов.

Чтобы узнать больше о WordPress безопасности в целом, посмотрите на «Обеспечение вашего WordPress веб-сайт«.

Конфиденциальности

Играя Ницца с другими

Тестирования

Обслуживания

Лицензирования

Лучшие практики развития темы

Ошибки и функциональность

Ваша тема должна пройти пять уровней правил и руководящих принципов:

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

Включены функции

Необходимые функции:

Автоматические каналы ссылки
Виджеты
Комментарии

Рекомендуемые функции:

Меню навигации
Опубликовать эскизы
Пользовательский заголовок
Пользовательский фон
Индивидуальный стиль визуального редактора

Дополнительные функции:

Интернационализации

Крючки и шаблон теги

wp_head()
body_class()
$content_width
post_class()
wp_link_pages()
paginate_comments_linkили previous_comments_link() иnext_comments_link()
posts_nav_link()или previous_posts_link() и next_posts_link() илиpaginate_link()
wp_footer()

Включая файлы и ресурсы

Звоните header.php сget_header()
Звоните footer.php сget_footer()
Звоните sidebar.php сget_sidebar()
Звоните comments.php сcomments_template()
Звоните searchform.php сget_search_form()

WordPress-определенные CSS классы

Классы выравнивания:

.alignleft
.alignright
.aligncenter

Классы подписей:

.wp-caption
.wp-caption-text
.gallery-caption

Почтовые классы:

.sticky

Классы комментариев:

.bypostauthor

Тематические файлы

Требуемые файлы:

index.php
comments.php
screenshot.png
style.css

Рекомендуемые файлы:

404.php
archive.php
page.php
search.php
header.php
footer.php
sidebar.php

Дополнительные файлы:

attachment.php
author.php
category.php
date.php
editor-style.php
image.php
tag.php

Тематические варианты

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

Имена тем

Слово «WordPress»;
Слово «тема», или любое связанное с ним слово, такое как «блог», «шаблон» или «кожа»;
Термины, связанные с версиями или разметкой (HTML5, CSS3 и так далее);
Кредит вкладчику;
Любое ключевое слово спам.

Тема Кредиты

Вы можете использовать author строку URI в файле style.css для ссылки на ваш личный или профессиональный веб-сайт.
Вы можете использовать theme строку URI в style.css файле для ссылки на демонстрацию темы.
Вы можете включить одну ссылку в колонтитул темы. Это должен быть либо автор URI или тема URI, которую вы определили в style.css файле.
Вы также можете иметь более сложный раздел или модуль для саморекламы, но это должно быть opt-in.
Вы не можете запретить пользователям удалять эти ссылки.
Прежде всего, вы не можете использовать любой из них для спама или для саморекламы, не связанных с данным продуктом.

Документации

Лучшие практики разработки плагинов

Плагин Именование

Файлы плагинов

Информация о вашем плагине

/*
Plugin Name: The Missing Task Manager
Plugin URI: http://tmtm.com
Description: A simple task manager for your WordPress website
Version: 1.2
Author: Good Guy Greg
Author URI: http://imtheauthor.com
License: GPL2
*/

Использование крючков

Подключение к активации

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

Деактивационный крюк

register_deactivation_hook()Крючок похож на крючк активации. Он работает, когда плагин деактивирован и позволяет сделать некоторые очистки до плагина деактивирован.

Установить крючок

Когда плагин не установлен, register_uninstall_hook() крючок может быть использован для выполнения некоторых задач. Вы должны сделать тщательную очистку после того, как ваш плагин был неустановлен; не обременяйте пользователя ненужными данными.

Стек Exchange имеет большой учебник по созданию класса, который обрабатывает все три функции.

Для получения дополнительной информации о крючки, проверить ранее упомянутые «WordPress Основы: Окончательное руководство wordPress Крючки» здесь, на Smashing Magazine.

Обработка данных

Существует три способа хранения и извлечения данных в плагине:

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

API механизма опционов и настроек

Механизм опций — это простой способ хранения именных фрагментов данных в базе данных. Это может быть использовано для опций в масштабах всего веб-сайта и других относительно статических данных. Настройки API был введен в WordPress 2.7 и в основном развивается версия механизма опций. Поскольку в конечном итоге потребуется использование API параметров, использование его вместо механизма опций является хорошей идеей.

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

Механизм после мета

Механизм post meta обеспечивает удобный способ хранения данных, относящихся к конкретной должности. Его функциональность очень похожа на функционал механизма опций. Это позволяет добавлять, обновлять, удалять или получать пользовательские поля. Прочитайте Кодекс для нюансов использования, но освоение этого должно быть довольно легко.

Создание новых таблиц баз данных

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

Используйте $wpdb класс и функции, которые он предоставляет. Для получения дополнительной информации о безопасности базы данных обратитесь к общему разделу, указанному выше в разделе о безопасности.

Интернационализации

Интернационализация не требуется, но это хорошая идея, если вы хотите добавить плагин в репозиторий или продать его. Это позволяет пользователям и разработчикам добавлять переводы в ваш плагин очень легко. Подготовка плагина для интернационализации занимает некоторое время, если вы никогда не делали этого раньше; для размещения переводных строк требуется сторонние инструменты и внештатные данные в код. Ваш лучший друг в этом предприятии будет i18n для WordPress разработчиков.

Обзор

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

Бродяотка от стандартов

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

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

Изгиб правил

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

Если вы планируете выпустить веб-приложение, кодирование его с нуля может занять некоторое время, но вы можете мириться тестовая версия на основе WordPress довольно быстро. В этом случае, изгиб несколько правил (например, о сохранении плагинов и темы различных) является приемлемым.

Многие великие вещи были созданы путем изгиба правил; хитрость заключается в том, зная, когда это сделать. Если у вас есть веские причины, и вы документ по пути, вы должны быть в безопасности. Ключевым моментом является общение: убедиться, что другие разработчики (и вы, позже) понять причины того, что вы сделали.

Заключение

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

Существует гораздо больше, чтобы знать о развитии WordPress, так что ниже куча ссылок, чтобы помочь вам на вашем пути к просветлению.

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

Дальнейшее чтение

Общие гиды:

«WordPress Кодинг стандарты,»WordPress Кодекс
«Вливая документация,»WordPress Кодекс
«Настройки API Учебник,»Отто на WordPress
«Руководстводля Nonces,»Марк Jaquith
«Знай свои источники,»WordPress CodexA много общих связей развития здесь.
«ШаблонТеги,»WordPress Кодекс
«Функция Ссылка,»WordPress Кодекс
«Проверка данных,»WordPress Кодекс
«Описание базы данных,»WordPress Кодекс
«Создание вариантов Страницы,»WordPress Кодекс

Тематические справочники:

«Тема Обзор«, WordPress Кодекс
«Тесттематиного блока,»WordPress Кодекс
«WordPress Тема развития,»WordPress Кодекс
«ШаблонИерархия,»WordPress Кодекс
«WordPress генерируется CSS классов,»WordPress Кодекс

Руководства, связанные с плагинами

«Написание плагина,»WordPress Кодекс
«Плагин ресурсы,»WordPress Кодекс
«Пример readme.txt файл,»WordPress
«Книгаразвития плагинов»,Владимир Преволак
«WordPress Крючки Справка,» Адам Браун
«Plugin API,»WordPress Codex
«Плагин Представления и поощрения,»WordPress Кодекс
«AJAX в плагинах,»WordPress Кодекс

Источник: smashingmagazine.com

Дальнейшее чтение на SmashingMag:

Форматирование кода

Почему код Форматирование вопросы

PHP в WordPress

Форматирование HTML

Форматирование CSS

Общие руководящие принципы развития

Информация и документация

Использование крючков

Безопасности

Конфиденциальности

Играя Ницца с другими

Тестирования

Обслуживания

Лицензирования

Лучшие практики развития темы

Ошибки и функциональность

Включены функции

Крючки и шаблон теги

Включая файлы и ресурсы

WordPress-определенные CSS классы

Тематические файлы

Тематические варианты

Имена тем

Тема Кредиты

Документации

Лучшие практики разработки плагинов

Плагин Именование

Файлы плагинов

Информация о вашем плагине

Использование крючков

Безопасности

Конфиденциальности

Играя Ницца с другими

Тестирования

Обслуживания

Лицензирования

Лучшие практики развития темы

Ошибки и функциональность

Включены функции

Крючки и шаблон теги

Включая файлы и ресурсы

WordPress-определенные CSS классы

Тематические файлы

Тематические варианты

Имена тем

Тема Кредиты

Документации

Лучшие практики разработки плагинов

Плагин Именование

Файлы плагинов

Информация о вашем плагине

Использование крючков

Обработка данных

Интернационализации

Обзор

Бродяотка от стандартов

Изгиб правил

Заключение

Дальнейшее чтение

Sharing is caring

Понравилось это:

Похожее

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