CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2024-03-15T21:05:34Zhttps://lab.civicrm.org/dev/core/-/issues/4954Upgrade to Smarty4....2024-03-15T21:05:34ZeileenUpgrade to Smarty4....Now that we have upgraded many sites to Smarty3 & seem close to ironing out the issues I had a go at Smarty4 and was able to get it working. The extra fixes were entirely in our core compatibility layer so the challenges of moving a site...Now that we have upgraded many sites to Smarty3 & seem close to ironing out the issues I had a go at Smarty4 and was able to get it working. The extra fixes were entirely in our core compatibility layer so the challenges of moving a site from Smarty2 to Smarty4 are now equivalent to moving to Smarty3.
https://smarty-php.github.io/smarty/5.x/upgrading/#removed-php-constants
One annoying thing we did was name our Smarty mixin & the define in a version specific way. In fact there is nothing v2 specific about our mixin and the methodology of defining ` CIVICRM_SMARTY3_AUTOLOAD_PATH` works for Smarty4 as well as it does for Smarty3. If it wasn't for those naming issues I would recommend we simply replace the contents of packages/smarty3 with the Smarty 4 library.
However, given where we are I recommend we
1) merge Smarty4 into packages here https://github.com/civicrm/civicrm-packages/pull/380
2) add a new define `CIVICRM_SMARTY_AUTOLOAD_PATH` - respect it but fall back to `CIVICRM_SMARTY3_AUTOLOAD_PATH` if present
3) update our demo sites / build sites etc to Smarty4
4) update all our messaging to encourage people to use Smarty4 not 3 (but if they have already switched to 3 don't further message as being off Smarty2 is enough to flush out any extension or issues that would impede our medium term plans to put Smarty4 in vendor & stop shipping Smarty3
Note that Smarty4 hard-fails on `{php}` tags in tpls whereas Smarty3 has a backwards compatibility layer that would have supported it, had we chosen to enable it, which we didn't.5.72.0https://lab.civicrm.org/dev/core/-/issues/4714Civi-Import change the description2023-10-26T07:16:29ZjaapjansmaCivi-Import change the descriptionI just installed a CiviCRM version 5.66 fresh for a client and saw a core extension Civi-Import.
The description line reads:
`Core extension for us to start moving import logic into, has more functionalit`
My question is what is this ...I just installed a CiviCRM version 5.66 fresh for a client and saw a core extension Civi-Import.
The description line reads:
`Core extension for us to start moving import logic into, has more functionalit`
My question is what is this extension? And who is the us?
I am bit afraid that the wording us also creates a not me and thus a we vs them mentality. I am not sure whether that is intededed.
So my proposal would be: `This is an extension in development to move core import functionality into an extension. This extension helps people who do development work on CiviCRM core. Feel free to contribute.`5.68.0https://lab.civicrm.org/dev/core/-/issues/4164CiviMail send mails only to certain location type2023-03-13T11:54:35ZjmargrafCiviMail send mails only to certain location typeI have the following Usecase:
A big organization is using CiviCRM for mailing marketing of different departments. Their Contacts can have several email addresses (with different location types).
A Contact has an email address that is use...I have the following Usecase:
A big organization is using CiviCRM for mailing marketing of different departments. Their Contacts can have several email addresses (with different location types).
A Contact has an email address that is used by department A for the communication with the customer via mass mailing.
But department B wants to communicate with the customer via another email address via mass mailing.
Currently there seems to be no possibility to select which email address location type should be preferred for an specific mass mailing (of department A - while department B creates another mass mailing and wants to select their preferred location type for another mass mailing).
Possibilities in CiviCRM:
I can create different location types for the different purposes.
I can add email addresses with the corresponding location type.
I can select one email address as the primary email address.
I can select one email address for mass mailing.
Problem:
But I can not select different email addresses for different mass mailings
Possible Workaround:
I could keep the two contacts as duplicates in the system. But the customer still still want to have an overall overview over their communication with this contact - so simply having duplicates is not an attractive option.
Feature Request:
What I would need is the feature of selecting the preferred location type to be used for a specific mailing.
If the contact has no email address of this communication type the fallback option could be the primary / bulk-e-mail-address
What effort would it take to create such a feature? I guess it would make most sense to implement it into the civicrm core - do you aggree?https://lab.civicrm.org/dev/core/-/issues/4142Add Activity Target consistently2023-04-24T19:25:30ZSandor SemseyAdd Activity Target consistentlyOverview
----------------------------------------
When creating related activities for other entities (e.g. Contribution, Participant (event registration), Membership) source and target contact IDs holds different contacts and have diffe...Overview
----------------------------------------
When creating related activities for other entities (e.g. Contribution, Participant (event registration), Membership) source and target contact IDs holds different contacts and have different meanings if a logged-in user added the entity or an anonymous user (through an online form).
This creates inconsistency and makes any downstream processing harder: searching, creating extensions & automations based on these activities.
Example use-case
----------------------------------------
If a contact get registered for an event by a logged-in user (someone showed interest in email and a backoffice user adding the registration to Civi) "Event Registration" activity's source (Added by) would be the CRM user and target (With) is the contact who wants to attend the event. This makes sense and the roles match the label: registration was *added by* the user and the *target* is the contact. Also works well as audit trails.
However, if the contact is using the online registration form source will be the contact and target will be empty.
Proposed behaviour
----------------------------------------
In my opinion best case would be: if there's no logged in user then source is the system user and target is the contact. This presents exactly what happened: a contact has registered and registration was added by the system, not by a real user manually.
If that's too much of a change or system user determination is hard across all CMS then just add contact to target (in this case source and target would be the same contact_id). This way also has the benefits of the same results for consumers.
In the latter case the downside is there would be redundancy in `civicrm_activity_contact` table (https://lab.civicrm.org/dev/core/-/issues/2450#note_55527). Regarding this, I argue that consistency worths more than disk space.
Comments
----------------------------------------
I've found some issues that mention this, but not as the main topic (https://lab.civicrm.org/dev/core/-/issues/2450) or hasn't any progress (https://lab.civicrm.org/dev/core/-/issues/2669). As it would be nice to change this through all of Civi.
PR at https://github.com/civicrm/civicrm-core/pull/256505.60.0https://lab.civicrm.org/dev/core/-/issues/3984Proposal: Enable OAUTH client extension by default now that microsoft has dis...2023-01-09T14:50:43ZDaveDProposal: Enable OAUTH client extension by default now that microsoft has discontinued username/password authenticationWhat the subject says. For new installs only, but with maybe an upgrade message if it detects you have a microsoft email account enabled.What the subject says. For new installs only, but with maybe an upgrade message if it detects you have a microsoft email account enabled.https://lab.civicrm.org/dev/core/-/issues/3920Update backend footer2023-05-27T17:14:31ZlarsssandergreenUpdate backend footerThe footer shown to backend users seems like it could be improved a bit:
![image](/uploads/3c4361fd529cf3ec27872a3a10660f81/image.png)
I think that bottom line could just be:
[Support](https://civicrm.org/help) [Documentation](http...The footer shown to backend users seems like it could be improved a bit:
![image](/uploads/3c4361fd529cf3ec27872a3a10660f81/image.png)
I think that bottom line could just be:
[Support](https://civicrm.org/help) [Documentation](https://docs.civicrm.org/)
Download is covered in the version number, which is also a download link. Support is a much more useful link that leads to options: Stack Exchange, chat, Gitlab, etc. rather than just Gitlab, which is probably not the right first stop for someone with a problem, in most cases.
Alternatively, support and documentation are covered in the top menu. Maybe there is no need for a second line at all?
Minor detail: Add a space between the status box and the word CiviCRM.5.63.0https://lab.civicrm.org/dev/core/-/issues/3855Add membership status as a filter for scheduled reminders2023-11-23T19:06:27Zpallavi_compucoAdd membership status as a filter for scheduled reminders**Current Behaviour** : At the moment, Under Schedule Reminders(Administer->Communication->Schedule Reminders) for Memberships, there is an option to filter the memberships by the type (as shown in the screenshot attached).
![Screenshot...**Current Behaviour** : At the moment, Under Schedule Reminders(Administer->Communication->Schedule Reminders) for Memberships, there is an option to filter the memberships by the type (as shown in the screenshot attached).
![Screenshot_2022-09-19_at_7.41.00_PM](/uploads/4298414cd4f52fb03b8c1dafb0d356c5/Screenshot_2022-09-19_at_7.41.00_PM.png)
**Proposal for addition** : We would like to add another filter "Membership Status" next to membership type which will allow the Civi Admin to schedule the reminders for memberships with selected status so only the memberships having the selected status will be applicable for the scheduled reminders and will be sent an email.
The status filter will allow multiple status selection
![Screenshot_2022-09-19_at_7.41.39_PM](/uploads/b4ade89c0b04328ddbb6059447b89892/Screenshot_2022-09-19_at_7.41.39_PM.png)https://lab.civicrm.org/dev/core/-/issues/3844Dummy payment processor should be flagged as such on LIVE page2023-01-31T09:53:32ZyashodhaDummy payment processor should be flagged as such on LIVE pageWhen dummy payment processor is configured for contribution pages/ event, there is no indication that is NOT a real transaction. This could be confusing and we should flag any LIVE page that is configured with dummy processor.
![dummy](...When dummy payment processor is configured for contribution pages/ event, there is no indication that is NOT a real transaction. This could be confusing and we should flag any LIVE page that is configured with dummy processor.
![dummy](/uploads/7cbf8624f40a97ab1c89d123ab4b4941/dummy.png)
![con_page](/uploads/1ea201d5b3c96e90e5385b5f82596996/con_page.png)
No indication that this is a Dummy payment processor
![contr+page](/uploads/456a92cbdafa407721c1ac4545cbb22e/contr+page.png)
This would similar to what we already do for TEST transactions.5.59.0yashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/3806Contribution Pages: Spread the Word show on Live Page from start if Enabled.2024-03-28T05:03:24ZBarijohnContribution Pages: Spread the Word show on Live Page from start if Enabled.Overview
----------------------------------------
Currently the Spread the Word Social Media footer on Contribution Pages ONLY appears when you have completed the transaction. This means that it isn't easy to share the page from the dona...Overview
----------------------------------------
Currently the Spread the Word Social Media footer on Contribution Pages ONLY appears when you have completed the transaction. This means that it isn't easy to share the page from the donation page, as you might have missed the opportunity when you complete it.
On Events this is showing as soon as you land on the Event Information Page and I suggest this would be a good improvement on Contribution Pages as well.
Example use-case
----------------------------------------
1. Click on Contribution Link - See Spread the Word. Can share directly from this page to Social Media.
May increase sharing of the page and increase donations. Also it will be shown to users when creating page and they can test it easily.
Current behaviour
----------------------------------------
Currently this ONLY appears when you have completed the full transaction and appears at the confirmation stage. Easy to skip past it as well.
![Contribution_Completed](/uploads/f1a68833823dec4ccd78bb4d12ab4cb8/Contribution_Completed.png)
Proposed behaviour
----------------------------------------
Show the Spread the Word on the main contribution page. As Per the Events Page.
![Screenshot_2022-08-16_at_12.31.16](/uploads/acaa5bedff273314189446561ca8c8be/Screenshot_2022-08-16_at_12.31.16.png)
Comments
----------------------------------------
Thoughts?https://lab.civicrm.org/dev/core/-/issues/3775Disable Deadlock retries for Mailing Jobs2024-03-24T05:03:28ZseamusleeDisable Deadlock retries for Mailing JobsSo CiviCRM added a feature which re-tries the same query x number of times by default that is 3 when either a deadlock or a lock wait timeout is hit which is useful, but in the concept of mailing job processing it is not so useful becaus...So CiviCRM added a feature which re-tries the same query x number of times by default that is 3 when either a deadlock or a lock wait timeout is hit which is useful, but in the concept of mailing job processing it is not so useful because it means it can get tied up on get_lock queries re-trying them a silly number of times when it should be moving onto the next thingseamusleeseamusleehttps://lab.civicrm.org/dev/core/-/issues/3753Proposal: Allow negative rules for ACLs2023-09-08T10:52:34ZTobias Voigttobias.voigt@civiservice.deProposal: Allow negative rules for ACLs**PROBLEM:**
When defining ACL rules, it is only possible to 'allow' certain behaviour but not to 'disallow' it. This makes it tedious to define a set of rules that restricts access to e.g. groups of contacts or sets of custom fields - ...**PROBLEM:**
When defining ACL rules, it is only possible to 'allow' certain behaviour but not to 'disallow' it. This makes it tedious to define a set of rules that restricts access to e.g. groups of contacts or sets of custom fields - especially if you have many (groups or sets of custom fields).
**USE CASE:**
In one of our client's system, we have many groups and many sets of custom fields. What I want to achieve is:
1. define a privileged group / role that has exclusive access to **one** set of custom fields
2. allow access to all other sets of custom fields for all users
3. prevent 'normal' users from giving themselves access to the exclusive information by adding themselves to the privileged group
Because I can only define 'positive' ACL rules, here's what I have to do:
- turn off the WP permission for custom fields for the relevant roles (to be able to define my rules via CiviCRM ACLs)
- allow access to all sets of custom fields for 'everyone' (excluding the one I want to restrict access for) - **by creating a rule for each set of custom fields**
- define a rule to allow access to the restricted set of custom fields to the privileged role
Depending on the number of sets of custom fields, this can be a tedious process. Not only that - if I create a new set of custom fields at a later time, I have to remember to create a new ACL rule for that as well.
Now for the third task (preventing users from adding themselves to the privileged group). To achive this I furthermore have to:
- turn off the WP permissions for viewing and editing all contacts for the relevant roles
- allow access to all groups for 'everyone' (excluding the one I want to restrict access for) - **by creating a rule for each contact group**
- define a rule to allow access to the restricted contact group only for the privileged role
Again: With about 50+ groups, that's a tedious task. And again: I have to remember to create a new ACL rule each time I add a new group.
All in all I could end up with a multitude of rules (in our case 70+) that are really hard to maintain.
**PROPOSAL:**
This task could be so much easier, if it was possible to define 'negative' ACL rules. If this was possible, I could:
- turn off the relevant WP permissions
- allow access to all sets of custom fields for everyone (1 rule)
- allow access to all contact groups for everyone (1 rule)
- disallow access to the restricted set of custom fields for everyone (1 rule)
- disallow access to the restricted contact group for everyone (1 rule)
- allow access to the restricted set of custom fields for the privileged role (1 rule)
- allow access to the restricted contact group for the privileged role (1 rule)
As is implied above, **there would have to be some form of priorisation** of rules to make this work.
This way I would end up with only 6 rules and would not have to remember to create new rules whenever I create a new set of custom fields or a new contact group.5.64.0https://lab.civicrm.org/dev/core/-/issues/3677API thoughts: Global switch to turn off all permission checking, not just to ...2022-06-27T21:54:03ZDaveDAPI thoughts: Global switch to turn off all permission checking, not just to the "top-level" api call that was madeI've been thinking about https://lab.civicrm.org/dev/core/-/issues/3671, and my thinking went something like:
* This worked before, so it should go back to the way it was.
* But wait, isn't this really exposing a bug in webform because ...I've been thinking about https://lab.civicrm.org/dev/core/-/issues/3671, and my thinking went something like:
* This worked before, so it should go back to the way it was.
* But wait, isn't this really exposing a bug in webform because how did the person update a case if they don't have permissions to cases?
* But wait, what's this? Every api call in webform purposely turns off permissions? https://github.com/colemanw/webform_civicrm/blob/0bedf9411bf3f0a682ce7a1b3fad9a682093b240/src/Utils.php#L654
```php
function wf_civicrm_api($entity, $operation, $params) {
...
$params += [
'check_permissions' => FALSE,
];
```
* So webform is saying: "Core, I don't want you to check any permissions. Anyone who has (drupal) permission to use this form should have permission to do whatever the form does."
* I don't remember where but I think I saw a similar type of thing come up with afform, or it seems likely to, where "I've only given certain people permission to reach this form, but if they have it, they should be able to do whatever the form does."
So one way to address this use-case, in a way that doesn't require core to lower permission checking for everyone else, is to provide a way for webform and others to set a global kill-switch that turns off all permission checking. That way secondary permission checks that get called from within the api itself like the one in Utils_Recent would still be on for everyone else, but could be turned off for forms that don't want it.
I'm not confident this is the _best_ way, but am just putting it out there.https://lab.civicrm.org/dev/core/-/issues/3646Support tracking URLs with tokens in query strings2022-06-11T14:58:11ZlarsssandergreenSupport tracking URLs with tokens in query stringsURLs with tokens in mailings do not have click tracking. This is an important metric for fundraising (e.g. to see how many and even which contacts click through to contribution pages). @artfulrobot put together some code that worked well...URLs with tokens in mailings do not have click tracking. This is an important metric for fundraising (e.g. to see how many and even which contacts click through to contribution pages). @artfulrobot put together some code that worked well to track these clicks in Flexmailer, but that code was not merged before Flexmailer was merged into core.
https://github.com/civicrm/org.civicrm.flexmailer/issues/30
We used this without issue for four months and found it worked very well. @artfulrobot was using it since March. Would it be possible to merge this into core. Rich, would you be willing to copy your code to a patch against core?RichRichhttps://lab.civicrm.org/dev/core/-/issues/3638Provide a fullPage property for message templates2024-02-22T05:03:26ZmfbProvide a fullPage property for message templatesIn various parts of the UI, CiviCRM allows users to send a message template either on its own, or wrapped in a header and footer.
e.g. you can send a message template to a contact.
Or, you can create a mailing based on a message templa...In various parts of the UI, CiviCRM allows users to send a message template either on its own, or wrapped in a header and footer.
e.g. you can send a message template to a contact.
Or, you can create a mailing based on a message template, with additional header and footer.
CKEditor needs different settings at civicrm/admin/ckeditor?preset=civimail re: allowed HTML tags to support these two scenarios. With fullPage = true, the HTML is forcibly wrapped with html/head/body tags, and so a message template that includes its header and footer can be composed. With fullPage = false, html/head/body are silently stripped, so this is useful for message templates that should be used with a header and footer.
However, there is only one CKEditor setting for both of these scenarios.
I would propose a new database column where we can indicate if a message template is "fullPage" - i.e. includes header and footer, or not fullPage, i.e. designed to be used with header and footer.
This would allow us to toggle the fullPage setting appropriately. It would also allow us to prevent a user from sending a message template that needs a header and footer without one, or wrapping a message template that includes its header and footer with an additional header and footer.https://lab.civicrm.org/dev/core/-/issues/3636CiviCRM, Find Mailings. If there are no results, the same message "There are ...2022-06-11T14:57:49Zjustinfreeman (Agileware)CiviCRM, Find Mailings. If there are no results, the same message "There are no Unscheduled Mailings" is shownCiviCRM, Find Mailings. If there are no results, the same message "There are no Unscheduled Mailings" is shown regardless of the search criteria. If a different mailing status was used for search, it does not make sense to refer to "Unsc...CiviCRM, Find Mailings. If there are no results, the same message "There are no Unscheduled Mailings" is shown regardless of the search criteria. If a different mailing status was used for search, it does not make sense to refer to "Unscheduled Mailings".
This text should be changed to something else like: "There are no mailings matching this criteria".
Using CiviCRM 5.7.2
Agileware Ref: CIVICRM-1121
![Find_Mailings-2](/uploads/34e6b1996338721a1a2a333a3a16cd2a/Find_Mailings-2.png)https://lab.civicrm.org/dev/core/-/issues/3635Emails marked as bounce when quota is full2024-02-22T05:03:25ZEdselopezEmails marked as bounce when quota is fullThere are cases (usually when using Gmail SMTP) when the Outbound email fails to deliver a mailing due to the user's daily quota being exhausted. In this case, if the mailing is re-used unknowingly, attempts to re-send the mailing adds t...There are cases (usually when using Gmail SMTP) when the Outbound email fails to deliver a mailing due to the user's daily quota being exhausted. In this case, if the mailing is re-used unknowingly, attempts to re-send the mailing adds to the bounce threshold, finally surpassing the limit of three bounces, marking the email as "on hold". To solve this, I'm thinking bounce type of "Quota" should be excluded from the calculation of marking the email as on hold. Please let me know if this is reasonable and I will provide a patch.https://lab.civicrm.org/dev/core/-/issues/3634When using a smart group as a mailing list, users who unsubscribe from the sm...2022-06-11T14:57:45Ztom.mWhen using a smart group as a mailing list, users who unsubscribe from the smart group are still included in the mailing.It looks like in CRM/MailingBAO/Mailing.php, is not taking into account those who have been removed from the smart group. Civi version 5.3.
```
if (count($includeSmartGroupIDs)) {
$query = CRM_Utils_SQL_Select::from($contact)
...It looks like in CRM/MailingBAO/Mailing.php, is not taking into account those who have been removed from the smart group. Civi version 5.3.
```
if (count($includeSmartGroupIDs)) {
$query = CRM_Utils_SQL_Select::from($contact)
->select("$contact.id as contact_id, $entityTable.id as $entityColumn")
->join($entityTable, " INNER JOIN $entityTable ON $entityTable.contact_id = $contact.id ")
->join('gc', " INNER JOIN civicrm_group_contact_cache gc ON $contact.id = gc.contact_id ")
->join('mg', " INNER JOIN civicrm_mailing_group mg ON gc.group_id = mg.entity_id AND mg.search_id IS NULL ")
->join('temp', " LEFT JOIN $excludeTempTablename temp ON $contact.id = temp.contact_id ")
->where('gc.group_id IN (#groups)')
->merge($criteria)
->replaceInto($includedTempTablename, array('contact_id', $entityColumn))
->param('#groups', $includeSmartGroupIDs)
->param('#mailingID', $mailingID)
->execute();
}
```https://lab.civicrm.org/dev/core/-/issues/3631Unexpected behavior from api.MailingEventSubscribe.create2024-02-21T05:03:31ZginkgofjgUnexpected behavior from api.MailingEventSubscribe.createIn creating a custom e-newsletter sign-up form for a client, I encountered the following unexpected behaviors. I'm happy to submit one or more corrective pull requests but would first like to:
* confirm that this is not an unexpected us...In creating a custom e-newsletter sign-up form for a client, I encountered the following unexpected behaviors. I'm happy to submit one or more corrective pull requests but would first like to:
* confirm that this is not an unexpected use of this API,
* confirm that these behaviors are unexpected,
* get two cents from others on the approach, and
* get acceptance criteria for the PR(s) -- i.e., what tests do I need to write/pass?
The unexpecteds:
1. This is cosmetic, but the API metadata are wrong. The API Explorer describes the params as though they were for unsubscription.
2. Suppose contact X is already a member of a mailing group Y. If their IDs are passed to this API, the contact's status in the group is "downgraded" to "Pending" and the user must reconfirm membership by clicking the link emailed to them.
3. The contact's DO NOT MAIL and NO BULK EMAILS Communication Preferences are not updated. These changes should not be effected by the initial API call, but after the user clicks the confirmation link emailed to her.
The approaches:
1. This should be a trivial update to the API's `_spec()` function.
2. The API delegates to `CRM_Mailing_Event_BAO_Subscribe::subscribe()`. I would fix the problem in the delegate by checking for group membership and bailing out early if the record already exists with the appropriate status.
3. Confirmation is handled by `CRM_Mailing_Page_Confirm` which delegates to `CRM_Mailing_Event_BAO_Confirm::confirm()`. I would unset the communication preferences in question in the delegate.ginkgofjgginkgofjghttps://lab.civicrm.org/dev/core/-/issues/3620"View in Browser" does not feed mailing statistics2024-02-19T05:03:28Ztotten"View in Browser" does not feed mailing statisticsI just want to log the existence of the issue generally... suppose you send a newsletter and it has a "View in Browser" link.
Suppose the recipient uses that link. The view the mailing and then drill-down, clicking through some more lin...I just want to log the existence of the issue generally... suppose you send a newsletter and it has a "View in Browser" link.
Suppose the recipient uses that link. The view the mailing and then drill-down, clicking through some more links.
What happens to the stats?
* The web-based view does not count as an "Open". The MUA may or may not report back the "Open" on the original message.
* You will not have any "Click Through" events logged.
This is because the "View in browser" variant of the newsletter is not instrumented with tracking codes (while the MUA variant of the newsletter does have tracking codes).https://lab.civicrm.org/dev/core/-/issues/3616Should tracking pixel be placed at start of email for when Gmail clips messages?2024-02-18T05:03:26ZlarsssandergreenShould tracking pixel be placed at start of email for when Gmail clips messages?With Mosaico templates, it isn't that difficult to reach Gmail's limit of 96-102kB with an email newsletter, after which your email message is clipped and not displayed in full. This is unfortunate in itself, but it also breaks open trac...With Mosaico templates, it isn't that difficult to reach Gmail's limit of 96-102kB with an email newsletter, after which your email message is clipped and not displayed in full. This is unfortunate in itself, but it also breaks open tracking as the tracking pixel is only embedded at the very end of the message and thus isn't fetched unless the reader clicks "View entire message".
Would it be worthwhile to consider putting the tracking pixel at the start of the message to avoid this issue? Obviously, less than ideal for those who don't display images, but I'm not sure how these two might balance out or if there is a clever way to have the best of both worlds.
I'd be happy to provide a patch, but not sure what the best way forward is here.
(Was a former Flexmailer issue, reposted here as I think this is still important.)