Use of undefined constant MODULE_PAYMENT_AUTHORIZENET_AIM_CURRENCY

zc156
vanilla install. confirm basic functionality with demo data
drop db tables
import db from backup of live db

I did fiddle around with zc_bootstrap template

Check Auth.net SIM and PP settings
Install Square payment settings

I am using SIM but AIM is also setup but disabled. Processor requires SIM use due to SAQ-A vs SAQ-A-EP differences.

Upload USPS and Fedex shipping modules
Have not uninstalled and reinstalled yet

This same error file appears several dozen times in the zc logs folder

Code:

---

[07-Jan-2019 15:37:01 America/Los_Angeles] Request URI: /156/ADMINFOLDER/modules.php?set=payment&module=square, IP address: 98.146.xxx.yyy
#1  authorizenet_aim->__construct() called at [/home/CPANEL/public_html/156/ADMINFOLDER/modules.php:195]
--> PHP Warning: Use of undefined constant MODULE_PAYMENT_AUTHORIZENET_AIM_CURRENCY - assumed 'MODULE_PAYMENT_AUTHORIZENET_AIM_CURRENCY' (this will throw an Error in a future version of PHP) in /home/chaisinf/public_html/156/includes/modules/payment/authorizenet_aim.php on line 135.

---

My thoughts are that in the __construct function that the assignment of a value to $this->gateway_currency be dependent on the gateway currency being defined. The potential problem with this is that later in the code, it seems that if the payment method is accessed while that definition is not set, that it may cause some other message to be issued. But the install of the plugin should take care of that absent definition...

So my current suggestion for the code of includes/modules/payment/authorizenet_aim.php is to change:

Code:

---

$this->gateway_currency = MODULE_PAYMENT_AUTHORIZENET_AIM_CURRENCY;

---

To:

Code:

---

if (defined('MODULE_PAYMENT_AUTHORIZENET_AIM_CURRENCY')) {
  $this->gateway_currency = MODULE_PAYMENT_AUTHORIZENET_AIM_CURRENCY;
}

---

This should be taken with a grain of salt as I haven't dug deeper into the code/situation.

But there may be some other suggestion like if it is defined to use that value otherwise use the default value of the installation?

What it does seem to include/encourage is the removal/installation of the payment module I believe which is otherwise encouraged/suggested when doing an upgrade/install?

I don't get that message on my default ZC install where I don't have a history of possibly using/installing the module in some previous cart version nor is it currently enabled/potentially being accessed...

MODULE_PAYMENT_AUTHORIZENET_AIM_CURRENCY is a new(ish) key. You have to uninstall and reinstall this module.

This issue will be detected and automatically resolved by Zen Cart in the next release for both Authorize and Authorize AIM.
See https://github.com/zencart/zencart/pull/2055

TNX

Uninstall/Reinstall AIM resolved the logfile being generated. on to USPS module logfiles now

IT SURE WOULD BE NICE IF ALL THE SETTINGS WOULD BE REMEMBERED for all these modules that always require just an uninstall/reinstall click every time there is an update.

Quote:

---

Originally Posted by RixStix

IT SURE WOULD BE NICE IF ALL THE SETTINGS WOULD BE REMEMBERED for all these modules that always require just an uninstall/reinstall click every time there is an update.

---

Indeed it was supposed to; however, there was an oversight in fixing that specifically for the authnet modules. :(

TNX DrByte.

I'm sure keeping things straight/ironed out is a monumental task that most of us average users haven't a clue.

So settings are ultimately, intended, supposed to be in a perfect world, remembered when uninstall/install USPS, FEDEX, UPS, Auth.net AIM/SIM, Square, etc during an upgrade?

Quote:

---

Originally Posted by RixStix

So settings are ultimately, intended, supposed to be in a perfect world, remembered when uninstall/install USPS, FEDEX, UPS, Auth.net AIM/SIM, Square, etc during an upgrade?

---

Bear in mind that lots of these modules are *not* part of the Zen Cart core, but are contributed by developers who generously share their work and time. So some receive more or less attention than others.

It took a lot of work to get to this point; early modules wouldn't even tell you that an uninstall-reinstall was *needed*.

But yes, the current design goal for modules like this is for changes to be transparent to users, so an uninstall/reinstall is not needed.

Quote:

---

Originally Posted by swguy

Bear in mind that lots of these modules are *not* part of the Zen Cart core, but are contributed by developers who generously share their work and time. So some receive more or less attention than others.

---

I understand that. I only indicated certain shipping and payment modules that are of significant concern. Many are core. I do try to show my appreciation to those who have shared their time.

Quote:

---

Originally Posted by swguy

It took a lot of work to get to this point; early modules wouldn't even tell you that an uninstall-reinstall was *needed*.

---

I appreciate that. None of those I mentioned had any indication that was obvious, so I didn't see any difference. There was notice that there were glitches in setup AFTER entering/exiting the edit mode. I just know from past updates that shipping/payment require that drill every time.

Quote:

---

Originally Posted by swguy

But yes, the current design goal for modules like this is for changes to be transparent to users, so an uninstall/reinstall is not needed.

---

I appreciate that too. Thank you.

Quote:

---

Originally Posted by RixStix

So settings are ultimately, intended, supposed to be in a perfect world, remembered when uninstall/install USPS, FEDEX, UPS, Auth.net AIM/SIM, Square, etc during an upgrade?

---

No, not "when uninstall/install", because "uninstall" removes the settings.

The REASON for the historical need to uninstall/reinstall was just to "add any new config settings for that module" if any were added, else the new features wouldn't work or maybe even errors would happen unexpectedly. That's it.
So the newer coding approach has been to try to ensure that if the module is missing a new config setting then just push it in quietly so there's no need to uninstall/reinstall. When we code it properly it works great. In this authnet case we missed one line of code to empower it. Argh.
But still, if you uninstall the module, you will indeed lose its settings and have to re-enter them.