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
- drupal-8-module-iform to provide core Indicia functions (Github repo)
- shared iform customisation modules adding features used on several sites (Github repo)
- site-specific customisation module adding features only used on the one site (Pantheon repo)
@johnvanbreda suggested the following options by email
- Custom modules, which use hooks to declare locations of additional prebuilt forms, extensions, plus page specific JS, CSS, lang and template files.
- As 1, but instead of hooks, use PSR4 to standardise the class structure so they can be auto-discovered.
- Maybe a standard library folder could be created for each project - iform_customisations, containing subfolders for prebuilt_forms, extensions and page specific files. These can then be easily auto-discovered.
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