Björn Endres (a243d977) at 14 Mar 09:59
[AIVL-10936] remove some fields in campaign form
... and 1 more commit
Björn Endres (e9236720) at 13 Mar 16:18
The way I see it, the AIP is one level more abstract: it can be used in a similar way as @JonGold's Advanced Import Form Processor, but it is designed for processing any conceivable (record based) input, collected from any kind of data source, and apply that record in any conceivable way to CiviCRM (e.g. APIv3/v4) automatically and without user interaction.
We've experienced this issue as well, and we also ended up either not upgrading civix (bad) or running civix upgrade and then manually (and painfully) patching out the broken* bits.
*) when using CiviCRM 5.37 or below, which some larger organisations still do, in a protected (VPN) setup.
Björn Endres (2a116bce) at 27 Sep 10:19
outlined two approaches to use this extension
We really need to set the
return_url
parameters which will be backward-compatible.
No doubt. I just wanted to document my patch in case somebody else is in trouble right now.
The current major version is 12. Maybe our problem was fixed in the recent version...Has anyone tested that?
I have tested that, and it doesn't help. It looks like this issue is not related to the Stripe API version.
I have instead now "hot-patched" the library and added the following line HERE:
$defaultHeaders['Stripe-Version'] = '2022-11-15';
With that, it seems to work again for me.
Obviously, that is a hack and not a proper fix, and we need to find out why the requested API version from the extension (e.g. HERE) isn't passed on to the API call, but I'm running out of resources to follow up on this.
Also, the composer.json
pegs the library version as 9.x
:
"stripe/stripe-php": "^9"
The current major version is 12. Maybe our problem was fixed in the recent version...Has anyone tested that?
Yes, I came across the same thing. I seemingly cannot find the right place to set the stripe_version
/ Stripe-Version
API parameter/header anywhere, it always gets ignored or filtered out. Maybe @mattwire knows better, otherwise I'd have to do some more profound debugging.
Hi @mattwire , thanks for reporting. I've run into this as well now.
What do you think would be easier as a "hotfix":
"return_url"
, or"stripe_version": "2022-11-15"
to the call?We are getting the "There might be a data problem, contribution id could not be loaded from the line item" message with certain line items in our 5.64.0
installation.
It looks like the system assumes that a line item should always have a contribution linked to it. That however, might not always be the case - in our setup we have two scenarios:
Remark: Despite the title, this is a different from #4441.
if the PHP constraint isn't met, then skip loading the extension
My thoughts were rather to check these requirements before install or upgrade. In that scenario the installer/upgrade would simply extract the info.xml first in order to check for compatibility.
But since that doesn't work if you do the upgrade by simply swapping the extension's code, I guess we have to do the PHP constraint checking anyway... OR we could finally provide sensible extension install/upgrade call that would accept a zip/tarball as input, and checks or resolves these issues before replacing code.
Since @totten asked me for an example, here it is:
the "LittleBIC Extension" had to switch a library which won't be adjusted for PHP8, and the new replacement library requires PHP8+. Therefore we ended up with all extension versions up until 1.7.x requiring PHP 7.x and crashing on PHP 8 - and all versions with 1.8.x crashing with PHP 7.x and requiring PHP 8+. So an upgrade of this extension will crash, and there is no way to communicate that to the user/system except for readmes that nobody reads when upgrading an extension. Note: it doesn't crash right away, only when the library is used to update the BIC database, and that's only done like every other month, or even less frequently.
We (at SYSTOPIA) would like to be able to list known compatible and incompatible PHP versions in the extensions' info.xml
.
Our current idea is to base the format on the CiviCRM Core version compatibility, which is expressed as a list of positive/compatible examples. This way this section of the info.xml
would look something like this:
...
<compatibility>
<ver>5.63</ver>
</compatibility>
<phpCompatibility>
<ver>8.0</ver>
</phpCompatibility>
<phpIncompatibility>
<ver>7.4</ver>
</phpIncompatibility>
...
Please note that we added the phpIncompatibility
too, so we could express specific known incompatibilities.
Of course, the of new tags phpCompatibility
and phpIncompatibility
would be optional.
Since I've received moderately positive, but diffuse feedback on the extension channel about the details, I've opened the discussion here.
Björn Endres (d499a354) at 15 Aug 11:59
released 2.1.0
Björn Endres (d499a354) at 15 Aug 11:59
released 2.1.0
Björn Endres (f9577588) at 28 Jul 12:27
adding the removed (deprecated) functions with 5.57