@dieterholvoet I was able to index 70k records without issue after the updates so the comment about not 100% perfect was maybe just a lack of confidence around testing edge cases. But it's working really well for us at the moment.
We ended up using the following patch after we ran into some issues. Might not be 100% perfect but we hit some snags with Korean characters and the splitting actually malforming them because of their bytes length. Hopefully this helps someone. Previous work on the MR worked great as far as I can tell other than that issue.
I ran into this recently so I went ahead and wrote a patch that works specifically for our use case. I have not ran any of the tests but we needed something quick and dirty to solve this. I know it's probably not the best solution out there but this did work for us in a pinch if it helps someone else that runs into this.
I was able to combine two fields (both plain text fields- title and another field) to query easily the ones we needed and skip over them since we had previously run the feeds and were overwriting multiple nodes multiple times due to collisions in either one of the fields chosen as unique.
I can confirm the <a> do not work. I know that others work just fine (like table tags). Was hoping to maybe dive in and try to figure it out but I can at least, for the time being, confirm the <a> tags are not created/persisted from pasting in.
I downgraded to algolia/algoliasearch-client-php:3.3.2 to resolve the issue. The implementation of typing is not lining up with the UriInterface declaration. I'm okay to do this for now. Doesn't seem like a problem for this module, but moreso with the UriInterface.
I should have followed up. This was due to another module not handling errors properly. This was NOT an issue with commerce_paypal, instead was an issue from commerce_multi_payments and not handling errors well.
Confirming I'm running into this issue as well.
I'd be interested in knowing if this is on the horizon at all. I don't know if I can help at all but I will try. Love this admin building experience from this module but have a client that needs moderation and/or revisions to work.
I've dug deeper into this.
I’m testing a weird instance where orders can be placed through PayPal but if a specific error is fired off (Insufficient Funds like the one above), the code traceback will go through the process of throwing a PaymentGatewayException however it still proceeds through the code without redirecting back to a previous spot. It actually continues on and places the order, without payment at all.
When it gets to the part of code about redirecting to the $error_step_id, $this->redirectToPrevious() is set to false which I think is where the bug is as well. It should not continue on through the code to where $order->save() is called.
The question I have is… what should my checkout flow look like for Paypal Checkout (Preferred)? Is it possible I have the wrong order of things?
Kinda seems like a bug to me in tthis module, but could it be with commerce itself?
Is it possible to look into this a little bit further? I'm running into this issue (the error from OP), but I think the bigger problem that I'm seeing and I'm not sure where to start with debugging it or providing more information for it is that my site is not handling the error at all. Instead it's allowing the order to process with no payments attached.
Order moves into a state for validation and has the look and feel that it was "completed" as a transaction.
Is it possible to look into this a little bit further? I'm running into this issue (the error from OP), but I think the bigger problem that I'm seeing and I'm not sure where to start with debugging it or providing more information for it is that my site is not handling the error at all. Instead it's allowing the order to process with no payments attached.
Order moves into a state for validation and has the look and feel that it was "completed" as a transaction.