Prior to 7.11.8 you could place a custom file custom/themes/SuiteP/tpls/_head.tpl and it would be used by the application.
Since the update, the path is hardcoded and does not check the custom directory.
This file controls the <head> section of the page. It was a nice place to add global javascript/css dependencies. (ie. bring in a third party library, etc).
Many platforms (ecommerce, website, etc) give folks a way to add scripts to the head - it's a common use case. So it's disappointing to have the feature removed.
A file placed in custom/themes/SuiteP/tpls/_head.tpl will be loaded by the app.
The path to the _head.tpl file is hardcoded in header.tpl and cannot be modified without overwriting core.
See #7591
@connorshea suggested a plugin here
custom/themes/SuiteP/tpls/_head.tpl. Let this file contain some custom javascript or something
I was using _head.tpl to load Global javascript libraries from a cdn.
Hmm, one fix I guess would be to replace { include file="themes/SuiteP/tpls/_head.tpl" } with this:
{{ if file_exists('custom/themes/SuiteP/tpls/_head.tpl') }}
{ include file="custom/themes/SuiteP/tpls/_head.tpl" }
{{ else }}
{ include file="themes/SuiteP/tpls/_head.tpl" }
{{/if}}
(I don't think file_exists is actually valid, we'd need to figure out whatever PHP function would work)
Like Jos茅 (@Abuelodelanada) suggested somewhere (on Gitter?) we should add a custom Smarty function to emulate our get_custom_file_if_exists PHP function, then we could use it anywhere in tpls.
Here is an example of such an addition, from a recent PR he made: https://github.com/salesagility/SuiteCRM/pull/7813/files
It doesn't look too hard to do...
@Dillon-Brown and @connorshea,
I just came accoss this issue, because I wanted to create a custom version of the themes/SuiteP/include/DetailView/tab_panel_content.tpl template. This template is also included with a fixed path in the DetailView.tpl file.
Wouldn't it be much clearer, to look for a custom template file each time a template is included (as @pgorod suggested)? The current fix just solves the _head.tpl issue.
I propose to extend the Smarty.php function _smarty_include in include/Sugar_Smarty.php
/**
* called for included templates
*
* @param string $_smarty_include_tpl_file
* @param string $_smarty_include_vars
*/
function _smarty_include($params)
{
$params['smarty_include_tpl_file'] = get_custom_file_if_exists($params['smarty_include_tpl_file']);
parent::_smarty_include($params);
}
This leverages the get_custom_file_if_exists function and allows developers to customize all included templates. Currently it is necessary to copy all template files for the specific view, because it is only looked for a custom version of the view's base tpl file.
I moreover think that it would be good practice to slice the large SuiteP tpl files into more granular pieces. For example, the tab_panel_content.tpl file could be sliced into one file for the bootstrap grid, which includes a second tpl that produces a single field's html.
In combination with the above addition to the Sugar_Smarty.php file, this allows developers to more granually adjust the theme to individual needs in a more upgrade safe manner.
PS: Happy to provide the PR for the above extension and/or the split of the tpl files, if that's of interest...
Most helpful comment
@Dillon-Brown and @connorshea,
I just came accoss this issue, because I wanted to create a custom version of the themes/SuiteP/include/DetailView/tab_panel_content.tpl template. This template is also included with a fixed path in the DetailView.tpl file.
Wouldn't it be much clearer, to look for a custom template file each time a template is included (as @pgorod suggested)? The current fix just solves the _head.tpl issue.
I propose to extend the Smarty.php function _smarty_include in include/Sugar_Smarty.php
This leverages the get_custom_file_if_exists function and allows developers to customize all included templates. Currently it is necessary to copy all template files for the specific view, because it is only looked for a custom version of the view's base tpl file.
I moreover think that it would be good practice to slice the large SuiteP tpl files into more granular pieces. For example, the tab_panel_content.tpl file could be sliced into one file for the bootstrap grid, which includes a second tpl that produces a single field's html.
In combination with the above addition to the Sugar_Smarty.php file, this allows developers to more granually adjust the theme to individual needs in a more upgrade safe manner.
PS: Happy to provide the PR for the above extension and/or the split of the tpl files, if that's of interest...