Payment_total_type throwing json warning

Resolved Matt Lowe
(@squelch)

1 year ago
We are not using payments in our form, but we’re running into a php notice that’s affecting our submission message:

Notice: Undefined index: payment_total_type in … plugins/ninja-forms/includes/Abstracts/MergeTags.php on line 68

The code in question checks to see if “payment_total” is a key in the $subject field, but not “payment_total_type”:
```
if (                isset($subject['payment_total'])                && $subject['payment_total_type'] == 'field'                && ! is_numeric($subject['payment_total'])                && ! strpos($subject['payment_total'], ':calc}')            ) 
```
When I output the $subject array, there is no payment_total_type in the array, but there is an empty payment_total:
```
... [payment_gateways] =>     [payment_total] =>     [tag] => ...
```
It appears that the isset($subject[“payment_total”]) is returning true, but since there’s not a key of “payment_total_type” in the $subject array, that is throwing the undefined index notice.

And as I said before you deleted my reply on the other thread that you erroneously marked as resolved, this has been like this for more than 3 weeks. The fix is A SINGLE LINE OF CODE to check whether payment_total_type is set or not. I can’t be bothered to provide you with the code again, since you deleted it.

BUT, as I pointed out in my deleted reply, your suggested fix is nothing of the sort. Recreating a form’s actions from scratch is hours and hours and hours of work across multiple forms. It’s hours of end-to-end testing, ironing out of bugs that will inevitably have crept in, and it’s probably months of irate customer support emails when human error leads to missed leads and opportunities. All so that Ninja Forms can avoid writing one line of code.

Aren’t you glad you made me rewrite all of this now? For the record I added more information to the other thread, I didn’t simply reply with a “me too”. Unceremoniously deleting replies because they highlight that your team haven’t fixed an obvious error in more than 3 weeks doesn’t make you look good. Now you have TWO threads pointing out your failure. From the FAQ you sent me,

“We ask everyone make a new topic, just for themselves, unless they are absolutely certain the problem is the same“

It very much is exactly the same. So who’s not following the FAQs now?

Viewing 3 replies - 1 through 3 (of 3 total)

Plugin Support Mia
(@xmiax)

1 year ago

Hi

Thanks for reaching out.

I’d like a chance to explain something. These forums are owned and moderated by WordPress. We only answer questions in here, and even then as we are able. Both Free and Paid users can get support on our site at https://ninjaforms.com/contact/. Any question that involves code changes or something more than a quick answer need to be entered there, mostly because we will likely have to ask for specifics that you may or may not want to see on a public forum. Having said that, we didn’t remove your post because we can’t do that. A ww.wp.xz.cn volunteer (they all are) likely did so because you didn’t start your own thread. Those are their rules. If you’d like to ask why you can find moderators in the Forums channel at https://app.slack.com/client/T024MFP4J/C02RQC6RW

Please note : For anyone else seeing this, that channel is not for general support of any kind. It’s for issues with the forum.

As to your issue, we’ve already been working on this issue and have an alpha version ready. After the fix is made we spend time QAing the alpha to be sure as possible it won’t cause unanticipated issues. It should be merged into core soon.

Lastly, I understand that when people reach out to support, they are already upset and I try to allow for that. What we don’t allow is any disrespect so we ask you please keep the discussion civil and free of emotion so we can help you get the support you want.

Thanks

Mia

Thread Starter Matt Lowe
(@squelch)

1 year ago

Hi Mia,

we didn’t remove your post because we can’t do that

Yes, I realised that a few hours after I’d posted it (I’m a plugin author myself) — absolutely not your / NF’s fault so please accept my apologies. I’m incredibly sleep deprived at the moment due to illness and wasn’t thinking clearly, was having a bad day, and was put into a bad mood by the mod removing my other post for supposedly violating the rules when, in fact, as I pointed out above, it didn’t since I was adding further information to the other thread. Also I realised, again after posting this, that it’s only a PHP warning and not an error so, again, mea culpa.

The point about having to recreate all actions still stands, but being a warning it’s not really necessary to recreate the actions anyway unless you absolutely need squeaky clean PHP logs, which the vast majority won’t. For background: I was debugging an issue with forms not pushing to Mailchimp and I had mistakenly thought that the PHP warning was what was preventing it from working (again, extreme sleep deprivation isn’t conducive to good debugging work). In actuality it was user error: some field names had changed on the form but the Mailchimp integration was still using the old field names and so was submitting empty information, the warning above had nothing to do with the observed issue. 100% my mistake.

A useful feature request for future consideration, if I may, would be to have a warning if there are field names being mapped anywhere that no longer exist on the form, so that the user knows that something is amiss. On save maybe? Something to consider, perhaps, to reduce the risk of attracting the unwarranted ire of insomniacs who are having a bad day!

Once again, my apologies, and ATB.
NetzzJD
(@netzzjd)

7 months ago
Also experiencing this issue and PHP error logs are filled with these Warnings. It’s been over 5 months since this issue was reported here. Ninja Forms 3.13.0 is the latest available. Has this fix been tested and merged yet or still in process?

Replacing:
```
isset($subject['payment_total'])
```
with:
```
!empty($subject['payment_total'])
```
appears to handle this check properly as a hotfix.

Viewing 3 replies - 1 through 3 (of 3 total)

The topic ‘Payment_total_type throwing json warning’ is closed to new replies.