Feature Proposal: Make UserRegistration customizable

Motivation

Any change to the UserRegistration topic is wiped out by an upgrade. It would be easier if this topic was handled like UserForm and NewUserTemplate: the customized topic is in users web, safe for upgrades.

Description and Documentation

Examples

Impact

WhatDoesItAffect:

%WHATDOESITAFFECT%

edit

Implementation

-- Contributors: ArthurClemens - 25 Feb 2010

Discussion

You know I support this.

But I also think ... why do you need to customize this topic?

My answer is - mainly because of added and removed fields in the UserForm.

I fixed the problem with the password field a few days ago.

The fields that are always there in 99% of all user/registration forms must be

• First Name
• Last Name
• Wiki Name
• Login Name - IF {Register}{AllowLoginName}
• Email address
• Password and Retype Password - IF context passwords_modifyable

Any other fields would be different depending on the site and purpose.

per default we have today

• Organisation name
• Organisation URL
• Country
• Comments

I will make this claim.

If we made our UserRegistration so that the "always there" fields above are always there (login name / password with the IF as currently in trunk) but any additional fields are the result of the additional fields present in the UserForm; then I believe 99% of our admins have no need to tailor the registration topic.

Could this be done?

Is my claim based on my gut feeling correct?

-- KennethLavrsen - 02 Mar 2010

I'd say it's correct, though there's the age-old problem of customising help text next to each field; but you're right, it would drastically reduce customisation pressures.

-- PaulHarvey - 03 Mar 2010

I like this proposal, and also agree that the default UserRegistration topic should only contain the most common fields (never understood Comments anyway).

-- AndrewJones - 03 Mar 2010

My idea was not to ommit the extra fields. My idea was to make a UserRegistration with the "always there" fields follows by a cleverly crafted SEARCH that appends the HTML table with the additional fields from UserForm.

This way, when someone adds fields to the UserForm they also appear on the UserRegistration. This way the registration page auto-tailor itself.

Now - it could be some want additional fields that get added to the user topic in a URLPARAM in the topic itself. So I cannot claim noone will need to tailor. But I bet 99% would not need to tailor the registration if it built itself using a SEARCH from the UserForm.

Small problem is - UserForm can be in Main or in System web. Main wins over System. Not impossible. But more complicated.

Who takes the challenge to craft this in TML.

Note that this does not prevent, or cancel out the original proposal Arthur put forward. We still need to care for the last 1-2 % and provide a good way to customize UserRegistration without having it overwritten when upgrading. So I 100% support Arthurs proposal.

-- KennethLavrsen - 03 Mar 2010

Actually, user registration should be as simple as possible to keep the entry barrier low. The less - the better. Users can add any extra information later - if they want.

-- MichaelDaum - 03 Mar 2010

I fully support to have the registration page lean and mean. We need to do that - I agree that this will cater for most cases, but we can expand on that in a different feature request.

I don't think Kenneth's idea of the automatic form creation will work, from a usability point of view. I just have to look at our own setup of the user form. It contains a lot of fields on the phone numbers, working department, function, etcetera. I would say about 15 fields in all. I would never want to put that on the registration page. It would be a showstopper. As Michael writes: users can add the extra information later.

On customization - I am not only thinking about the form fields, but also on the excessive disclaimer on data storage. I understand it must be there in some countries, but on my intranet I would remove it.

-- ArthurClemens - 03 Mar 2010

It was just an idea. I must admit that people usually never add anything in the none mandatory fields anyway. Not even later.

I agree we can remove any extra fields beyond the "always there". Except country. I would leave that in because the complex list of countries we have is not easy to later add.

So it seems the current conclusion is

• Remove Organisation name, Organisation URL, and Comments fields. Leave First Name, Last Name, Wiki Name, Login Name - IF {Register}{AllowLoginName}, Email address, Password/Retype Password - IF context passwords_modifyable, and country as they are now.
• Implement a solution so that the admin can create a copy of System.UserRegistration in Main web and tailor it there.

Still need to give people until the 11th before calling a final conclusion but it seems we can reach consensus on this one.

-- KennethLavrsen - 04 Mar 2010

I have no objection to this proposal.

Can we delete the default content that gets appended to the users page? Stuff like ChangePassword doesn't belong there - it belongs in the ViewTemplate.

-- MartinCleaver - 04 Mar 2010

I have split the re-organization of the page to MakeUserRegistrationAsLeanAsPossible.

-- ArthurClemens - 04 Mar 2010

The hard-coded country list and formfield should go out of the registration form. It really doesn't belong there and is not reusable for different purposes. See this task with a couple of good ideas of creative reusage of country list in registration form.

-- MichaelDaum - 05 Mar 2010

Just for clarification. The reason why I said I would leave the country list in the registration form is because it is relatively easy to remove but very hard for a newbie to add.

If we separated the country list out in a separate topic, then it could both be reused other places and we could further simplify the registration page.

-- KennethLavrsen - 07 Mar 2010

Could be as simple as adding

%TMPL:P{"countries"}%

What the countries macro actually does should be hidden from newbies. Btw, as soon as you managed to customize the registration form, you are no newbie anymore by definition

Basically, the list of countries should be stored and used as part of the UserForm's formfield definition for the Country field.

-- MichaelDaum - 08 Mar 2010

There has been a good talk about the content of the registration topic but the original proposal to handle the tailoring the same way as it is done for UserForm and NewUserTemplate is as such accepted.

The rest of the discussion lead to a new proposal MakeUserRegistrationAsLeanAsPossible

The original proposal is passed by consensus and the 14-day rule has expired.

-- KennethLavrsen - 11 Mar 2010

Implemented in Tasks.Item8701.

-- ArthurClemens - 13 Mar 2010

Here's the template based solution for those that are interested.

-- MichaelDaum - 14 Mar 2010

Thanks for this example. Now anyone can see how a template based solution would be for a newbie admin to customize the topic.

Thankfully we chose the simple way instead that anyone can understand.

-- KennethLavrsen - 14 Mar 2010

You mean the current set of UserRegistration, DefaultUserRegistration, and various preference variables are easy to grasp?

Well, I've uploaded a new version that comes with two flavours

• UserRegistrationTemplateView (all features enabled)
• SimpleUserRegistrationTemplateView (made up of three lines)

Then I added this to the LocalSite.cfg

$Foswiki::cfg{Plugins}{AutoTemplatePlugin}{ViewTemplateRules} = {
...
  'UserRegistration' => 'SimpleUserRegistrationView',
};

And that's it. Not particular hard.

Among other features, I moved the hard coded list of country names from the registration form to a ContryList topic that serves as an attribute list for the UserForm. So when users decide to specify their country later and not during registration, they still get a nice select box.

I also added some code from another installation for client side form validation including an ajax check if a login or wiki name is already taken.

-- MichaelDaum - 14 Mar 2010

The structure of the registration topic makes it impossible to INCLUDE it in another topic: the macros no longer evaluate - see Tasks.Item8701.

But Michael, we don't have AutoTemplatePlugin distributed. Did you want to make a case for it?

• Somehow I missed this plugin will be part of the core. -- ArthurClemens - 20 Mar 2010

-- ArthurClemens - 19 Mar 2010

The problem with the template solution is that the newbie admin cannot tailor the registration page without having learned the very complicated template language we have.

It is not easy to understand the TMPL:DEF and TMPL:P universe. Only skin developers have the real knowledge. And both Michael and Arthur feel home in this universe.

Why should we choose a solution that requires

• Knowledge of template language. Simply adding a TMPL:P is only simple when you understand in full how the template language works and where to find the template. I have seen Crawford asking on IRC "where do I find the template for...".
• Knowledge of $Foswiki::cfg{Plugins}{AutoTemplatePlugin}{ViewTemplateRules} perl syntax that even I have a hard time grasping. (When to use =>, comma, -> etc). That requires perl programming knowledge
• Access to configure.

?

When in fact we can choose a simple solution where everything is contained in a DefaultUserRegistration where you can see the fields that are already there, and where removing fields is easy. Adding fields is a matter of copying the "stuff" for the existing field and just change the name for your new field. And all from the browser.

We could make it even easier by changing the registration form to a number of INCLUDES where we have one INCLUDE per field.

The two requirement must simply be.

• Provide a means for people not yet knowing Foswiki TML, Template syntax or perl syntax or JQuery syntax to remove and add fields to and from the registration page.
• Provide a means for people to not having their registration page overwritten when they upgrade

HOW this is done is less important. We can in fact make a very smart template, voodoo, perl, CSS ,JS etc etc solution as long as it is behind the scenes. The key element is that a new admin can look at the UserRegistration topic, look at what is already there, and being able to guess how to add and remove fields.

I have seen the right moves so far.

The INCLUDE enhancement where the new admin hits edit and see a simple code and a html comment instructing him where to go and tailor is perfect.

The removal of the country list into its own topic is perfect. That was confusing.

But using the template language and expecting the new admin to guess the magic behind some auto template. That is too steep a mountain to climb.

-- KennethLavrsen - 20 Mar 2010

Kenneth, you are right. We haven't explored all possibilities yet.

-- ArthurClemens - 20 Mar 2010

This morning is suddenly came to me that we are seeking a complex solution to a simple problem.

The problem is that people get their tailored UserRegistration topic overwritten when they upgrade.

And we are making a solution that requires them to copy the default topic to another topic which gets used instead if it exists. And then we make a complex solution to make this work.

There is an obvious simpler solution.

In DefaultPreferences we can define a Macro called USERREGISTRATIONTOPIC and set it to System.UserRegistration.

And in all distributed topics we change the hardcoded System.UserRegistration to %USERREGISTRATIONTOPIC%

Voila. All people need to do is copy System.UserRegistration to e.g. Main.UserRegistration and set USERREGISTRATIONTOPIC in SitePreferences.

And the same solution can be applied to topics listed in the UpgradeSafeCustomisationsOfSystemTopics as I have already stated there.

We get the same solution for most of the tailored topics

We get a simple and easy to understand solution.

And it resolves the problem with the INCLUDE and using macros and IF in the included topics.

-- KennethLavrsen - 25 Mar 2010

Indeed, this can be a good solution.

Note that we will have an array of customization options:

• System.UserForm: create Main.UserForm
• System.NewUserTemplate: create Main.NewUserTemplate
• System.DocumentGraphics: define new topic in ICONTOPIC
• WebLeftBarExample: create WebLeftBar in web
• WebSearch, WebIndex: will have a template design
• and UserRegistration: define new topic in USERREGISTRATIONTOPIC

Although we have good arguments for each approach, this will not be memorizable for users. On the other hand, it shows the versatility of Foswiki: there is more than one way to do it.

-- ArthurClemens - 25 Mar 2010

Arthur

Thinking about it - your original approach - that you started implemting but not yet working - is the best in the situation

We have

• System.UserForm: create Main.UserForm
• System.NewUserTemplate: create Main.NewUserTemplate

UserRegistration tailoring is directly connected with tailoring UserForm and NewUserTemplate. You add or remove fields from the user form and match the fields on the registration page. They belong together. They should follow same approach.

So let is solve the problem we have in the registration form and make that work - and keep the approach that we already decided for.

-- KennethLavrsen - 26 Mar 2010

Done.

-- ArthurClemens - 05 Apr 2010