Thanks for your reply. My modifications to the shop module are in essence an extension of the information collected when placing an order.
However, regardless of whether ezp could use this as an extension or not, I'll be making several modifications in the future, and several of them will be usable just for us. So I really need to find out how this works.
If you need additional information on an order you should look into storing this using the shop account handler ( which serializes information to XML ).
Another approach can be using workflows.
You should try to make your additions in extensions as much as possible. If you change the kernel code you will definetly have problems with upgrades.
I have made use of the shop account handler to the extend possible. However, this is (as you know) also a part of the kernel code, as well as the register view of the shop module which I've had to modify in order to validate the new data being collected.
It surprised me that there was no other way of doing something as simple as modifying the collected order information without touching the kernel code, but when dived into it, I found out that the data used by ezp was hardcoded. Hopefully, I'm missing something that would make this easier.
Maybe the answer is in the creation of a new shopaccounthandler? But that brings me back to the question of whether it would be accessible or not if I put it in a module extension with the same name as the shop module. Furthermore, that still doesn't solve the problem with the shop/register.php modifications.
I also made some minor changes in some files which are in /kernel/content and I've the same question: Is there another way to keep this modifications instead of doing the modifications in new versions of ez again?
-> Suggestion for future versions: An "override" directory for kernel / lib files would be fine (the same way as with templates), this can be placed in "extension" or in an own main directory.
