29 января 2012 в 17:36
Задача - сделать на DRUPAL 7:
- Нужна возможность создавать профиль отдельно от пользователей, с дальнейшей возможностью пользователями присоединяться (например, школа, институт) На практике так - заходим на сайт, и если есть соответствующее право доступа, то можем добавлять записи в профили.
- Использовать именно сущность профиля или иное, но не ноды.
В Drupal 6 есть такой модуль, как Content Profile. Этот модуль дает возможность создавать профили к аккаунтам пользователей, используя выбранный нами тип нод, на котором мы поставим галочку "использовать как профиль пользователя". После этого при редактировании Аккаунта пользователя мы видим вкладку с названием профиля. Естественно, если это практически нода, все поля и все возможности - такие же как и у нод. При заполнении этой вкладки и создается нода, которая фактически выполняет роль одного из профилей пользователя, например, место жительства или интересы.
Профиль = нода.
То есть профиль можно создать и через создание материала, без привязки к пользователю. !!!
В Drupal 7 модуль Profile 2 работает немного иначе. Он создает отдельную таблицу в базе для профилей, а не использует таблицу нод. Это и хорошо и плохо одновременно.
Хорошо в том плане, что профиль - это все таки профиль, а не нода.
Плохо - от ограничений в создании отдельно от пользователя (см. задачу)
Если будут идеи или может я что упустил - спасибо.
ЗЫ: так же нужен хороший специалист по DRUPAL 7, постоянные задачи (знание архитектуры БД, модулей, опыт - обязательно)
Комментарии
Не совсем понятно, зачем всё таки нужно создавать профайлы отдельно от пользователей.
Например, для того, чтобы завести все школы, а потом пользователи могли эти школы использовать как сущность "профиль" - то есть как одну из вкладок (профилей).
Сначала школы, потом пользователи.
Как деньги и стулья. )
можно привязать школы к пользователям через node reference или через таксономию
У нас условия поставлены так, что ноды не трогаем вообще, это - железо!
Остальное - любые варианты
Готов платить за толковое решение.
А что значит "ноды не трогаем"? Т.е. вам обязательно нужно чтобы всё было без нод?
Все что касается профилей - да, без нод.
То есть по факту нужно сделать так, чтобы к одному профилю могли ссылаться несколько пользователей.
У пользователя остается выбор - или самому заполнить профиль "школа" (тогда создастся новый профиль, единственно - проверка на дубль с уже созданными профилями по адресу), или может выбрать из списка.
Так же у пользователей с определенным правом доступа должна быть возможность создавать набор этих профилей.
Но профиль остается профилем. Данные об этом хранятся в совершенно определенной таблице БД. Это важно.
Может использовать OG?чем вам не "не ноды"?
У меня есть видюшки по этому модулю.
У вас какое то особое понимание термина "профиль". Какая разница в какой таблице хранятся данные пользователя? В друпал 7 поля можно прикреплять к профилю пользователя поэтому content_profile для 7-ки не нужен.
получается что задействуем Entity API и делаем новую сущность,
или подключаем Organic Group.Посмотрел OG - не подходит.
НУЖЕН ЧЕЛОВЕК, КОТОРЫЙ отлично разбирается в Entity API
Вы с этим работали?
Работал. Ток не пойму а зачем вам Entity API? Вас кидает из одной крайности в другую.
Пользователи в друпал 7 и без того являются сущностями.
Пишу отдельным сообщением на личную почту
Задействуйте сущность термина таксономии, прикрепите к ней нужные поля, будет вам готовый профиль, который сможете прикрепить к кому угодно. Подрихтуете хуками возможности и права да и всё. Можете программно создать сущность, но если пойдете через таксономию или ноды - вам готовая полная интеграция с views и другими модулями, в итоге кодить меньше все равно прийдется. Хотя в 7-ке с этим и так проще стало намного после 6-ки.
На мой взгляд тут как раз лучше использовать либо OG либо таксономию. Судя по вашей задаче - пользователь создает свои "интересы" (места учебы и прочее - типичное использование в социалках).
ОГ удобен, так как хранит привязку пользователя к другим сущностям, но вполне можно обойтись entityreference полем у пользователя ссылающимся на сущность для хранения информации (таксономия наверно предпочтительнее)
А кодить придется только виджет для «удобного» выбора/ввода, хотя, полагаю, что можно найти достаточно готовых решений в контрибе и обойтись без кода.