> --
> You received this message because you are subscribed to the Google
> Groups "Joomla! Framework Development" group.
> To post to this group, send an email to
> joomla-dev...@googlegroups.com.
> To unsubscribe from this group, send email to
> joomla-dev-frame...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/joomla-dev-framework?hl=en-GB.
Just to clarify, the plugin is a "user" plugin, not a "framework"
plugin and the email was moved there so site builders had a way of
overriding the automatic email generation that is impossible when you
tightly couple mail functions to the application layer. As noted, the
frontend should also use this one method (DRY).
In order to accommodate a range of different scenarios, the solution
should probably:
1. Add appropriate parameters to the Joomla user plugin to more finely
control when emails are sent.
2. A 5th $options variable is added to the onUserAfterSave event
argument list that can hold a "switch" to indicate whether an email
should be sent (also future proofs against more new options).
3. JUser save also includes a $options variable as a new 2nd argument
and this is passed to the onUserAfterSave. This allows extreme
flexibility for custom user plugins and programmatic usage of
JUser::save. Alternatively, $updateOnly could be recycled into an
options variable and the type is checked to ensure backward compat.
4. Similar rationalisation could be done to other events.
5. Convert frontend emails to use the plugin event as well to reduce
code duplication.
I think this is more logical to fix in 1.7 than to try and hot fix it
in 1.6 given that we aren't far away from merge.
My 2c
Regards,
Andrew Eddie
http://learn.theartofjoomla.com - training videos for Joomla 1.6 developers