Create a page, limiting access to this page to Backend users who will be authorized to send invitations to register. Insert the Front End User Registration extension, setting the display mode Invite (or CODE to INVITE) and the Starting Point to the System Folder that will contain the front end user records created.
When an account is created through this page, an invitation message will be sent to the email address specified on the account. The invited person may accept or decline the invitation.
If the registration confirmation page (confirmPID) is designed to be displayed within frames, then add the following lines to your TS template setup:
[globalVar = TSFE:id = {$plugin.tx_srfeuserregister_pi1.confirmPID} ]
config.page.frameReloadIfNotInFrameset = 1
config.linkVars >
config.linkVars = L,tx_srfeuserregister_pi1,fD,cmd,rU,aC
config.no_cache = 1
[global]
after setting plugin.tx_srfeuserregister_pi1.confirmPID in your TS template constants.
Note that cmd, rU and aC are in the list for compatibility with the Direct mail extension.
Two sets of hooks may be used by the extension.
The first set of hooks is named confirmRegistrationClass and offers the possibility of the following two hooks:
confirmRegistrationClass_preProcess: this hook is invoked just BEFORE the registration confirmation (or so-called setfixed) is processed;
confirmRegistrationClass_postProcess: this hook is invoked just AFTER the registration confirmation (or so-called setfixed) is processed.
The second set of hooks is named registrationProcess and offers the possibility of the following four hooks:
registrationProcess_beforeConfirmCreate: this hook is invoked just BEFORE the Frontend user record is filled for preview by the user;
registrationProcess_afterSaveCreate: this hook is invoked just AFTER the Frontend user record has been created and saved;
registrationProcess_afterSaveEdit: this hook is invoked just AFTER the Frontend user record has been edited and saved;
registrationProcess_beforeSaveDelete: this hook is invoked just BEFORE the Frontend user record is deleted.
Each set of hooks must be defined within a class, each hook being a method of this class. However, all six hooks could be defined as methods of the same class.
Each hook receives two parameters: the current Frontend user record and a reference to the invoking object. In the case of confirmRegistrationClass_preProcess and of registrationProcess_beforeConfirmCreate, the first parameter is also passed as a reference so that some action may be taken on the content of the record.
The hooks are configured by the following assignments which could be included in the ext_localconf.php file of the extension providing the hooks:
$TYPO3_CONF_VARS['EXTCONF']['sr_feuser_register']['tx_srfeuserregister_pi1']['confirmRegistrationClass'][] = classReference;
$TYPO3_CONF_VARS['EXTCONF']['sr_feuser_register']['tx_srfeuserregister_pi1']['registrationProcess'][] = classReference;
Note that these are arrays, therefore you could configure multiple hooks of each type for various purposes.
File hooks/class.tx_srfeuserregister_hooksHandler.php of this extension provides a simple example class containing six hooks doing mostly nothing but reporting their existence when invoked. File ext_localconf.php also contains example statements for configuring these example hooks. They are commented out. If you uncomment them, you should see the hooks being invoked when the extension is used in the Frontend.
In the case of the confirmRegistrationClass example hooks, if the confirmation page is configured to be redirected to auto-login, you may not notice on the Frontend that the example hooks are being invoked.
In the case of the registrationProcess_beforeConfirmCreate example hook, if the plugin is configured to generate a username, a username is generated based on the first and last names of the user.
When extension KB MD5 FE Password (kb_md5fepw) and useMd5Password is enabled, the extension also uses the following hook:
$TYPO3_CONF_VARS['TYPO3_CONF_VARS']['EXTCONF']['newloginbox']['loginFormOnSubmitFuncs']
See the documentation of New Login Box and KB MD5 FE Password extensions for more information on this hook.
For more information on hooks, see: http://typo3.org/documentation/document-library/doc_core_api/The_concept_of_quot/ .
You may find that the URL's sent in emails to the front end user are too long and may be broken when using plain text emails.
If you are using HTML emails (enableHTMLMail is set to 1):
Configure your site to use the simulateStaticDocuments property. See TSRef for information about this CONFIG setup property.
When the simulateStaticDocuments is working, add the following lines to your TS template setup:
config.simulateStaticDocuments_pEnc = md5
simulateStaticDocuments_pEnc_onlyP = L,fD[_FIELDLIST],fD[disable],fD[usergroup],tx_srfeuserregister_pi1[aC], tx_srfeuserregister_pi1[cmd],tx_srfeuserregister_pi1[rU],tx_srfeuserregister_pi1[sFK]
If you are using plain text emails (enableHTMLMail is set to 0), the above method will also work, but if you do not wish to use the simulateStaticDocuments feature, then:
In your TS template setup, set config.notification_email_urlmode = 76 or config.notification_email_urlmode = all . See TSRef for information about this CONFIG setup property.
This approach is compatible with both HTML and plain text emails. Simply enable the feature by setting the TS constant useShortUrls = 1 in your TS template. You should also review the default value of TS constant shortUrlLife and set it to a value that fits your needs.
If you are using the simulateStaticDocuments feature, you may want to add tx_srfeuserregister_pi1[regHash] to the list simulateStaticDocuments_pEnc_onlyP.
If you are using the RealURL extension, you should add something like the following to your RealURL configuration in the $TYPO3_CONF_VARS['EXTCONF']['realurl'] variable of localconf.php:
'postVarSets' => array(
'_DEFAULT' => array(
'user' => array(
array(
'GETvar' => 'tx_srfeuserregister_pi1[regHash]'
)
)
)
),
You must set the page id of the user's folder in the constants field. Otherwise the login will not work, because TYPO3 only searches in the root page 0.
Example:
styles.content.loginform {pid = 9
}
Or you could also turn off the page checking at all in the Install Tool:
[FE][checkFeUserPid] = 0
If you unset this, you should change the fe_users.username eval-flag 'uniqueInPid' to 'unique' in $TCA. This will do: $TCA['fe_users']['columns']['username']['config']['eval']= 'nospace,lower,required,unique';
Thanks to Sebastian Stanger for helping produce this section.
The path of the image upload folder used by the Front End User Registration extension may be set in the installation dialog. The default value is uploads/tx_srfeuserregister. A popular alternative in many configurations is uploads/pics. The Front End User registration extension will update the TCA of the fe_users table. Therefore, the Backend forms will use the specified path.
It should also be possible to edit the image of the user profile using either the CHC Forum profile mode or the Front End User Registration edit mode. It is also possible to show the user image in the user listing produced by the New Front End Login Box.
If you use the User Listing plugin of the New Front End Login Box extension (key: newloginbox), and you want to display the user image in the details view, set the following property in your TS template setup:
plugin.tx_newloginbox_pi3.singleView.customProcessing.image.file.import = uploads/tx_srfeuserregister/
or
plugin.tx_newloginbox_pi3.singleView.customProcessing.image.file.import = uploads/pics/
or whatever value you have set for the Front End User Registration extension.
Note the ending slash (/).
Note also that only the first image will be displayed.
Use the Constant editor to set the constant useEmailAsUsername to 1;
You may want to change the relative position of the email field in the following subparts of the HTML template: ###TEMPLATE_CREATE###, ###TEMPLATE_INVITE### and ###TEMPLATE_EDIT###.
Note that if you have set constant enableEmailConfirmation, the email field will not appear on the editing form because no confirmation request is sent when the email address is modified.
Also in tt_products the email addresses are used as user names.
You can have different select boxes defined in TCA, which can also be shown as checkboxes in FE. You will need this for DirectMail or overwritten topics. The configuration needs the activity and the field name of fe_users.
activities: EMAIL
plugin.tx_srfeuserregister_pi1 {select {email {module_sys_dmail_category.wrap = | <br/>
}
}
}
Property: | Data type: | Description: | Default: |
|---|---|---|---|
wrap | stdWrap | Wrap around each single item. |
If you use the CHC Forum extension (extension key: chc_forum), go to the page on which you inserted the CHC Forum and edit the record. In the flexform, at the Profile tab, find the field named Alternate user image relative path.
Enter uploads/tx_srfeuserregister or uploads/pics (or whatever value you have set for the Front End User Registration extension).
If you want to display the FE users data without any edit functionality, you can use TypoScript for setting this up.
by Peter Klein :
lib.userinfo = COA_INT
lib.userinfo {10 = TEXT
10.data = TSFE:fe_user|user|username
10.wrap = Username: |<br />
10.required = 1
# Use "first_name" and "last_name", if present,
# otherwise use the "name" field
20 = COA
20.1 = TEXT
20.1.data = TSFE:fe_user|user|first_name
20.1.required = 1
20.2 = TEXT
20.2.data = TSFE:fe_user|user|last_name
20.2.wrap = |
20.2.required = 1
20.stdWrap.ifEmpty.data = TSFE:fe_user|user|name
20.stdWrap.wrap = Name: |<br />
20.stdWrap.required = 1
30 <.10
30.data = TSFE:fe_user|user|address
30.wrap = Address: |<br />
40 <.10
40.data = TSFE:fe_user|user|city
40.wrap = City: |<br />
50 <.10
50.data = TSFE:fe_user|user|zip
50.wrap = Zip: |<br />
60 <.10
60.data = TSFE:fe_user|user|country
60.wrap = Country: |<br />
70 <.10
70.data = TSFE:fe_user|user|company
70.wrap = Company: |<br />
80 <.10
80.data = TSFE:fe_user|user|telephone
80.wrap = Telephone: |<br />
90 <.10
90.data = TSFE:fe_user|user|fax
90.wrap = Fax: |<br />
100 <.10
100.data = TSFE:fe_user|user|email
100.typolink.parameter.data = TSFE:fe_user|user|email
100.wrap = Email: |<br />
110 <.10
110.data = TSFE:fe_user|user|www
110.typolink.parameter.data = TSFE:fe_user|user|www
110.typolink.extTarget = _blank
110.wrap = WWW: |<br />
200 < .10
200.data = TSFE:fe_user|user|usergroup
200.split {token = ,
cObjNum = 1 || 2
1 {10 = CONTENT
10.table = fe_groups
# ID 13 is the folder where I store my FE users and FE groups.
# Remember to change it to the ID of the folder
# where YOU store your FE data!!
10.select.pidInList = 13
10.select.andWhere.current = 1
10.select.andWhere.wrap = uid=|
10.renderObj = TEXT
10.renderObj.field = title
10.renderObj.wrap = |,
}
2 < .1
2.10.renderObj.wrap >
}
200.wrap = Member of group(s): |<br />
300 < .10
300.data = TSFE:fe_user|user|image
300.split {token = ,
cObjNum = 1
1 {10 = IMAGE
10.file.import.current = 1
10.file.import = uploads/tx_srfeuserregister/
10.file.width = 100
}
}
300.wrap = Image(s): |<br />
}
page.100 < lib.userinfo
It is possible to activate the display of a captcha image and a text field, where the user must enter the text displayed on the image. sr_freecap must have been installed. See the tx_sremailsubscribe_pi1_captcha_css_tmpl.html example template. You must not use the captcha_response as a required field.
Example Constants
formFields = email,first_name,last_name,captcha_response,module_sys_dmail_html
Example Setup:
# check for captcha
plugin.tx_srfeuserregister_pi1.create.evalValues.captcha_response = captcha
plugin.tx_srfeuserregister_pi1._CSS_DEFAULT_STYLE >
plugin.tx_srfreecap_pi2._CSS_DEFAULT_STYLE >
