-
Task
-
Resolution: Fixed
-
Neutral
-
None
-
None
-
None
-
-
Empty show more show less
-
Basel 73
-
13
We will have to replace the old PUR-legacy functionality with the new one. The following elements still use it:
- stkPURLoginForm
- dialog has custom fields that can be replaced with the ones from PUR and
- template definition uses legacy modelClass=info.magnolia.module.publicuserregistration.frontend.action.AuthenticationModel
- ftl template uses model logic
- stkPURAuthSubmit, stkPURNotAuthSubmit, stkPURIntranet
- template definitions still reference legacy modelClass=info.magnolia.module.publicuserregistration.frontend.action.RegistrationFieldModel and
- use the model logic/methods in their ftl templates
- stkPURPasswordChangeForm, stkPURPasswordForm, stkPURRegistrationForm and stkPURUpdateForm
- use legacy modelClass=info.magnolia.module.publicuserregistration.frontend.action.RegistrationModel which needs to be replaced with modelClass=info.magnolia.module.form.templates.components.FormModel
- STK's double-opt-in example still uses the legacy registration page (/.magnolia/pages/user-validation.html) and therefore needs adjustment. The new method is using a form processor (see EnableUserByUuidProcessor).
- We need to provide a new form component which provide above form processor.
- Password retrieval strategy still uses legacy parameter targetPage instead of targetPagePath and also references the password-reset-email template from PUR-legacy.
- Reference to /.resources/0.gif from admininterface-legacy in components/teasers/promo.ftl
- stkForumLoginForm still has legacy model logic in components/forum/login.ftl which needs replacement (see above stkPURLoginForm, component inherits from it)
Acceptance criteria
- relates to
-
MGNLSTK-1545 Double-opt-in examples should use PUR's registration strategy
- Closed