Средства регистрации пользователей с подачей документов - страница 2 - Поиск компонентов, модулей, плагинов

PHP 8 официально не поддерживается компонентом, рекомендованная 7.4

Да, с PHP8 - весь сайт - ошибка 500.

Ладно, будем считать, что система (J 3.10 + Fabrik 3.10 + PHP 7.3.9 + периодически "ошибка 500") более-менее работает, но тогда, всё-равно, извините, нам приходится возвращаться к началу... (не пинайте сильно - задача нам внятно не поставлена)

Итак, требуется построить систему регистрации посетителей со следующими возможностями:
- просто зарегистрироваться посетителю на сайте;
- посетителю, в зависимости от выбранной от 1 до 4-5 целей регистрации (учёба, работа, практика и т.п.), заполнить соответствующую анкету в 1-2 шага;
- посетителю получить доступ в "личный кабинет" с возможностью следить за статусом заявки;
- менеджеру иметь доступ к данным посетителя через доп. интерфейс (не через админку сайта).
Вроде, всё, и всё достаточно стандартно. Как пример - регистрация на сайте СПбГУ:
http://cabinet.spbu.ru/Account/Register

Главный вопрос - какова стратегия, последовательность построения?

Ну, и "до кучи":
Как лучше осуществить первичную регистрацию - через стандартную форму CMS, или сразу средствами Фабрик? (При попытке вывода системной формы регистрации в ней выводится куча лишних полей, которые никак не удаётся убрать).

Как лучше осуществить первичную регистрацию - через стандартную форму CMS

Лучше через стандартную, просто ее надо доработать под себя. Пример правки https://wedal.ru/uroki-joomla/bystraya-registratsiya-s-zashchitoj-ot-spama-v-joomla-svoimi-rukami.html

Итак, требуется построить систему регистрации посетителей со следующими возможностями:
- просто зарегистрироваться посетителю на сайте;
- посетителю, в зависимости от выбранной от 1 до 4-5 целей регистрации (учёба, работа, практика и т.п.), заполнить соответствующую анкету в 1-2 шага;
- посетителю получить доступ в "личный кабинет" с возможностью следить за статусом заявки;
- менеджеру иметь доступ к данным посетителя через доп. интерфейс (не через админку сайта).
Вроде, всё, и всё достаточно стандартно. Как пример - регистрация на сайте СПбГУ:

Мое видение.
- Слегка подправить стандартную форму регистрации, убрать лишнее, добавить нужное через стандартные доп. поля. (минус в этом, что придется заморачиваться с дополнительными связями таблиц, чтобы получить данные из доп. полей, т.к. они хранятся в отдельной таблице). Либо упростить форму до минимума, а подробные данные уже заполнять через форму фабрик, уже после авторизации.
- Сделать список в фабрик, в котором будут храниться данные анкеты, и форма подачи заявления к нему. Сам список должен иметь дополнительные данные о статусе. Опубликовать список в профиле пользователя, чтобы он видел что подал заявление и какой текущий статус рассмотрения.
- Этот же список опубликовать для модераторов, просто без префильтра привязанного к пользователю, чтобы видеть все заявки. Простое редактирование будет менять сведения и в профиле заявителя.

Большое спасибо!

Лучше через стандартную, просто ее надо доработать под себя. Пример правки https://...

Сделано, работает.

подробные данные уже заполнять через форму фабрик, уже после авторизации...

Следуя Вашей инструкции, тоже сделано в общих чертах. Не хватает, конечно, продолжения инструкции, 3-4-го уроков, и некоторые моменты разжевать бы получше...

Подскажите теперь, пожалуйста, как организовать следующую структуру:
Нужно обработать несколько (пусть 4) групп пользователей, пришедших с разными целями. Для каждой группы набор обязательных полей анкеты (формы) должен несколько отличаться от других групп, хотя есть и одинаковые поля, типа ФИО и т. п.
Наверное, правильно будет для каждого посетителя иметь однотипные шаблоны строк данных (строки в БД, вероятно), но заполняться, в соответствии с целью, будет только определённый набор полей данных из этих строк.
Как и какими инструментами из Fabrik это реализовать? Создать для каждой группы свой "Список" с обращением к одной и той же таблице БД? Или к разным? Как выделить нужные 4 группы пользователей? Может стоит воспользоваться связями, как в примере Списка комментариев (из 1 урока инструкции)?

На вскидку, протестировать и поэкспериментировать сейчас возможности нет.
Вариантов несколько, и зависит от того, как это планируется видеть:
1. Создать один общий список (таблицу), который будет доступен модератору и будет включать все поля, с разными направлениями заявок.
2. Разбить на несколько списков (таблиц) в бд. Допустим один список с данными о заявителе, типа ФИО, и прочие, другие списки по направлениям, с подтягиванием данных о заявителе из первого списка.
===
1. В случае с первым вариантом. Поля списка, разбить на группы, типа ФИО - одна группа, "заявка 1" - вторая, и т.д., в т.ч. и группа для модератора. Создать несколько форм, включающих данные группы в зависимости от потребности, и опубликовать их на сайте.
2. Ну тут если списки разные, то и формы будут сразу разными. Но для модерирования, можно попробовать сделать дополнительный список, который связями будет подтягивать со всех.
===
Это в общих чертах, а все нюансы будут всплывать по мере реализации.

P.S. Если бы я знал, ка сделать все одной формой, показывающей нужные строки в зависимости от чекбокса или выпадающего списка, то это можно было сделать в одной форме, но я не знаю как, и возможно ли. Хотя может с внедрением js, как-то и возможно, либо делать промежуточный этап, с выбором "роли", который уже и будет подтягивать нужную форму. Еще один из вариантов, написать скрипт назначения пользователя в группу пользователей. И создать нужные группы в стандартном менеджере пользователей, и тогда можно будет просто ограничивать доступ к разным полям по группе безопасности joomla.

Честно говоря, не вполне понятна суть объекта "Список"... Это, вроде, и не таблица в БД, т.к. разные Списки могут одной таблице соответствовать, и не просто выборка из большого набора данных в таблице БД, т.к., пойдя по второму пути мы создали пару новых Списков "с нуля" с обращением к той же таблице, а в них _автоматом_ появились все элементы первоначального Списка, хотя предполагалось накидать туда новых... И все они стали "родительскими" И как заставить форму выводить ограниченный набор из этих полей - не понятно - выходят одинаковые формы... А если создать списки, связанные с разными таблицами БД, как встроенными средствами добиться в них одинаковости данных...

Ещё появляются проблемы с пунктами меню, рекомендованными в инструкции (сделано строго по ней):
- почему-то список полей демонстрируется только для одного из зарегистрированных, для остальных - текст: "нет записей";
- пункт типа "Fabrik form" при описанном подходе позволяет создать сколько угодно записей. Понятно, что они имеют смысл обращений от лица одного пользователя. Нам же нужно, чтобы пользователь мог создать только одно обращение-анкету от своего имени.

И как заставить форму выводить ограниченный набор из этих полей - не понятно - выходят одинаковые формы...

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

Нужно лишние снять с публикации

Да, спасибо, это работает!

список полей демонстрируется только для одного из зарегистрированных

Разобрался: это он показывает обращение-анкету, а его нет, если анкета не заполнялась, а была только штатная регистрация. Поэтому актуален подвопрос:

нужно, чтобы пользователь мог создать только одно обращение-анкету

Ещё появляются проблемы с пунктами меню, рекомендованными в инструкции (сделано строго по ней):
- почему-то список полей демонстрируется только для одного из зарегистрированных, для остальных - текст: "нет записей";

Не совсем понял о чем речь. Что-то с префильтром? Привязан только к одному id пользователя?

- пункт типа "Fabrik form" при описанном подходе позволяет создать сколько угодно записей. Понятно, что они имеют смысл обращений от лица одного пользователя. Нам же нужно, чтобы пользователь мог создать только одно обращение-анкету от своего имени.

Т.е. нужно ограничение на повторную подачу заявления? Возможно нужно к форме добавить плагин php, и в нем написать код, перемещающий пользователя в другую группу доступа, которая не будет иметь доступа к пункту меню и форме отправки.

Возможно нужно к форме добавить плагин php, и в нем написать код

Будем думать...

Не совсем понял о чем речь. Что-то с префильтром?

Написал в редакции предыдущего поста - разобрался.
Однако получается, что пока реализуемый по инструкции алгоритм не вполне соответствует задаче: в нём предусмотрено множество обращений от пользователя через формы, нам же нужно получить единственное обращение-анкету от каждого пользователя. Будем думать

А как, всё-таки вот с этим:

Честно говоря, не вполне понятна суть объекта "Список"...

?

Честно говоря, не вполне понятна суть объекта "Список"...

Ну это своего рода интерфейс для работы с таблицей БД.

Т.е. нужно ограничение на повторную подачу заявления? Возможно нужно к форме добавить плагин php, и в нем написать код, перемещающий пользователя в другую группу доступа...

Как-то слишком заморочено... У такой мощной системы как Fabrik должны быть другие возможности для этого, просто мы не поняли ещё...

Как-то слишком заморочено... У такой мощной системы как Fabrik должны быть другие возможности для этого, просто мы не поняли ещё...

Бегло пробежался по плагинам, да, есть нужный плагин для формы Limit form plugin. Судя по описанию, это именно то, что нужно.

Limit form plugin

Да, наверное, спасибо, как смогу - скачаю и поставлю.

А вот ещё не могу найти настроек, чтобы поле сделать обязательным *... Может, тоже плагином каким?

А вот ещё не могу найти настроек, чтобы поле сделать обязательным *... Может, тоже плагином каким?

Нужно отредактировать элементы, которые должны быть обязательными. Там слева есть меню - Валидации, там нужно добавить проверку - notempty

Нужно отредактировать элементы, которые должны быть обязательными

Догадывался, только никак не привыкну этим принципам настройки - включение настроек по типу подключения плагина...
Работает, только опять не вижу, где бы в самой форме можно было пометить, что поле обязательно (типа - *), вроде, всё перетыкал...

Limit form plugin

И с этим тоже непонятно, куда именно его прикрутить - плагин включен, но в настройках его не видно. В инструкции про это тоже пусто, видимо, "уровнем выше".
Нашёл что-то на уровне "Формы".

Работает, только опять не вижу, где бы в самой форме можно было пометить, что поле обязательно (типа - *), вроде, всё перетыкал..

Может что-то уже не помню, но вроде ничего больше не нужно делать, только валидацию настроить. На скриншоте в прошлом комментарии приложен рабочий вариант настройки.

Да, функционал сработал, ругается, если не заполнить. Пометочки * не хватает...

Гораздо хуже с плагином Limit - там есть пункт о количестве записей, но сколько там ни ставь (1, 2, ... 100), получается ограничение только в один раз, а нужно два раза, т.к. первый раз "тратится" на стандартную регистрацию, а ещё нужно заполнить анкету...
И непонятно назначение пунктов, где упоминается "Element" (их аж 4 шт. в настройках плагина). В офиц. инструкции слишком коротко...

Пометочки * не хватает...

Может я уже не помню, что где-то включал, а может все дело в шаблоне, но в моем случае на модернизированном шаблоне протостара выводит вот так:

Ещё прикол: нажав что-то в тестируемой форме-анкете на сайте, получили форму "Изменить свой профиль" по ссылке "<сайт>/index.php/<раздел_регистрации>/profile?layout=edit" . Видимо, это что-то стандартное от CMS, ведь в Фабрике ничего подобного не конструировали. Полезно, но непонятно, откуда взялось и как повторить эту удачу, кроме как зафиксировав прямую ссылку (ну нет там такой кнопки "редактировать профиль", ХЗ на что нажали  )...

Возможно это как-то связано с полем связанным с профилем пользователя.

нажав что-то в тестируемой форме-анкете на сайте...

Это похоже на глюк, но нужная ссылка вылезает, если исходная ссылка неправильная, т.е., если написать "<сайт>/index.php/<раздел_регистрации>/любыебуквы" 

Подскажите, пожалуйста, как пользоваться полем "По умолчанию" в настройках Элемента! Примерно понятно, что там некий PHP-код; например, для автоматического заполнения поля формы "E-mail" используется конструкция {$my->email}. Тем же путём удалось вставить имя:{$my->name}. А вот вставить тему обращения ({$my->topic}) не получается...

А "{$my->topic}" где-то существует? Откуда берется информация? Вообще данная конструкция работает только с переменными из api joomla, а переменной topic там нет.
Вот примеры заполнений
http://fabrikar.com/forums/index.php?wiki/element-default-examples/

Если данные берутся из другого поля, то заполнитель будет по имени элемента
return '{tablename___elementname}';

Спасибо большое! Шерстил мануал, но не наткнулся на эту инфу - видимо, не разглядел название "заполнители"...
Сделал вывод Топика через {tablename___elementname}, создав в списке специальный элемент типа fild для показа, подставляя туда данные из ранее заполненного поля "топик" и скрыв их лишние показы в соответствующих формах и списках - работает!

Теперь главная проблема - ограничение по числу разрешённых к заполнению форм/заявок. "Лимит" предлагает два пути построить эти ограничения: прямым ограничением по элементу или "поиском в другом списке". Но первый вариант полностью блокирует заполнение анкеты, а второй приводит к сообщению типа "вы можете заполнить ещё N заявок", но реально ничего не ограничено

Сделал вывод Топика через {tablename___elementname}, создав в списке специальный элемент типа fild для показа, подставляя туда данные из ранее заполненного поля "топик" и скрыв их лишние показы в соответствующих формах и списках - работает!

Если содержание данного поля статичное, то можно в принципе и без заполнителя - return 'Название топика';

Теперь главная проблема - ограничение по числу разрешённых к заполнению форм/заявок. "Лимит" предлагает два пути построить эти ограничения: прямым ограничением по элементу или "поиском в другом списке". Но первый вариант полностью блокирует заполнение анкеты, а второй приводит к сообщению типа "вы можете заполнить ещё N заявок", но реально ничего не ограничено

Мне не приходилось работать с данным плагином, потому ничего сказать не могу. С виду, все просто, настроек особых нет, выбрать поле с пользователем и указать ограничение. Возможно стоит поэкспериментировать, и писать в таблицу id пользователя, логин и имя. И пробовать выбирать поочередно данные поля. И тестировать не под админом, а то, вполне возможно, что данный плагин не отрабатывает админов.

UPD
Сейчас на скорую руку глянул плагин. Добавил в устанавливаемую в fabrik для образца форму отправки письма, поле с id пользователя, указал его в плагине лимита. Все работает, форма просто не открывается, с уведомлением, которое я прописал в плагине.

Если содержание данного поля статичное, то можно в принципе и без заполнителя - return 'Название топика'

Выбирается из выпадающего списка заготовленных вариантов.

выбрать поле с пользователем и указать ограничение. Возможно стоит поэкспериментировать, и писать в таблицу id пользователя, логин и имя

Именно так! Перепробовано много комбинаций, например:
User element - Почта (e-mail)
Limit - 1
Grouping Element - Почта (e-mail)
=> в результате пишет: "You have 1 of 1 entries remaning" и предлагает (и позволяет) заполнить форму любое количество раз.
И да, конечно, не под админом...

А если по второму способу (ниже слова OR):
Lookup Element - ФИО
Max Element - ФИО
=>

форма просто не открывается, с уведомлением, которое я прописал в плагине

, независимо от разрешённого количества.

Вот так настраивал для теста, все отрабатывает, даже у админа.