Open JimBacon opened 2 years ago
Success in resolving this issue would enable automatic updates of the iform module across multiple websites without risk to custom code. In the context of sites hosted by Pantheon, that means the iform module could be added to the upstream repo. This would ensure that sites are better maintained with the latest bug fixes but with less effort than currently.
I like the ideas outlined above. It puts me in mind of the QGIS plugin ecosystem where it is easy for anyone at all to add features to QGIS without messing with the core code. Over time some plugins are found to have such widespread and general utility that their functionality is pulled into the core product. The mechanisms outlined above sound attractive to me as a way of starting new developments and trying stuff out without worrying too much about messing with the core product.
Working on this in https://github.com/Indicia-Team/drupal-module-iform-custom-forms
Progress so far in
Supports
Still to do
Added support for validation and extensions and merged the client_helpers and iform module code in to their dev branches.
This repo and those for client_helpers and media keep the core code, useful to all websites, under version control.
In the past, custom code for particular websites has found its way in to these repos, which is then confusing and messy for other users. This should no longer happen but we'd like to remove it where it still remains.
Sometimes websites put custom code in to the folders of this module or maybe even hack the module. Where the website is under version control e.g. for websites hosted by Pantheon, this means that the custom code is then controlled without polluting the core repositories. However, every update of the module risks overwriting the custom code which is a pain to manage.
In an effort to separate custom code and core code, we allowed custom files to be located outside the module, in the Drupal files folder. This prevents the core code being polluted and makes updates to the module safe. The drawback of this is that the custom files are no longer under any obvious version control although copies are sometimes stored in a support-files repo.
We need a better solution which allows custom code to be located outside the core repos but within some other repo. There are occasions where custom code is relevant to several websites so a site may want to draw customisations from multiple modules I.e. a site could include
@johnvanbreda suggested the following options by email