Possible bug but not sure

[DrByte]

I also found that when I change the attribute Option Type like I did I am getting 2 new debug log files regarding the includes/functions/functions_files.php

[19-Feb-2025 10:34:57 America/Boise] Request URI: //admin/index.php?cmd=orders&page=1&oID=4&action=edit, IP address: , Language id 1
#0 //public_html//includes/functions/functions_files.php(384): zen_debug_error_handler()
#1 //public_html//admin/orders.php(885): zen_get_uploaded_file()
#2 //public_html//admin/index.php(16): require('//..')
--> PHP Warning: Undefined array key 1 in /public_html//includes/functions/functions_files.php on line 384.

[19-Feb-2025 10:57:34 America/Boise] Request URI: //admin/index.php?cmd=orders&page=1&oID=4&action=edit, IP address: , Language id 1
#0 [internal function]: zen_debug_error_handler()
#1 //public_html//includes/functions/functions_files.php(385): explode()
#2 //public_html//admin/orders.php(885): zen_get_uploaded_file()
#3 //public_html//admin/index.php(16): require('//...')
--> PHP Deprecated: explode(): Passing null to parameter #2 ($string) of type string is deprecated in //public_html//includes/functions/functions_files.php on line 385.

Those two errors are because the filename is null/blank, which is correct because no filename was stored on the order, because it wasn't a File attribute when the order was placed.

I suppose if you're going to be in the habit of changing TEXT attributes to FILE attributes after-the-fact, then you could patch the lookup by changing line 884 of orders.php:

if (zen_is_option_file($order->products[$i]['attributes'][$j]['option_id'])) { 

to

if (zen_is_option_file($order->products[$i]['attributes'][$j]['option_id']) && !empty($order->products[$i]['attributes'][$j]['value'])) { 

[DrByte]

I created a new stock item "TEST PRODUCT FOR ATTRIBUTES"
I created a new text attribute "SPECIAL ORDER ITEM DESCRIPTION"
I entered the store side and created a new order for the demo customer, checked out and logged out of the store
I accessed the invoice on the admin side as seen below:

Attachment 20914

I then go to "Option Value Manager" access the "SPECIAL ORDER ITEM DESCRIPTION", click edit and change the "Option Type" to File. I go back to the invoice that was created and find the attribute change is now reflected on the invoice line items that have already been committed as seen below:

Attachment 20916

I would expect the code that sets up the invoice interface would pull line-item data from an order database table and the option value type id would be stored against that invoice's id number, correct?

While many attribute details are indeed stored with the order, the "type" that you're changing in this case is only stored in the catalog, not the order history.

[wsworx]

Those two errors are because the filename is null/blank, which is correct because no filename was stored on the order, because it wasn't a File attribute when the order was placed.

I suppose if you're going to be in the habit of changing TEXT attributes to FILE attributes after-the-fact, then you could patch the lookup by changing line 884 of orders.php:

if (zen_is_option_file($order->products[$i]['attributes'][$j]['option_id'])) { 

to

if (zen_is_option_file($order->products[$i]['attributes'][$j]['option_id']) && !empty($order->products[$i]['attributes'][$j]['value'])) { 

I'm not sure which "filename you are referring" to.
Some of the details in the debug file I deleted to keep my site secure.
Since I did a standard order I don't know why ZC would leave a filename blank.

I don't think it is a matter of what I would be apt to do or not do so much as it being an issue with securing the invoice to a fully committed state once saved. I would find it concerning that anyone would argue with that statement when it comes to security and consistency of one's data.

[wsworx]

While many attribute details are indeed stored with the order, the "type" that you're changing in this case is only stored in the catalog, not the order history.

Shouldn't it be about data consistency and security?
You can't have full data consistency and security if details for an item like an invoice are allowed to be altered in anyway outside of a proper admin edit actions.

[swguy]

You really can't change a TEXT attribute to FILE attribute and expect existing orders that used the old type to work well.

If you actually decide, gee, this thing should really be a FILE, create a new option type, delete the old option type from the product and add the new one.

[wsworx]

You really can't change a TEXT attribute to FILE attribute and expect existing orders that used the old type to work well.

If you actually decide, gee, this thing should really be a FILE, create a new option type, delete the old option type from the product and add the new one.

I agree with you completely, but it is not about what someone expects.

But In this type of data schema nothing should be able to change critical stored data.
Only a proper edit function put in motion by an admin and then saved by that admin should be allowed to change stored data.
Something that helps define an item tied to a specific invoice tied to a specific date and Customer id should be stored data and not be able to be changed at a whim.
Especially since many of the people using this software do not understand the underlying workings of it so if they were to do something like this they likely wouldn't even know until later down the road when everything is a mess.
I am in no way trying to stir up trouble.
It's just in my mind if I was the developer of something like this, I wouldn't want this occurring anywhere on any level of my software.
If someone brought it to my attention, then I would fix it.
If I am wrong about the developers of this software, then so be it.
If I knew how to do this stuff, I would just rewrite it and submit it myself, but I am a motorcycle mechanic not a programmer lol.

[wsworx]

While many attribute details are indeed stored with the order, the "type" that you're changing in this case is only stored in the catalog, not the order history.

From my testing that is clearly obvious.
However, my question is why.
Shouldn't all data attached to an invoice that defines something on that invoice be stored in a way that makes it unique to that invoice for future audit purposes?
If the Option Type were stored with the invoice data then it can't be changed inadvertently later which is how an invoice should be once it is committed.

I don't want to beat this to death though.
If everyone thinks I should just drop it, then I am moving on.

As it stands right now, I have my ZC 2.1 site live with authorizenet_merchant_seal_2.0, customer_tax_exempt_2.0.2, edit_orders-5.0.0, sitemapxml-4.0.3, usps-USPS_2024_08_25_K11l and zen_TyPackageTracker-5.0.0 all running without any more debug files, so I am happy and appreciative of everyone's hard work.