добрый день!
мне нужно добавить в регистрационную форму несколько своих полей (имя, фамилия) и поле из другой таблицы(организация)-->(foreign key) данные должны хранится в таблице "user".
подскажите пожста, как это можно осуществить.
Спасибо за помощь! Еще вопрос от новичка если я изменю модуль user будут ли проблемы с обновлениями? Вопрос по добавлением поля из другой таблицы.
Проблемы обязательно будут :), надо будет хранить патч и накатывать его при каждом обновлении ... или обновляться через ж ...
Что вам мешает расширить функционал стандартного модуля своим модулем (раз уж из десятков готовых модулей расширяющих работу с экаунтом подобрать ничего не сумели) ...
И волки сыты и овцы целы ...
"Muhrab" wrote:
данные должны хранится в таблице "user".
Почему должны ? что мешает хранить данные в другой таблице (своей) и связать ее с user 1:1
Значить пропатчить стандарный модуль хватает, а написать свой нет
Поищите готовые на d.o - там десятки модулей занимающиеся расширением функционала стандартного user ...
Хотя по мне, ваша задача решается элементарно при помощи стандартного модуля profile + словарь с организациями и допустим модулем User Terms, что бы привязать словарь к профилю
не подумайте не правильно но я создал таблицу myuser, со всеми полями что мне надо, а как ее поля добавить в форму регистрации помимо полей от drupal таблицы user?
не подумайте не правильно но я создал таблицу myuser, со всеми полями что мне надо, а как ее поля добавить в форму регистрации помимо полей от drupal таблицы user?
Вы подошли к друпалу не с того конца
Убейте вашу таблицу ...
Включите модуль profile (он в ядре),
Зайдите на страницу admin/user/profile
Добавьте нужные типы поля
ФИО и остальное
(кстати если список организаций не большой, то его тоже можно добавить в виде поля с типом "выбор из списка)
Все ... больше ничего делать не надо, и если вы при заведении полей выставили флажок - "Отображать в форме регистрации пользователя."
то данные поля у вас появятся в форме регистрации, там же можно настроить видимость и обязательность заполнения этих полей ....
А вот когда вы получше узнаете архитектуру друпала (хуки, FormAPI, написание модулей и т.п.) уже сможете задавать более конкретные и сложные вопросы
Если еще не начали добавлять поля в Profile, остановитесь.
Модуль Profile - худший вариант хранения данных о юзере из всех возможных в Drupal. Говорю как программист. В принципе не подходит для нормальной разработки. Даже статью хотел по этому поводу написать по итогу недельной миграции данных (тысячу пользователей биржи talentory.com после того, как предыдущие разработчики все сделали на profile) из полей Profile в поля Content Profile + таксономию.
Потому что:
1. Данные в таблице profile_values хранятся в сыром виде, как есть. Нет нормализации
2. Select-поле (к примеру) не может принимать множественные значения. Есть модуль profile_checkboxes, который позволяет пофиксить эту проблему, породив однако еще большую - данные просто конкатенируются и записываются в строковом значении. Т.е. поиск по ним делается через бубен и шаманские танцы.
3. Нет нормальной возможности использовать таксономию в качестве поля (аля Content Taxonomy).
4. Ограниченное количество типов полей, которых не хватает для нормальной разработки
5. Совершенно адская локализация select-полей и отсутствие проверок на уникальность (поля переводятся не по одному, а всей пачкой. Если одно поле убрать - переводы начинают перемешиваться)
6. И еще много чего
Что делать
1. Ставить Content Profile. Данные хранятся в ноде в нормализованном виде. Становится доступно все множество полей CCK в профиле.
2. Списки (select, checkboxes и т.д.) хранить в таксономии, через модуль Content Taxonomy выводить их в профиле. Удобно искать, переводить, всячески изменять и удалять без последствий для соседних элементов. Для сложных деревьев использовать Taxonomy Manager.
3. Поскольку Content Profile выводит свои данные на отд. странице в профиле, то можно поставить Account Profile (dev-версия, но вполне работоспособная), который вернет одну страницу вместо двух.
Что не надо делать
Учить Drupal API, разбираться с hook_schema_alter и прочими хуками, которые тут зачем-то насоветовали. Ваша задача тривиальна и решается из админки, а не кодом.
Если все же руки чешутся что-то написать
данные должны хранится в таблице "user" -> данные Profile хранятся в $user->data в сериализованном виде, в БД таблицах profile_fields и profile_values (если вам зачем-то надо БД, а не устраивает работа на уровне объекта пользователя). Сохраняются через функции user_save($user, $new_values) и profile_save_profile($new_values, $user, $category)
Я рыдал и матерился, когда писал скрипт миграции данных для 30 разнотипных полей. Drupal классная система, работаю с ней почти ежедневно более 2 лет, однако imho: модуль Profile - редкостное д...о, написанное индусом-фрилансером.
Без обид, новичку учить API Drupal и разбираться с хуками для того, чтобы правильно добавить поля в профиль не надо в принципе. Не для того Drupal был создан, чтобы тратить на это время вначале пути. Лучше потратить пару месяцев на изучение сотни-полторы модулей, которые затем серьезно облегчат жизнь. Потребность в изучении API приходит позже, когда функционала модулей перестает хватать.
:)) Я рыдал и матерился, когда писал скрипт миграции данных для 30 разнотипных полей. Drupal классная система, работаю с ней почти ежедневно более 2 лет, однако imho: модуль Profile - редкостное д...о, написанное индусом-фрилансером.
А Profile2 подойдёт? Просто Content Profile ещё не мигрировали на D7...
По мне так в семерке он и не нужен, так как стандартный юзер уже обладает почти всеми возможностями модуля, т.е. можно к юзеру прикреплять любые CCК поля.
Комментарии
модуль Profile
hook_schema_alter
Вам поможет [api=hook_form_alter], [api=hook_form_FORM_ID_alter] а также знание formApi
Спасибо за помощь! Еще вопрос от новичка если я изменю модуль user будут ли проблемы с обновлениями? Вопрос по добавлением поля из другой таблицы.
Проблемы обязательно будут :), надо будет хранить патч и накатывать его при каждом обновлении ... или обновляться через ж ...
Что вам мешает расширить функционал стандартного модуля своим модулем (раз уж из десятков готовых модулей расширяющих работу с экаунтом подобрать ничего не сумели) ...
И волки сыты и овцы целы ...
Почему должны ? что мешает хранить данные в другой таблице (своей) и связать ее с user 1:1
нехватка знаний
Значить пропатчить стандарный модуль хватает, а написать свой нет
Поищите готовые на d.o - там десятки модулей занимающиеся расширением функционала стандартного user ...
Хотя по мне, ваша задача решается элементарно при помощи стандартного модуля profile + словарь с организациями и допустим модулем User Terms, что бы привязать словарь к профилю
не подумайте не правильно но я создал таблицу myuser, со всеми полями что мне надо, а как ее поля добавить в форму регистрации помимо полей от drupal таблицы user?
Вы подошли к друпалу не с того конца
Убейте вашу таблицу ...
Включите модуль profile (он в ядре),
Зайдите на страницу admin/user/profile
Добавьте нужные типы поля
ФИО и остальное
(кстати если список организаций не большой, то его тоже можно добавить в виде поля с типом "выбор из списка)
Все ... больше ничего делать не надо, и если вы при заведении полей выставили флажок - "Отображать в форме регистрации пользователя."
то данные поля у вас появятся в форме регистрации, там же можно настроить видимость и обязательность заполнения этих полей ....
А вот когда вы получше узнаете архитектуру друпала (хуки, FormAPI, написание модулей и т.п.) уже сможете задавать более конкретные и сложные вопросы
Советчики, блин.... Так сказать, накипело...
Если еще не начали добавлять поля в Profile, остановитесь.
Модуль Profile - худший вариант хранения данных о юзере из всех возможных в Drupal. Говорю как программист. В принципе не подходит для нормальной разработки. Даже статью хотел по этому поводу написать по итогу недельной миграции данных (тысячу пользователей биржи talentory.com после того, как предыдущие разработчики все сделали на profile) из полей Profile в поля Content Profile + таксономию.
Потому что:
1. Данные в таблице profile_values хранятся в сыром виде, как есть. Нет нормализации
2. Select-поле (к примеру) не может принимать множественные значения. Есть модуль profile_checkboxes, который позволяет пофиксить эту проблему, породив однако еще большую - данные просто конкатенируются и записываются в строковом значении. Т.е. поиск по ним делается через бубен и шаманские танцы.
3. Нет нормальной возможности использовать таксономию в качестве поля (аля Content Taxonomy).
4. Ограниченное количество типов полей, которых не хватает для нормальной разработки
5. Совершенно адская локализация select-полей и отсутствие проверок на уникальность (поля переводятся не по одному, а всей пачкой. Если одно поле убрать - переводы начинают перемешиваться)
6. И еще много чего
Что делать
1. Ставить Content Profile. Данные хранятся в ноде в нормализованном виде. Становится доступно все множество полей CCK в профиле.
2. Списки (select, checkboxes и т.д.) хранить в таксономии, через модуль Content Taxonomy выводить их в профиле. Удобно искать, переводить, всячески изменять и удалять без последствий для соседних элементов. Для сложных деревьев использовать Taxonomy Manager.
3. Поскольку Content Profile выводит свои данные на отд. странице в профиле, то можно поставить Account Profile (dev-версия, но вполне работоспособная), который вернет одну страницу вместо двух.
Что не надо делать
Учить Drupal API, разбираться с hook_schema_alter и прочими хуками, которые тут зачем-то насоветовали. Ваша задача тривиальна и решается из админки, а не кодом.
Если все же руки чешутся что-то написать
данные должны хранится в таблице "user" -> данные Profile хранятся в $user->data в сериализованном виде, в БД таблицах profile_fields и profile_values (если вам зачем-то надо БД, а не устраивает работа на уровне объекта пользователя). Сохраняются через функции user_save($user, $new_values) и profile_save_profile($new_values, $user, $category)
Спасибо!
рыдал
To xxandeadxx
Я рыдал и матерился, когда писал скрипт миграции данных для 30 разнотипных полей. Drupal классная система, работаю с ней почти ежедневно более 2 лет, однако imho: модуль Profile - редкостное д...о, написанное индусом-фрилансером.
Без обид, новичку учить API Drupal и разбираться с хуками для того, чтобы правильно добавить поля в профиль не надо в принципе. Не для того Drupal был создан, чтобы тратить на это время вначале пути. Лучше потратить пару месяцев на изучение сотни-полторы модулей, которые затем серьезно облегчат жизнь. Потребность в изучении API приходит позже, когда функционала модулей перестает хватать.
я так понимаю, миграцию осуществляли в обход API?
Миграция осуществлялась по API, более того, для этих целей писался модуль для миграции на будущее.
А Profile2 подойдёт? Просто Content Profile ещё не мигрировали на D7...
По мне так в семерке он и не нужен, так как стандартный юзер уже обладает почти всеми возможностями модуля, т.е. можно к юзеру прикреплять любые CCК поля.