Задачей любой CMS является ускорение разработки. Возможность использования модулей и дополнений - это один из ключевых факторов.
Если вам по какой-то причине для получения фото нужно сначала вывести отдельно комментарий, потом запись к нему, потом рубрику, по рубрике найти автора, а потом уже у него загрузить аватарку, то вы однозначно что-то делаете не так. Давайте посмотрим на ваш код:
<?=$comment->post->category->owner->avatar;?>
Это пример того как не нужно писать код. Вот представьте, что у записи появится возможность выбрать несколько категорий. Как ваш код будет обрабатывать эту ситуацию? А если эти категории будут вложенными, то какую аватарку стоит выдавать? Как ваш код будет обрабатывать ситуацию, если у категории несколько владельцев? Как обрабатывается ситуация, когда у записи комментарии отключены? А если запись связана с другой таксономией, у которой нет владельца? А если в записях, например, изменится связь с категориями и вместо объекта с свойством owner категория вам будет выдавать массив таких объектов? Во всех этих ситуациях код будет выдавать ошибку и создавать проблемы. Они являются следствием сильной связанности сущностей. Вот какое отношение имеет аватарка автора категории к сущности комментария записи из этой категории? Никакого.
<?=$product->manuf->thumb?>
Здесь те же проблемы. Если у продукта не будет указан производитель, то код выдаст ошибку.
А зачем вам куча страниц, на которых выводится по одному комментарию? Вы уверены, что это хорошее решение?
Если требуется получить страницы с отзывами, то можно их выделить в отдельный тип записей и вынести в админку. Это делается через register_post_type. Под новый тип записей создается два шаблона: один для списка, второй для самого отзыва. Добавлять отзывы изначально можно через админку. Можно также сделать небольшую форму и написать небольшой AJAX-обработчик для добавления отзыва через фронтэнд. Использовать для этого комментарии - это, мягко говоря, костыль.
ACF - это фактически обертка над стандартными функциями WordPress для работы с метаданными. Это дополнение кардинально экономит время как на разработку, так и на поддержку проекта. Я могу не залезая в код и документацию быстро настроить, что вот для такого-то шаблона страниц в админке должны выводиться такие поля, а для такой-то рубрики - другие, а вот в таком-то месте количество этих самых полей может варьироваться.
Никто ведь не запрещает использовать стандартную функцию get_metadata вместо get_field. В этом случае нужно учесть, что если в дополнительном поле хранится ID изображения, то нужно будет написать дополнительный код для получения объекта изображения с нужными размерами и метаданными. Если хранится расположение на карте, то и его нужно как-то обрабатывать перед выводом. Если разработчик ценит свое время, то он очень быстро напишет свою обертку над стандартным функционалом и по сути придумает очередной велосипед. В итоге получится та же функция get_field плагина ACF.
Если стоит задача получить аватарку пользователя, который связан с текущим термином таксономии, то для этого достаточно просто добавить для него дополнительное поле для указания пользователя, а для самого пользователя поле для аватарки. Полный код будет выглядеть примерно так:
$queried_object = get_queried_object();if (!empty($queried_object->term_id)) $user_id = get_field('user', 'vendor_' . $queried_object->term_id);if (!empty($user_id)) $image = get_field('image', 'user_' . $user_id);
3 строки, включая проверки. Функцию get_field можно заменить на стандартную get_metadata c соответствующей правкой кода. Ваш способ реализации с получением ID записи, комментария к ней и с циклом - это есть самый что не есть говнокод.
$queried_object = get_queried_object();
В свойстве term_id находится ID текущего термина ($vendor_id). Да, в 15 строк у меня не получилось вложиться.
Этот плагин хорошо поддерживается разработчиками, в число которых я вхожу. На данный момент разработкой ACF 5 PRO на GitHub занимается 32 человека, включая переводчиков и QA.
PSR-1 позволяет использовать как полный, так и сокращенный синтаксис, стандарт оформления кода WordPress разрешает только полные PHP теги.
Лично мне нравится MyBB 1.8. Форум достаточно хороший с кучей дополнений.
Еще один неплохой форум - Burning Board от WoltLab. Он, правда, платный.
<?php if ($field = get_field('image', 'vendor_' . $vendor_id)) { ?> <img src="<?php echo $field['sizes']['product']; ?>" alt="<?php echo $field['alt']; ?>" /><?php } ?>
В примере product - это зарегистрированный ранее размер картинки, который требуется выводить на сайте, vendor - таксономия с производителями. Если сменить тип поля с картинки на галерею и поместить вывод в цикл, то для производителя можно указывать сколько угодно изображений.
Отдельно один комментарий можно вывести с помощью функции get_comment. Если дополнительное поле с аватаркой связать с пользователем, то оно будет выводиться абсолютно так же как показано выше с той лишь разницей, что вместо vendor будет user с соответствующим ID (свойство user_id возвращаемого объекта с комментарием).
Я с вами полностью согласен в том, что эта задача является непосильной для тех, у кого мало опыта работы с WordPress. Обычно в таких случаях разработчики начинают придумывать свои костыли с таксономиями и типами полей, а потом долго мучаются с отладкой этого всего счастья.
Странно, что о WP-CLI никто не вспомнил. Если учесть специфику работы автора, то этот инструмент был бы очень кстати.
Для термина таксономии "Производители" просто добавляется еще одно дополнительное поле с картинкой. В случае с ACF делается это через админку без правки конфигов. Само изображение можно вывести в шаблоне через функцию get_field в нужном размере и с нужными метаданными.
В OpenCart можно относительно быстро написать свой модуль и не городить лишний раз костыли. Вам же потом это все поддерживать.
А зачем вы костылями пользуетесь? По WordPress есть много отличной документации с best practices. Если во время разработки им следовать, то поддержка проекта кардинально упростится.
Да, действительно, изначально WordPress создавался как платформа для блогов, но в последние годы разработчики планомерно делают ее все более и более универсальной. Из самого последнего в данном направлении - это постепенное внедрение REST API на уровне ядра.
Вы сравниваете разные вещи. Основным недостатком VQMOD/OCMOD является то, что они правят исходный код системы, что создает огромные проблемы при поддержке. Грубо говоря, если Даниель опять захочет что-то поменять, вынести модули в папку extensions или перевести весь код на Twig (это не шутка), то вся совместимость ломается. Хуже всего, что она может сломаться по-тихому и потом очень сложно найти что именно поломалось. Именно это является основной проблемой.
Способ хранения записей у WordPress - это его архитектурная особенность. Разработчики когда-то решили хранить все типы записей в одной таблице в базе данных. Грубо говоря, если разработчик создаст тип "Продукт", то все записи с этим типом будут храниться в той же таблице, что и обычные записи, страницы, вложения, ревизии и пункты меню. Решение не самое красивое, я от него не в восторге, но оно стабильно работает уже много лет.
С другой стороны у этого подхода есть свои плюсы для разработчика. Ему достаточно просто вызвать функцию для инициализации нового типа записи и все, у него в админке есть новое меню, где он может добавлять записи нового типа. С помощью другой функции он может связать этот тип записей с новой таксономией. Там же в админке он может создать для нового типа записей кучу дополнительных полей и получить полноценный каталог за 15 минут.
И это еще не все. Написанный код он может спокойно запихнуть в плагин и тягать из проекта в проект. Скопировал плагин на новый сайт, активировал в админке - и все, созданный ранее функционал каталога появился. И эта штука будет с высокой вероятностью работать годами на новых версиях WP. Это огромная экономия времени.
В Yii2, например, для создания новой сущности требуется сначала создать модель, контроллер и представление, прописать нужные правила для валидации значений, написать код для CRUD, каким-то образом организовать дополнительные поля с помощью отдельной сущности и протестировать это все счастье. Да, Gii этот процесс несколько упрощает, но все равно на это все придется потратить гораздо больше времени. Переносить этот код из проекта в проект также сложнее.
Да, мне очень нравится работать с фреймворком Yii (1 и 2 версии), для многих задач он действительно незаменим, но для большинства стандартных проектов я предпочитаю использовать WordPress. Причина до жути проста: эта система позволяет получить требуемый результат гораздо быстрее и при этом ее поддержка не требует большого количества моего времени.
Если функционалом неудобно пользоваться, то им пользоваться не будут. Вообще создание качественного продукта требует огромного количества времени и сил. На написание чего-то сравнимого с ACF может легко уйти полгода-год. Вот, например, команда из 8 человек уже два года пилит на Yii2 систему DotPlant2. В своем нынешнем виде она все еще сырая.
Неужели у вас нет собственных наработок по формам обратной связи? Если нет, то можно тот же Contact Form 7 развернуть. Многие заказчики знакомы с этим дополнением и им не приходится меня дергать, если вдруг что-то в форме нужно поменять.
В этом нет смысла. На WordPress есть чудесный плагин WooCommerce, который по многим аспектам реализован удачнее OpenCart. Около 39% всех магазинов в мире используют именно это дополнение.
Вы, наверное, неправильно меня поняли. Таксономия и тип записей - это не записи и категории, это просто один из способов их разделения и классификации. Если вдруг возникает необходимость в нескольких десятках типов записей и таксономий, то скорее-всего вы что-то не так делаете. Помимо этого необходимость много раз копировать и вставлять один и тот же код должна посеять зерно сомнения и навеять мысли на счет правильности избранной архитектуры. Если грамотно подойти к разработке, использовать стабильное API, то получится достаточно простой и поддерживаемый код.
У меня
VQMOD не нужно придумывать, его лучше как можно быстрее забыть. Правка исходного кода пускай даже в том виде, в котором это делают VQMOD/OCMOD - это большое зло.
К сожалению, аналогов ACF PRO для других систем я пока не встречал. На данный момент его разработкой и тестированием занимается более 30 человек, включая меня. За качеством кода там действительно следят.
Для клиента реализация дополнительных полей с его помощью означает более удобное наполнение сайта, а для меня ускорение разработки и уменьшение головной боли при поддержке. Согласитесь, что перетащить картинки в окошко галереи на порядок проще, чем вручную их обрезать, загружать и вставлять ссылки.
Из стоящих альтернатив для WP есть CMB2, но там нельзя настроить поля через админку, приходится лезть в документацию. Есть также и Pods, но там возможностей меньше.
Самое очевидное решение - это создать новый тип записи "Баннер" с поддержкой миниатюры и описания. Можно также с помощью ACF PRO создать страницу настроек и туда вынести настройки баннеров, включая загрузку картинок, сортировку и указание дополнительной информации. Создание доп. полей производится через админку и не требует копания в коде. Остается только организовать вывод баннеров в нужном месте темы оформления.
Эту задачу также можно решить с помощью плагина ACF PRO. Для определенных записей создается доп. поле для выбора связанных страниц, записей или рубрик. В качестве бонуса появляется возможность сортировать и отфильтровать записи, ограничить их минимальное или максимальное количество, указать какого типа записи можно выбрать, из какой рубрики и т. д.. Также можно создать отдельный тип записей для самих текстов и выделить под них еще одно дополнительное поле. Для генерации метаполей навешивается соответствующий обработчик на сохранение записи, например.
Для реализации этого функционала можно использовать уже готовые решения, которые основаны на все тех же типах записей, таксономиях, дополнительных полях и событиях. Для изменения поведения плагинов можно использовать все тот же Plugin API. В дополнение некоторые плагины представляют дополнительное API. В WooCommerce, например, есть встроенные функции для генерации дополнительных полей для вариации. Мне достаточно просто создать обработчик с вызовом тех функций, навесить его на событие и все, у вариаций теперь есть дополнительные поля.
Если записи нового типа не должны выводиться на фронтенде, то это можно явно указать при регистрации типа. За это отвечает параметр public функции register_post_type. Указываете его равным false и все, не нужно городить костыли с фиктивными шаблонами, правами и прочей ересью.
Я полностью с вами согласен, что если каждый раз изобретать такие костыли, то разработка будет напоминать страшный сон.
WordPress постоянно меняется и при этом умудряется не ломать совместимость. API там более чем стабильно. Это большой плюс.
С OpenCart ситуация обратная. Там код в 2.х версии крайне нестабилен, поддерживать его сложно. По этой причине я сейчас меньше работаю с этой системой.
Зачем изобретать велосипед и писать вручную код для работы с какой-то очередной сущностью?
В WordPress ведь можно создать новый тип записи со своими таксономиями и дополнительными полями с использованием встроенного API WordPress. Для изменения поведения системы есть Plugin API. Это все позволяет решить большую часть стандартных задач без изобретения собственных велосипедов и решения всех связанных с этим проблем. Вообще очень многие плагины в той или иной степени используют возможности, которые им предоставляет WordPress.
WooCommerce, например, для продуктов создает отдельный тип записей, для рубрик и меток товаров - таксономию, а атрибуты хранит с использованием Metadata API и все тех же таксономий. Плагин ACF также создает свой тип записей для групп и для отдельных полей. Работа со значениями полей производится через все тот же Metadata API. Чтобы это все работало быстро, в плагине реализовано кеширование с использованием все того же API WordPress. Стандартные функции также используются для работы с изображениями, редактором, для загрузки файлов и многих других вещей. Yoast SEO, например, активно использует Metadata API для хранения метаданных.
Стоит заметить, что многие начинающие разработчики в силу отсутствия опыта пытаются написать свою реализацию CRUD, а потом пытаются как-то ее допилить.
