My guess is that it is perfectly possible by setting up a new module extension (for example smsregister), with register view copied from the kernel and then modified according to your needs. A view is just an interface to certain system state, and I am pretty sure you can have multiple different interfaces, which are independent. You can also turn disable the standard register view without having to touch the kernel (ini).
I might be wrong here, but seems to me that a module is an abstract collection of views and fetches (and maybe some reusable parts of code), so creating a custom view for a module would actually extend module's functionality as such, but not affect anything 'in it'.
<i>Is it possible to extend parts of a modue? Or do I need to make a new module, very similar to the original?</i>
Hi, I'm in need of a similar solution and I'm with Felix, I don't want to mess with the kernel either. Is it possible to extend parts of a module? If so can someone maybe point me to some documentation that might explain how to do this?
The changes I need to make to the registration process are rather minor so it would be great if I didn't have to recreate the entire user module for the sake of 50 odd lines of code.
we are currently looking into the possibility of patching kernel/user/register.php to allow for other types of handling than the default one (email). More specifically we plan to add a custom handling method, defined in an ini-file, which lets you control the registration process and thus the feedback/activation methods.
If successful, we plan to kindly request for the adoption of this enhancement into ezpublish.
Wow, that was a quicker response than I expected, thank André I'll check it out.
I must say it would be nice if this sort of action was possible with every core
module, I had to hack a kernel file for the browse function which simply added the
ability to specify the start node with a hidden input field in one of my
developments because the start node depended on the current user, this was a
function not achievable through ini settings and it wasn't worth developing an entire extension for due to the fact it only needed three lines of code.
I would like to see the ability to extend all of the core modules and functions in
future versions, I think this will add yet another layer of flexibility to eZ and I
can't see it being a major issue to implement, simply add in a check if additional
functionality has been set in an extension and if so execute it within the current
action. This would basically be a plugin mechanism for core modules, the only issue
I can see would be executing multiple plugins/extra actions within one module action instance, but you guys are pretty brainy ;).
I'll check this patch out, thanks André.
Pardon me while I burst into flames...
You must be logged in to post messages in this topic!