Create your own register.tpl and place it in /design/<your_design>/templates/user/register.tpl - eZ publish will automatically use it because it is there (and thus it will not fallback to the register template that lives in the standard design).
I ve test this code and works fine on default settings in site.ini. Clear the all cache or delete /var/cache and /var/prefix/cache. If still doesn`t work, reset your settings to default in site.ini.
[UserSettings]
RegistrationEmail=enabled
DefaultUserPlacement= //place where new user will be created! (usualy user group)
UserClassID=25 //your user class
Thanks for your interest so far. Martin and I are working together on this.
In your last post you are using the base user class User whose id is 4.
What we to do is use our own user class with it's own attributes e.g. a class called Subscriber with an id of 25 and still be able to interface it to the User module:
[UserSettings]
RegistrationEmail=enabled
DefaultUserPlacement=367 // yes - this is the id of the user group
UserClassID=25
but use the same script to extract the class attributes.
The problem is that the attributes that are displayed are for the base class User (4) and not Subscriber (25) which is the one we want to use for registration.
Basically that was it, the [UserSettings] are in settings/<our site>/site.append.ini.php and [register_form] is at the botton of settings/<our site>/override.ini.php.
The RegistrationEmail=enabled was probably copied in from somewhere by default would this cause a problem?
Basically if you submit the form to register a user (this using the base register.tpl), the next time you go to the registration form it has now switched to register_form.tpl and (the important thing) it uses the new user class's (id 25) attributes to build the form.
This seems to be a caching problem, although we deleted all caches in between attempts. It would be good if someone could explain this behaviour to us.
On to the next problem ...
You must be logged in to post messages in this topic!