Логины в ICMS 2 v.5 – открытое тестирование

+40
5.28K
Общение с Fuze, а также перечитывание каментов в блоге и в темах про логины, адреса профилей и авторизацию произвели на мой системно-программерский ум неизгладимое впечатление. 😊 В общем, дабы учесть видение разработчиков Инстанта и противоречивые желания большинства пользователей, я полностью изменил концепцию и переделал весь код. В систему внесено очень много правок, изменено более сотни файлов. Надеюсь, этот вариант понравится и пользователям, и разработчикам InstantCMS 2 настолько, что он будет включён в систему «из коробки». Нужна ваша активная помощь в его тестировании.

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

Иллюстрация

Предупреждение:

Данный вариант НЕ ПРЕДНАЗНАЧЕН для использования в реальных проектах.
Он выложен тут ТОЛЬКО ДЛЯ ТЕСТИРОВАНИЯ.


Начнём с самого простого, с авторизации

В «Админка – Компоненты – Авторизация и регистрация – Авторизация» появилась новая опция – выпадающий список «Авторизация по полю». В него подставляются все уникальные поля профиля пользователя, включая 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.
Например:
  1. // раньше было
  2. href_to('users', $profile[‘id'])
  3. // теперь можно и нужно использовать
  4. href_to('users', $profile[‘slug'])
  1. // раньше было
  2. href_to('users', $user_id])
  3. // теперь можно и нужно использовать
  4. href_to('users', $user_slug])
Это решение разработчиков Двойки. И я с ним согласен. Такой подход концептуально правильный. Он позволяет разделить адрес и остальные поля, а также исключает небольшое замедление системы, которое было в моём предыдущем варианте логинов.

Добавлена новая функция getUserBySlug($slug) в модели cmsUsers. Возвращает профиль пользователя по его slug.

Добавлена новая функция getAuthByTitle() в контроллере аутентификации и регистрации, возвращающая название поля для авторизации.

Что ещё осталось сделать

Поскольку «Никнейм» — системное поле, то нельзя разрешать менять в нём тип поля со строковго на другй. Но при этом нужно дать возможность настраивать параметры этого типа. В данный момент я пока разрешил доступ ко всем полям в блоке «Тип поля» никнема, сделав его не системным. Но это неправильно. Идеальный вариант – скрыть выпадающий список вариантов типов полей, но оставить параметры, которые в этом блоке под этим списком.
Скрыть легко. В файле \system\controllers\users\backend\actions\fields_edit.php меняем строку 32
  1. if ($field['is_fixed_type']) { $form->removeFieldset('type'); }
на
  1. if ($field['is_fixed_type']) { $form->hideField('type', 'type'); }
Это уже сделано.
Потом в таблице 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. Оно заменяет только один файл.
0
Capitan Capitan 5 лет назад #
А если используется два сайта с единой базой пользователей, то настройки что там что там должны быть идентичны?
+1
WebMan WebMan 5 лет назад #
Не обязательно, но желательно. Нужно смотреть по конкретным задачам.
Например, авторизация может быть по разным полям. Или на одном при регистрации будут запрашиваться адреса профилей, на другом будут подставляться id. Так можно, но зачем?
0
Нико Нико 5 лет назад #
Ошибка 503 в чем проблема и сайт не работает)) ?
0
Нико Нико 5 лет назад #
Сайт работает но, в свой профиль заглянуть не возможно и в админке в users не возможно
0
WebMan WebMan 5 лет назад #
Что Вы перед этим делали и какие настройки выставили?
0
Нико Нико 5 лет назад #
Я ничего не делал установил движок 2.5.1 залил компонент все норм работает щас но в админке с пользователями не заходит admin/users HTTP ERROR 500
0
WebMan WebMan 5 лет назад #
Только что опять накатил пакет на чистую демо. Всё работает, список пользователей в Админке по admin/users показывает.
Покажите, пожалуйста, логи ошибок Апача. Или включите в настройках сайта отладку и пришлите текст ошибки, если она где-то будет показана.
0
Нико Нико 5 лет назад #
Если ошибка с папкой в админке Auth то надо справить в файле grids_users.php
Это

Код PHP:
  1. $auth_by = cmsCore::getController('Auth')->options['auth_by'];
  2. // Добавляем в таблицу поле для авторизации, если это не email
  3. if ($auth_by != 'email') {
  4. $columns += array(
  5. $auth_by => array(
  6. 'title' => cmsCore::getController('Auth')->getAuthByTitle(),
  7. 'filter' => 'like'
  8. )
  9. );
  10. }
на это


Код PHP:
  1. $auth_by = cmsCore::getController('auth')->options['auth_by'];
  2. // Добавляем в таблицу поле для авторизации, если это не email
  3. if ($auth_by != 'email') {
  4. $columns += array(
  5. $auth_by => array(
  6. 'title' => cmsCore::getController('auth')->getAuthByTitle(),
  7. 'filter' => 'like'
  8. )
  9. );
  10. }
+2
WebMan WebMan 5 лет назад #
Спасибо!!! А то я уже собрался вечером ставить демо на юниксовый хостинг, чтобы найти причины ошибки. Дома на под Виндой ошибка не проявлялась, так как винде пополам регистр букв.
Сейчас исправлю в инсталле и перевыложу его.
+1
WebMan WebMan 5 лет назад #
Исправил инсталл. И сделал пакет обновления с одним исправленным файликом.
0
Нико Нико 5 лет назад #
Да это дополнение надо сделать, тогда инстант будет еще круче, + если users можно было бы убрать и компоненты при добавления имели бы ссылку как сomponents/news это было бы лучше чем пользователей запихнули в users/id
0
WebMan WebMan 5 лет назад #
Нико:
если users можно было бы убрать
Это нужно лишь для очень больших соцсетей. Но там принцип другой, цели другие, а значит и решения другие.
Инстант - это более универсальное решение, скорее портальный движок с социальной направленностью. Тут такого не нужно и не будет.
+1
eoleg eoleg 5 лет назад #
+ хоть и не смог осилить весь текст! smile
0
WebMan WebMan 5 лет назад #
Понимаю, текста много. smile
Если кого-то интересует мигратор с Единички на Двойку, то прошу всё-таки осилить текст и потестировать это решение. Потому как для полноценного мигратора нужны логины и их в любом случае придётся делать. На мой взгляд, лучше сделать и протестировать универсальное решение, чем только логины.
0
Ris Ris 5 лет назад #
Можно ли мне разъяснения выдать, так чтобы даже первоклассник понял?
Логин нужен для авторизации пользователя. Пользователь успешно авторизовался и у него теперь есть user_id. Зачем дальше нужен логин?
Проблемы с переходом с первой ветки решаются добавлением колонки login в таблицу cms_users, отменой проверки поля на мыльность и добавлением пары строк:
http://instantcms.ru/forum/thread24563-1.html#235000

Я ни в коем случае не хочу как-то дискредитировать вашу работу, я искренне пытаюсь понять, зачем нужен логин пользователю, который уже авторизовался и имеет id и nickname в его дальнейшей жизни на сайте.
0
Нико Нико 5 лет назад #
По логину легче войти чем вписывать email
0
Ris Ris 5 лет назад #
Добавляется поле логин в смс_юзерс и готов вход по логину.
Для чего всё остальное?
0
Нико Нико 5 лет назад #
Чтобы у пользователя была ссылка своя на профиль и в будущем можно было обращаться к нему в комментах по @ivan а не @1
0
Ris Ris 5 лет назад #
А никнейм? scratch
0
WebMan WebMan 5 лет назад #
А никнейм можно или оставить, или использовать в качестве поля "Логин". Зависит от задач на Ваших проектах.
0
WebMan WebMan 5 лет назад #
И это. И, например, блог по имени пользователя site.ru/blogs/vasya_pupkin, и мини-сайт каждого пользователя с его материалами, и юрлица/фирмы с ОКПО (налоговый номер) в адресах, и многое другое.
0
Ris Ris 5 лет назад #
Угу. Теперь понял.
Манипуляции с адресной строкой.
А блог site.ru/blogs/123 некошерно?
0
WebMan WebMan 5 лет назад #
Кошерно или нет зависит от задач проекта и от отношения к проекту его вебмастера. Кому-то и site.ru/components/data/get.php?type=user&id=123 - прекрасно подходит. smile
0
Ris Ris 5 лет назад #
Пользователи плевать хотели в адресную строку.
Кому, кроме вебмастера, нужны эти красивости?
0
Val Val 5 лет назад #
Нико:
По логину легче войти чем вписывать email
Чем легче? Открою секрет, что в современных браузерах в большинстве случаев достаточно курсор установить и автозаполнение само все сделает joke Так что ваше утверждение абсолютно не обосновано.

Нико:
Чтобы у пользователя была ссылка своя на профиль и в будущем можно было обращаться к нему в комментах по @ivan а не @1
Чтобы была ссылка через собаку или через любой другой символ не обязательно чтобы были логины! При вашем желании можете повесить ссылку на любое поле (ФИО или никнейм). Я лично считаю что в текущих условиях удобнее всего вешать на никнейм (вопросы уникальности тоже решаемы при неуникальных значениях никнеймов)
+2
WebMan WebMan 5 лет назад #
В этой теме прошу прекратить обсуждение "нужности/ненужности" данного функционала, причём именно теми людьми, кому он действительно не интересен. А прошу высказаться о реализации функций тех людей, кому это нужно и кто готов потратить 15-20 минут, чтобы потестировать удобство и качество решения на разных вариантах применения.
Заранее спасибо за понимание.
0
Ris Ris 5 лет назад #
WebMan
Вы не поняли. Мне, например, логин нужен и интересен. Я пытался выяснить, какие еще возможности, кроме авторизации и отображения в адресной строке.
0
WebMan WebMan 5 лет назад #
Всё основное описано в первых абзацах поста. Плюс ещё в "Других возможностях". Главное - что всё это встроено в концепцию движка и сделано УНИВЕРСАЛЬНО, а не как разрозненные хаки-костыли с форума, которые ещё нужно править под себя.
+2
Val Val 5 лет назад #
WebMan, мой пост исключительно ответ для Нико. Нужность/ненужность не могу судить, т.к. пока что не осилил многобуков)) Так что есть решение и это хорошо!
0
Нико Нико 5 лет назад #
Ну кому как удобно я бы хотел бы вместо id цифр было бы ник пользователя и конфиденциальность усиливается, а то любой пользователь будет листать всех по id )) Я вот сейчас целый день пытаюсь одну вещь сделать ни как не могу )))
0
Val Val 5 лет назад #
Прошу прощения не удержался:
WebMan:
причём именно теми людьми, кому он действительно не интересен.
Вы сказали что хотите внедрить его в коробку! А мне не безразлична судьба InstantCMS 2 smile
0
WebMan WebMan 5 лет назад #
HiAndy:
Можно ли мне разъяснения выдать, так чтобы даже первоклассник понял?
Попробую. smile
1. Логин может использоваться и при авторизации, и в адресе профиля пользователя, и в качестве замены никнейму для однозначной визуальной идентификации пользователей. Под разные проекты - разные использования. Например, в Единичке логины используются и в адресах тоже. Без этого полноценный мигратор не сделаешь.
В Вашем примере логин используется только для авторизации. А другие возможности не реализуются.
2. Кроме того, в Вашем примере это делается хаком. А любые хаки создают проблемы при обновлении.
3. Авторизовываться можно не только по мылу или логину. А и, например, по телефону. Если следовать логике Вашего примера, то для этого нужны ещё бОльше хаки. А значит будут ещё бОльшие сложности с обновлениями.
4. Создать в Админке нужное поле с желаемым названием и подсказкой, а потом выбрать его в выпадающем списке "Использовать для авторизации", а всё остальное сделает движок с предложенными мной правками - это гораздо проще, чем добавлять в базе данных поле нужного типа и делать дополнительные хаки на нужные проверки, добавление колонки в Админку и т.п.
5. То же самое касается и адресов пользователей. В этом варианте всё делается несколькими щелчками мышки в Админке без любого программирования.
6. Кроме того, возможен вариант, когда требуется минимальная регистрация (по почте и паролю). Его можно сделать или несколькими хуками без моего решения, или можно в моём решении поставить нужные настройки и добавить перехват событий, что позволит спокойно обновляться на новые версии.

Короче - предложенное к тестированию решение универсальное и позволяет сделать на сайте массу разных вариантов без программирования.
0
Ris Ris 5 лет назад #
Я дико извиняюсь, но ваше решение заменяет не один системный файл в core, а аж четыре!
Если сделать дополнение, которое будет просто заменять один файл \system\core\user.php - это уже не будет хаком, а полноценным дополнением?

Например, в Единичке логины используются и в адресах тоже. Без этого полноценный мигратор не сделаешь.
Почему?
Или для полноценного переноса ссылок в комментариях? scratch

Если следовать логике Вашего примера, то для этого нужны ещё бОльше хаки.
Да хоть до диаметру колеса велосипеда. Правится один файл. Никаких больших хаков не требуется.

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

А другие возможности не реализуются.
Вот он главный вопрос! Что за "другие возможности"?
0
WebMan WebMan 5 лет назад #
Это решение разрабатывалось не как хак, а как плановые изменения в движок. Если разработчики его примут, то это всё будет уже "из коробки" и ничего править не придётся и новые хаки не понадобятся.

HiAndy:
Правится один файл ...
Это не совсем правда. Правка одного файла годится лишь для одной задачи - авторизации. И не позволит сделать нужные проверки. Например, на уникальность. Также не позволит отображать новое поле в Админке, редактировать его там и многое другое.

HiAndy:
Так всё это можно сделать в установочном файле. Добавляется одна колонка в одну таблицу.
Да, об этом я и говорю. Что одной правкой не обойдёшься.

HiAndy:
Что за "другие возможности"?
Не подставляйтесь, HiAndy. Если Вам тема интересна, то хотя бы прочитайте топик. Там всё подробно описано и даже есть примеры. Если тема не интересна и Вам для любых Ваших проектов хватает "правки одного файла", то без проблем, остановитесь на этом. А мы продолжим про "другие возможности" и универсальность. smile
+1
Ris Ris 5 лет назад #
Я внимательно прочитал. Кроме подстановки логина в адресную строку других возможностей не увидел.
Огромное спасибо за информацию!
+1
Bonefacei Bonefacei 5 лет назад #
Отличная работа!
+2
Старый балбес Старый балбес 5 лет назад #
Уважаемые модераторы! Разрешите мне поставить в этом блоге столько плюсов сколько я хочу!
Прекрасная разработка. Я ставил цель сделать хороший магазин для системы и это выполнено,
А то что ВЫ уважаемый WebMan выполнили, это предел моих мечтаний! Я прекрасно понимаю что ВЫ выполнили.
Я просто поражен как это вовремя.
Я ставлю вашу разработку и в локально и реальном варианте и просто понимаю что это реальное развитие.
Это то что мне именно не хватало в системе, Свои "красивые " ссылки на страницы я готовил хитрыми решениями. А теперь ( http://gen-cart.com/users/crasava/cart_profile) все складывается в одну единую цепочку.
Кто желает тестировать магазин в свете разработки Уважаемого WebMan , Сегодня открою регистрацию .
Временно!
0
Старый балбес Старый балбес 5 лет назад #
Если есть проблемы , сообщайте личным сообщением ! Я на связи до 21
+1
WebMan WebMan 5 лет назад #
Спасибо за хороший отзыв, Геннадий Иванович!
Использовать этот пакет на реальных сайтах не стоит. Разве что на сайтах в режиме тестирования без реальных пользователей. Будет лучше для Вас и для сообщества, если Вы погоняете его функционал на локалке, чтобы оценить удобство решения и выявить все ошибки.
+1
Старый балбес Старый балбес 5 лет назад #
Так сознательно предлагаю площадку. Локально это как с резиновой женщиной.
+1
Bubble Gumoff Bubble Gumoff 5 лет назад #
Что-то я не понял - готов магазин?! А что так скромно, не заметно, в чужой теме об этом говорите?
0
Нико Нико 5 лет назад #
Может будет что-то новое в новом релизе ? Хочу использовать это уже )))
0
WebMan WebMan 5 лет назад #
У меня будет чуток изменённое старое, но для нового релиза. Выложу когда будет готово.
А по поводу "в новом релизе" - это к разработчикам Инстанта, они принимают решение о включении нового функционала.
+1
Нико Нико 5 лет назад #
Ну даже если они не сделают, это можно использовать как компонент. Это хорошая и нужная вещь. И тогда можно обращение сделать. к профилю. Я буду ждать вашего обновления под 2.6.0 и установлю себе.
0
WebMan WebMan 5 лет назад #
Как компонент - нельзя. Слишком глубокие изменения в движке, которые невозможно сделать хуками. На данный момент "Логины" - это большой хак.
+1
Нико Нико 5 лет назад #
Ну даже если они не сделают, это можно использовать как компонент. Это хорошая и нужная вещь. И тогда можно обращение сделать. к профилю. Я буду ждать вашего обновления под 2.6.0 и установлю себе.
0
ParadoX ParadoX 5 лет назад #
Уважаемый @WebMan есть ли новости по моду? Он по сей день очень нужен и актуален!
+3
WebMan WebMan 5 лет назад #
Всё, что я мог сделать - сделал. Все правки передал Игорю (Fuze). Уточните у него, когда он планирует их использовать. Судя по Гиту, он очень много нужного и полезного сделал в приближающейся 2.7.3. Но "логинов" там не будет, слишком много изменений в движке для минорной версии. Будем ждать мажорную.

Еще от автора

Хуки-хухуки: Исключаем неактивных пользователей из списков
Как иногда начинают свой монолог неопытные стендаперы: «У всех в жизни было такое …
«Расширенная отладка» для InstantCMS 2.14.1 (v.14.1.2) – большое обновление для разработчиков
Новые возможности и удобства, облегчающие разработчикам отладку компонентов и шаблонов.
Использование расширенной отладки. Часть 11. Анализ ошибок 403/404 и редиректов
Одной из неудобных задач при отладке для меня является поиск причины ошибки 403/404.
Используя этот сайт, вы соглашаетесь с тем, что мы используем файлы cookie.