Accumulated backports for Mosaico support #9555
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
totten
force-pushed
the
4.6-19690
branch
2 times, most recently
from
c043e33 to
00f20ec
Compare
totten
changed the title
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 - Fixup for v4.6
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).
totten
added a commit
to totten/uk.co.vedaconsulting.mosaico
that referenced
this pull request
Feb 25, 2017
To run on CiviCRM v4.6, you need to specifically use v4.6.26+ along with the patches from [PR #9555](civicrm/civicrm-core#9555). Although I do expect some folks will use the patches, it doesn't feel accurate to list it for general consumption on 4.6 sites. Note: You can enable/use extensions regardless of what's in the `<compatibility>` / `<ver>` tags. The tag's main purpose is to filter the list of extensions advertised in the public directory.
|
I think we'll try to get this into 4.6.30 |
|
@jackrabbithanna I am not against it, in fact I think it will make sense to have it in 4.6 if it doesn't pose a threat to anything at all. |
|
We still think this could get into 4.6, but not for the October release.... @eileenmcnaughton you'd prefer I close this now, and reopen later when we choose to start integration into 4.6 ? |
|
Yeah - let's do that! Let's try to keep open PRs to things that are progressing & just close & re-open more liberally |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This branch contains a number backports to support the updated Mosaico extension on 4.6. There are a lot of them, so let me try to structure them a bit more:
Batch 1:(merged (Backport) CRM-19690 - Declare Mailing.template_type, Mailing.template_options, Hook::mailingTemplateTypes #9645)Mailingdata model (0bda941, 8f03c76, 7d0815d; originally, CRM-19690 - Declare Mailing.template_type, Mailing.template_options, Hook::mailingTemplateTypes. #9562)This addstemplate_typeandtemplate_optionsto schema+API. This is probably the single-most useful thing to merge into mainline 4.6 -- for an administrator looking after a custom-build, schema patches are the most difficult to manage from outside. All the other patches are essentially runtime patches (which you can apply/revert more haphazardly).headlessande2etests work on 4.6, but thelegacy(CiviUnitTestCase) don't. I intuitively expect this to be safe, but it's a valid question whether this breaks test routines used by other 4.6 extensions (e.g. CiviVolunteer or CiviRules or CiviSEPA).vendorURLs (530ee4d; originally CRM-19826 - CRM_Extension_System - Fix extra slash invendorURLs #9618)CRM_Mailing_MailingSystemTestand Mailing BAOs (d5c4958, 6fbbc4b, 5c92978, 3c65d1d, 6ce1c8e, 7fb0e12)hook_civicrm_container(d9df759)TokenProcessor(1ec5bd0, e1e95d7; originally CRM-19690 - CRM_Mailing_Tokens - Add TokenProcessor support #9563 and many more)FlexMailerhidden interfaces (2cdf7a3, 86344a2; originally CRM-19690 - Enable FlexMailer (if present) #9619)CRM_Extension_Browser(528b869; originally CRM_Extension_Browser - Allow different cache files for different feeds #9693)cv dlusers.I'm submitting this as a large branch/PR to facilitate both personal-usage and automated-testing of the combined work. However, I wouldn't expect all of these to go into canonical 4.6. Rather, I'll submit the first one (
Mailingdata model) because it feels like the most important.If anyone is interested in engaging with testing/refinement of other specific batches/patches, I'll happily submit separate 4.6 PRs.
(Note: I've updated the description after merging batch 1and rebasing. If we need it, the old description is https://gist.github.com/totten/bce6aebdd5a30cbd372311cd98b253c8.)
--