Drupal 7.82 Civi 5.41.0
We just updated Civi to 5.41.0. Since the update when we go to a contact and click the contribution tab, we often get a "Network Error: Unable to reach the server" message.
It seems to be certain contacts work and certain ones do not.
We have tried it on multiple computers and browsers and the problem in consistent with which donors work/fail.
In Drupal logs: LOCATION https://secure.radiusinternational.org/civicrm/contact/view/contribution...
REFERRER https://secure.radiusinternational.org/civicrm/contact/view?reset=1&cid=...
MESSAGE TypeError: Argument 1 passed to CRM_Financial_BAO_Order::setPriceSetID() must be of the type int, null given, called in .../civicrm/CRM/Financial/BAO/Order.php on line 902 in CRM_Financial_BAO_Order->setPriceSetID() (line 465 of .../civicrm/CRM/Financial/BAO/Order.php).
I figured out that the contacts that it fails on are ones that do not have anything in civicrm_line_item:price_field_id or price_field_value_id These are blank because webform-civicrm does not populate those fields.
To verify the issue, I checked the line item table against contributions from donors that failed vs those that worked. Once I verified that that seemed to be the common character, I then edited 2 donors that had contributions missing data in those fields. Once I populated all of their contributions in the line item table for the price_field_id and price_field_value_id, we can access their contribution tab.
I am not sure what it takes to get webform-civicrm to populate those fields, for now I may write a sql query to back fill those fields. I might look at CiviRules to fill in those fields going forward or else a cron job to keep the fields updated.
| Comment | File | Size | Author |
|---|
Comments
Comment #2
karingHi @IowaBoy - do you have LineItem Editor Extension installed by any chance?
Comment #3
karingWebform CiviCRM indeed has not been specific about price_field_id or price_field_value_id in the past - b/c CiviCRM core has been 'fetching' these automatically. When there is a ton of price_fields though (both visible and hidden), the fetching may not produce the correct result or no result at all.
I have already started drafting a better line item branch for Webform CiviCRM to be more specific. Using it for 1 client at this time. It will need to get finalized in the 8.x-5.x version first and secured with a test before we can backport that to 7.x-5.x
Comment #4
IowaBoy commentedYes, I do have the LineItem Editor extension installed.
I disabled it and tested and I still cannot access donor contribution tabs if they have one donation that is missing the price field id.
Comment #5
IowaBoy commentedKaren, I will be happy to be a 7.x guinea pig for you--unless I have got around to updating from Drupal 7 before you get to this.
Comment #6
karingWe started looking at this last weekend - and will be circulating back to this later this week (if not today/tomorrow).
We will fix this on D9 first - which has extensive test coverage. Then we’ll back-port to D7 (that last part is quick) - reproducing this reliably on D9 in a test is where I’m at now. And on my local 5.41 I did see pricefield_value_id in the line item when buying membership eg.
So CiviCRM core is still looking for and filling in price_field_value_id when it can.
What is your exact scenario in webform civicrm? Can you attach a screenshot of what the contribution view looks like when you manually add the price_field bits in the table?
Comment #7
karingI spent some time with one of my team on this earlier today and this may work. This passes all our tests in D8/D9 - including on CiviCRM dev-master. Can you try and add this code to your D7 Webform CiviCRM. It goes in this file: includes/wf_crm_webform_postprocess.inc -> put it just after line
2197 // Save the line_itemI don't know yet if this will have unintended ramifications but it ensures that we always have a price_field_id (albeit a quick-config one) in the line_items that are generated with WFC.
Comment #8
karingWe worked on line items over the past couple of days. Can you please try https://github.com/colemanw/webform_civicrm/pull/621 - it's a backport of some work we did for D8/D9 and it passes all our tests there.
Comment #9
karingHi Carl -> if you could please test to confirm -> https://github.com/colemanw/webform_civicrm/pull/621 resolves the issue on your instance that would be super helpful.
Comment #10
karingWe have merged https://github.com/colemanw/webform_civicrm/pull/621
Comment #12
IowaBoy commentedSorry, I guess I did not have it emailing me when there were responses to this and I wrote my own cron job to update the line item table and fill in those fields.
I tried pull/621 and it completely stopped writing anything to the lineitem table and the donor sees a Error message to try again later. However, the contribution did process, it just did not write anything to the line item table
Comment #13
IowaBoy commentedI get the following in my admin logs
Error: Call to a member function wf_civicrm_api() on null in wf_crm_webform_postprocess->processContribution() (line 2206 of /home/radiusint/secure/sites/all/modules/webform_civicrm/includes/wf_crm_webform_postprocess.inc).
I went back to the original wf_crm_webform_postprocess and it is all working as before
Comment #14
francescbassasNote that it's necessary to apply https://github.com/colemanw/webform_civicrm/pull/641/files after https://github.com/colemanw/webform_civicrm/pull/621/files
Comment #15
karing@francescbassas - can you confirm that applying both 641 and 621 fixes the issues with D7 + CiviCRM (>=5.41)? If so we'll queue up for a D7 release.
Comment #16
IowaBoy commentedFor D7-Civi 5.41, After also applying 641 I no longer get the error.
However, it applied the wrong price_field_id and price_field_value_id is still null.
Comment #17
francescbassas@KarinG I can confirm that applying patch 641 and 621 I have stopped having problems accessing the contributions contact tab with contributions generated with webform.
Comment #18
karing@francescbassas -> thank you for looping back on this. I've queued up a D7 release for this weekend.
Carl: note that the price_field_id = 1 (and 2) (by design). They are the so called quick config ones.
Comment #19
IowaBoy commentedDoesn't that defeat the point of line items?
Comment #20
karingNo - not at all. CiviCRM itself too produces line items with quick config method (id=1 or 2). That's more reliable then CiviCRM guessing based on the label of the line item. That can have multiple possible matches.
Comment #21
IowaBoy commentedThat must be a change with Civi since I switched to using Webform Integration. Because Civi always had the price_field and price_field_id filled in with ids greater than 1 & 2. I never have duplicate line item labels so maybe Civi was able to function for me.
No problem, if the update interferes with what I want, I will just write a cron to correct the line item table.