Изменение / добавление своих полей для топика

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

Было бы замечательно, чтобы это можно было делать в отдельных файлах, как это реализовано в дополнении IP.Content для IP.Board.

Похожие статьи

  • Редактирование топиков
    Столкнулся с багом или не доработкой!!! Пользователь при создании топика накосячил, отредактировал его топик, сохраняю. А и автоматически автор топика становится админ!!! Вопрос, как сделать так чтобы при...
  • Система приглашения по инвайтам.
    Добрый вечер! Возник небольшой вопрос по поводу системы приглашения по инвайтам. На данный момент инвайты создавать может только администратор? Если нет, то где и как включить, чтобы зарегистрированные пользователи...
  • Добавит чекбокс, показывать контакты на сайте
    Всем доброго времени суток. Подскажите, как добавить на сайт чекбокс показывать контакты на сайте. Хочу добавить к массиву со значениями полей булевое поле, и делать проверку, если есть то показывать на сайте....
  • Переход с Livestreet на ALTO
    Здравствуйте. Есть следующий вопрос, имеем экспериментальный сайт микроблогов работающий на Livestreet: http://cbunga.ru/ Работает в принципе нормально но есть ряд проблем которые заставляют задуматься над сменой...

27 комментариев

+2
Добрый день. Это делается в админке. Раздел «Типы контента», в редактировании каждого из типов можно привязать к нему свои дополнительные поля — строковое поле, текстовое поле, выпадающий список, дата, ссылка, прикрепление файла.
+1
Пожалуй, все-таки нужно обзорную статью написать по части типов контента и работе с дополнительными полями.
0
Это замечательно. Только вопрос как раз и состоит в том, чтобы можно было менять обработку этих полей или создавать свои типы полей, а всю функциональность описывать в php файле.
0
создавать свои типы полей, а всю функциональность описывать в php файле.
Что мешает сейчас делать доработки и дополнительные поля плагинами, (которые пишутся, конечно, на php)? Хуки, есть в большинстве мест, если где то будет не хватать — можно и наследованиями.

Либо я не совсем вас понял, либо не хватает конкретики и примеров
Отредактирован:
0
Значит дополнительные поля добавлять только плагинами или хуками. Понятно. Тогда, допустим, за обработку поля «файл» какой модуль/хук отвечает?

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

Такую систему я встретил в дополнении IP.Content для IP.Board (http://www.invisionpower.com/support/guides/_/advanced-and-developers/ipcontent/creating-database-fields-r161). Там для добавления нового типа поля достаточно было положить файл с необходимым кодом в определенную директорию, а движок сам его подхватывал. Оставалось только указать его в нужном месте.
0
А первоначально я хотел узнать у вас, не вынесен ли каждый тип поля в отдельный файл
Нет, реализация иная. Обработка происходит в экшене и хуке. В MVC модели такие вещи вообще нельзя грамотно сделать именно одним файлом, да и не нужно. Но запрос в целом понятен, у меня есть соображения на счет форм вообще и подобных случаев в частности.
0
Просто, если я правильно понимаю, мне придется каждый раз править код при обновлении движка, а хотелось бы какой-нибудь независимости
0
Неправильно понимаете, если все делать качественно с использованием плагинов — то подобные вещи будут минимизированы.
0
Будем ковырять, спасибо.
0
кстати, а почему бы тогда и вам не реализовать это через плагины, чтобы на их примере можно было бы создавать новые или редактировать существующие?
0
Приветствую еще раз. Правильно ли я понимаю, что в текущей версии движка реализовать свои типы полей с помощью хуков или плагинов не получится — в качестве field_type могут выступать только значения 'input', 'textarea', 'photoset', 'link', 'select', 'date', 'map', 'daoobj', 'object', 'user', 'file', 'litepoll', 'gallery'. При попытке добавить с помощью хука свои, вываливается ошибка FIELD_TYPE_ERROR, потому что в функции проверки полей CheckFieldsField жестко прописаны типы, которые могут использоваться.
Это так или я чего-то еще не знаю?
0
А как можно создать поле, например, типа «map»? Не нашел такого.
+1
Если речь о том, чтоб прикрутить карту к топику, то скоро будет решение для этого
0
Нормальная реакция. Оооооо, тут и это и есть, и вот это есть. Проходит время, а почему вот этого нет )))))
0
Покопался в наследованиях и в функции CheckFieldsField. Для решения вопроса с проверкой новых типов полей придется в наследованной функции переписывать весь ее код, в котором перечислять новые типы, что потом может обернуться другими проблемами с совместимостью при обновлении движка, например. Я прав?
0
Верно. Согласен, что не совсем удобно, упростим расширение полей к следующей версии.
Отредактирован:
0
Долго копался в чем может быть причина удаления загруженных файлов через доп поля, пока не понял, что все значения чистятся в функции processFields() процедурой $this->Topic_DeleteTopicValuesByTopicId($oTopic->getId()). Это сделано осознанно или недосмотр?
0
Это недосмотр, спасибо, исправлю в ближайшие дни.
0
Спасибо за добавление поддержки своих типов полей в коде на гитхабе. Заметил только, что для работы с полем на подобие file, в хуке content_field_proccess не хватает переменной $oTopic, чтобы можно было вызывать метод $oTopic->getFile().
0
И, если я не путаю, хук надо вызывать так: $this->Hook_Run('content_field_proccess',array('sText'=>&$sText,'oField'=>$oField,'oTopic'=>$oTopic)), иначе в $sText не будет возвращаться значение.
0
Нет, не обязательно, проверьте)
0
проверил — доп. поля не появились. вернул & — заработало.
0
Еще заметил. Дополнительные поля почему-то криво кешируются. Добавляю новый топик с доп. полями, но он отображается, как будто без них. Отключаю кеш — доп. поля тут как тут.
0
проверим.
0
кто продаёт плагин для добавления обязательных полей к регистрации? Куплу мгновенно
0
Уважаемые разработчики, подскажите, как вместо одного общего вывода кастомных полей вида
{if $oContentType}
            {foreach from=$oContentType->getFields() item=oField}
                {include file="fields/customs/field.custom.`$oField->getFieldType()`-show.tpl" oField=$oField}
            {/foreach}


Вывести каждое поле по одиночке? При этом поля разного типа. Полей одного типа может быть несколько.
+1
Немного замороченно, но можно. Если не программировать и не писать никаких плагинов, то можно чуть-чуть «накостылить» прямо в шаблонах.

Для начала надо узнать ID полей. К сожалению, увидеть их без того, чтоб лезть в базу, можно только обновившись с гитхаба, в админке там при просмотре типа контента теперь выводятся ID кастомных полей. Либо, если не обновляться, то можно увидеть их в таблице ?_content_field, поле field_id.

Дальше немного проще.

В шаблоне /common/templates/skin/_skin_name_/tpls/fields/customs/field.custom.textarea-show.tpl убирается этот самый кусок кода, который приведен выше.

В нужных местах шаблона, где нужно выводить кастомные поля, вставляете такой код:
{if $oContentType}
   {foreach from=$oContentType->getFields() item=oField}
      {if $oField->getFieldId() == N}
      {include file="fields/customs/field.custom.`$oField->getFieldType()`-show.tpl" oField=$oField}
      {/if}
   {/foreach}
{/if}
Здесь N — это как раз ID поля, которое нам надо вывести в конкретном месте.
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.