One of the main problems faced by Drupal Developers today is that modules customized for a particular application cannot be updated to newer versions without loss of customizations. When updates to such modules are released for a newer version, the developer has to rewrite the customization from scratch in the new version.
I would be interested in working towards the creation of an abstraction layer/module, that would enable version free customizations of Drupal modules for Google Summer Of Code 2012.
Now, this module can basically work in the following way:-
1. Provide the user with an editor to edit existing files in the module or create new files for the module itself.
2. Keep a track of these changes in a way similar to version control systems or maybe in a database, whichever is more feasible.
3. Display this information to the user in simple yet fully functional interface.
The main problem with such a system is comprehending what changes have been done between two versions of the same module.
While providing complete version independence is not possible due to obvious reasons in cases where there have been massive overhauls in the module's architecture itself, it is possible to provide some level of independence in cases, where there are only some basic porting modifications.
The simplest way of implementing this would be by creating some basic conventions for developers like following a basic structure for creation of new modules. These rules can then be used by the module when checking for changes in the updated modules.
I do have some ideas in this regard, but need some guidance.
Can any potential mentors give me some suggestions regarding this?
Comments
Yes it can be
But if we are doing some changes in patchs, then we can apply patchs for that particular patch and after that i think we can easily upgrade the module.
But that still requires the
But that still requires the extra effort of re doing the patches for every single patched module, which can lead to a huge effort on the maintainer's part if say there are hundred's of customized modules in a project environment.
Sayak Sarkar
I don't think this is
I don't think this is feasible at all (though I think I've seen it proposed for previous summer of code years). There's a reason why nobody has done it yet, despite there being great benefits for businesses.
Thanks for your feedback
Thanks for your feedback Bojan. I do know that at the very outset this idea may look a bit non-feasible, but then again it is something that hasn't been previously tried.
My main idea comes from the fact that Drupal already has a database abstraction layer in place which allows it to work with multiple types of databases. This concept can be further extended to module development in newer versions of Drupal like Drupal 8, wherein an implementation can be created in the form of a module or an extended layer altogether.
I would be very grateful if you could let me know about the major issues involved in creating such an implementation.
Sayak Sarkar
You are free to ping me on
You are free to ping me on #drupal-contribute (I'm bojanz on IRC) and discuss it. Maybe we can arrive at a more feasible idea.
My goal is not to discourage you, just lead you to a more practical idea ;)