Deploy на shared-хостинг, как с этим жить

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 записи, комментария к ней и с циклом - это есть самый что не есть говнокод.

В том и суть. Функционал вордпресса достаточен для блога. Но чуть дальше и нужно делать надстройки, чтобы вместо 15 символов делать 3 строчки. А вместо 30 символов - 10 строк.

Не будет.

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

Дальше уже мы по этому ид получим аватарку.

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

Всё в точности до наоборот :) В функционале ВП столько всего, что можно сделать практически любой сайт, используя встроенные функции. И это без изобретения костылей (которые вставляют нек кодеры. Они умные, но к сож. не знающие АПИ ВП чем доставляют массу проблем). Это аналогично работе с фрейморком, если рассматривать в разрезе кодинга.

Но есть инструменты (как напр, упомянутый TiA АCF), которые позволяют даже не кодить, а указав в админке только вход-выход (условно) быстро получить результат. Причем зачатую не узкий (напр вывести на фейс форму с полями некоторых данных), а даже с плюшками, типа аякс-обраточиков форм (проверка данных напр) при создании этих самых форм.

Вы помните как во времена вин3.11 "сервер под виндоус" было анекдотом? Шуточки всякие ходили и т.п.

Потом как-то не так смешно стало когда это стало правдой.

Причина простая. Нет, не в том, что чуваки улучшили ось. Это уже следствие.

А в том, что ее лучше знали.

У меня в то время был сервак под ДОС. Фидошная нода крутилась.

Мне всего хватало.

Потом ближе к закату Фидо она уже жила в Вин95. Иногда. Иногда в Дос загружал, но если нужна была многозадачность то запускал ее в винде.

Линуховый сервер на том же железе у меня завелся не потому что он лучше решал мои задачи, более защищенный и т.п. - просто не было подходящего софта под винду. Собирать руками, патчить и т.п. было глупо. Сейчас всё тот-же софт уже и под виндой прекрасно живет.... Да и сейчас сижу под виндой, хотя весь софт что использую изначально или виндовый или кроссплатформенный. Но разбираться с драйверами и т.п.? Та ну нафиг.... "Та ну нафиг" это вообще движущая сила нашего времени)

Эмм.. Чуваки - это разрабы винды?

Удивительно было бы, если б они её знали хуже юникса :). Но да, следствие. Следствие, вызванное желанием завоевать рынок серверов. но никак не потому что "винда - для домохозяек" и поэтому стала популярна.

И вообще наверное не стоит уже в третью ветку офтопа уводить топик.. :)

Мож вынести из этого топика в отдельный, что мы тут по ВП нафотопили?

ЗЫ. эх фидо-фидо.. ностальжи :)

Вы говорили что не внимательно следили, так что я повторюсь коротко:

Ну и третья тема, жЫрная, это как сделать чтобы собственно этот комментарий отображался отдельно. Без костылей. Есть оно в АПИ?

Вот так хочу.

---------- Добавлено 22.07.2016 в 13:43 ----------

Лучше знали пользователи, продвинутые пользователи ставшие админами.

Им проще использовать знакомую вин95 поставив на нее какой-то серверный софт, чем разбираться с линухой.

Да еще и в вынь можно спокойно с той же машины искать советы, а тут даже с браузером непонятно что. lynx если не ошибаюсь? Поднять окна? На сервере? При 32мб ОЗУ? Можно, но это лишнее....

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

Ну по крайней мере до того уровня когда это уже не анекдот а осознанный выбор.

---------- Добавлено 22.07.2016 в 13:51 ----------

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

:) Ну тут ты вообще путаешь причино-следсвенные связи. :) Причём тут пацаны? Они юзают что есть. Что предлагает рынок. Другого не дано (если самим не писать своё).

Пацанам нечего было ставить на сервера, кроме юникса даже когда 95 винда уже завоевала весь рынок HOME/SOHO PC. И прекрасно, кстати, некоторые на юникасах жили вплоть до вин2к (но уже прощупывая NT).

А то, что на северной ОС фейс/юзабилити такие же же, как и на хоум/сохо, так это и удешевление разработки и маркетинг. Не более и не менее.

Не уверен, что понял.. https://codex.wordpress.org/Function_Reference/get_comment_text это что ли?

Я вот когда решил уходить из админства, так за два года до ухода уже не трогал виндовые машины а всегда слал подчиненных. потому что уже пошли вин7 и т.п., и мне харило изучать что там и где, когда в хрюше всё с закрытыми глазами....

Когда до сих пор если надо восьмерку или десятку поставить или поколупать, то везу машину к себе в отдел где работал.) Нафиг оно мне не надо голову забивать.

Также и другим нафиг не надо было.... Да, у меня там в конторе на одном рабочем компе стоит денвер в котором развернута одна СЭД. Я ее даже на сервак не тянул так-как работают с ней лишь в одном отделе. А уж разворачивать LAMP ради одной програмулинки я не буду. Там вся инфраструктура под виндой.

Именно так всё и начиналось.

Если бы не этот маркетинговый бонус, то нишу винсерверов заняла бы какая-то эпл.)

Нет. Я про всю инфраструктуру. Получить данные комментария не проблема.

А вот как сделать саму страничку на которой будет отображаться только он, и ничего больше?

У меня в голове только один хак вырисовывается - в шаблоне поста сделать проверку, есть ли гет-параметр "комментИД", и если он есть, то не выводить шаблон поста, а выводить шаблон комментария.

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

Но это бруталити. И поддерживать потом стороннему человеку будет сложно.

---------- Добавлено 22.07.2016 в 14:14 ----------

ПС: тему с виндой предлагаю закрыть, вроде как мы по второму кругу пошли уже.

Задачей любой CMS является ускорение разработки. Возможность использования модулей и дополнений - это один из ключевых факторов.

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

<?=$comment->post->category->owner->avatar;?>

Это пример того как не нужно писать код. Вот представьте, что у записи появится возможность выбрать несколько категорий. Как ваш код будет обрабатывать эту ситуацию? А если эти категории будут вложенными, то какую аватарку стоит выдавать? Как ваш код будет обрабатывать ситуацию, если у категории несколько владельцев? Как обрабатывается ситуация, когда у записи комментарии отключены? А если запись связана с другой таксономией, у которой нет владельца? А если в записях, например, изменится связь с категориями и вместо объекта с свойством owner категория вам будет выдавать массив таких объектов? Во всех этих ситуациях код будет выдавать ошибку и создавать проблемы. Они являются следствием сильной связанности сущностей. Вот какое отношение имеет аватарка автора категории к сущности комментария записи из этой категории? Никакого.

<?=$product->manuf->thumb?>

Здесь те же проблемы. Если у продукта не будет указан производитель, то код выдаст ошибку.

А зачем вам куча страниц, на которых выводится по одному комментарию? Вы уверены, что это хорошее решение?

Если требуется получить страницы с отзывами, то можно их выделить в отдельный тип записей и вынести в админку. Это делается через register_post_type. Под новый тип записей создается два шаблона: один для списка, второй для самого отзыва. Добавлять отзывы изначально можно через админку. Можно также сделать небольшую форму и написать небольшой AJAX-обработчик для добавления отзыва через фронтэнд. Использовать для этого комментарии - это, мягко говоря, костыль.

Опять же не уверен что понял задачу, но наверное нужно просто создать шаблон.

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

Но можно создать свой шаблон страницы.

Вот, кстати, подобная чёткая иерархия шаблонов - ещё один мегаудобный инструмент, позволяющий разработчику не парить моск ГДЕ вводить/выводить и плодить сущности, а сосредоточиться только на КАК.

ЗЫ. Я пока ушел, сорри.