|
Tuesday 02 January 2007 3:13:23 am
Your welcome Felix, Thank you for speaking up, being detailed, reporting your issue cross linking your issue to your forum thread. I simply believe that in the end the shop admin user or group setting should for now remain consistent with the existing implementation. This means the email address would remain an ini setting variable. This variable can be an email list, alias or real mail account. The variable allows for the shop email information to be separated from the admin email in a simple way.
I think that being able to send the order information to a unique email address has real value.
In the end the logic for the sending of the order resides in PHP code. Because of this simple fact,
I have an idea that it would be best to override or extend the system which controls this behavior in PHP not in TPL. It would be nice if this functionality could be augmented to allow for extension on an as needed basis but not by default. This would allow you to extend that part how ever you see fit. Extending the TPL + kernel to support overriding parts of the kernel seems awkward. I could be wrong and it could be a terrible mistake but ... I think the problem filters back to an individual's functional needs (as implemented in PHP) may not meet everyones unique needs. Further compounded (I can only guess) with a kernel design which does not allow for overriding all the files in a kernel; like the ones required to be modified to meet your own unique functional needs. This might make an interesting conversation surrounding workflows and extending the parts of the kernel to support this extension? I just see a larger problem that happens to cover the use case you describe ... <i>//kracker i write too much!</i>
Member since: 2001.07.13 || http://ezpedia.se7enx.com/
|