Drupal 8 has overhauled various aspects of the theming layer. They introduced Twig with the aim of preventing business logic from display template files. There are other benefits to using Twig such as increased security for printed strings via the built in auto-escaping. Along with the move to Twig came a number of general best practices about how to structure the code that the Ebsco module doesn't follow, which makes it very complicated to override.
For example, it appears that all of the display logic basically lives in template_preprocess_ebsco_result file, instead of separating business logic (like preparing variables for display) into preprocess and the actual display logic (like rendering the data in a table layout) in the twig file.
The basic strategy for preprocess functions can be summarized with these two methods:
Avoid adding classes is preprocess, let them be added in the Twig files, overridable by themes.
For complex templates that contain sub-templates, use preprocess to prepare variables containing render arrays and accessible data instead of writing DOM (HTML) structures in the PHP. Drupal Render arrays let Frontend devs override the output of the specific DOM sub-components in a much cleaner way than overriding an entire template_preprocess.
The module needs a fairly extensive overhaul to do the following tasks
[x] Separate business logic from display logic in template_preprocess_ebsco_result templates and move as much as possible to ebsco-result.html.twig that can be overridden by a theme.
[ ] Convert auto_link to a Twig filter.
[ ] Separate business logic from display logic in template_preprocess_ebsco_results and move as much as possible to ebsco-results.html.twig that can be overridden by a theme.
Drupal 8 has overhauled various aspects of the theming layer. They introduced Twig with the aim of preventing business logic from display template files. There are other benefits to using Twig such as increased security for printed strings via the built in auto-escaping. Along with the move to Twig came a number of general best practices about how to structure the code that the Ebsco module doesn't follow, which makes it very complicated to override.
For example, it appears that all of the display logic basically lives in
template_preprocess_ebsco_resultfile, instead of separating business logic (like preparing variables for display) into preprocess and the actual display logic (like rendering the data in a table layout) in the twig file.The basic strategy for preprocess functions can be summarized with these two methods:
The module needs a fairly extensive overhaul to do the following tasks