CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2023-01-31T04:26:55Zhttps://lab.civicrm.org/dev/core/-/issues/2222Imported contributions get matched to soft-deleted contacts when External ID ...2023-01-31T04:26:55ZLisaJervisImported contributions get matched to soft-deleted contacts when External ID is used to match to contactOverview
----------------------------------------
When importing contributions using External ID as the match-to-contact method, contributions can get matched to soft-deleted contacts, which means no error message appears but the contrib...Overview
----------------------------------------
When importing contributions using External ID as the match-to-contact method, contributions can get matched to soft-deleted contacts, which means no error message appears but the contributions do not appear on the expected record.
See https://civicrm.stackexchange.com/questions/38155/possible-bug-when-using-external-id-as-matching-method-imported-contributions for more.
Reproduction steps
----------------------------------------
1. Soft-delete a contact (put in the trash but no not delete permanently)
1. Create a .csv for contributions import using that soft-deleted record's information, including External ID
1. Import the contributions file
1. Confirm that the contribution has been added to the soft-deleted contact
Current behaviour
----------------------------------------
Successful import of a contribution to a contact record that is in the trash
Expected behaviour
----------------------------------------
Behavior should match what happens when you import a contribution using email or Contact ID to match to contact and the contact is soft-deleted: Error line in the import, with an informative error message (E.g., Email address as matching method gives "No matching Contact found for ([EMAIL ADDRESS])";
Contact ID as matching method gives "Invalid Contact ID: contact_id 204 is a soft-deleted contact." Either one of these would be fine!)
Environment information
----------------------------------------
* __Browser:__ Chrome OS Version 86.0.4240.198 (Official Build) (64-bit)
* __CiviCRM:__ 5.31.0
* __PHP:__ not sure
* __CMS:__ WordPress 5.5.3
* __Database:__ not sure
* __Web Server:__ not sure
Comments
----------------------------------------
I am working on getting more environment info but I replicated the issue in two demos (dmaster and wpmaster) so I am not sure that's needed.https://lab.civicrm.org/dev/core/-/issues/2218Upgrade to 5.30.x causes "Unrecognized asset name: crm-menubar.css" under Dr...2021-03-10T20:00:53ZspalmstromUpgrade to 5.30.x causes "Unrecognized asset name: crm-menubar.css" under Drupal 8 or 9Overview
----------------------------------------
[Why can't the asset builder find](https://civicrm.stackexchange.com/questions/37994/why-cant-the-asset-builder-find) was posted by @AlanDixon, but I saw the same issue.
Reproduction st...Overview
----------------------------------------
[Why can't the asset builder find](https://civicrm.stackexchange.com/questions/37994/why-cant-the-asset-builder-find) was posted by @AlanDixon, but I saw the same issue.
Reproduction steps
----------------------------------------
1. Upgrade a Drupal 8 or 9 site to CiviCRM 5.30.+
1. Clear caches or just click on CiviCRM.
1. Got a white screen with "**The website encountered an unexpected error. Please try again later.**".
Current behaviour
----------------------------------------
_What happens currently. Please provide error messages, screenshots or gifs ([LICEcap](http://www.cockos.com/licecap/), [SilentCast](https://github.com/colinkeenan/silentcast)) where appropriate._
```
27-Nov-2020 14:45:13 Europe/London] Uncaught PHP Exception Civi\Core\Exception\UnknownAssetException: "Unrecognized asset name: crm-menubar.css" at D:\CiviCRM_Custom.git\drupal8\vendor\civicrm\civicrm-core\Civi\Core\AssetBuilder.php line 217
```
Expected behaviour
----------------------------------------
_What should happen._
You should get the CiviCRM web page.
Environment information
----------------------------------------
<!-- Some of the items below may not be relevant for every bug - if in doubt please include more information than you think is necessary. -->
* __Browser:__ _Edge_ but probably irrelevant
* __CiviCRM:__ _5.30.0/5.31.1/..._ <!-- If this problem relates to an upgrade, then specify both old and new versions -->
* __PHP:__ _7.4...__ but probably irrrelevant
* __CMS:__ _Drupal 8/Drupal 9/..._ Not apparent in Drupal 7 or Joomla.
* __Database:__ _MySQL 5.7.7..._ but probably irrelevant
* __Web Server:__ _IIS_ This may be relevant
Comments
----------------------------------------
_Anything else you would like the reviewer to note._
Extensive researched found that adding
`\CRM_Core_Resources::renderMenubarStylesheet($event);`
before line 168 in `../vendor/civicrm/civicrm-core/CRM/Utils/Hook.php`, in other words before the invoke function returns to its caller seems to solve the problem. I am not currently set up to produce a PR. It is possible that someone more expert than I can explain what the real issue is. It could be related to Composer and Windows.https://lab.civicrm.org/dev/core/-/issues/2200Create edge CI for PHP82020-11-19T15:37:09ZJoeMurrayCreate edge CI for PHP8PHP 8.0.0 comes out Nov 26, 2020.
Create an appropriate set of edge test configurations for PHP8.
It appears that Drupal8 and Drupal 9.0 are not compatible with PHP 8, but that Drupal 9.1+ will be (https://www.drupal.org/node/3180764?u...PHP 8.0.0 comes out Nov 26, 2020.
Create an appropriate set of edge test configurations for PHP8.
It appears that Drupal8 and Drupal 9.0 are not compatible with PHP 8, but that Drupal 9.1+ will be (https://www.drupal.org/node/3180764?utm_source=drupal-newsletter&utm_medium=email&utm_campaign=drupal-newsletter-20201119).
WordPress 5.6 is likely to be compatible (https://make.wordpress.org/core/2020/10/06/call-for-testing-php-8-0/)
Joomla aims to be compatible with minor PHP versions on day of release or within a few weeks but not for a major upgrade.
I'm not familiar with BackDrop's PHP8's compatibility efforts.
So I would start with WordPress and Drupal9.bgmbgmhttps://lab.civicrm.org/dev/core/-/issues/2198CiviMail "DB error": suspected core bug relating to attachment replace api2022-09-25T16:43:26ZedwardpetersCiviMail "DB error": suspected core bug relating to attachment replace apiOverview
----------------------------------------
In CiviMail, trying to send a Test mailing gives "Error - DB error - unknown error" on screen, see screenshot, and mail cannot be sent. Seems to be triggered by attachment replace api.
![...Overview
----------------------------------------
In CiviMail, trying to send a Test mailing gives "Error - DB error - unknown error" on screen, see screenshot, and mail cannot be sent. Seems to be triggered by attachment replace api.
![DBerror](/uploads/ae853f717ef1eecd051b826ff91b20de/DBerror.png)
Reproduction steps
----------------------------------------
1. Mailing -> New Mailing
2. Proceed to mailing template (I am using Mosaico) and try to send a Test.
Current behaviour
----------------------------------------
Error in the Civi Log is:
```
Nov 17 12:28:40 [error] $Fatal Error Details = Array
(
[callback] => Array
(
[0] => CRM_Core_Error
[1] => exceptionHandler
)
[code] => -1
[message] => DB Error: unknown error
[mode] => 16
[debug_info] => ROLLBACK TO SAVEPOINT civi_0 [nativecode=1305 ** SAVEPOINT civi_0 does not exist]
[type] => DB_Error
[user_info] => ROLLBACK TO SAVEPOINT civi_0 [nativecode=1305 ** SAVEPOINT civi_0 does not exist]
[to_string] => [db_error: message="DB Error: unknown error" code=-1 mode=callback callback=CRM_Core_Error::exceptionHandler prefix="" info="ROLLBACK TO SAVEPOINT civi_0 [nativecode=1305 ** SAVEPOINT civi_0 does not exist]"]
)
Nov 17 12:28:40 [debug] $backTrace = #0 /home/sclgulf/public_html/sclgulf/vendor/civicrm/civicrm-core/CRM/Core/Error.php(942): CRM_Core_Error::backtrace("backTrace", TRUE)
#1 /home/sclgulf/public_html/sclgulf/vendor/pear/pear-core-minimal/src/PEAR.php(944): CRM_Core_Error::exceptionHandler(Object(DB_Error))
#2 /home/sclgulf/public_html/sclgulf/vendor/pear/db/DB.php(977): PEAR_Error->__construct("DB Error: unknown error", -1, 16, (Array:2), "ROLLBACK TO SAVEPOINT civi_0 [nativecode=1305 ** SAVEPOINT civi_0 does not ex...")
#3 /home/sclgulf/public_html/sclgulf/vendor/pear/pear-core-minimal/src/PEAR.php(575): DB_Error->__construct(-1, 16, (Array:2), "ROLLBACK TO SAVEPOINT civi_0 [nativecode=1305 ** SAVEPOINT civi_0 does not ex...")
#4 /home/sclgulf/public_html/sclgulf/vendor/pear/pear-core-minimal/src/PEAR.php(223): PEAR->_raiseError(Object(DB_mysqli), NULL, -1, 16, (Array:2), "ROLLBACK TO SAVEPOINT civi_0 [nativecode=1305 ** SAVEPOINT civi_0 does not ex...", "DB_Error", TRUE)
#5 /home/sclgulf/public_html/sclgulf/vendor/pear/db/DB/common.php(1913): PEAR->__call("raiseError", (Array:7))
#6 /home/sclgulf/public_html/sclgulf/vendor/pear/db/DB/mysqli.php(932): DB_common->raiseError(-1, NULL, NULL, "ROLLBACK TO SAVEPOINT civi_0 [nativecode=1305 ** SAVEPOINT civi_0 does not ex...", "1305 ** SAVEPOINT civi_0 does not exist")
#7 /home/sclgulf/public_html/sclgulf/vendor/pear/db/DB/mysqli.php(402): DB_mysqli->mysqliRaiseError()
#8 /home/sclgulf/public_html/sclgulf/vendor/pear/db/DB/common.php(1219): DB_mysqli->simpleQuery("ROLLBACK TO SAVEPOINT civi_0")
#9 /home/sclgulf/public_html/sclgulf/vendor/civicrm/civicrm-core/packages/DB/DataObject.php(2696): DB_common->query("ROLLBACK TO SAVEPOINT civi_0")
#10 /home/sclgulf/public_html/sclgulf/vendor/civicrm/civicrm-core/packages/DB/DataObject.php(1829): DB_DataObject->_query("ROLLBACK TO SAVEPOINT civi_0")
#11 /home/sclgulf/public_html/sclgulf/vendor/civicrm/civicrm-core/CRM/Core/DAO.php(445): DB_DataObject->query("ROLLBACK TO SAVEPOINT civi_0")
#12 /home/sclgulf/public_html/sclgulf/vendor/civicrm/civicrm-core/Civi/Core/Transaction/Frame.php(153): CRM_Core_DAO->query("ROLLBACK TO SAVEPOINT civi_0")
#13 /home/sclgulf/public_html/sclgulf/vendor/civicrm/civicrm-core/Civi/Core/Transaction/Manager.php(103): Civi\Core\Transaction\Frame->finish()
#14 /home/sclgulf/public_html/sclgulf/vendor/civicrm/civicrm-core/CRM/Core/Transaction.php(126): Civi\Core\Transaction\Manager->dec()
#15 /home/sclgulf/public_html/sclgulf/vendor/civicrm/civicrm-core/CRM/Core/Transaction.php(175): CRM_Core_Transaction->commit()
#16 /home/sclgulf/public_html/sclgulf/vendor/civicrm/civicrm-core/Civi/API/Subscriber/DynamicFKAuthorization.php(240): CRM_Core_Transaction->run(Object(Closure))
#17 /home/sclgulf/public_html/sclgulf/vendor/civicrm/civicrm-core/Civi/API/Subscriber/DynamicFKAuthorization.php(181): Civi\API\Subscriber\DynamicFKAuthorization->authorizeDelegate("get", "civicrm_mailing", "130", (Array:8))
#18 /home/sclgulf/public_html/sclgulf/vendor/symfony/event-dispatcher/EventDispatcher.php(214): Civi\API\Subscriber\DynamicFKAuthorization->onApiAuthorize(Object(Civi\API\Event\AuthorizeEvent), "civi.api.authorize", Object(Civi\Core\CiviEventDispatcher))
#19 /home/sclgulf/public_html/sclgulf/vendor/symfony/event-dispatcher/EventDispatcher.php(44): Symfony\Component\EventDispatcher\EventDispatcher->doDispatch((Array:5), "civi.api.authorize", Object(Civi\API\Event\AuthorizeEvent))
#20 /home/sclgulf/public_html/sclgulf/vendor/civicrm/civicrm-core/Civi/Core/CiviEventDispatcher.php(129): Symfony\Component\EventDispatcher\EventDispatcher->dispatch("civi.api.authorize", Object(Civi\API\Event\AuthorizeEvent))
#21 /home/sclgulf/public_html/sclgulf/vendor/civicrm/civicrm-core/Civi/API/Kernel.php(219): Civi\Core\CiviEventDispatcher->dispatch("civi.api.authorize", Object(Civi\API\Event\AuthorizeEvent))
#22 /home/sclgulf/public_html/sclgulf/vendor/civicrm/civicrm-core/Civi/API/Kernel.php(148): Civi\API\Kernel->authorize(Object(Civi\API\Provider\MagicFunctionProvider), (Array:8))
#23 /home/sclgulf/public_html/sclgulf/vendor/civicrm/civicrm-core/Civi/API/Kernel.php(81): Civi\API\Kernel->runRequest((Array:8))
#24 /home/sclgulf/public_html/sclgulf/vendor/civicrm/civicrm-core/api/api.php(22): Civi\API\Kernel->runSafe("Attachment", "get", (Array:4))
#25 /home/sclgulf/public_html/sclgulf/vendor/civicrm/civicrm-core/api/v3/utils.php(1800): civicrm_api("Attachment", "get", (Array:4), (Array:5))
#26 /home/sclgulf/public_html/sclgulf/vendor/civicrm/civicrm-core/api/v3/Generic.php(398): _civicrm_api3_generic_replace("Attachment", (Array:5))
#27 /home/sclgulf/public_html/sclgulf/vendor/civicrm/civicrm-core/Civi/API/Provider/MagicFunctionProvider.php(85): civicrm_api3_generic_replace((Array:8))
#28 /home/sclgulf/public_html/sclgulf/vendor/civicrm/civicrm-core/Civi/API/Kernel.php(150): Civi\API\Provider\MagicFunctionProvider->invoke((Array:8))
#29 /home/sclgulf/public_html/sclgulf/vendor/civicrm/civicrm-core/Civi/API/Kernel.php(81): Civi\API\Kernel->runRequest((Array:8))
#30 /home/sclgulf/public_html/sclgulf/vendor/civicrm/civicrm-core/api/api.php(22): Civi\API\Kernel->runSafe("Attachment", "replace", (Array:5))
#31 /home/sclgulf/public_html/sclgulf/vendor/civicrm/civicrm-core/CRM/Utils/REST.php(300): civicrm_api("Attachment", "replace", (Array:5))
#32 /home/sclgulf/public_html/sclgulf/vendor/civicrm/civicrm-core/CRM/Utils/REST.php(550): CRM_Utils_REST::process((Array:3), (Array:5))
#33 /home/sclgulf/public_html/sclgulf/vendor/civicrm/civicrm-core/CRM/Core/Invoke.php(278): CRM_Utils_REST::ajax()
#34 /home/sclgulf/public_html/sclgulf/vendor/civicrm/civicrm-core/CRM/Core/Invoke.php(68): CRM_Core_Invoke::runItem((Array:12))
#35 /home/sclgulf/public_html/sclgulf/vendor/civicrm/civicrm-core/CRM/Core/Invoke.php(36): CRM_Core_Invoke::_invoke((Array:3))
#36 /home/sclgulf/public_html/sclgulf/web/modules/contrib/civicrm/src/Civicrm.php(88): CRM_Core_Invoke::invoke((Array:3))
#37 /home/sclgulf/public_html/sclgulf/web/modules/contrib/civicrm/src/Controller/CivicrmController.php(80): Drupal\civicrm\Civicrm->invoke((Array:3))
#38 [internal function](): Drupal\civicrm\Controller\CivicrmController->main((Array:3), "")
#39 /home/sclgulf/public_html/sclgulf/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(123): call_user_func_array((Array:2), (Array:2))
#40 /home/sclgulf/public_html/sclgulf/web/core/lib/Drupal/Core/Render/Renderer.php(573): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#41 /home/sclgulf/public_html/sclgulf/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(124): Drupal\Core\Render\Renderer->executeInRenderContext(Object(Drupal\Core\Render\RenderContext), Object(Closure))
#42 /home/sclgulf/public_html/sclgulf/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(97): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext((Array:2), (Array:2))
#43 /home/sclgulf/public_html/sclgulf/vendor/symfony/http-kernel/HttpKernel.php(151): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#44 /home/sclgulf/public_html/sclgulf/vendor/symfony/http-kernel/HttpKernel.php(68): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1)
#45 /home/sclgulf/public_html/sclgulf/web/core/lib/Drupal/Core/StackMiddleware/Session.php(57): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, TRUE)
#46 /home/sclgulf/public_html/sclgulf/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(47): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, TRUE)
#47 /home/sclgulf/public_html/sclgulf/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(106): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, TRUE)
#48 /home/sclgulf/public_html/sclgulf/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(85): Drupal\page_cache\StackMiddleware\PageCache->pass(Object(Symfony\Component\HttpFoundation\Request), 1, TRUE)
#49 /home/sclgulf/public_html/sclgulf/web/modules/contrib/shield/src/ShieldMiddleware.php(91): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, TRUE)
#50 /home/sclgulf/public_html/sclgulf/web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(47): Drupal\shield\ShieldMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, TRUE)
#51 /home/sclgulf/public_html/sclgulf/web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(52): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, TRUE)
#52 /home/sclgulf/public_html/sclgulf/vendor/stack/builder/src/Stack/StackedHttpKernel.php(23): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, TRUE)
#53 /home/sclgulf/public_html/sclgulf/web/core/lib/Drupal/Core/DrupalKernel.php(708): Stack\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, TRUE)
#54 /home/sclgulf/public_html/sclgulf/web/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request))
#55 {main}
```
Expected behaviour
----------------------------------------
Test mailing gets sent
Environment information
----------------------------------------
<!-- Some of the items below may not be relevant for every bug - if in doubt please include more information than you think is neccessary. -->
* __Browser:__ _Safari 14.0.1_
* __CiviCRM:__ 5.29.0
* __PHP:__ _7.3__
* __CMS:__ _Drupal 8.96_
* __Database:__ _5.5.5-10.3.27-MariaDB_
* __Web Server:__ _Apache_
Comments
----------------------------------------
My developer says he thinks it is a core bug. "the error seems to be around transaction and how it's being rollbacked".
He has done a temporary patch so that mailings can get sent:
```
[~/www/sclgulf/vendor/civicrm/civicrm-core/api/v3]# diff utils.php utils.php.orig
1800,1805c1800,1803
< if ($entity != 'Attachment') {
< $preexisting = civicrm_api($entity, 'get', $baseParams, $params);
< if (civicrm_error($preexisting)) {
< $transaction->rollback();
< return $preexisting;
< }
---
> $preexisting = civicrm_api($entity, 'get', $baseParams, $params);
> if (civicrm_error($preexisting)) {
> $transaction->rollback();
> return $preexisting;
```5.52.0https://lab.civicrm.org/dev/core/-/issues/2194Email sent to primary email if non primary email field is included on the reg...2021-10-07T21:42:51ZjitendraEmail sent to primary email if non primary email field is included on the registration pageTo replicate
- Create a profile with Fname, Lname, Email (non primary loc type).
- Use this on an event registration page.
- Now, if a user registers on this event and enters a value in the email field, the invoice is sent to the primar...To replicate
- Create a profile with Fname, Lname, Email (non primary loc type).
- Use this on an event registration page.
- Now, if a user registers on this event and enters a value in the email field, the invoice is sent to the primary email stored in civicrm. Not on the email which was entered while registering.
**Step 1**
![image](/uploads/b15adeab947da8b7435317eac4c2ce86/image.png)
**Step 2**
Thankyou page confirms that the email was sent to the primary address.
![Screenshot_2020-11-17_at_3.56.44_PM](/uploads/4d242f534eac5d118128312b927620e4/Screenshot_2020-11-17_at_3.56.44_PM.jpg)5.43.0https://lab.civicrm.org/dev/core/-/issues/2189Activity Type cleanup2023-06-15T05:03:16ZJonGoldActivity Type cleanupCurrently, activity types can have a `component_id`, so they're not displayed unless that component is enabled. However, 4 activities definitively tied to components ("Bulk Email", "Mass SMS" for CiviMail; "Downloaded Invoice", "Emailed...Currently, activity types can have a `component_id`, so they're not displayed unless that component is enabled. However, 4 activities definitively tied to components ("Bulk Email", "Mass SMS" for CiviMail; "Downloaded Invoice", "Emailed Invoice" for CiviContribute) don't have a `component_id` assigned.
It also seems that "Meeting" and "Phone Call" are set as `is_reserved`, but there aren't any references to those in the codebase such that disabling or deleting them should affect a Civi install.JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/2175Do not send backoffice receipts for contributions that are pending2023-05-29T05:03:23ZseamusleeDo not send backoffice receipts for contributions that are pendingOverview
----------------------------------------
We have found on a client site as per https://github.com/iATSPayments/com.iatspayments.civicrm/issues/225 that if you use an ACH / EFT as Iats does or the payment is completed via notific...Overview
----------------------------------------
We have found on a client site as per https://github.com/iATSPayments/com.iatspayments.civicrm/issues/225 that if you use an ACH / EFT as Iats does or the payment is completed via notification which might be the case for some processors you can wind up with 2 receipts being issued. One when the back office form is completed and the other when the payment is actually successful.
Current behaviour
----------------------------------------
If the send receipt checkbox is checked on the back office contribution and the contribution remains pending a receipt is issued
Expected behaviour
----------------------------------------
Only one Receipt should be issued when the contribution is completedhttps://lab.civicrm.org/dev/core/-/issues/2159Proposal replace PEAR mailer classes in core extension2023-06-12T05:03:15ZeileenProposal replace PEAR mailer classes in core extensionI'm proposing that we add a new core extension that swaps out the existing Pear Mailer classes with a more modern and better supported library.
Per the above comment the reason is largely that I think PEAR mail is not well supported or ...I'm proposing that we add a new core extension that swaps out the existing Pear Mailer classes with a more modern and better supported library.
Per the above comment the reason is largely that I think PEAR mail is not well supported or future proofed - but here are some other advantages of modern libraries - these apply to PhpMailer but may equally apply to others
1) SMTP failover - phpmailer (& others) allow you to specify more than 1 smtp server and will use a different one if the first is down
2) SMTP auth over LOGIN, PLAIN, CRAM-MD5, XOAUTH2.
3) Multilanguage support for error messages.
4) Better developer docs
5) More widely used used - ie by WP, Joomla and Drupal.
**Contenders**
[PhpMailer](https://github.com/PHPMailer/PHPMailer)
[SwiftMailer](https://swiftmailer.symfony.com/)
[Zeta-components](http://zetacomponents.org/documentation/trunk/Mail/tutorial.html)
[Omnimail](https://github.com/omnimail/omnimail)
I've mostly focussed on PhpMailer as it seems to be the most prevalent without any obvious downsides but there isn't that much in it. Regardless, I think agreeing a package & that we should do this is the hardest part of this task.
https://php.libhunt.com/compare-phpmailer-vs-swiftmailer
https://alexwebdevelop.com/phpmailer-tutorial/
Google trends https://trends.google.com/trends/explore?date=all&q=phpmailer,swiftmailer
I'm not sold on the Omnimail library as better than just PhpMailer - it adds a few more variants - but it wraps them (which is good) but such that some options are not available - eg https://github.com/shahariaazam/smtp-mailer/pull/1
The Omnimail maintainer has been good at merging PRs but it's not that active - so if we went that way it would be because we feel it's better than writing a wrapper ourselves.
**Implementation**
The process for swapping out a mailer class is pretty simple - ie
```
/**
* Implements hook_civicrm_container().
*/
function omnimail_civicrm_container(\Symfony\Component\DependencyInjection\ContainerBuilder $container) {
$container->setDefinition('pear_mail', new Definition('Civi\Omnimail'))
->setFactory('Civi\Omnimail\MailFactory::getFactoryMailer')->setPublic(TRUE);
}
```
The challenge is that the signature is a bit Pear-shaped (hah) - so we need a class that does the mapping. Note that for the first one we can assume an array in our implementation.
```
* @param mixed $recipients Either a comma-seperated list of recipients
* (RFC822 compliant), or an array of recipients,
* each RFC822 valid. This may contain recipients not
* specified in the headers, for Bcc:, resending
* messages, etc.
*
* @param array $headers The array of headers to send with the mail, in an
* associative array, where the array key is the
* header name (ie, 'Subject'), and the array value
* is the header value (ie, 'test'). The header
* produced from those values would be 'Subject:
* test'.
*
* @param string $body The full text of the message body, including any
* Mime parts, etc.
*
* @return mixed Returns true on success, or a PEAR_Error
* containing a descriptive error message on
* failure.
```
**Preliminary work**
We want to fix it to throw an exception rather than return a PEAR_Error on fail as the latter if VERY Pear-shaped. We can just catch any exception.https://lab.civicrm.org/dev/core/-/issues/2146Long cyrillic names give error Data too long for column sort_name when saving...2020-10-27T22:27:08ZDaveDLong cyrillic names give error Data too long for column sort_name when saving a contactSee also [stackexchange post](https://civicrm.stackexchange.com/questions/37992/db-error-for-sort-name-when-adding-contacts-with-long-names-in-2-bytes-utf8-char).
The problem is that CRM_Contact_BAO_Contact::add tries to [truncate the s...See also [stackexchange post](https://civicrm.stackexchange.com/questions/37992/db-error-for-sort-name-when-adding-contacts-with-long-names-in-2-bytes-utf8-char).
The problem is that CRM_Contact_BAO_Contact::add tries to [truncate the sort_name](https://github.com/civicrm/civicrm-core/blob/1c8707d6ae7f034474e400a42a4650985616b631/CRM/Contact/BAO/Contact.php#L163-L165) and assumes 1 byte per char. While using substr() instead of mb_substr() would get the number of chars wrong, possibly exceeding the byte length, the main problem is that it can truncate half a character creating an invalid utf8 string. This isn't a utf8 vs utf8mb4 thing either.5.32.0https://lab.civicrm.org/dev/core/-/issues/2127Contact import by CSV fails when string ends with "à"2020-12-29T19:07:07Zsluc23Contact import by CSV fails when string ends with "à"Overview
----------------------------------------
When importing a Contact with a CSV file, the strings that end with character `à` are replaced by a non-printing character.
![bug_trim](/uploads/c6df28ed3579a66b77d2433d90fc2d4d/bug_tr...Overview
----------------------------------------
When importing a Contact with a CSV file, the strings that end with character `à` are replaced by a non-printing character.
![bug_trim](/uploads/c6df28ed3579a66b77d2433d90fc2d4d/bug_trim.gif)
Reproduction steps
----------------------------------------
1. Create CSV file with string field ending with `à`
2. Import Contact by CSV, and choose this file
3. The file has been loaded in a temp table, and final `à` character is replaced by a non-printing character
Current behaviour
----------------------------------------
String ending with `à` is broken and replaced by a non-printing character
Expected behaviour
----------------------------------------
String must remain as-it-is
Environment information
----------------------------------------
Reproduced in `5.27.7` and in `dmaster`
Comments
----------------------------------------
This line of code is the culprit of replacing the character:
https://github.com/civicrm/civicrm-core/blob/master/CRM/Import/DataSource/CSV.php#L227
Included in PR:
https://github.com/civicrm/civicrm-core/pull/7813
Not sure what's the best fix for this, to avoid removing the original fix for bug:
https://issues.civicrm.org/jira/browse/CRM-178595.34.0https://lab.civicrm.org/dev/core/-/issues/2088Maximum Participant Count for Event not enforced in some situation (Wordpress...2023-05-23T05:03:28ZclementMaximum Participant Count for Event not enforced in some situation (Wordpress 5.0.8, CIVICRM 5.12.0, also observed on WP 5.4.2/CIVICRM 5.21.2))We saw recently that 2 event registration that were set to have a maximum number of participants. Event A has set to a maximum number of 29 but allowed 30, and Event B has set to a maximum number of 17 but allowed 19. Until these 2 event...We saw recently that 2 event registration that were set to have a maximum number of participants. Event A has set to a maximum number of 29 but allowed 30, and Event B has set to a maximum number of 17 but allowed 19. Until these 2 events, the maximum number has been enforced well on the events.
When I looked at the last few registrations (all frontend) for these 2 events, for Event A, the last registration registered 1min after the prior 2 registrations which registered at the same time to the minute. For Event B, the last 3 registrations where all registered at the same time to the minute. I tried to register for these events and the Event is full message is correctly shown.
Would this anomaly be due to how the registrations take place particularly when they are in close succession? Any advice and what can be done ? I researched on the net and it seems there was a issue about max participant enforcement (CRM5039), but that was more than ten years ago, that woulnd't be the issue by know i suppose. Any advise? Thanks.
After some fiddling around, I managed to get 2 participants into a event with a 1 participant limit using the following method:
- Participant A typing in his details to register for event
- Participant B registered later but completed his registration and pressed "Continue"
- Participant A pressed "Continue"
- Both participants pressed "Continue" together at the "Confirm Your Registration Information" page
This looks like a bug to me, any views ? Thanks.https://lab.civicrm.org/dev/core/-/issues/2072Why does composer.json contain `"include-path": ["vendor/tecnickcom"]`2023-05-10T12:51:31ZDaveDWhy does composer.json contain `"include-path": ["vendor/tecnickcom"]`As per https://lab.civicrm.org/extensions/cdntaxreceipts/-/issues/110#note_47514 it seems to cause issues with extensions that try to use TCPDF in drupal 8 since composer creates a vendor/composer/include_paths.php file that then makes t...As per https://lab.civicrm.org/extensions/cdntaxreceipts/-/issues/110#note_47514 it seems to cause issues with extensions that try to use TCPDF in drupal 8 since composer creates a vendor/composer/include_paths.php file that then makes the path relative to /vendor/civicrm/civicrm-core, instead of relative to just /vendor.
Maybe the line was from an early iteration of autoloading and using composer?https://lab.civicrm.org/dev/core/-/issues/1991Fix the counter-intuitive steps required to save a new CiviCRM Report, which ...2020-09-17T09:47:10Zjustinfreeman (Agileware)Fix the counter-intuitive steps required to save a new CiviCRM Report, which currently requires: Clicking the View the results button and then selecting Save Report from the Actions menuFix the counter-intuitive steps required to save a new CiviCRM Report, which currently requires: Clicking the View the results button and then selecting Save Report from the Actions menu.
What users actually expect to see as a button on...Fix the counter-intuitive steps required to save a new CiviCRM Report, which currently requires: Clicking the View the results button and then selecting Save Report from the Actions menu.
What users actually expect to see as a button on the CiviCRM Report page is just simple "Save report" as a button.
Having the action only shown after the results of the report are visible is the problem. This also prevents a report from being saved which does not currently show any results now, but may show results in the future - when the criteria is met.https://lab.civicrm.org/dev/core/-/issues/1950Profile settings - Add new contacts to a Group? is misleading2020-08-23T21:47:08ZlarsssandergreenProfile settings - Add new contacts to a Group? is misleadingIn settings for profiles, there is an option to "Add new contacts to a Group?" with a help text "Select a group if you are using this profile for adding new contacts, AND you want the new contacts to be automatically assigned to a group....In settings for profiles, there is an option to "Add new contacts to a Group?" with a help text "Select a group if you are using this profile for adding new contacts, AND you want the new contacts to be automatically assigned to a group."
However, on profile submission, any contact is added to the group, not just new contacts. I think that this is the desired behaviour, but the text is misleading.
I would suggest "Add contacts to a group?" and "Select a group if you want contacts to be automatically added to that group when the profile is submitted." or something along those lines.5.30.0https://lab.civicrm.org/dev/core/-/issues/1835Export preview not showing data that exists2023-03-28T05:03:44ZStoobExport preview not showing data that existsIn both of these attached cases, the data exists in CiviCRM, and the data is contained in the CSV downloaded upon export. But it is blank in the preview.
![preview](/uploads/82c5b38bb88effd5bb67b6842470111c/preview.png)
![export](/upl...In both of these attached cases, the data exists in CiviCRM, and the data is contained in the CSV downloaded upon export. But it is blank in the preview.
![preview](/uploads/82c5b38bb88effd5bb67b6842470111c/preview.png)
![export](/uploads/a2e1ee8affbeaff3d1377572b080b7f2/export.png)https://lab.civicrm.org/dev/core/-/issues/1834End date default set on Find Contributions to 12:00am eliminates contribution...2020-09-05T21:20:45ZStoobEnd date default set on Find Contributions to 12:00am eliminates contributions made todayUsing the Current Month-to-Date link from the Contribution page the default time is set to 12:00am. This eliminates any contributions "made today". The end time should probably be 11:59pm today, or the next day at 12:00am.
`https://dm...Using the Current Month-to-Date link from the Contribution page the default time is set to 12:00am. This eliminates any contributions "made today". The end time should probably be 11:59pm today, or the next day at 12:00am.
`https://dmaster.demo.civicrm.org/civicrm/contribute/search?reset=1&contribution_page_id=1&force=1&test=0&receive_date_low=20200601&receive_date_high=20200622`
![bunnbuad](/uploads/68779d57eaec0a43b8c8a4a7b77ac472/bunnbuad.png)
![curm](/uploads/0b073ab580660694f99808111fb18a7d/curm.png)`https://lab.civicrm.org/dev/core/-/issues/1830Export not returning addresses properly by location type2023-04-18T05:03:18ZStoobExport not returning addresses properly by location type**Issue 1:**
Select Primary address and is returning the oldest address instead. This is what the underlying data is like:
```
MariaDB [civicrm_crm]> select id,is_primary,contact_id,street_address,location_type_id from civicrm_address w...**Issue 1:**
Select Primary address and is returning the oldest address instead. This is what the underlying data is like:
```
MariaDB [civicrm_crm]> select id,is_primary,contact_id,street_address,location_type_id from civicrm_address where contact_id=5205;
+-------+------------+------------+---------------------+------------------+
| id | is_primary | contact_id | street_address | location_type_id |
+-------+------------+------------+---------------------+------------------+
| 1470 | 0 | 5205 | 317 SW 6th Ave #400 | 2 |
| 13705 | 1 | 5205 | 9755 SW Barnes Road | 3 |
| 13706 | 0 | 5205 | 9755 SW Barnes Road | 6 |
+-------+------------+------------+---------------------+------------------+
3 rows in set (0.00 sec)
```
And this is what is returned.
![neen](/uploads/66248d7e4974b423fe806aaa4acb493a/neen.png)
**Issue 2:**
Select state by Location Main/Work and shows nothing, even though exists. Note: selecting State by Primary location does return results.
![state](/uploads/735e25cdfbc479715a88b32894a8d3dc/state.png)
![main](/uploads/dea0cbd07ecc6fda7687aa3d622b66f2/main.png)
Currently using CiviCRM 5.26.2https://lab.civicrm.org/dev/core/-/issues/1826Dedupe: Location type is treated inconsistently2023-03-18T04:15:46ZJonGoldDedupe: Location type is treated inconsistentlyPer [this Stack Exchange discussion](https://civicrm.stackexchange.com/questions/34671/dedupe-rule-ignores-the-location-type-for-email-phone-but-does-not-ignore-for-ad), there's a UX issue that dedupe ignores location type ID for email a...Per [this Stack Exchange discussion](https://civicrm.stackexchange.com/questions/34671/dedupe-rule-ignores-the-location-type-for-email-phone-but-does-not-ignore-for-ad), there's a UX issue that dedupe ignores location type ID for email and phone but not postal address. The consensus on that page is that we should be consistent in favor of ignoring location type everywhere.
Note that this is a change from the position taken in [https://issues.civicrm.org/jira/browse/CRM-5026](https://issues.civicrm.org/jira/browse/CRM-5026), but I think the 11 years that have passed since that position have given us real-world experience to favor the newly-suggested approach.
I have a patch for this, but no test yet. Once I have a test I'll submit a PR.JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/1825Merge/bundle flexmailer into core2020-10-23T13:46:59ZbgmMerge/bundle flexmailer into coreFollow-up to: https://github.com/civicrm/org.civicrm.flexmailer/issues/26 - publish a stable version.
Rationale:
* Flexmailer provides cleaner an alternative to a lot of core civimail code
* It adheres to Lexim, in that eventually it w...Follow-up to: https://github.com/civicrm/org.civicrm.flexmailer/issues/26 - publish a stable version.
Rationale:
* Flexmailer provides cleaner an alternative to a lot of core civimail code
* It adheres to Lexim, in that eventually it was meant to replace the core code (i.e. the core code should be flagged as deprecated and eventually removed).
What steps would be required to ship flexmailer in core?
I recall Tim mentioning two options:
* (1) Merge flexmailer in the same way that Api4 was merged, if both versions are highly inter-dependent.
* (2) Bundle flexmailer as a core-extension, similar to sequentialcreditnotes or eventually eventcart (i.e. clearly separate isolation between code bases, but core can assume that the extension is enabled).
I feel like we are more in the second situation, because flexmailer is stable and not tightly coupled with the version of CiviCRM core. However, it may be a bit more work, since we have to tweak the packaging/distribution of CiviCRM?
cc @totten @eileen5.28.0https://lab.civicrm.org/dev/core/-/issues/1818Upgrade Angular from 1.5 => 1.82021-05-07T02:27:09ZcolemanwUpgrade Angular from 1.5 => 1.8I'm not sure why CiviCRM core still ships with angular 1.5.
The latest in the 1.x branch is 1.8.
Looking over the [list of breaking changes](https://docs.angularjs.org/guide/migration#migrating-from-1-5-to-1-6) between 1.5 and 1.8, it ...I'm not sure why CiviCRM core still ships with angular 1.5.
The latest in the 1.x branch is 1.8.
Looking over the [list of breaking changes](https://docs.angularjs.org/guide/migration#migrating-from-1-5-to-1-6) between 1.5 and 1.8, it seems pretty minimal.
The biggest change that affects us is the route default has changed from `#` to `#!` https://github.com/angular/angular.js/blob/master/CHANGELOG.md#location-due-to-1