[TYPO3] sr_feuser_register: trying to have 2 edit screens

Francois Suter fsuter at cobweb.ch
Sat Nov 3 18:42:08 CET 2007

Hi again,

Here is a situation update. I got the thing working, but with an ugly  
code hack. I need to transform that into a nice TS property :-)

> I have been investigating into sr_feuser_register. In particular I  
> am printing some stuff from inside  
> tx_srfeuserregister_data::evalValues() and I am puzzled. The method  
> gets a list of the required fields, which contains all the fields I  
> defined in my TS setup plus "username". Where is "username" coming  
> from? I need to investigate further.
> After that first checks, evalValues() goes on to check the password  
> which is not displayed in my form. Quite obviously it chokes on  
> it... Apparently all fields defined in  
> plugin.tx_srfeuserregister_pi1.evalValues are checked, no matter  
> whether they appear in the form or no. If I empty this property,  
> evalValues() then just complains about the missing "username" field.
> All this seems to point to some flaw in the validation process. I  
> will investigate further.

The "username" field is forcefully added to the list of fields when  
the table is "fe_users". This happens in with the following lines:

			$this->conf[$cmdKey.'.']['fields'] = implode(',', array_unique 
(t3lib_div::trimExplode(',', $this->conf[$cmdKey.'.']['fields'] .  
',username', 1)));
			$this->conf[$cmdKey.'.']['required'] = implode(',', array_unique 
(t3lib_div::trimExplode(',', $this->conf[$cmdKey.'.']['required'] .  
',username', 1)));

Commenting out these two lines takes care of the problem, but is of  
course not a good solution. It seems it would be worth introducing a  
property such as  
plugin.tx_srfeuserregister_pi1.edit.doNotEnforceUsername to bypass  
this piece of code.

About the password error, as said before it goes away just by  
removing the password conditions in  
plugin.tx_srfeuserregister_pi1.edit.evalValues. It's funny because  
the other conditions don't seem to interfere when the relevant field  
is not present in the form, but the conditions on password do, so  
there must be something wrong with the test, but I haven't taken the  
time to check what.

I will work on the additional TS property described above and submit  
a patch via the bugtracker when ready.

Cheers and thanks to all those who helped.

François Suter

Cobweb Development Sàrl

Rue Eugène-Marziano 15, CH-1227 Les Acacias (Geneva - Switzerland)
T: +41 22 880 00 93, F: +41 22 880 00 94, E: support at cobweb.ch
web solutions for professionnal requirements

More information about the TYPO3-english mailing list