Ответ
На основе https://toster.ru/q/276441 Понятное дело, многое зависит от проекта, поэтому данный пост стоит адаптировать под ваш случай.
* Безопасность:
- Каждый аргумент метода простого типа должен проверяться на тип в случае его проксирования и на граничные значения в случае обработки. Чуть что не так - бросается исключение. Если метод с несколькими аргументами на 80% состоит из поверки из аргументов - это вполне нормально))
- Никаких trigger_error, только исключения.
- Исключения ДОЛЖНЫ быть человеко-понятны, всякие "Something went wrong" можно отдавать пользователю, но в лог должно попасть исключение со стектрейсом и человеко-понятным описанием, что же там пошло не так.
- Каждый аргумент (объект) метода должен быть с тайпхинтингом на этот его класс, или интерфейс.
- За eval как правило жесткий выговор
- @ допускается только в безвыходных ситуациях, например проверка json_last_error.
- Перед работой с БД - обязательная проверка данных.
- Никаких == и!=. Со swtich - единственное исключение, по ситуации.
- Если метод возвращает не только bool, а еще что-то - жесткая проверка с ===, или!== обязательна.
- Никаких условий с присваиваниями внутри. while($row = ...) - тоже недопустимо.
- Магические геттеры/сеттеры разрешаются только в безвыходных ситуациях, в остальном - запрещены.
- Конкатенации в sql - только в безвыходных ситуациях.
- Параметры в sql - ТОЛЬКО через плейсхолдеры.
- Никаких глобальных переменных.
- Даты в виде строки разрешаются только в шаблонах и в БД, в пхп коде сразу преобразуется в \DateTimeImmutable (в безвыходных ситуациях разрешено \DateTime)
- Конечно зависит от проекта, но как правило должно быть всего две точки входа: index.php для web и console(или как-то по другому назваться) - для консоли.
* Кодстайл PSR-2 + PSR-5 как минимум, + еще куча более жестких требований (для начала все то что в PSR помечено как SHOULD - становится MUST)
- В PhpStorm ни одна строчка не должна подсвечиваться (исключением является typo ошибки, например словарик не знает какой-то из аббревиатур, принятых в вашем проекте). При этом разрешается использовать /** @noinspection *** */ для безвыходных ситуаций.
- Если кто-то говорит, что пишет в другом редакторе и у него не подсвечивается, все равно отправляется на доработку.
* Организация кода:
- Никаких глобальных функций.
- Классы без неймспейса разрешаются только в исключительно безвыходных ситуациях.
* Тестируемость (в смысле простота тестирования) кода должна быть высокая.
- Покрытие кода обязательно для всех возможных кейсов использования каждого публичного метода с моками зависимостей.
* Принципы MVC:
- Никаких обработок пользовательского ввода в моделях, от слова совсем.
- Никаких запросов в БД из шаблонов.
- Никаких верстки/js/css/sql-ин в контроллерах.
- В моделях НИКАКОЙ МАГИИ, только приватные свойства + геттеры с сеттерами.
- В моделях разрешено использовать метод save(при наличии такого разумеется) только в исключительных ситуациях. Во всех остальных - либо insert, либо update.
* Принципы SOLID:
- Никаких универсальных объектов, умеющих все.
- Если метод для внутреннего пользования - private, никаких public.
- Статические методы разрешаются только в случае безвыходности.
* Принцип DRY разрешено нарушать в случаях:
- Явного разделения обязанностей
- В тестах (каждый тест должен быть независимым, на сколько это возможно)
* Работа с БД:
- Запрос в цикле должен быть РЕАЛЬНО обоснован.
- За ORDER BY RAND() жесткий выговор
- Поиск не по ключам (конечно если таблица НЕ на 5 строк) запрещен.
- Поиск без LIMIT (опять же если таблица НЕ на 5 строк) запрещен.
- SELECT * - запрещен.
- Денормализация БД должна быть обоснована.
- MyISAM не используется (так уж)))
- Множественные операции обязательно в транзакции, с откатом если что-то пошло не так.
- БД не должна содержать бизнес логики, только данные в целостном виде.
- Не должно быть нецелесообразного дерганья БД там, где без этого можно обойтись.
* Кэш должен очищаться по двум условиям (не по одному из, а именно по двум):
- Время.
- Протухание по бизнес логике.
Разрешается по только времени в безвыходных ситуациях, но тогда время - короткий период.
- При расчете ключей кэша должна использоваться переменная из конфигурации приложения (на случай обновлений кэш сбрасывается кодом, а не флашем кэш-сервера). В случае использования множества серверов - это очень удобный и гибкий инструмент при диплое.
* О людях:
- "Я привык писать так и буду дальше" - не вопрос, ревью пройдешь только когда поменяешь свое мнение.
- "Я пишу в vim-е и мне так удобно" - здорово, код консолью я тоже в нем пишу)) но есть требования к коду, если в них не сможешь - не пройдешь ревью.
- "Я скопировал этот страшный метод и поменял 2 строчки" - это конечно замечательно, но по блейму автор всего этого метода ты, так что давай без ерунды, хорошо?
- "Оно же работает!" - вот эта фраза переводится примерно так: "да, я понимаю, что пишу полную ерунду, но не могу писать нормально потому, что не могу", я правильно тебя понял?))
- "У меня все работает!" - рад за тебя, а как на счет продакшна?
- "Там все просто" - не используй слово "просто", от слова "совсем". Вот тебе кусок кода (первого попавшегося со сложной бизнес логикой), где там ошибка (не важно есть она, или нет)? Ты смотришь его уже 2 минуты, в чем проблема, там же все "просто"))
* Всякое:
ActiveRecord (это я вам как в прошлом фанат Yii говорю) - полный отстой, примите за исходную. По факту у вас бесконтрольно по проекту гуляют модельки с подключением к БД. Не раз натыкался на то, что в тех же шаблонах вызывают save, или update (за такое надо сжигать).
Основное:
1. Наличие критических ошибок и устаревших функций.
2. Использование паттернов, элегантность решений.
3. Читабельность кода, наличие коментариев, наличие доков.
4. Соблюдение парадигм и соглашений (например, нарушение MVC).
Второстепенно\непринципиально:
1. Быстродействие кода (за исключением хайлоад)
2. Потребление памяти (за исключением бигдаты)
3. Эфективность SQL запросов (за исключением совсем уж несуразных)
4. Избегание в данных момент неважных, но потенциально узких мест (например замедление работы файловой системы при большом количестве картинок в папке аплоада)
5. Новизна примененых технологий.
6. Оправданое\Неоправднанное\Избыточное Велосипедирование.
- Код не содержит явных и потенциальных ошибок.
- Код работает так, как это описано в документации, техническом задании или сопроводительных комментариях.
- Стиль кодирования соответствует принятым правилам кодирования
- Код имеет сопроводительные комментарии в соответствии с phpDoc
- Вложенность блоков не превышает 4-го уровня.
- Код не генерирует сообщения уровня Strict, Warning, Notice, Deprecated. Если этого невозможно избежать, то непосредственно перед строкой, которая это генерирует необходимо принудительно отключить error_reporting, а непосредственно после строки включить error_reporting в исходное значение (которое было до этого). Такой код должен быть задокументирован специальным образом.
- Закомментированный кусок кода должен быть удален.
- В PHP коде (за исключением phpTemplate) запрещены вставки HTML, JavaScript. Все вставки должны производиться через специальные шаблоны.
- Классы, функции, переменные и константы должны логически именоваться человекопонятным способом на английском языке в соответствии со стандартами кодирования. Не допускается именование транслитом на русском, либо на иных языках
- Область видимости переменных и методов классов всегда должна быть определена (private, protected, public).
- Размер одного метода не должен превышать 40-50 строк.
- Переменная, используемая в цикле, либо в условном блоке должна быть инициализирована заранее.
- Переменная в любой момент времени должна содержать только один тип. Пустая переменная должна содержать null. (не допускается $var = false; $var = "test"; . Допускается $var = null; $var = "test";).
- При передаче объектов классов в методы должен использоваться контроль типов.
Get a valuable feedback from your customers by giving them the freedom to share their impressions freely. Let them rate your products and/or services straight on your website. See below the key features that come standard with our online review system.
Reviews & Ratings
Embed PHP Review Script into your website and let clients share their experience with the products and services you offer. They can rate by criteria and give both positive and negative feedback.
Multiple Languages
The PHP review system can speak not only English, but any language you may need. You can translate all titles and system messages from the admin page using unique IDs for each piece of text.
Editable Rating Criteria
Depending on the type of business, review system admins can
set different rating criteria to be shown in the front-end form.
Each of these criteria is rated with 1 to 5 stars.
Email & SMS Notifications
Set up the online review system to send Email & SMS alerts when a new review has been posted. You can easily specify which users to receive these messages from the Users menu.
Multiple User Types
Create unlimited client types depending on the industry and services used. Hotel ratings can go with following user types: Family with kids, Couple, Business trip etc. They appear as labels in the reviews.
Responsive & Attractive
The review and rating script runs on all devices, seamlessly adapting to various screen sizes. In accord with your website branding, you can pick the best matching front-end theme among 10 color options.
A quick tips box next to the review form allows you to add some witty words and draw customers out. The review system filters reviews by user type. Customers can rate other clients" ratings, too.
With a Developer Licence you get the source code and can make any custom changes to the PHP Review Script. We can also modify the customer review system upon request.
Шаблоны файлов WooCommerce содержат разметку и структуру шаблона интерфейса (и HTML сообщения электронной почты) вашего магазина. Если Вы откроете эти файлы, то Вы заметите, что все они содержат много хуков (hooks), которые позволят Вам добавлять / перемещать контент без необходимости редактирования самих файлов шаблона. Такой подход защищает от любых проблем с обновлениями, так как файлы шаблона могут оставаться полностью нетронутыми.
Кроме того, вы можете редактировать эти файлы безопасным способом с помощью подмены. Просто скопируйте их в Ваш шаблон в папку с именем /woocommerce , сохраняя ту же иерархическую структуру вложенных файлов и папок. Скопированные файлы шаблонов переопределят файлы шаблонов WooCommerce, используемые по умолчанию. Не редактируйте файлы шаблонов в ядре самого плагина, так как они будут перезаписаны в процессе обновления и все внесенные в них изменения будут потеряны, поскольку обновленные файлы шаблонов затрут старые файлы шаблонов.
Если Вы хотите внести изменения в один из шаблонов , то нет необходимости копировать все файл шаблонов, расположенные в папке templates, а достаточно скопировать только файл шаблона, в который Вы хотите внести изменения . Для этого с директории в вашей темой создайте папку woocommerce и перенесите в нее шаблон, соблюдая вложенность папок.
Пример: для внесения изменений в шаблон корзины, скопируйте woocommerce/templates/cart/cart.php в . После этого Вы можете вносить любые изменения в файл шаблона cart.php , расположенный в папке с вашей темой (т.е. в файл cart.php, расположенный по адресу ваша_тема/woocommerce/cart/cart.php ), и внесенные вами изменения сохранятся даже после обновления WooCommerce.
В директории /woocommerce/templates/ можно найти следующие файлы шаблонов
Спойлер: Список файлов
(данный список файлов шаблонов актуален для версии WooCommerce 2.0+):
· archive-product.php
· cart/
· cart-empty.php
· cross-sells.php
· mini-cart.php
· shipping-calculator.php
· shipping-methods.php
· totals.php
· checkout/
· cart-errors.php
· form-billing.php
· form-checkout.php
· form-coupon.php
· form-login.php
· form-pay.php
· form-shipping.php
· review-order.php
· thankyou.php
· content-product_cat.php
· content-product.php
· content-single-product.php
· emails/
· admin-new-order.php
· customer-completed-order.php
· customer-invoice.php
· customer-new_account.php
· customer-note.php
· customer-processing-order.php
· customer-reset-password.php
· email-addresses.php
· email-footer.php
· email-header.php
· email-order-items.php
· loop/
· add-to-cart.php
· loop-end.php
· loop-start.php
· no-products-found.php
· pagination.php
· result-count.php
· sale-flash.php
· myaccount/
· form-change-password.php
· form-edit-address.php
· form-login.php
· form-lost-password.php
· my-account.php
· my-address.php
· my-downloads.php
· my-orders.php
· order/
· form-tracking.php
· order-details.php
· tracking.php
· shop/
· breadcrumb.php
· form-login.php
· messages.php
· wrapper-end.php
WordPress создан для кастомизации. Он был создан таким образом, что каждую его часть можно настроить. В этом руководстве мы расскажем об одной из самых мощных возможностей WordPress, известную как пользовательские типы записей , и о том, как WordPress достиг высот с появлением этой замечательной возможности.
| Скачать исходники |
Что такое Custom Post Types?
Предположим, вы хотите сделать на вашем блоге отдельный раздел для кино-рецензий. Используя пользовательские типы записей, вы можете создать новый тип вроде Записи или Страницы , который будет содержать другой набор данных. У него будет свое меню администратора, отдельные страницы редактирования, своя таксономия и другие возможности, необходимые для полноценных публикаций.
Пользовательские типы записей - новый набор административных настроек, которые используются наряду со стандартными типами, такими как Записи , Страницы , Прикрепленные файлы и так далее. Пользовательский тип записей может хранить любой тип информации. У него есть свой редактор и медиа-загрузчик. Он использует существующую структуру таблиц WordPress для простого управления данными. Главное преимущество создания пользовательских типов записей с помощью WordPress API - это удобное использование с существующими темами и шаблонами. Пользовательские типы записей также SEO-дружественны из-за своих постоянных ссылок.
Зачем использовать пользовательские типы записей?
Пользовательские типы записей помогают хранить разные типы записей в разных корзинах. Они отделяют наши обычные записи от других. Очень просто!
Пример создания плагина Custom Post Type
Здесь мы создадим плагин для вывода записей нового типа, которые покажут наши кино-рецензии. Давайте начнем.
Шаг 1. Создаем папку WordPress плагина
Откройте свою папку с WordPress плагинами и создайте новую под названием Movie-Reviews .
Шаг 2. Создаем PHP файл
Откройте папку и создайте PHP файл под названием Movie-Reviews.php .
Шаг 3. Добавляем шапку
Откройте файл и добавьте код шапки плагина.
Перед командой закрытия PHP , введите следующую строку кода для того, чтобы выполнять пользовательскую функцию по имени create_movie_review при инициализации каждый раз, когда страница генерируется.
Add_action("init", "create_movie_review");
Шаг 5. Выполнение функции
Выполнение функции create_movie_review :
Function create_movie_review() { register_post_type("movie_reviews", array("labels" => array("name" => "Movie Reviews", "singular_name" => "Movie Review", "add_new" => "Add New", "add_new_item" => "Add New Movie Review", "edit" => "Edit", "edit_item" => "Edit Movie Review", "new_item" => "New Movie Review", "view" => "View", "view_item" => "View Movie Review", "search_items" => "Search Movie Reviews", "not_found" => "No Movie Reviews found", "not_found_in_trash" => "No Movie Reviews found in Trash", "parent" => "Parent Movie Review"), "public" => true, "menu_position" => 15, "supports" => array("title", "editor", "comments", "thumbnail", "custom-fields"), "taxonomies" => array(""), "menu_icon" => plugins_url("images/image.png", __FILE__), "has_archive" => true)); }
Функция register_post_type делает за нас большинство работы. Как только она вызывается, она готовит среду WordPress к новому пользовательскому типу записи, включая разные разделы в админ. части.
Эта функция принимает два аргумента : первый - уникальное имя пользовательского типа записей, а второй - массив, который представляет свойства нового пользовательского типа записей. Вот другой массив, который содержит разные метки, которые обозначают, какие текстовые строки будут отображаться в разных частях пользовательского типа записей, например "name " отображает название пользовательского типа записей в консоли, "edit " и "view " отображаются соответственно в кнопках Edit и View . Думаю, остальное говорит само о себе.
Аргументы :
- "public" => true - определяет видимость пользовательского типа записи и в панели администратора, и в клиентской части.
- "menu_position" => 15 - обозначает позицию меню пользовательского типа записи.
- "supports" => array("title", "editor", "comments", "thumbnail", "custom-fields" ) - определяет характеристики пользовательского типа записей, которые будут отображаться.
- "taxonomies" => array(" ") - создает пользовательские таксономии. Здесь они не определены.
- "menu_icon" => plugins_url( "images/image.png", __FILE__ ) - отображает иконку меню администратора.
- "has_archive" => true - включает архивирование пользовательского типа записи.
На странице WordPress Codex о функции register_post_type вы можете прочесть больше об аргументах, которые используются в пользовательских типах записи.
Шаг 6. Иконка для пользовательского типа записи
Сохраните иконку размером 16 x 16 px в папку вашего текущего плагина. Это необходимо для иконки пользовательского типа записи в консоли.
Шаг 7. Активируем плагин
Активируйте плагин - и готово, у вас есть новый пользовательский тип записей, у которого есть текстовый редактор, управление публикацией и изображениями, комментариями, а также редактор пользовательских полей.
Шаг 8. Добавление новой записи
Щелкните по Add New , чтобы перейти в редактор пользовательского типа записи. Напишите название фильма, рецензию и миниатюру для записи.
Шаг 9. Публикация
Опубликуйте запись и щелкните по View Movie Review , чтобы увидеть созданную кино-рецензию.
Создание полей Meta Box для пользовательских типов записей
Механизм мета-блоков использует помощь встроенной системы мета-блоков WordPress и помогает добавить поля, необходимые для пользовательских типов записей, без необходимых по умолчанию пользовательских полей в редакторе.
Шаг 1. Регистрация пользовательской функции
Откройте файл Movie-Reviews.php и добавьте следующий код перед закрывающимся PHP тегом. Это регистрирует функцию, которая будет вызвана, когда будет посещен интерфейс администратора WordPress.
Add_action("admin_init", "my_admin");
Шаг 2. Выполнение пользовательской функции
Добавьте выполнение функции my_admin , которая регистрирует мета-блоки и связывает их с пользовательским типом записей movie_reviews .
Function my_admin() { add_meta_box("movie_review_meta_box", "Movie Review Details", "display_movie_review_meta_box", "movie_reviews", "normal", "high"); }
Здесь функция add_meta_box использована для добавления мета-блоков в пользовательские типы записей.
Атрибуты :
- movie_review_meta_box - необходимый HTML атрибут id .
- Movie Review Details - текст, видимый в верхней части мета-блока.
- display_movie_review_meta_box - обратный вызов, который отображает содержимое мета-блока.
- movie_reviews - это имя пользовательского типа записей, где будет отображаться мета-блок.
- normal - определяет часть страницы, где должен быть отображен блок редактирования.
- high - определяет приоритет в контексте, в котором будут отображаться блоки.
Шаг 3. Выполнение функции display_movie_review_meta_box
ID, "movie_director", true)); $movie_rating = intval(get_post_meta($movie_review->ID, "movie_rating", true)); ?>| Movie Director | |
| Movie Rating |
Этот код отображает содержимое мета-блока. Здесь мы использовали объектную переменную, которая содержит информацию о каждой кино-рецензии, которая отображается в редакторе. Используя этот объект, мы получили ID записи и использовали его для запроса в базу, чтобы получить связанное имя режиссера и рейтинг, что привело к отображению полей на экране. Когда новая запись добавлена, get_post_meta возвращает пустую строку, что приводит к отображению пустых полей в мета-блоке.
Шаг 4. Регистрация функции Save Post
add_action("save_post", "add_movie_review_fields", 10, 2);Эта функция вызывается, когда записи сохраняются в базе данных.
Шаг 5. Вызов функции add_movie_review_fields
function add_movie_review_fields($movie_review_id, $movie_review) { // Check post type for movie reviews if ($movie_review->post_type == "movie_reviews") { // Store data in post meta table if present in post data if (isset($_POST["movie_review_director_name"]) && $_POST["movie_review_director_name"] != "") { update_post_meta($movie_review_id, "movie_director", $_POST["movie_review_director_name"]); } if (isset($_POST["movie_review_rating"]) && $_POST["movie_review_rating"] != "") { update_post_meta($movie_review_id, "movie_rating", $_POST["movie_review_rating"]); } } }Эта функция выполняется, когда записи сохраняются или удаляются из панели администратора. Здесь после проверки типа полученных данных записи на предмет того, является ли это пользовательским типом записи, проверяется, были ли прикреплены значения к элементам мета-блоков, и затем, наконец, сохраняются значения в эти поля.
Шаг 6. Отключение стандартных пользовательских полей
При создании пользовательского типа записи мы определили функцию create_movie_review . Удалите элемент custom-fields из массива supports , потому что это больше не нужно. Сейчас если вы сохраните файл и откроете редактор Movie Reviews , вы заметите два поля в мета-блоке под названием Movie Author и Movie Rating . Таким же образом вы можете добавить и другие элементы.
Создание пользовательского шаблона для пользовательского типа записи
Правильный способ отображения данных пользовательского типа записи - это использование пользовательских шаблонов для каждого пользовательского типа записи. Здесь мы должны создать шаблон, который отображает все кино-рецензии, добавленные с использованием пользовательского типа записи Movie Review .
Шаг 1. Регистрируем функцию для шаблона
Откройте файл Movie-Reviews.php и добавьте перед тегом закрытия PHP следующий код. Он зарегистрирует функцию для вызова, когда будет посещен интерфейс администратора WordPress.
Add_filter("template_include", "include_template_function", 1);
Шаг 2. Выполнение функции
function include_template_function($template_path) { if (get_post_type() == "movie_reviews") { if (is_single()) { // checks if the file exists in the theme first, // otherwise serve the file from the plugin if ($theme_file = locate_template(array ("single-movie_reviews.php"))) { $template_path = $theme_file; } else { $template_path = plugin_dir_path(__FILE__) . "/single-movie_reviews.php"; } } } return $template_path; }Здесь код ищет шаблон single-(post-type-name ).php в папке текущей темы. Если его там нет, он ищет в папке плагина шаблон, который мы предоставили как часть плагина. Зацепка template_include была использована для изменения стандартного поведения и применения специфического шаблона.
Шаг 3. Создание файла шаблона Single Page
После сохранения открытого файла плагина создайте другой PHP файл под названием single-movie_reviews.php и вставьте в него следующий код.
Director:
Rating: "; } else { echo "
Здесь мы создали базовый шаблон страницы , используя цикл. Функция query_posts получает элементы пользовательского типа записи и отображает их, используя цикл. Конечно, это только базовый цикл, и вы можете играть с ним, как вам вздумается. Вы также можете использовать CSS стили, чтобы форматировать элементы.
Обратите внимание : вам нужно создать новую страницу из консоли, используя созданный только что шаблон.
Шаг 4. Изображения
Вам нужно сохранить два изображения иконок 32 x 32 px в папке вашего плагина. Назовите их icon.png и grey.png . Все, теперь кино-рецензии отображаются на отдельной странице, отсортированные по дате.
В дальнейшем я опишу больше возможностей собственных пользовательских типов, таких как: создание страниц архивов, создание пользовательских таксономий, пользовательских столбцов и так далее.