There is 80% of the code you need. You will need some way of determining if it should execute or not, I am assuming domain name and that you will place the site domain in the plugin config...but didn't do any work on it since it's up to you.
You would also need to update the install to include the langauge file and review it to make sure everything matches. And finally, a redirect needs to be placed in it so that it redirects the user to the correct place.
Basically what you would do is make sure this plugin is enabled to run LAST in the sequence, so what would happen is:
User is saved as normal, all regular plugins are triggered. Then if the user is not for this specific domain, control passes back to the com_user registration model, which will generate an email as normal and send it.
If the registration IS for the domain, then this plugin will:
1) Generate an activation token
2) Set the user as needing activation and set the token, then save the user updates[triggering another round of "onsave" stuff for the change but all plugins should skip over that...if for some reason this plugin does get called again and the skip/isnew check fails then there is an infinite recursion loop].
3) Sends an email to the user using it's own language file ini settings so you can customize/override it.
4) Bypasses the rest of the normal processing by immediately redirecting the user to the registration successful/please activate url
A much simpler solution would be to load a custom language file that will overwrite the ini value for the email message with a new string... but that gets down to timing issues as you have to make sure that the com_user language file is not re-loaded before the e-mail is sent - I am much more familiar with usurpting actions be doing them first then re-writing langauge files - plus I'm not sure if it would work in this case anyway.
No comments:
Post a Comment