I recently built a customisation for SugarCRM that required a custom footer on the metadata definition file.
This was a requirement, so that the final user was not able to edit the panel from Studio, and potentially damage the javascript intensive customisation.
To build the customisation as upgrade safe as possible, I created a custom view for the module I was customising, and inside the “display()” method, I set my own custom footer in the following way:
$this->ev->defs['templateMeta']['form']['footerTpl'] = 'custom/modules/Opportunities/mycustomfooter.tpl';
Then I coded all my business logic inside the display method and at the end, I called the “parent::display()” method.
This worked perfectly, and the module could be installad and uninstalled, without affecting the module’s metadata, originally customised through studio.
Then I encountered a problem when the metadata contained already a custom footer. My version of the footer was displayed while the original one was not.
To be able to make both the custom footers display without problems I had to tweak slightly my code.
Firstly I stored the old template filename into a Smarty variable, and then I replaced the metadata key, with my custom footer:
if(!empty($this->ev->defs['templateMeta']['form']['footerTpl'])) { $this->ss->assign('additional_footer', $this->ev->defs['templateMeta']['form']['footerTpl']); } $this->ev->defs['templateMeta']['form']['footerTpl'] = 'custom/modules/Opportunities/mycustomfooter.tpl';
Then, inside my actual Smarty template (custom/modules/Opportunities/mycustomfooter.tpl) I added the following Smarty code at the top of the file:
{if !empty($additional_footer)} {include file="$additional_footer"} {/if}
At the end of my custom footer I then displayed the standard SugarCRM footer:
{{include file='include/EditView/footer.tpl'}}
With this code, you can now easily customise SugarCRM footers, extending the current functionality.