Improve management of custom code

[JimBacon]

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

1. Custom modules, which use hooks to declare locations of additional prebuilt forms, extensions, plus page specific JS, CSS, lang and template files.
2. As 1, but instead of hooks, use PSR4 to standardise the class structure so they can be auto-discovered.
3. 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.

[JimBacon]

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.

[burkmarr]

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.

[JimBacon]

Working on this in https://github.com/Indicia-Team/drupal-module-iform-custom-forms

[JimBacon]

Progress so far in

• main branch of https://github.com/Indicia-Team/drupal-module-iform-custom-forms
• https://github.com/Indicia-Team/client_helpers/tree/feature-custom-forms
• https://github.com/Indicia-Team/drupal-8-module-iform/tree/feature-custom-forms

Supports

• custom forms
• css
• js
• lang
• templates

Still to do

• validation
• extensions

[JimBacon]

Added support for validation and extensions and merged the client_helpers and iform module code in to their dev branches.