Accumulated backports for Mosaico support #9555

This adds the TokenProcessor and associated classes to the container in 4.6. These are not *used* at runtime -- but they're published so that extensions may use them. This folds in a few more recent patches to TokenProcessor subsystem provided by civicrm#9497 and removes the parts defined for scheduled reminders.

…public These two functions will be useful in FlexMailer's DefaultEngine.

… `static` This function is only called once, and it previously lacked test coverage, so the `static` warning previously snuck through. Fix it!

…erage

…erage - Fixup for v4.6

…nstream styling

If you install an extension under `$cmsRoot/vendor/org.example.foo`, the resulting URL contains an extraneous `/` (eg `http://example.org//vendor/org.example.foo`). (In Windows, I suspect it's even worse because it uses DIRECTORY_SEPARATOR in the URl -- eg `http://example.org/\vendor/org.example.foo`.) This patch checks for and removes the extraneous slash -- and always constructs the URL with the appropriate delimiter (`/`). Problem observed in `dmaster`.

General notes: 1. Template types can be declared (along with preferred editor) using hook_civicrm_mailingTemplateTypes. 2. 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). 3. When creating a mailing, use the path `civicrm/a/#/mailing/new/{template_type}` to create a mailing with a specific `template_type`. 4. When editing a mailing, check the `template_type` and load the appropriate editor. 5. Some of hte boilerplate from `2step.html`, `unified.html`, etal has been moved to `base.html`. Note that this breaks a hidden feature -- 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'; } } } ```

If you perform a contact search and create a new mailing, it would use `template_type=traditional`, even if another template type had greater priority. With this patch, it respects the priority. Note: I considered changing the default in Mailing.create API to always match most-preferred template-type. However, that would break some existing API consumers (e.g. headless consumers or ones who define their own UI). For external API-based integrations, we should preserve the default semantics of `body_text`/`body_html` by defaulting to `template_type=traditional`. The preference in CRM-19690 is that any use-case based on the screen `civicrm/a/#/mailing/{id}` should have its default determined by weight.

FlexMailer (https://github.com/civicrm/org.civicrm.flexmailer/) is a refactoring of the email-delivery logic from the Mailing BAOs. The primary goal is to make the email-delivery logic more extensible by exposing a better set of events for extension-authors. Sadly, the original code is a bit toxic (originally lacking in tests; thick with many features; using some quirky dataflows), which means: 1. Any refactoring of it poses a high risk. 2. The refactoring should ideally be done with iteration/validation as an optional extension. This patch aims to be the bare-minimum core patch required to facilitate a better 'leap by extension'. The main priorities are: 1. Minimize risk -- no impact on existing users who can continue using existing logic. 2. Enable iteration/testing/deployment of an optional extension in real-world scenarios. 3. Keep any core hacks clear and isolated - don't rashly commit to new, public APIs.

Note: These classes are not actually referenced by anything in core v4.6; however, we provide so that extensions can use them.

The motivation here is to support these two different CLI commands: ``` cv dl myextension cv dl myextension --dev ``` The two commands differ in that they pull from different feeds -- e.g. the stable feed `https://civicrm.org/extdir/ver={ver}|cms={uf}` vs the developmental feed `https://civicrm.org/extdir/ver={ver}|cms={uf}|status=`. However, this creates the real possibility that the user might go back/forth among different feeds (omitting/enabling the `--dev` option per whim).

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Accumulated backports for Mosaico support #9555

Accumulated backports for Mosaico support #9555

Commits on Jan 18, 2017