Development issueshttps://lab.civicrm.org/groups/dev/-/issues2024-03-13T19:07:26Zhttps://lab.civicrm.org/dev/drupal/-/issues/94Notice: Undefined property: CRM_Core_DAO2024-03-13T19:07:26ZGhost UserNotice: Undefined property: CRM_Core_DAOAfter a login in drupal I see the following errors:
* Notice: Undefined property: CRM_Core_DAO::$Private_Adresse-street_address in CRM_Core_BAO_UFGroup::getValues() (Zeile 1289 von /var/www/html/sites/all/modules/civicrm/CRM/Core/BAO/UF...After a login in drupal I see the following errors:
* Notice: Undefined property: CRM_Core_DAO::$Private_Adresse-street_address in CRM_Core_BAO_UFGroup::getValues() (Zeile 1289 von /var/www/html/sites/all/modules/civicrm/CRM/Core/BAO/UFGroup.php).
* Notice: Undefined property: CRM_Core_DAO::$Private_Adresse-city in CRM_Core_BAO_UFGroup::getValues() (Zeile 1289 von /var/www/html/sites/all/modules/civicrm/CRM/Core/BAO/UFGroup.php).
* Notice: Undefined property: CRM_Core_DAO::$Private_Adresse-postal_code in CRM_Core_BAO_UFGroup::getValues() (Zeile 1289 von /var/www/html/sites/all/modules/civicrm/CRM/Core/BAO/UFGroup.php).
* Notice: Undefined property: CRM_Core_DAO::$Private_Adresse-country in CRM_Core_BAO_UFGroup::getValues() (Zeile 1264 von /var/www/html/sites/all/modules/civicrm/CRM/Core/BAO/UFGroup.php).
* Notice: Undefined property: CRM_Core_DAO::$Private_Adresse-country_id in CRM_Core_BAO_UFGroup::getValues() (Zeile 1266 von /var/www/html/sites/all/modules/civicrm/CRM/Core/BAO/UFGroup.php).
* Notice: Undefined property: CRM_Core_DAO::$Private_Adresse-state_province in CRM_Core_BAO_UFGroup::getValues() (Zeile 1264 von /var/www/html/sites/all/modules/civicrm/CRM/Core/BAO/UFGroup.php).
* Notice: Undefined property: CRM_Core_DAO::$Private_Adresse-state_province_id in CRM_Core_BAO_UFGroup::getValues() (Zeile 1266 von /var/www/html/sites/all/modules/civicrm/CRM/Core/BAO/UFGroup.php).
![image](/uploads/02599db50123540bbe5d48006cd818a6/image.png)
---
CiviCRM Version: `7.x-5.18.4`
Drupal Version: `7.67`https://lab.civicrm.org/dev/core/-/issues/4951Event registration under Windows fails2024-02-08T10:22:24ZspalmstromEvent registration under Windows fails## Overview
_This is similar to_ https://lab.civicrm.org/dev/core/-/issues/4928, but a different problem. See also Stack Exchange [smarty - Is it the end of the road for CiviCRM under Windows? - CiviCRM Stack Exchange](https://civicrm.s...## Overview
_This is similar to_ https://lab.civicrm.org/dev/core/-/issues/4928, but a different problem. See also Stack Exchange [smarty - Is it the end of the road for CiviCRM under Windows? - CiviCRM Stack Exchange](https://civicrm.stackexchange.com/questions/46268/is-it-the-end-of-the-road-for-civicrm-under-windows?noredirect=1#comment55844_46268) and [registration - Fatal error - unable to register for events with Smarty3 enabled - CiviCRM Stack Exchange](https://civicrm.stackexchange.com/questions/46311/fatal-error-unable-to-register-for-events-with-smarty3-enabled). I wonder if it is an issue with the use of Smarty3.
The final Register page crashes with:
```plaintext
The website encountered an unexpected error. Try again later.TypeError: Unsupported operand types: float + string in content_65ba5d1bd929c5_86413884() (line 408 of <drupal root>\vendor\civicrm\civicrm-packages\smarty3\vendor\smarty\smarty\libs\sysplugins\smarty_resource_recompiled.php(52) : eval()'d code).
```
followed by the stack trace.\`\`\`
## Reproduction steps
1. Register for an event.
2. Click on Review
3. Click on Register.
## Current behaviour
The web page returns:
```plaintext
The website encountered an unexpected error. Try again later.
TypeError: Unsupported operand types: float + string in content_65ba5d1bd929c5_86413884() (line 408 of <drupal root>\vendor\civicrm\civicrm-packages\smarty3\vendor\smarty\smarty\libs\sysplugins\smarty_resource_recompiled.php(52) : eval()'d code).
Smarty_Template_Resource_Base->getRenderedTemplateCode() (Line: 114)
Smarty_Template_Compiled->render() (Line: 216)
Smarty_Internal_Template->render() (Line: 232)
Smarty_Internal_TemplateBase->_execute() (Line: 116)
Smarty_Internal_TemplateBase->fetch() (Line: 24)
content_65ba5c676ca3f2_96523772() (Line: 123)
Smarty_Template_Resource_Base->getRenderedTemplateCode() (Line: 114)
Smarty_Template_Compiled->render() (Line: 216)
Smarty_Internal_Template->render() (Line: 232)
Smarty_Internal_TemplateBase->_execute() (Line: 116)
Smarty_Internal_TemplateBase->fetch() (Line: 1046)
CRM_Utils_String::parseOneOffStringThroughSmarty() (Line: 108)
Civi\Token\TokenCompatSubscriber->onRender() (Line: 220)
Symfony\Component\EventDispatcher\EventDispatcher->callListeners() (Line: 56)
Symfony\Component\EventDispatcher\EventDispatcher->dispatch() (Line: 263)
Civi\Core\CiviEventDispatcher->dispatch() (Line: 397)
Civi\Token\TokenProcessor->render() (Line: 327)
Civi\Token\TokenRow->render() (Line: 67)
CRM_Core_TokenSmarty::render() (Line: 374)
CRM_Core_BAO_MessageTemplate::renderTemplateRaw() (Line: 422)
CRM_Core_BAO_MessageTemplate::sendTemplate() (Line: 1254)
CRM_Event_BAO_Event::sendMail() (Line: 895)
CRM_Event_Form_Registration_Confirm->postProcess() (Line: 625)
CRM_Core_Form->mainProcess() (Line: 144)
CRM_Core_StateMachine->perform() (Line: 43)
CRM_Core_QuickForm_Action_Next->perform() (Line: 203)
HTML_QuickForm_Controller->handle() (Line: 103)
HTML_QuickForm_Page->handle() (Line: 355)
CRM_Core_Controller->run() (Line: 322)
CRM_Core_Invoke::runItem() (Line: 69)
CRM_Core_Invoke::_invoke() (Line: 36)
CRM_Core_Invoke::invoke() (Line: 88)
Drupal\civicrm\Civicrm->invoke() (Line: 83)
Drupal\civicrm\Controller\CivicrmController->main()
call_user_func_array() (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 627)
Drupal\Core\Render\Renderer->executeInRenderContext() (Line: 121)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext() (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 181)
Symfony\Component\HttpKernel\HttpKernel->handleRaw() (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle() (Line: 58)
Drupal\Core\StackMiddleware\Session->handle() (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle() (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle() (Line: 32)
Drupal\big_pipe\StackMiddleware\ContentLength->handle() (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass() (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle() (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle() (Line: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle() (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle() (Line: 704)
Drupal\Core\DrupalKernel->handle() (Line: 19)
```
## Expected behaviour
A registration confirmation page is displayed.
## Environment information
* **Browser:** _Edge_ but probably irrelevant.
* **CiviCRM:** _5.69.3_
* **PHP:** _8.3.1_ but probably irrelevant.
* **CMS:** _Drupal 10.2.2_
* **Database:** _MySQL 8.0.36_ but probably irrelevant.
* **Web Server:** _IIS 10_
## Comments
_Anything else you would like the reviewer to note._
I have tried debugging the issue and spent quite some time on this. I raising it as an issue as my knowledge of Smarty isn't that great, but I hope a Smarty expert has better insight.
I think the issue is due to Smarty creating a template 'on the fly' rather than using a text file template. In the call stack, there is
CRM_Utils_String::parseOneOffStringThroughSmarty() (Line: 108) which passes `plaintext 'eval:{eval var=$smartySingleUseString|smarty:nodefaults}'`.
Incidentally, the line numbers on the call stack are strange, they seem out by one entity - `plaintext CRM_Utils_String::parseOneOffStringThroughSmarty() (Line: 108)` is actually line 1046 which is in the line above.
It seems that the system is calling some epheremal code which we can't see. The NetBeans call stack has transient entries like: ![image](/uploads/3a4859a5ff1b41a1152677863bfa1713/image.png)
You are able to step through the entity beginning with dbgp:// but cannot see the code. I have been unable to find content_65ba5d1bd929c5_86413884() during debugging, let alone see line 408. This makes debugging rather difficult. If one could see the template it was trying to process, it would help.5.69.5https://lab.civicrm.org/dev/release/-/issues/245.69.1 critical error: Undefined array key "crmSearchTasks" in "ext/search_ki...2024-02-01T22:42:39ZDmitry Smirnov5.69.1 critical error: Undefined array key "crmSearchTasks" in "ext/search_kit/search_kit.php" on line 61```
PHP Warning: Undefined array key "crmSearchTasks" in ext/search_kit/search_kit.php on line 61
PHP Warning: Trying to access array offset on value of type null in ext/search_kit/search_kit.php on line 61
PHP Fatal error: Uncaught T...```
PHP Warning: Undefined array key "crmSearchTasks" in ext/search_kit/search_kit.php on line 61
PHP Warning: Trying to access array offset on value of type null in ext/search_kit/search_kit.php on line 61
PHP Fatal error: Uncaught TypeError: in_array(): Argument #2 ($haystack) must be of type array, null given in ext/search_kit/search_kit.php:61
```https://lab.civicrm.org/dev/core/-/issues/4843CronJob for smart group rebuild / cache purge not working2024-01-15T13:12:26ZTobias Voigttobias.voigt@civiservice.deCronJob for smart group rebuild / cache purge not workingI love the idea of being able to use smart / dynamic groups for our client's projects. In one particular case I'm heavily relying on CiviCRM relationships to mirror the organization's structures. Yet I would like to set up accompanying s...I love the idea of being able to use smart / dynamic groups for our client's projects. In one particular case I'm heavily relying on CiviCRM relationships to mirror the organization's structures. Yet I would like to set up accompanying smart groups, that reflect certain relationships (or combination of relationships) to be able to address those smart groups in mailings or use them in the context of ACLs.
The problem I experienced over and over is that **the rebuild process of the smart group cache doesn't work reliably.**
I tested the two existing cronjobs for the rebuild process **Job.group_rebuild** and **Job.group_cache_flush** - yet they don't actually do what they're supposed to do, independent of the sequence in which I trigger them.
Only when I manually purge the system's cache (after I executed those cronjobs), the rebuilt smart groups are shown in the system. It might be possible that only the "**Job.group_cache_flush**" doesn't work correctly and therefore the smart groups are rebuilt by "**Job.group_rebuild**" but the result isn't shown in the system since the cache doesn't get purged.
I was able to reproduce this behaviour on several systems.https://lab.civicrm.org/dev/core/-/issues/3353No way to empty the cart procedurally or via a URL2024-01-05T05:03:31ZTomAndersonNo way to empty the cart procedurally or via a URLHow do we get rid of anything in the cart? For example, if it's after 1 hour, we may want to dump the entire cart.
For example, could I do an AJAX call like this? `{crmURL p='civicrm/event/empty_cart' q="reset=1" fb=1}`
I'm not seeing ...How do we get rid of anything in the cart? For example, if it's after 1 hour, we may want to dump the entire cart.
For example, could I do an AJAX call like this? `{crmURL p='civicrm/event/empty_cart' q="reset=1" fb=1}`
I'm not seeing anything to this effect.
Alternately, how can we do this procedurally (in PHP).https://lab.civicrm.org/dev/core/-/issues/3200Contributions search result summary not correct2023-12-19T05:03:24ZhfarooqContributions search result summary not correctCMS: Drupal 7.69
CiviCRM: 5.21.3
If contributions with status complete and for "Contributions OR Soft Credits?" field, select "Both" (both contributions and soft credits), in result summary there is a discrepancy seen; Number of total r...CMS: Drupal 7.69
CiviCRM: 5.21.3
If contributions with status complete and for "Contributions OR Soft Credits?" field, select "Both" (both contributions and soft credits), in result summary there is a discrepancy seen; Number of total results does not match with the sum of total contributions and soft credits, please see attached screenshot. I was able to replicate it on [dmaster demo](https://dmaster.demo.civicrm.org/) site at some point back few days but not anymore.
![image](/uploads/655780b5f00f98abf880697baac2aa9c/image.png)https://lab.civicrm.org/dev/drupal/-/issues/84Drupal7: use label instead of name in membership views2023-11-09T23:27:57ZwdecraeneDrupal7: use label instead of name in membership viewsIn `drupal/modules/views/components/civicrm.member.inc` add two times 'pseudo args' so (translated) labels are used instead of machine names.
```php
//Membership Status
$data['civicrm_membership']['status'] = array(
'title' => t...In `drupal/modules/views/components/civicrm.member.inc` add two times 'pseudo args' so (translated) labels are used instead of machine names.
```php
//Membership Status
$data['civicrm_membership']['status'] = array(
'title' => t('Status'),
'real field' => 'status_id',
'help' => t('The Status of the Membership'),
'field' => array(
'handler' => 'civicrm_handler_field_pseudo_constant',
'click sortable' => TRUE,
'pseudo class' => 'CRM_Member_PseudoConstant',
'pseudo method' => 'membershipStatus',
'pseudo args' => array(NULL, NULL, 'label'),
),
'argument' => array(
'handler' => 'views_handler_argument',
),
'filter' => array(
'handler' => 'civicrm_handler_filter_pseudo_constant',
'allow empty' => TRUE,
'pseudo class' => 'CRM_Member_PseudoConstant',
'pseudo method' => 'membershipStatus',
'pseudo args' => array(NULL, NULL, 'label'),
),
'sort' => array(
'handler' => 'views_handler_sort',
),
);
```https://lab.civicrm.org/dev/core/-/issues/4289Multi record Profile forms not saving and redirecting on "Add New Record".2023-11-08T14:04:31Zdarren.woodsMulti record Profile forms not saving and redirecting on "Add New Record".Overview
----------------------------------------
Multi record Profile forms are no longer respecting the "Redirect URL" for the Profile:-
![image](/uploads/3b349b061965a160ec7a51cfab703972/image.png)
Reproduction steps
----------------...Overview
----------------------------------------
Multi record Profile forms are no longer respecting the "Redirect URL" for the Profile:-
![image](/uploads/3b349b061965a160ec7a51cfab703972/image.png)
Reproduction steps
----------------------------------------
1. Under "Administer/Custom Data and Screens/Display Preferences" deselect "Enable Popup Forms".
2. Create a multi record custom data group and add a field.
2. Create a Profile which exposes these fields as a standalone form, setting the "Redirect URL" to be a valid URL.
3. Embed this Profile in a WordPress page using a shortcode, e.g.: [civicrm component="profile" gid="16" mode="edit" hijack="0"]
4. View the Page and click "Add new record", enter some valid data and click "Submit button.
Current behaviour
----------------------------------------
Form data is not saved and user is redirected to /civicrm/profile/edit which results in a blank WordPress page.
Expected behaviour
----------------------------------------
Form data is saved and user is redirected to the Redirect URL.
Environment information
----------------------------------------
CiviCRM 5.61.2
WordPress 6.2
Comments
----------------------------------------
_Anything else you would like the reviewer to note._https://lab.civicrm.org/dev/core/-/issues/4005Minor formatting gripes with Contributions UserDashboard.tpl2023-10-17T14:38:15ZAdam WoodMinor formatting gripes with Contributions UserDashboard.tplRaising this as a minor residual issue / action vaguely related to historic issues https://lab.civicrm.org/dev/core/-/issues/2034 and https://lab.civicrm.org/dev/core/-/issues/2129, namely some incidental formatting issues spotted in the...Raising this as a minor residual issue / action vaguely related to historic issues https://lab.civicrm.org/dev/core/-/issues/2034 and https://lab.civicrm.org/dev/core/-/issues/2129, namely some incidental formatting issues spotted in the user dashboard template for recurring contributions.
Minor issues relating to spacing and formatting, will raise PR to close off.
1. No handling for if (installments == 0), i.e. the recurring contribution is open-ended. Just leaves a blank string which is confusing to users.
2. No spacing between clauses in 'Terms' - makes difficult to read. Also untranslated strings.
3. Unnecessary colon after 'Terms' in table header (doesn't match other header cells).
Screenshot below shows issues.
![image](https://user-images.githubusercontent.com/72983627/205190951-4db837e1-85df-4e38-a8b4-77ab1550a44b.png)
![image](https://user-images.githubusercontent.com/72983627/205190481-e8d642a5-9956-4fc3-a0d2-51f16187dca1.png)https://lab.civicrm.org/dev/core/-/issues/4521CiviCRM 5.64.1 update does not always enable core extension CiviContribute wh...2023-09-18T23:43:03Zjustinfreeman (Agileware)CiviCRM 5.64.1 update does not always enable core extension CiviContribute which then causes WSODCiviCRM 5.64.1 update does not always enable core extension CiviContribute which then causes WSOD, throwing an error:
`Error: Class 'Civi\Api4\EntityFinancialAccount' not found in CRM_Financial_BAO_FinancialType::getIncomeFinancialType(...CiviCRM 5.64.1 update does not always enable core extension CiviContribute which then causes WSOD, throwing an error:
`Error: Class 'Civi\Api4\EntityFinancialAccount' not found in CRM_Financial_BAO_FinancialType::getIncomeFinancialType() (line 171 of .../civicrm/CRM/Financial/BAO/FinancialType.php).`
OR
`Uncaught Error: Class 'Civi\Api4\PaymentProcessorType' not found`
This is because the **civi_contribute** extension has not been enabled / loaded yet, which is part of a set of core-bundled extensions that map to each CiviCRM component.
This seems to occurs more regularly when an extension update is available for a Payment Processor or other extension which calls on the missing class from CiviContribute.
Can be manually solved by running `cv en civi_contribute` on the CLI. Sometimes the website UI is inaccessible after this error and CLI is only method available to recover.
This error also seems to interrupt the enabling of other core-bundled extensions, eg. CiviReport, CiviMail, CiviEvent etc.
CiviCRM 5.64.1
Agileware ref: CIVICRM-2163https://lab.civicrm.org/dev/core/-/issues/517Intermittent, ambiguous error "requires cookies" or is it "invalid session ke...2023-09-12T05:03:26ZbrianhayIntermittent, ambiguous error "requires cookies" or is it "invalid session keys"?Fresh, clean install of Drupal 7.61 + CiviCRM 5.7.0 on PHP 7.1
Error is intermittent (maybe every 3rd or so time) when editing contact records like adding a phone number (inline or record save) or clearing caches. Likely other actions t...Fresh, clean install of Drupal 7.61 + CiviCRM 5.7.0 on PHP 7.1
Error is intermittent (maybe every 3rd or so time) when editing contact records like adding a phone number (inline or record save) or clearing caches. Likely other actions trigger the error as well but these are the ones we've discovered so far.
HTTPS is enforced in .htaccess and permanent redirects in place to ensure one URL is used.
No javascript or network console errors. No related apache server errors logged.
The CiviCRM error message is vague and makes little sense. Cookies are enabled in the browser. And is it a cookies or invalid session key issue? It's very strange that it isn't triggered consistently, every time.
![Screen_Shot_2018-11-13_at_5.11.47_pm](/uploads/5dc5e484fba734fbcf16b1248f75cbc5/Screen_Shot_2018-11-13_at_5.11.47_pm.png)https://lab.civicrm.org/dev/core/-/issues/3114CiviMail - Error on sending/viewing mail via Mosaico following core update2023-09-05T09:58:20ZsbyrneCiviMail - Error on sending/viewing mail via Mosaico following core updateWe're seeing the error: "DB Error: no such field" when trying to send email from Mosaico. This happens regardless of whether the email is a test, or going out to the intended recipients. The error appears immediately upon submitting the ...We're seeing the error: "DB Error: no such field" when trying to send email from Mosaico. This happens regardless of whether the email is a test, or going out to the intended recipients. The error appears immediately upon submitting the mailing.
We're also unable to view old mailings submitted via Mosico, with the same error appearing but as a webpage rather than a pop-up.
This started happening after we upgraded CiviCRM from 5.39.0 to 5.46.0.
"Traditional" mails are working fine (sending and viewing)
I've done a few basic things to fix the problem with no success:
- Cleaned all caches
- Tricked Civi into thinking it was running an older version of the database and upgraded again to rule out problems with the DB update
- Upgraded Civi to 5.47.0
- Updated Mosaico to 2.9, while also installing Form Core and Seatch kit. Completed additional database updates required by this.
The error that appears while sending the mailing doesn't leave anything in the error log. I do get the following when viewing old mailings though:
```
Mar 11 16:35:20 [error]
$Fatal Error Details = array:3 [
"message" => "DB Error: no such field"
"code" => null
"exception" => CiviCRM_API3_Exception {#3486
-extraParams: array:4 [
"error_code" => "no such field"
"tip" => "add debug=1 to your API call to have more info about the error"
"is_error" => 1
"error_message" => "DB Error: no such field"
]
#message: "DB Error: no such field"
#code: 0
#file: ".../sites/all/modules/civicrm/api/api.php"
#line: 134
trace: {
/.../sites/all/modules/civicrm/api/api.php:134 {
› if (is_array($result) && !empty($result['is_error'])) {
› throw new CiviCRM_API3_Exception($result['error_message'], CRM_Utils_Array::value('error_code', $result, 'undefined'), $result);
› }
}
/.../sites/all/modules/civicrm/CRM/Mailing/Page/View.php:148 { …}
/.../sites/all/modules/civicrm/CRM/Core/Invoke.php:319 { …}
/.../sites/all/modules/civicrm/CRM/Core/Invoke.php:69 { …}
/.../sites/all/modules/civicrm/CRM/Core/Invoke.php:36 { …}
/.../sites/all/modules/civicrm/drupal/civicrm.module:471 { …}
/.../domains/secure/htdocs/includes/menu.inc:527 { …}
/.../domains/secure/htdocs/index.php:21 { …}
}
}
]
Mar 11 16:35:20 [debug] $backTrace = #0 /.../domains/secure/htdocs/sites/all/modules/civicrm/CRM/Core/Error.php(433): CRM_Core_Error::backtrace("backTrace", TRUE)
#1 /.../domains/secure/htdocs/sites/all/modules/civicrm/CRM/Core/Invoke.php(39): CRM_Core_Error::handleUnhandledException(Object(CiviCRM_API3_Exception))
#2 /.../domains/secure/htdocs/sites/all/modules/civicrm/drupal/civicrm.module(471): CRM_Core_Invoke::invoke((Array:3))
#3 /.../domains/secure/htdocs/includes/menu.inc(527): civicrm_invoke("mailing", "view")
#4 /.../domains/secure/htdocs/index.php(21): menu_execute_active_handler()
#5 {main}
```
Environment:
- Debian 10 (64 bit)
- MariaDB 10.3
- PHP 7.3
- Drupal 7.88
- CiviCRM 5.47.0
- Mosaico 2.9https://lab.civicrm.org/dev/core/-/issues/4123Support for accessing Contribution Recur tokens when a membership or contribu...2023-08-10T22:34:36ZseamusleeSupport for accessing Contribution Recur tokens when a membership or contribution is referenced5.62.0https://lab.civicrm.org/dev/core/-/issues/4398Mailing never starts2023-08-03T12:41:03ZphilmckMailing never startsOverview
----------------------------------------
_Please describe your problem or bug in detail._
Group emails from one of my CiviCRM installations are not being delivered (ever), which has caused some embarrassment. Messages can be com...Overview
----------------------------------------
_Please describe your problem or bug in detail._
Group emails from one of my CiviCRM installations are not being delivered (ever), which has caused some embarrassment. Messages can be composed as usual, but are never scheduled and there's no "runner" display. Pausing and restarting the mailing results in the status changing from "Scheduled" to "Running" and clicking "Report" shows the expected number of intended recipients but the "Successful Deliveries" count is always zero. In case it's relevant, I did notice that the option to send "immediately" is not selected by default (which I think it always is on sites that work), but it can be selected manually.
Obviously, I have enabled the "Send Scheduled Mailings" job and tried triggering that both manually and from a cron job. The log shows success but with a count of zero.
I have also tried obvious things like disabling all extensions, resetting caches and paths, comparing all settings with other installations that do work, searching the forums, bug reports and so on. I've checked that outgoing mail is configured correctly and I can send test emails. There's nothing in the error logs. Nothing makes any difference, it seems to be a bug.
The problem is reproducible in the sense that it's not intermittent, but I haven't been able to reproduce it on a clean installation.
I'd be prepared to move everything to a new installation to work around this but it's a heavily used instance with lots of contacts, invoices and so on and I know of no way to export all those and reimport them later to a working instance. Everything else seems to be working as usual.
Reproduction steps
----------------------------------------
1. Create a group containing some test contacts.
2. Go to **Mailing > New Mailing** and compose a test message, with the group from the previous step selected as Recipients.
3. Click **Send test** and check that a test message is correctly delivered.
4. Click **Next** then select **Immediately** or a date and time 5 minutes in the future.
5. Click **Submit Mailing**.
6. Wait for cron to run or go to **System Settings > Scheduled Jobs** and trigger **Send Scheduled Mailings**. Check that the result is success.
7. Check that the message is now in **Mailing > Scheduled and Sent Mailings**. Click **Report**. Observe that **Intended recipients** is not zero but **Successful deliveries** is always zero.
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._
Nothing happens. No messages delivered, nothing in error logs.
Expected behaviour
----------------------------------------
_What should happen._
Messages are sent once the scheduled job is triggered, perhaps with a batch limit. Eventually the whole job completes and the status changes to "Completed".
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:__ _Chrome 114.0.5735.135_
* __CiviCRM:__ _Master/5.62.1_
* __PHP:__ _8.1_
* __CMS:__ _WordPress 6.2.2 running on Ubuntu 22.04_
* __Database:__ _MariaDB 10.6.12_
* __Web Server:__ _OpenLiteSpeed 1.7.17_https://lab.civicrm.org/dev/core/-/issues/2520ACL restricted users lose access to contacts when editing via search list2023-07-28T05:03:21ZDetlev SieberACL restricted users lose access to contacts when editing via search listOverview
----------------------------------------
When using ACL restriction for access to contacts, the following problem occurs:
After searching contacts and editing a contact via the edit link on the search list, CiviCRM tries to save...Overview
----------------------------------------
When using ACL restriction for access to contacts, the following problem occurs:
After searching contacts and editing a contact via the edit link on the search list, CiviCRM tries to save the group, which is used to handle the ACL access. However, since this user doesn't have the permission to edit the group, the group is automatically removed from the contact when it is saved.
This only happens when the contact is edited using the edit link on the search list, instead editing using the summary page works well.
Reproduction steps
----------------------------------------
1. Create ACL permission (edit group of contacts, resulting in member of group A is allowed to edit contacts in group B only).
1. Search all contacts, click on edit-Link of the first contact in search list.
1. Change Address, click on SAVE
1. Contact is save, but membership in group B is removed, the user cannot view the contact anymore.
Current behaviour
----------------------------------------
1. See above: the ACL-restricted user has no access to the contact anymore.
1. When editing via summary screen, everything works fine.
1. Strangely, when the user is assigned to another ACL rule, everything works fine.
Expected behaviour
----------------------------------------
1. After editing, the edited contact should stay in group B.
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. -->
* __CiviCRM:__ _5.35.1_
* __PHP:__ _7.3_
* __CMS:__ _5.7_
* __Database:__ _MySQL 5.7.7_
Comments
----------------------------------------
I believe, this issue was introduced with the change of ACL's (permission to edit group) recently.https://lab.civicrm.org/dev/wordpress/-/issues/104Payment form option for username check availablity not working correctly.2023-04-16T03:51:49ZnpdesignPayment form option for username check availablity not working correctly.After upgrading to the most recent CiviCRM release our payment forms for membership sign up will no longer allow users to use the "Check Availability" option when attempting to select a username. Continually receive the message "Error c...After upgrading to the most recent CiviCRM release our payment forms for membership sign up will no longer allow users to use the "Check Availability" option when attempting to select a username. Continually receive the message "Error checking username. Please reload the form and try again."
All CiviCRM extenions are up to date and all Wordpress plugins are up to date. Nothing really shows in our error logs in relation to this issue and at a loss for next steps. Any help/guidance would be appreciated.
CiviCRM 5.38.0 / WordPress 5.7.2https://lab.civicrm.org/dev/core/-/issues/750The following PHP variables are not set: $_SERVER[HTTP_HOST]2023-04-11T05:03:21ZYepaThe following PHP variables are not set: $_SERVER[HTTP_HOST]### The error
```drush updb
[error] The following PHP variables are not set: $_SERVER[HTTP_HOST]
Requirements check reports errors. Do you wish to continue? (yes/no) [yes]:
```
### Steps to reproduce
* Launch the command ```drush u...### The error
```drush updb
[error] The following PHP variables are not set: $_SERVER[HTTP_HOST]
Requirements check reports errors. Do you wish to continue? (yes/no) [yes]:
```
### Steps to reproduce
* Launch the command ```drush updb```
### Versions
* Drupal : 8.6.10
* Drush : 9.5.2
* CiviCRM : 5.10.3
### Related to
* https://github.com/drush-ops/drush/issues/3562https://lab.civicrm.org/dev/core/-/issues/1873Possible safari url direction issue2023-04-03T05:03:33ZeileenPossible safari url direction issueLong discussion on this now-closed PR
https://github.com/civicrm/civicrm-core/pull/17422Long discussion on this now-closed PR
https://github.com/civicrm/civicrm-core/pull/17422https://lab.civicrm.org/dev/core/-/issues/4135Regression: Fatal errors in IPNs after loadRelatedObjects refactor2023-03-10T14:35:06ZJKingsnorthRegression: Fatal errors in IPNs after loadRelatedObjects refactor@eileen This refactor causes fatal errors with our IPN-based payment processor : https://github.com/civicrm/civicrm-core/commit/d0a93d4dfc2a771b095f26fa33eb5551d6c9dcdb
I still need to do some more investigation, but the error we see is...@eileen This refactor causes fatal errors with our IPN-based payment processor : https://github.com/civicrm/civicrm-core/commit/d0a93d4dfc2a771b095f26fa33eb5551d6c9dcdb
I still need to do some more investigation, but the error we see is:
`TypeError: Illegal offset type in CRM_Financial_BAO_PaymentProcessor::getPayment() (line 222 of .../CRM/Financial/BAO/PaymentProcessor.php).`
Which corresponds to the return in:
![image](/uploads/dd002c8675a668f90d75e6ebb20dc9a1/image.png)
Reverting that refactor fixes the issue for us. I'll do some more digging...https://lab.civicrm.org/dev/civicrm-asset-plugin/-/issues/2Notice: Undefined property: CRM_Core_DAO2023-02-20T15:45:46ZGhost UserNotice: Undefined property: CRM_Core_DAOAfter a login in drupal I see the following errors:
* Notice: Undefined property: CRM_Core_DAO::$Private_Adresse-street_address in CRM_Core_BAO_UFGroup::getValues() (Zeile 1289 von /var/www/html/sites/all/modules/civicrm/CRM/Core/BAO/UF...After a login in drupal I see the following errors:
* Notice: Undefined property: CRM_Core_DAO::$Private_Adresse-street_address in CRM_Core_BAO_UFGroup::getValues() (Zeile 1289 von /var/www/html/sites/all/modules/civicrm/CRM/Core/BAO/UFGroup.php).
* Notice: Undefined property: CRM_Core_DAO::$Private_Adresse-city in CRM_Core_BAO_UFGroup::getValues() (Zeile 1289 von /var/www/html/sites/all/modules/civicrm/CRM/Core/BAO/UFGroup.php).
* Notice: Undefined property: CRM_Core_DAO::$Private_Adresse-postal_code in CRM_Core_BAO_UFGroup::getValues() (Zeile 1289 von /var/www/html/sites/all/modules/civicrm/CRM/Core/BAO/UFGroup.php).
* Notice: Undefined property: CRM_Core_DAO::$Private_Adresse-country in CRM_Core_BAO_UFGroup::getValues() (Zeile 1264 von /var/www/html/sites/all/modules/civicrm/CRM/Core/BAO/UFGroup.php).
* Notice: Undefined property: CRM_Core_DAO::$Private_Adresse-country_id in CRM_Core_BAO_UFGroup::getValues() (Zeile 1266 von /var/www/html/sites/all/modules/civicrm/CRM/Core/BAO/UFGroup.php).
* Notice: Undefined property: CRM_Core_DAO::$Private_Adresse-state_province in CRM_Core_BAO_UFGroup::getValues() (Zeile 1264 von /var/www/html/sites/all/modules/civicrm/CRM/Core/BAO/UFGroup.php).
* Notice: Undefined property: CRM_Core_DAO::$Private_Adresse-state_province_id in CRM_Core_BAO_UFGroup::getValues() (Zeile 1266 von /var/www/html/sites/all/modules/civicrm/CRM/Core/BAO/UFGroup.php).
![image](/uploads/839e8f47d4b8f6c1cd6798e06fcf8ad0/image.png)
---
CiviCRM Version: `7.x-5.18.4`
Drupal Version: `7.67`