mranner

Sure, we know. We commented it for the developers, because they shutdown the issue tab on github and you cannot longer report issues on the github repo.

We have the same error: if cart total is 0, we will have an exception (crash) on the checkout page. We have fixed this issue in
./includes/service/class-wc-postfinancecheckout-service-line-item.php on line 350:
$proportional_discount_amount = empty($total_amount) ? 0 : $total_discount_amount * ( $data['total'] / $total_amount );

• This reply was modified 2 days, 21 hours ago by mranner.

Yes it’s the 6292 issue. Only saving field/pod definition (toggling required for example) again resolves the issue. Tested on 3 sites.

• This reply was modified 3 years ago by mranner.

@quasel it seems to be a cache issue, but I missed the “pods cache” hint. I thought on WP Rocket or WP Super Cache, which I have not installed ??

Saving pods field definition will also clear the cache.

• This reply was modified 3 years ago by mranner.

It seems, after toggling the “required” one time, it also works now with required on 2.8.3. I try to reproduce it on our staging environment.

Ok, the solution is to duplicate or import/export the form definition and to create a new form.

I have compared the JSON export data with print_r(json_decode(…)), but I cannot find a significant difference. So I dont understand, why it works with a duplicated form.

--- dump1       2015-11-25 18:04:46.000000000 +0100
+++ dump2       2015-11-25 18:04:56.000000000 +0100
@@ -1,14 +1,14 @@
 stdClass Object
 (
     [_last_updated] => Wed, 25 Nov 2015 17:00:37 +0000
-    [ID] => CF557ffeae8967e
-    [name] => Bewerbung DE
+    [ID] => CF5655e9cc420ce
+    [name] => Bewerbung Test 2
     [description] =>
     [db_support] => 0
     [pinned] => 0
     [hide_form] => 1
     [check_honey] => 1
-    [success] => Deine Bewerbung wurde abgeschickt. Vielen Dank.
+    [success] => Form has been successfully submitted. Thank you.
     [avatar_field] =>
     [form_ajax] => 1
     [custom_callback] =>

Ok, have found the reason: since 1.3.1 it seems CF runs “Processors” in a different order or way.

I have also used an “Redirection” processor, before the “Run Action” processor. Putting the “Redirection” at the end or after “Run Action” and all works ok.

UPDATE: Sorry, this was not the solution – I have tested with 1.3.0 instead 1.3.1 – problem still occurs

Regards
Michael

Any news on this?

Thank you!

Ok I see get_slug_data is deprecated, but still the same with get_field_data().

Thank you!

Yes, right. Is there a workaround?

We should pass $current_post_type instead $args to the filter.