Примеры написания кода в wp. Полезные вставки (фрагменты) кода для WordPress

Чтобы код WordPress везде был оформлен в одном стиле и удобно читался в ядре, плагинах и темах, рекомендуется соблюдать стандарты написания кода, которые приняты разработчиками WordPress. Эти стандарты очень похожи на стандарт PEAR , однако есть и кардинальные отличия. Рекомендую ознакомится с ними и при создании плагинов или тем, по возможности, их соблюдать.

Кроме стандартов к написанию самого кода PHP, также есть стандарты документирования кода - это комментарии к функциям и хукам: PHP Documentation Standards (англ.)

Одинарные и двойные кавычки

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

Echo "Link name"; echo "$linkname";

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

Отступы

Отступ должен всегда показывать логическую структуру кода. Используйте табуляцию (клавиша Tab), а не пробелы - это дает больше гибкости. Пробелы стоит использовать, когда нужно выравнять что-либо внутри строки.

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

If (условие) { $foo = "somevalue"; $foo2 = "somevalue2"; $foo_bar = "somevalue3"; $foo5 = "somevalue4"; }

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

If (условие) { ---$foo.....= "somevalue"; ---$foo2....= "somevalue2"; ---$foo_bar.= "somevalue3"; ---$foo5....= "somevalue4"; }

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

$my_array = array(---"foo"...=> "somevalue", ---"foo2"..=> "somevalue2", ---"foo3"..=> "somevalue3", ---"foo34".=> "somevalue3",);

Стиль фигурных скобок

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

If (условие) { action1(); action2(); } elseif (условие2 && условие3) { action3(); action4(); } else { defaultaction(); }

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

Следует комментировать любой код, который интуитивно не понятен.

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

If (условие) { action0(); } if (условие) { action1(); } elseif (условие2) { action2a(); action2b(); } foreach ($items as $item) { process_item($item); }

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

$var = "dangerous""; // необработанные данные, которые могут быть экранированы или не экранированы $id = some_foo_number(); // данные ожидаются как число, но мы не уверены $wpdb->query($wpdb->prepare("UPDATE $wpdb->posts SET post_title = %s WHERE ID = %d", $var, $id));

%s используется для строк и %d для целых чисел. Обратите внимание, что они не "в кавычках" ! $wpdb->prepare() сам экранирует строки и добавляет кавычки, если надо. Преимущество prepare() в том, что не нужно помнить о ручном использовании esc_sql() , а также, что строка запроса с плейсхолдерами более наглядна, чем если бы там использовались переменные обернутые в esc_sql() .

Запросы базы данных

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

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

Имена классов, функций, файлов, констант, переменных Имена функций, переменных, хуков

Используйте строчные буквы a-z в переменных, хуках и названиях функций и никогда CamelCase . Разделяйте отдельные слова нижним подчеркиванием _ . Не сокращайте имена переменных без необходимости; пусть код будет однозначным и само-документированным.

Function some_name($some_variable) { [...] }

Имена классов

Нужно использовать слова с Заглавных_Букв, разделенные подчеркиванием. Любые сокращения (акронимы, аббревиатуры) должны быть ПРОПИСНЫМИ.

Class Walker_Category extends Walker { [...] } class WP_HTTP { [...] }

Константы должны быть словами в ВЕРХНЕМ_РЕГИСТРЕ, разделенные нижним подчеркиванием:

Define("DOING_AJAX", true);

Названия файлов

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

My-plugin-name.php

Названия файлов классов

Должны быть основаны на имени класса с приставкой class- , подчеркивания в имени класса заменены дефисом, например WP_Error становится:

Class-wp-error.php

Этот стандарт именования файлов справедлив для всех существующих и новых файлов с классами. Однако существуют файлы исключения: class.wp-dependencies.php , class.wp-scripts.php , class.wp-styles.php . Эти файлы имеют префикс class. , точка после слова class вместо дефиса.

Понятные значения переменных в параметрах функций

Булевам, предпочтительны строковые значения. Т.е. вместо true/false при вызове функций лучше использовать какую-то объясняющую значение параметра строку.

Плохой код:

Function eat($what, $slowly = true) { ... } eat("mushrooms"); eat("mushrooms", true); // что означает true? eat("dogfood", false); // что означает false, противоположность true?

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

Хороший код:

Function eat($what, $speed = "slowly") { ... } eat("mushrooms"); eat("mushrooms", "slowly"); eat("dogfood", "quickly");

Когда нужно больше параметров функции, используйте массив $args . Он даже лучше!

Очень хороший код:

Function eat($what, $args) { ... } eat("noodles", array("speed" => "moderate"));

Интерполяция для имен динамических хуков

Для удобства чтения и обнаружения, хуки с переменными в названии должны быть интерполирован (заключен в фигурные скобки { и }), и не должны конкатенироваться:

Скобки нужны, чтобы PHP мог корректно анализировать типы данных переменных в интерполированной строке.

// правильно do_action("{$new_status}_{$post->post_type}", $post->ID, $post); // неправильно do_action($new_status ."_". $post->post_type, $post->ID, $post);

Там, где это возможно, динамические значения в именах тегов также должны быть максимально краткими и точными. $user_id гораздо понятнее чем, скажем, $this->id .

Тернарный оператор

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

Как нужно проверять:

// (если условие выполняется = true) ? (то делаем это) : (иначе это); $music_type = ("jazz" == $music) ? "cool" : "blah"; // (если значение не пустое - ! empty) ? (то делаем это) : (иначе это);

Как не следует писать:

// (если условие не выполняется!= true) ? (то делаем это) : (иначе это); $music_type = ("jazz" != $music) ? "blah" : "cool";

Условия Магистра Йоды

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

If (true == $the_force) { $victorious = you_will($be); }

Если пропустить второй знак = в приведенном примере (признаться, это происходит даже с самыми опытными из нас), то мы получим ошибку PHP и сразу её увидим, потому что код не будет работать. А вот если бы конструкция была обратной - $the_force = true , то условие всегда будет выполняться и никакой ошибки мы не увидим, и можем пропустить такой серьезный баг, который к тому же иногда сложно отловить!

К такому «перевернутому» написанию просто нужно привыкнуть.

Это относится и к == , != , === и!== . «Условия Йоды» для < , > , = значительно труднее читать и тут их лучше не использовать.

Умный код

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

Isset($var) || $var = some_function(); // или! isset($var) && $var = some_function();

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

If (! isset($var)) { $var = some_function(); }

Оператор подавления ошибок @

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

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

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

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

Вы идете на «склад» плагинов для wordpress и обнаруживаете, что необходимого плагина для Вас нету. Что же делать? Как быть? Если вы хотя бы немного знакомы с азами программирования на php, верстке, то Вам не составит труда Самому написать плагин для WordPress .

А теперь отправимся на «кухню» для приготовления нашего плагина.

P.s. Если знаний в php и верстке нету… не расстраивайтесь, попросите кого-либо написать Вам нужный функционал 🙂

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

Я не буду дублировать эту информацию, а сразу перейду непосредственно к написанию кода.

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

Первое, что мы сделаем, это придумаем уникальное название нашему плагину - «AdvUserReviews «.

Далее создадим в директории Вашего сайта «/wp-content/plugins/» новую директорию «advuserreviews». И в ней создадим файл «advuserreviews.php». Это будет основной файл, который будет отвечать за общею инициализацию. (Желательно используйте кодировку для файлов UTF-8).

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