-
totten authored
This PR allows one to display a different CiviMail composition UI depending on the `template_type`. Key details: 1. When creating a mailing, use the path `civicrm/a/#/mailing/new` to create a mailing with the default `template_type` (aka first-preferred, by weight). 2. When creating a mailing, use the path `civicrm/a/#/mailing/new/{template_type}` to create a mailing with a specific `template_type`. 3. When editing a mailing, it checks the `template_type` and loads the appropriate editor. 4. Some of the boilerplate from `2step.html`, `unified.html`, etal has been moved to `base.html`. Note that this breaks some hidden functionality -- before, you could switch among a few different layouts (`2step`, `unified`, `unified2`, `wizard`) by manually editing the URL (e.g. `civicrm/a/#/mailing/2/unified`). Now, to change the layout of the traditional-style mailings, you can implement a hook, e.g. ``` function mymod_civicrm_mailingTemplateTypes(&$types) { foreach ($types as &$typeDef) { if ($typeDef['name'] === 'traditional') { $typeDef['editorUrl'] = '~/crmMailing/EditMailingCtrl/unified.html'; } } } ``` Relatedly, if a downstream system has found some other way to patch/hack a replacement for the CiviMail layout, then they'll need to update it. (Specifically, port the changes on display in `2step.html` or any of the other layouts.). However, this has always been a hidden trick with unrealistic UX -- and we've refrained from documenting/institutionalizing it... until now. With this PR, overloading CiviMail UI becomes a supported feature (by way of the public-facing `hook_civicrm_mailingTypes`).
3ac6e107