Общение с Fuze, а также перечитывание каментов в блоге и в темах про логины, адреса профилей и авторизацию произвели на мой системно-программерский ум неизгладимое впечатление. 😊 В общем, дабы учесть видение разработчиков Инстанта и противоречивые желания большинства пользователей, я полностью изменил концепцию и переделал весь код. В систему внесено очень много правок, изменено более сотни файлов. Надеюсь, этот вариант понравится и пользователям, и разработчикам InstantCMS 2 настолько, что он будет включён в систему «из коробки». Нужна ваша активная помощь в его тестировании.
Возможности: авторизация по любому полю, подстановка любого поля в адреса профилей пользователей, уникальные никнеймы, правила сайта и другие интересности. Итак, забываем про просто логины и тестируем универсальное решение.
Предупреждение:
При этом для совместимости с Единичкой сделана двойная авторизация. Если вместо ожидаемого поля передали почту, то авторизация будет по ней независимо от выбранного поля в списке.
Естественно, на странице, в виджете и ява-окошке авторизации подставляется соответствующее название поля и изменено сообщение о неправильном вводе данных.
Для удобства уже реализована подстановка поля, заданного в Админке.
Во-первых, в «Админка – Компоненты – Авторизация и регистрация – Регистрация» – новый выпадающий список «При регистрации запрашивать/подставлять в адреса пользовательских страниц». В него собираются все уникальные и при этом обязательные поля профиля пользователя, а также добавлены два значения «id» и «Адрес профиля (slug)». Если выбрано «id», то при регистрации ничего не запрашивается, а в адрес нового пользователя подставляется его id. При выборе «Адрес профиля (slug)» в форму регистрации будет добавлено поле «Красивое имя для адреса Ваших страниц». Под ним отображается подсказка про будущий адрес профиля, в который подставляется набранное пользователем значение. Если выбрано другое поле, то оно с подсказкой про будущий адрес выводится в форму и его значение будет подставлено в адрес пользователя.
Во-вторых, аналогичная опция есть и в «Админка – Компоненты – Профили пользователей – Опции – Профиль пользователя» – выпадающий список «При редактировании адреса профиля использовать поле». В нём присутствуют те же уникальные поля профиля пользователя, а также «Адрес профиля (slug)». Как и при регистрации, в форму редактирования профиля добавляется соответствующее поле с подсказкой про будущий адрес.
Естественно, везде поле, используемое для адреса профиля, проверяется по нескольким условиям:
— оно должно быть заполнено;
— оно должно быть уникальным;
— оно может содержать только заглавные или прописные латинские буквы (хотя бы одну), цифры и знак подчёркивания;
— длина от 4 до 64 символов;
— оно проверяется по списку «Запрещенные слова в адресах пользовательских профилей»;
— оно не может совпадать с именем любого экшена для компонента users.
Пока в Двойке нет принудительной сортировки групп полей в профиле, я предлагаю использовать соглашение о том, что группа с пустым именем (в выпадающем списке обозначена знаком дефиса «–») будет считаться основной и всегда располагаться вверху формы регистрации и редактирования профиля. Следовательно, если нужно, чтобы какое-то поле при регистрации было в самой верхней группе (с почтой и паролем), нужно выбрать для него группу «–». Аналогично и при редактировании профиля.
Если изменение адреса запрещено (всегда или уже), то поле адреса или связанное с ним поле в форме редактирования профиля не выводятся.
Если изменение доступно один раз, то рядом с заголовком поля выводится предупреждение красными буквами.
Админу редактирование адреса и связанного поля доступно всегда независимо от выбранного режима.
В формах добавления и редактирования пользователя также добавлено поля «URL» и поле, используемое для подстановки в адрес (опционально). Обычно эти поля будут совпадать, но можно внести и разные значения. Осуществляется проверка только поля «URL» и только на уникальность и по списку экшенов. Всё остальное – под ответственность админа сайта.
Если поле «URL» оставить пустым, то в него будет подставлен id пользователя.
Авторизация и регистрация – Регистрация
выпад. список «При регистрации запрашивать/подставлять в адреса пользовательских страниц»
поле «Ссылка на "Правила сайта"»
Авторизация и регистрация – Авторизация
выпадающий список «Авторизация по полю»
Авторизация и регистрация – Ограничения и запреты
поле «Запрещенные слова в адресах пользовательских профилей»
Профили пользователей – Опции – Профиль пользователя
выпадающий список «Редактирование адреса профиля пользователем»
выпадающий список «При редактировании адреса профиля использовать поле»
Регулярные выражения в строковых полях. Теперь вы можете задать регулярку в настройках строкового поля в любом месте (и в профилях, и в контенте). Это очень удобно.
Подсчёт введённых/оставшихся символов никнейма при регистрации и редактировании профиля. Теперь можно включить эту полезную опцию и для никнеймов.
Возможность подстановки адреса профиля в адрес контента – в шаблоне адреса контента кроме прежнего {user_id} можно использовать {user_slug}. С этим нужно быть осторожнее, так как при изменении адреса пользователя останутся прежние адреса материалов со старым адресом пользователя.
301-й редирект на правильный адрес при переходе на пользователя по id при наличии буквенно-цифрового адреса. Если slug в полученном адресе цифровой, то ищется пользователь по id. Если пользователь найден, то делается 301-й редирект на его правильный адрес. Зацикленность редиректов при реально цифровом адресе исключена.
Пока для тестирования эта функция временно отключёна и при доступе к профилю по цифровому id, если он уже заменён буквенным адресом, возникнет 404-я ошибка. Обо всех таких ошибках сообщите мне.
Уменьшены и сделаны динамическими левые отступы (для значков сортировки) в шапке и ячейках таблиц в Админке (список пользователей, контента и т.д).
Новые хуки:
user_register_form – Создана форма для регистрации. Можете её изменить по своему усмотрению.
user_before_register – После всех проверок перед добавлением пользователя. Можете дополнительно проверить данные пользователя, при необходимости вернуть сообщения об ошибках или изменить подготовленный профиль пользователя.
user_profile_form – Создана форма для редактирования профиля пользователем. Можете её изменить, если нужно.
user_before_update – При редактировании профиля пользователем после всех проверок перед подстановкой адреса профиля и сохранением профиля. Можете дополнительно проверить профиль пользователя, при необходимости вернуть сообщения об ошибках или изменить подготовленный профиль.
По идее, учитывается и должно работать переименование users во что-то другое (см в документации «Замена URL компонентов»).
2. Если в ленту активности попало событие «Дружба пользователей», то в БД сохраняется адрес профиля второго пользователя в с тем адресом, какой был на момент дружбы. И при изменении адреса профиля этот адрес уже не меняется и по нему профиль пользователя может оказаться уже недоступен.
3. При использовании модулей регистрации новых пользователей из соцсетей, может понадобиться доработка этих модулей, чтобы они сохраняли логины пользователей или подставляли вместо логинов в поле login их id.
4. Обратите внимание, что переключаться в разные варианты регистрации, авторизации и адресов профилей можно в любой момент. Но нужно помнить, что в адресах профилей используется поле slug. И даже если вы решили туда подставлять что-то другое, то в уже заполненных полях значения сохранятся, а значит для существующих пользователей подставляться будут именно эти значения.
5. В любой момент при любых настройках вы можете изменить id в адресах любых пользователей на нужные вам значения. Например, при цифровых адресах у пользователей сделать службе поддержки, модератору и админу адреса support, moderator и admin.
Например:
Это решение разработчиков Двойки. И я с ним согласен. Такой подход концептуально правильный. Он позволяет разделить адрес и остальные поля, а также исключает небольшое замедление системы, которое было в моём предыдущем варианте логинов.
Добавлена новая функция getUserBySlug($slug) в модели cmsUsers. Возвращает профиль пользователя по его slug.
Добавлена новая функция getAuthByTitle() в контроллере аутентификации и регистрации, возвращающая название поля для авторизации.
Скрыть легко. В файле \system\controllers\users\backend\actions\fields_edit.php меняем строку 32
на
Это уже сделано.
Потом в таблице cms_users_fields нужно включить is_fixed_type для никнейма (поставить в поле «1»). Это я пока не делал. Так как при скрытии списка типа поля в форме редактирования поля «Никнейм» в «Админка – Профили пользователей – Поля профилей» вылазят ошибки. Их причина в том, что при скрытом списке не передаётся параметр ‘type’ при запросе опций поля /admin/controllers/edit/users/fields_options. Номер поля передаётся, а тип – нет. А я в яве не силён и сходу не нашёл, как тип подставляется в запрос. Если кто-то может подсказать, напишите где и что подправить.
И ещё нужно разнести языковые константы по файлам и сделать перевод на английский. Но это мелочь, сделаю при создании комита на гите.
Поля профилей – Никнейм
Группа = ‘-‘
«Поле должно быть заполнено» = Вкл
Поля профилей – дополнительное поле Логин из этого демо – отсутствует (можете не обращать на него внимание в этом тесте)
Группа = любая
«Поле должно быть заполнено» = Выкл
«Уникальное значение» = Выкл
Авторизация и регистрация
«При регистрации запрашивать/подставлять в адреса пользовательских страниц» = id
«Авторизация по полю» = E-mail
Профили пользователей
«Редактирование адреса профиля пользователем» = Запрещено
«При редактировании адреса профиля использовать поле» = любое
Работа CMS ничем не отличается от её работы в версиях до 2.5.1 включительно. Авторизация по почте. При регистрации запрашиваются никнейм, почта и пароль. В адреса профиля пользователя подставляются id. Изменить адрес пользователи не могут.
Поля профилей – Никнейм
Группа = ‘-‘
«Поле должно быть заполнено» = Вкл
Поля профилей – дополнительное поле Логин из этого демо – отсутствует (можете не обращать на него внимание в этом тесте)
Группа = ‘-‘
«Поле должно быть заполнено» = Выкл
«Уникальное значение» = Выкл
Авторизация и регистрация
«При регистрации запрашивать/подставлять в адреса пользовательских страниц» = Адрес профиля (slug)
«Авторизация по полю» = E-mail
Профили пользователей
«Редактирование адреса профиля пользователем» = любой по необходимости
«При редактировании адреса профиля использовать поле» = Адрес профиля (slug)
Никакие дополнительные поля создавать не нужно.
При регистрации кроме стандартных полей запрашивается адрес. Режим изменения адреса пользователями задаёте в опции «Редактирование адреса профиля пользователем». Если редактирование адреса пользователем разрешено, то при редактировании профиля в форму добавляется поле «Адрес» с подсказкой о будущем адресе. Если запрещено, то поле «Адрес» в форме не отображается.
Поля профилей – Никнейм
Группа = ‘-‘
«Поле должно быть заполнено» = Вкл
«Уникальное значение» = Выкл
Поля профилей – Логин
Группа = ‘-‘
«Поле должно быть заполнено» = Вкл
«Уникальное значение» = Вкл
Авторизация и регистрация
«При регистрации запрашивать/подставлять в адреса пользовательских страниц» = Логин (login)
«Авторизация по полю» = Логин (login)
Профили пользователей
«Редактирование адреса профиля пользователем» = любой по необходимости
«При редактировании адреса профиля использовать поле» = Логин (login)
При регистрации кроме стандартных полей запрашивается логин. Под его примечанием появляется подсказка про будущий адрес профиля. Режим изменения адреса пользователями задаёте в опции «Редактирование адреса профиля пользователем». Если редактирование адреса пользователем разрешено, то при редактировании профиля в форму добавляется поле «Логин» с подсказкой о будущем адресе. Если запрещено, то поле «Логин» в форме не отображается.
Поля профилей – Никнейм
Группа = ‘-‘
«Поле должно быть заполнено» = Выкл
«Уникальное значение» = Выкл
Поля профилей – Город
«Поле должно быть заполнено» = Выкл
Поля профилей – дополнительное поле Логин из этого демо – отсутствует (можете не обращать на него внимание в этом тесте)
Группа = ‘-‘
«Поле должно быть заполнено» =Выкл
«Уникальное значение» = Выкл
Авторизация и регистрация
«При регистрации запрашивать/подставлять в адреса пользовательских страниц» =id
«Авторизация по полю» = E-mail
Профили пользователей
«Редактирование адреса профиля пользователем» = любой по необходимости
«При редактировании адреса профиля использовать поле» = Адрес профиля (slug)
При регистрации запрашиваются только почта и пароль. Авторизация по почте. Режим изменения адреса пользователями задаёте в опции «Редактирование адреса профиля пользователем».
Вниманию «упрощателей регистрации». 😊 Вы можете отключить галку «Обязательное поле» у «Никнеймов» и это поле перестанет запрашиваться при регистрации. Но тогда вам нужно будет самим озаботиться тем, чтобы в любом своём компоненте перехватывать события user_before_register, user_registered и user_before_update и подставлять в них корректные значения поля «Никнейм». Иначе возникнет ошибка при добавления отсутствующего никнейма в БД и пропадут пользователи в ссылках.
Я сделал пример такой обработки. В этом тестовом варианте системы присутствует компонент «nickname» – папка \system\controllers\nickname\. В папке есть пустой фронтенд компонента, манифест с перечнем перехватываемых хуков и три файла обработки хуков. Если при регистрации перед сохранением пользователя у него пустой никнейм, как в этом варианте регистрации, то в поле никнейма сначала подставляется временное значение «user» (так как до сохранения пользователя id неизвестен). После сохранения профиля делаем более осмысленный ник, добавляя id этого пользователя (например, «user123»). Далее пользователь может изменить ник на любой другой в своём профиле. Но если он попытается при этом удалить никнейм вообще, то третий обработчик либо подставит обратно тот ник, который был до редактирования, либо выдаст сообщение о том, что поле должно быть заполнено (в обработчике один из вариантов закомментирован).
Поля профилей – Никнейм
Переименовываем это поле в «Логин» и соответственно меняем комментарий
Регулярное выражение = /^([a-z0-9\_]*[a-z]+[a-z0-9\_]*)$/i (нужно для ограничения ввода только латинскими буквами и для присутствия хотя бы одной буквы, чтобы отличаться от цифрового id)
Группа = ‘-‘
«Поле должно быть заполнено» = Вкл
«Уникальное значение» = Вкл
Поля профилей – дополнительное поле Логин из этого демо – отсутствует (можете не обращать на него внимание в этом тесте)
Группа = любая
«Поле должно быть заполнено» = Выкл
«Уникальное значение» = Выкл
Авторизация и регистрация
«При регистрации запрашивать/подставлять в адреса пользовательских страниц» = Логин (nickname)
«Авторизация по полю» = E-mail или Логин (nickname) (по необходимости)
Профили пользователей
«Редактирование адреса профиля пользователем» = любой по необходимости
«При редактировании адреса профиля использовать поле» = Логин (nickname)
В этом варианте никнеймов в их привычном понимании не будет. Вместо них будут логины из латинских букв и цифр. Они же будут подставляться в адреса профилей.
Имя поля «Логина» останется nickname. Это нужно учитывать при дальнейшей работе с этим полем. Авторизация на ваш выбор: по почте или по логину. Режим изменения адреса пользователями задаёте в опции «Редактирование адреса профиля пользователем», как и в варианте с никнеймами и логинами.Для этих примеров поле «Логин» было создано вручную. Вместо него вы можете создать любое другое поле. Например, «Номер телефона» или «Налоговый код предприятия» и использовать его для авторизации и/или адреса профиля. Или вообще не создавать его, если оно не нужно (в стандартном варианте, например).
А далее пробуйте разные варианты по инструкциям выше.
В случае возникновения ошибок, замечаний и предложений, прошу указывать какой вариант тестировали или какие настройки были выставлены. Заодно ещё раз проверьте настройки на совпадение с указанными вариантами.
Скачать пакет установки версии 0.5.251.1
UPD 2016.06.06
Исправлена ошибка неправильного вызова контроллера "auth". Спасибо Нико! Инсталл перезалит.
На уже установленный пакет можно накатить обновление до версии 0.5.251.1. Оно заменяет только один файл.
Возможности: авторизация по любому полю, подстановка любого поля в адреса профилей пользователей, уникальные никнеймы, правила сайта и другие интересности. Итак, забываем про просто логины и тестируем универсальное решение.
Предупреждение:
Данный вариант НЕ ПРЕДНАЗНАЧЕН для использования в реальных проектах.
Он выложен тут ТОЛЬКО ДЛЯ ТЕСТИРОВАНИЯ.
Начнём с самого простого, с авторизации
В «Админка – Компоненты – Авторизация и регистрация – Авторизация» появилась новая опция – выпадающий список «Авторизация по полю». В него подставляются все уникальные поля профиля пользователя, включая e-mail. Таким образом, вы можете выбрать любое поле для входа, хоть созданное вами поле «Логин» или «Телефон». И даже «Никнейм», но об этом ниже.При этом для совместимости с Единичкой сделана двойная авторизация. Если вместо ожидаемого поля передали почту, то авторизация будет по ней независимо от выбранного поля в списке.
Естественно, на странице, в виджете и ява-окошке авторизации подставляется соответствующее название поля и изменено сообщение о неправильном вводе данных.
Адреса профилей
Всё достаточно просто, нужно только уловить принцип. Подход изменился и теперь приведён в соответствие с «политикой партии». Поля «Логин» для авторизации и адреса уже нет (если его не создать самому, как в данной тестовой сборке). Вместо него в таблицу cms_users добавил поле slug «Адрес профиля». Значения из этого поля теперь подставляются в адреса профилей вместо поля id. Разработчикам компонентов нужно учитывать, что это поле всегда должно быть заполнено, иначе пропадут ссылки на пользователей. В это поле можно подставлять или id, или любое другое значение, допустимое для использования в адресе профиля.Для удобства уже реализована подстановка поля, заданного в Админке.
Во-первых, в «Админка – Компоненты – Авторизация и регистрация – Регистрация» – новый выпадающий список «При регистрации запрашивать/подставлять в адреса пользовательских страниц». В него собираются все уникальные и при этом обязательные поля профиля пользователя, а также добавлены два значения «id» и «Адрес профиля (slug)». Если выбрано «id», то при регистрации ничего не запрашивается, а в адрес нового пользователя подставляется его id. При выборе «Адрес профиля (slug)» в форму регистрации будет добавлено поле «Красивое имя для адреса Ваших страниц». Под ним отображается подсказка про будущий адрес профиля, в который подставляется набранное пользователем значение. Если выбрано другое поле, то оно с подсказкой про будущий адрес выводится в форму и его значение будет подставлено в адрес пользователя.
Во-вторых, аналогичная опция есть и в «Админка – Компоненты – Профили пользователей – Опции – Профиль пользователя» – выпадающий список «При редактировании адреса профиля использовать поле». В нём присутствуют те же уникальные поля профиля пользователя, а также «Адрес профиля (slug)». Как и при регистрации, в форму редактирования профиля добавляется соответствующее поле с подсказкой про будущий адрес.
Естественно, везде поле, используемое для адреса профиля, проверяется по нескольким условиям:
— оно должно быть заполнено;
— оно должно быть уникальным;
— оно может содержать только заглавные или прописные латинские буквы (хотя бы одну), цифры и знак подчёркивания;
— длина от 4 до 64 символов;
— оно проверяется по списку «Запрещенные слова в адресах пользовательских профилей»;
— оно не может совпадать с именем любого экшена для компонента users.
Пока в Двойке нет принудительной сортировки групп полей в профиле, я предлагаю использовать соглашение о том, что группа с пустым именем (в выпадающем списке обозначена знаком дефиса «–») будет считаться основной и всегда располагаться вверху формы регистрации и редактирования профиля. Следовательно, если нужно, чтобы какое-то поле при регистрации было в самой верхней группе (с почтой и паролем), нужно выбрать для него группу «–». Аналогично и при редактировании профиля.
Изменение адреса пользователями
Новая опция в «Админка – Компоненты – Профили пользователей – Опции – Профиль пользователя» – выпадающий список «Редактирование адреса профиля пользователем». Три режима изменения адреса: разрешить, разрешить один раз при смене адреса с цифрового id на нормальный адрес, запретить.Если изменение адреса запрещено (всегда или уже), то поле адреса или связанное с ним поле в форме редактирования профиля не выводятся.
Если изменение доступно один раз, то рядом с заголовком поля выводится предупреждение красными буквами.
Админу редактирование адреса и связанного поля доступно всегда независимо от выбранного режима.
Админка
В Админке тоже есть соответствующие изменения. В «Пользователях» в списке пользователей после колонки почты опционально добавляется колонка с полем, используемым для авторизации. А после колонки авторизации добавлена колонка «URL». По этим колонкам, как и по остальным, работают фильтры.В формах добавления и редактирования пользователя также добавлено поля «URL» и поле, используемое для подстановки в адрес (опционально). Обычно эти поля будут совпадать, но можно внести и разные значения. Осуществляется проверка только поля «URL» и только на уникальность и по списку экшенов. Всё остальное – под ответственность админа сайта.
Если поле «URL» оставить пустым, то в него будет подставлен id пользователя.
Согласие с Правилами сайта
Принцип такой же, как и в прошлой версии. В «Админка – Компоненты – Авторизация и регистрация – Регистрация» добавлена новая опция – поле «Ссылка на "Правила сайта"». Если это поле заполнено, то при регистрации внизу под всеми полями появляется галка «Я подтверждаю, что прочитал(-а) и принимаю "Пользовательское соглашение"», где под "Пользовательское соглашение" подставляется ссылка из этого поля. Кнопка «Продолжить» появляется лишь при включении галки согласия с правилами. При выключенной галке эта кнопка скрывается.Суммарный список новых опций
Просто для вашего удобства.Авторизация и регистрация – Регистрация
выпад. список «При регистрации запрашивать/подставлять в адреса пользовательских страниц»
поле «Ссылка на "Правила сайта"»
Авторизация и регистрация – Авторизация
выпадающий список «Авторизация по полю»
Авторизация и регистрация – Ограничения и запреты
поле «Запрещенные слова в адресах пользовательских профилей»
Профили пользователей – Опции – Профиль пользователя
выпадающий список «Редактирование адреса профиля пользователем»
выпадающий список «При редактировании адреса профиля использовать поле»
Другие возможности
Уникальный никнейм. Включается стандартной галкой «Уникальное значение» в настройках поля «Никнейм» в профилях. Также эта опция работает и для всех остальных полей.Регулярные выражения в строковых полях. Теперь вы можете задать регулярку в настройках строкового поля в любом месте (и в профилях, и в контенте). Это очень удобно.
Подсчёт введённых/оставшихся символов никнейма при регистрации и редактировании профиля. Теперь можно включить эту полезную опцию и для никнеймов.
Возможность подстановки адреса профиля в адрес контента – в шаблоне адреса контента кроме прежнего {user_id} можно использовать {user_slug}. С этим нужно быть осторожнее, так как при изменении адреса пользователя останутся прежние адреса материалов со старым адресом пользователя.
301-й редирект на правильный адрес при переходе на пользователя по id при наличии буквенно-цифрового адреса. Если slug в полученном адресе цифровой, то ищется пользователь по id. Если пользователь найден, то делается 301-й редирект на его правильный адрес. Зацикленность редиректов при реально цифровом адресе исключена.
Пока для тестирования эта функция временно отключёна и при доступе к профилю по цифровому id, если он уже заменён буквенным адресом, возникнет 404-я ошибка. Обо всех таких ошибках сообщите мне.
Уменьшены и сделаны динамическими левые отступы (для значков сортировки) в шапке и ячейках таблиц в Админке (список пользователей, контента и т.д).
Новые хуки:
user_register_form – Создана форма для регистрации. Можете её изменить по своему усмотрению.
user_before_register – После всех проверок перед добавлением пользователя. Можете дополнительно проверить данные пользователя, при необходимости вернуть сообщения об ошибках или изменить подготовленный профиль пользователя.
user_profile_form – Создана форма для редактирования профиля пользователем. Можете её изменить, если нужно.
user_before_update – При редактировании профиля пользователем после всех проверок перед подстановкой адреса профиля и сохранением профиля. Можете дополнительно проверить профиль пользователя, при необходимости вернуть сообщения об ошибках или изменить подготовленный профиль.
Особенности реализации
1. Адреса профилей вместо id подставляются только в адреса пользовательских страниц (контроллера users) вида site.ru/users/id или site.ru//users/id/что-то_ещё. В служебных адресах вида site.ru/users/action_name/id логины не подставляются и там в любом режиме остаются id. То есть подстановка делается только там, где id стоит на первом месте после имени контроллера users.По идее, учитывается и должно работать переименование users во что-то другое (см в документации «Замена URL компонентов»).
2. Если в ленту активности попало событие «Дружба пользователей», то в БД сохраняется адрес профиля второго пользователя в с тем адресом, какой был на момент дружбы. И при изменении адреса профиля этот адрес уже не меняется и по нему профиль пользователя может оказаться уже недоступен.
3. При использовании модулей регистрации новых пользователей из соцсетей, может понадобиться доработка этих модулей, чтобы они сохраняли логины пользователей или подставляли вместо логинов в поле login их id.
4. Обратите внимание, что переключаться в разные варианты регистрации, авторизации и адресов профилей можно в любой момент. Но нужно помнить, что в адресах профилей используется поле slug. И даже если вы решили туда подставлять что-то другое, то в уже заполненных полях значения сохранятся, а значит для существующих пользователей подставляться будут именно эти значения.
5. В любой момент при любых настройках вы можете изменить id в адресах любых пользователей на нужные вам значения. Например, при цифровых адресах у пользователей сделать службе поддержки, модератору и админу адреса support, moderator и admin.
Важная информация для разработчиков
Изменилось создание ссылок на пользователей для адресов вида site.ru/users/id или site.ru//users/id/что-то_ещё. Вам нужно будет в своих компонентах и шаблонах проверить все такие места и изменить вызовы функции href_to(), типа href_to('users', $profile[‘id’]) для всех вариантов этой функции, подставив slug вместо id. Во всех стандартных компонентах и шаблоне это уже сделано. Кроме того, в их фронтенды уже добавлено поле slug во все переменные, которые используются в подстановке адресов, в том числе и в шаблон. Поправьте ваши компоненты, чтобы они тоже в информации о пользователях возвращали поле slug.Например:
Добавлена новая функция getUserBySlug($slug) в модели cmsUsers. Возвращает профиль пользователя по его slug.
Добавлена новая функция getAuthByTitle() в контроллере аутентификации и регистрации, возвращающая название поля для авторизации.
Что ещё осталось сделать
Поскольку «Никнейм» — системное поле, то нельзя разрешать менять в нём тип поля со строковго на другй. Но при этом нужно дать возможность настраивать параметры этого типа. В данный момент я пока разрешил доступ ко всем полям в блоке «Тип поля» никнема, сделав его не системным. Но это неправильно. Идеальный вариант – скрыть выпадающий список вариантов типов полей, но оставить параметры, которые в этом блоке под этим списком.Скрыть легко. В файле \system\controllers\users\backend\actions\fields_edit.php меняем строку 32
Потом в таблице cms_users_fields нужно включить is_fixed_type для никнейма (поставить в поле «1»). Это я пока не делал. Так как при скрытии списка типа поля в форме редактирования поля «Никнейм» в «Админка – Профили пользователей – Поля профилей» вылазят ошибки. Их причина в том, что при скрытом списке не передаётся параметр ‘type’ при запросе опций поля /admin/controllers/edit/users/fields_options. Номер поля передаётся, а тип – нет. А я в яве не силён и сходу не нашёл, как тип подставляется в запрос. Если кто-то может подсказать, напишите где и что подправить.
И ещё нужно разнести языковые константы по файлам и сделать перевод на английский. Но это мелочь, сделаю при создании комита на гите.
Примеры использования
Поля профилей – Никнейм
Группа = ‘-‘
«Поле должно быть заполнено» = Вкл
Поля профилей – дополнительное поле Логин из этого демо – отсутствует (можете не обращать на него внимание в этом тесте)
Группа = любая
«Поле должно быть заполнено» = Выкл
«Уникальное значение» = Выкл
Авторизация и регистрация
«При регистрации запрашивать/подставлять в адреса пользовательских страниц» = id
«Авторизация по полю» = E-mail
Профили пользователей
«Редактирование адреса профиля пользователем» = Запрещено
«При редактировании адреса профиля использовать поле» = любое
Работа CMS ничем не отличается от её работы в версиях до 2.5.1 включительно. Авторизация по почте. При регистрации запрашиваются никнейм, почта и пароль. В адреса профиля пользователя подставляются id. Изменить адрес пользователи не могут.
Поля профилей – Никнейм
Группа = ‘-‘
«Поле должно быть заполнено» = Вкл
Поля профилей – дополнительное поле Логин из этого демо – отсутствует (можете не обращать на него внимание в этом тесте)
Группа = ‘-‘
«Поле должно быть заполнено» = Выкл
«Уникальное значение» = Выкл
Авторизация и регистрация
«При регистрации запрашивать/подставлять в адреса пользовательских страниц» = Адрес профиля (slug)
«Авторизация по полю» = E-mail
Профили пользователей
«Редактирование адреса профиля пользователем» = любой по необходимости
«При редактировании адреса профиля использовать поле» = Адрес профиля (slug)
Никакие дополнительные поля создавать не нужно.
При регистрации кроме стандартных полей запрашивается адрес. Режим изменения адреса пользователями задаёте в опции «Редактирование адреса профиля пользователем». Если редактирование адреса пользователем разрешено, то при редактировании профиля в форму добавляется поле «Адрес» с подсказкой о будущем адресе. Если запрещено, то поле «Адрес» в форме не отображается.
Поля профилей – Никнейм
Группа = ‘-‘
«Поле должно быть заполнено» = Вкл
«Уникальное значение» = Выкл
Поля профилей – Логин
Группа = ‘-‘
«Поле должно быть заполнено» = Вкл
«Уникальное значение» = Вкл
Авторизация и регистрация
«При регистрации запрашивать/подставлять в адреса пользовательских страниц» = Логин (login)
«Авторизация по полю» = Логин (login)
Профили пользователей
«Редактирование адреса профиля пользователем» = любой по необходимости
«При редактировании адреса профиля использовать поле» = Логин (login)
При регистрации кроме стандартных полей запрашивается логин. Под его примечанием появляется подсказка про будущий адрес профиля. Режим изменения адреса пользователями задаёте в опции «Редактирование адреса профиля пользователем». Если редактирование адреса пользователем разрешено, то при редактировании профиля в форму добавляется поле «Логин» с подсказкой о будущем адресе. Если запрещено, то поле «Логин» в форме не отображается.
Поля профилей – Никнейм
Группа = ‘-‘
«Поле должно быть заполнено» = Выкл
«Уникальное значение» = Выкл
Поля профилей – Город
«Поле должно быть заполнено» = Выкл
Поля профилей – дополнительное поле Логин из этого демо – отсутствует (можете не обращать на него внимание в этом тесте)
Группа = ‘-‘
«Поле должно быть заполнено» =Выкл
«Уникальное значение» = Выкл
Авторизация и регистрация
«При регистрации запрашивать/подставлять в адреса пользовательских страниц» =id
«Авторизация по полю» = E-mail
Профили пользователей
«Редактирование адреса профиля пользователем» = любой по необходимости
«При редактировании адреса профиля использовать поле» = Адрес профиля (slug)
При регистрации запрашиваются только почта и пароль. Авторизация по почте. Режим изменения адреса пользователями задаёте в опции «Редактирование адреса профиля пользователем».
Вниманию «упрощателей регистрации». 😊 Вы можете отключить галку «Обязательное поле» у «Никнеймов» и это поле перестанет запрашиваться при регистрации. Но тогда вам нужно будет самим озаботиться тем, чтобы в любом своём компоненте перехватывать события user_before_register, user_registered и user_before_update и подставлять в них корректные значения поля «Никнейм». Иначе возникнет ошибка при добавления отсутствующего никнейма в БД и пропадут пользователи в ссылках.
Я сделал пример такой обработки. В этом тестовом варианте системы присутствует компонент «nickname» – папка \system\controllers\nickname\. В папке есть пустой фронтенд компонента, манифест с перечнем перехватываемых хуков и три файла обработки хуков. Если при регистрации перед сохранением пользователя у него пустой никнейм, как в этом варианте регистрации, то в поле никнейма сначала подставляется временное значение «user» (так как до сохранения пользователя id неизвестен). После сохранения профиля делаем более осмысленный ник, добавляя id этого пользователя (например, «user123»). Далее пользователь может изменить ник на любой другой в своём профиле. Но если он попытается при этом удалить никнейм вообще, то третий обработчик либо подставит обратно тот ник, который был до редактирования, либо выдаст сообщение о том, что поле должно быть заполнено (в обработчике один из вариантов закомментирован).
Поля профилей – Никнейм
Переименовываем это поле в «Логин» и соответственно меняем комментарий
Регулярное выражение = /^([a-z0-9\_]*[a-z]+[a-z0-9\_]*)$/i (нужно для ограничения ввода только латинскими буквами и для присутствия хотя бы одной буквы, чтобы отличаться от цифрового id)
Группа = ‘-‘
«Поле должно быть заполнено» = Вкл
«Уникальное значение» = Вкл
Поля профилей – дополнительное поле Логин из этого демо – отсутствует (можете не обращать на него внимание в этом тесте)
Группа = любая
«Поле должно быть заполнено» = Выкл
«Уникальное значение» = Выкл
Авторизация и регистрация
«При регистрации запрашивать/подставлять в адреса пользовательских страниц» = Логин (nickname)
«Авторизация по полю» = E-mail или Логин (nickname) (по необходимости)
Профили пользователей
«Редактирование адреса профиля пользователем» = любой по необходимости
«При редактировании адреса профиля использовать поле» = Логин (nickname)
В этом варианте никнеймов в их привычном понимании не будет. Вместо них будут логины из латинских букв и цифр. Они же будут подставляться в адреса профилей.
Имя поля «Логина» останется nickname. Это нужно учитывать при дальнейшей работе с этим полем. Авторизация на ваш выбор: по почте или по логину. Режим изменения адреса пользователями задаёте в опции «Редактирование адреса профиля пользователем», как и в варианте с никнеймами и логинами.
Как тестировать
Поставьте чистую 2.5.1 с демо-данными. Накатите установочный пакет. На странице «Установка завершена» может быть показано предупреждение о неопределённом свойстве класса – это нормально, не обращайте внимание, страница готовится старым фронтендом, а собирается уже обновлённым шаблоном.А далее пробуйте разные варианты по инструкциям выше.
В случае возникновения ошибок, замечаний и предложений, прошу указывать какой вариант тестировали или какие настройки были выставлены. Заодно ещё раз проверьте настройки на совпадение с указанными вариантами.
Скачать пакет установки версии 0.5.251.1
Заранее спасибо за помощь!
UPD 2016.06.06
Исправлена ошибка неправильного вызова контроллера "auth". Спасибо Нико! Инсталл перезалит.
На уже установленный пакет можно накатить обновление до версии 0.5.251.1. Оно заменяет только один файл.
Например, авторизация может быть по разным полям. Или на одном при регистрации будут запрашиваться адреса профилей, на другом будут подставляться id. Так можно, но зачем?
Покажите, пожалуйста, логи ошибок Апача. Или включите в настройках сайта отладку и пришлите текст ошибки, если она где-то будет показана.
Это
Сейчас исправлю в инсталле и перевыложу его.
Инстант - это более универсальное решение, скорее портальный движок с социальной направленностью. Тут такого не нужно и не будет.
Если кого-то интересует мигратор с Единички на Двойку, то прошу всё-таки осилить текст и потестировать это решение. Потому как для полноценного мигратора нужны логины и их в любом случае придётся делать. На мой взгляд, лучше сделать и протестировать универсальное решение, чем только логины.
Логин нужен для авторизации пользователя. Пользователь успешно авторизовался и у него теперь есть user_id. Зачем дальше нужен логин?
Проблемы с переходом с первой ветки решаются добавлением колонки login в таблицу cms_users, отменой проверки поля на мыльность и добавлением пары строк:
http://instantcms.ru/forum/thread24563-1.html#235000
Я ни в коем случае не хочу как-то дискредитировать вашу работу, я искренне пытаюсь понять, зачем нужен логин пользователю, который уже авторизовался и имеет id и nickname в его дальнейшей жизни на сайте.
Для чего всё остальное?
Манипуляции с адресной строкой.
А блог site.ru/blogs/123 некошерно?
Кому, кроме вебмастера, нужны эти красивости?
Заранее спасибо за понимание.
Вы не поняли. Мне, например, логин нужен и интересен. Я пытался выяснить, какие еще возможности, кроме авторизации и отображения в адресной строке.
1. Логин может использоваться и при авторизации, и в адресе профиля пользователя, и в качестве замены никнейму для однозначной визуальной идентификации пользователей. Под разные проекты - разные использования. Например, в Единичке логины используются и в адресах тоже. Без этого полноценный мигратор не сделаешь.
В Вашем примере логин используется только для авторизации. А другие возможности не реализуются.
2. Кроме того, в Вашем примере это делается хаком. А любые хаки создают проблемы при обновлении.
3. Авторизовываться можно не только по мылу или логину. А и, например, по телефону. Если следовать логике Вашего примера, то для этого нужны ещё бОльше хаки. А значит будут ещё бОльшие сложности с обновлениями.
4. Создать в Админке нужное поле с желаемым названием и подсказкой, а потом выбрать его в выпадающем списке "Использовать для авторизации", а всё остальное сделает движок с предложенными мной правками - это гораздо проще, чем добавлять в базе данных поле нужного типа и делать дополнительные хаки на нужные проверки, добавление колонки в Админку и т.п.
5. То же самое касается и адресов пользователей. В этом варианте всё делается несколькими щелчками мышки в Админке без любого программирования.
6. Кроме того, возможен вариант, когда требуется минимальная регистрация (по почте и паролю). Его можно сделать или несколькими хуками без моего решения, или можно в моём решении поставить нужные настройки и добавить перехват событий, что позволит спокойно обновляться на новые версии.
Короче - предложенное к тестированию решение универсальное и позволяет сделать на сайте массу разных вариантов без программирования.
Если сделать дополнение, которое будет просто заменять один файл \system\core\user.php - это уже не будет хаком, а полноценным дополнением?
Или для полноценного переноса ссылок в комментариях?
Огромное спасибо за информацию!
Прекрасная разработка. Я ставил цель сделать хороший магазин для системы и это выполнено,
А то что ВЫ уважаемый WebMan выполнили, это предел моих мечтаний! Я прекрасно понимаю что ВЫ выполнили.
Я просто поражен как это вовремя.
Я ставлю вашу разработку и в локально и реальном варианте и просто понимаю что это реальное развитие.
Это то что мне именно не хватало в системе, Свои "красивые " ссылки на страницы я готовил хитрыми решениями. А теперь ( http://gen-cart.com/users/crasava/cart_profile) все складывается в одну единую цепочку.
Кто желает тестировать магазин в свете разработки Уважаемого WebMan , Сегодня открою регистрацию .
Временно!
Использовать этот пакет на реальных сайтах не стоит. Разве что на сайтах в режиме тестирования без реальных пользователей. Будет лучше для Вас и для сообщества, если Вы погоняете его функционал на локалке, чтобы оценить удобство решения и выявить все ошибки.
А по поводу "в новом релизе" - это к разработчикам Инстанта, они принимают решение о включении нового функционала.