1 Attachment(s)
Possible bug but not sure
ZC 2.1
Edit Orders 5 most recent beta release as of 2 days ago
Ty Package Tracker 5
usps-USPS_2024_08_25_K11l
uploaded via FTP and ran zc_install
Currently only getting the one debug file that is listed in this post
PHP 8.3
If I go to Admin/Catalog/Option Name Manager and create a new attribute, it can be any one of the attributes allowed, I can then see the new attribute in the Option Name Manager list.
If I go to Admin/Catalog/Option Value Manager I cannot see the new attribute in the list there.
If I run a search for it in the Option Value Manager search box nothing comes up.
No debug log files are created during these tasks.
When I access Admin/Catalog/Attributes Controller and click on the dropdown above the statement "Select a Product to View and Click Display" the following debug error log is created:
Code:
[17-Feb-2025 14:47:20 America/Boise] Request URI: //admin/index.php?cmd=attributes_controller&products_filter=181¤t_category_id=3, IP address: , Language id 1
#0 ///public_html//admin/attributes_controller.php(1962): zen_debug_error_handler()
#1 ///public_html//admin/index.php(16): require('/...')
--> PHP Warning: Undefined variable $attributes_value in ///public_html//admin/attributes_controller.php on line 1962.
When I click in the next dropdown box to select a specific inventory item a debug file is not created
When I select an attribute and option value and click "Insert" I will again get another debug file created that is a duplicate of the above.
The attribute does get added to the inventory item, it is visible on the store side and does show on the invoice on the Admin side.
The issue starts when using Edit Orders 5.
I understand that ZC does no handle troubleshooting for Plugins, but I don't believe this is an issue with the Plugin.
You can see a very in-depth description at EO5s github page HERE
The gist of the issue is that I can add a text attribute to an item on the Admin side, apply it to an item on the store side and complete checkout.
However, when I access the invoice on the Admin side, click "Edit" in the invoice window to activate Edit Orders 5 I can then access the line item via EO5's "Edit" button next to the line item and I can see the items attributes in the edit dialog box that EO5 opens. However, If I click EO5s "Add Product" button and choose that same product to add it to the invoice EO5's "Add Product to Invoice" dialog box does not display the items attributes.
Having stated all of the above I have a number of text attributes that I created a number of years ago for other products. All of those attributes work perfectly with the prospective inventory items they are assigned to and will show their attributes in both areas of EO5. If I attach one of those old attributes, understanding that they are working fine with products that were already in the database prior to upgrading to ZC 2.1, to any new inventory item I create in ZC 2.1 that attribute displays the incorrect behavior I referred to earlier.
I compared the ZC 2.0.1 admin/attributes_controller.php file to the ZC 2.1 file and found the following what appears to be a syntax error:
Attachment 20907
I tried changing the ZC 2.1 file to read the same as the 2.0.1 file but that did not change the behavior described earlier.
All of my testing seems to indicate that there is an issue with how ZC 2.1 is linking data, at least in reference to attributes, between tables since any of my older stock items that were created prior to this ZC 2.1 upgrade are working correctly in EO5 but any new attribute assignment, be it any of the old attributes created in a previous version or any new attribute just created, is not working correctly.
Thank You for your consideration.
Re: Possible bug but not sure
I haven't taken in all that you mentioned, but focussing on that particular error log warning - that was a bug and has been addressed in this issue with the solution here:
https://github.com/zencart/zencart/c...6989d14e9d9117
Hopefully that will iron out the wrinkles you've highlighted.
Re: Possible bug but not sure
Quote:
Originally Posted by
simon1066
Hi simon1066
Thank You so much for your response.
I read through and implemented the fix.
It did eliminate the debug log file I was getting.
Unfortunately, it did not solve the issue I am having where I create a TEXT attribute, I can then see that TEXT attribute in the "Option Name Manager" but I cannot see that TEXT attribute in the "Option Value Manager".
I can change it to one of the other Option Types i.e. "checkbox", "dropdown" etc and I can force it to show in the "Option Value Manager" interface by using "Select Option Name to filter Values" and it will show up but even as a different "Option Type" other than TEXT it will still not show up in the list itself that appears when you first access the "Option Value Manager" interface.
If I make the attribute a TEXT Option Type, then I cannot see it in the initial list or even it call it up via the "Select Option Name to filter Values" search box.
It is as if it does not exist at all to the Option Value Manager.
I am fairly certain this issue is what is causing the failure in EO.
None of this was an issue in previous versions of ZC so it has to be something new.
2 Attachment(s)
Re: Possible bug but not sure
Quote:
Originally Posted by
wsworx
Hi simon1066
Thank You so much for your response.
I read through and implemented the fix.
It did eliminate the debug log file I was getting.
Unfortunately, it did not solve the issue I am having where I create a TEXT attribute, I can then see that TEXT attribute in the "Option Name Manager" but I cannot see that TEXT attribute in the "Option Value Manager".
I can change it to one of the other Option Types i.e. "checkbox", "dropdown" etc and I can force it to show in the "Option Value Manager" interface by using "Select Option Name to filter Values" and it will show up but even as a different "Option Type" other than TEXT it will still not show up in the list itself that appears when you first access the "Option Value Manager" interface.
If I make the attribute a TEXT Option Type, then I cannot see it in the initial list or even it call it up via the "Select Option Name to filter Values" search box.
It is as if it does not exist at all to the Option Value Manager.
I am fairly certain this issue is what is causing the failure in EO.
None of this was an issue in previous versions of ZC so it has to be something new.
Since I conducted the above test I have now done the following and I do believe 100% now that this is a bug in ZC.
I downloaded the most recent ZC source code directly off github, setup a brand-new Demo store and let zc_install create the database and load the demo inventory.
I installed EO5, created a new inventory item and a new TEXT attribute.
I attached that new TEXT Attribute to the new inventory item.
I then installed EO5 went to the store side and created an invoice with the demo customer that comes preloaded. I get the same results with this setup as I am getting with my database.
All the exact same behavior where the "Option Type" TEXT attribute is not visible in the "Option Value Manager" interface etc.
When I open the invoice on the Admin side, open EO, click "Edit" next to the line item I can see the attributes for the line item that was entered on the store side.
But again, if I click on "Add Product" the "Add a Product to the Order" dialog opens but no attributes are displayed.
Attachment 20910
If I change the "Option Type" to any of the other types i.e. "Drop Down" then the attribute will show up. I don't recreate the invoice or anything. I just go into Option Name Manager and change the "Option Type" to "Drop Down" and then the attributes will show up in EO.
Attachment 20911
Since my TEXT attributes that were created prior to ZC2 work correctly I would think it has to be something in ZC2 and above that links the table data for Option Type TEXT has either been highly modified or deleted and this feature for Option Type TEXT has been broken.
Re: Possible bug but not sure
TEXT attributes don't show up in the option value manager. They're for user input, not a specific set of values like a dropdown.
Re: Possible bug but not sure
Quote:
Originally Posted by
swguy
TEXT attributes don't show up in the option value manager. They're for user input, not a specific set of values like a dropdown.
Okay, understood.
Then that would mean the issue I am having in EO5 is specific to EO5 and its coding.
I am working on this with lat9 in the issue section of the EO5 github but lat9 is having a hard time with it.
LOL it all started with the previous versions of EO allowing a user to enter multiple identical line items.
EO5 does not allow this.
I use one inventory item titled "Special Order".
I have many cases where a customer wants to purchase items we stock but then they need items we don't stock as well.
Sometimes this happens right while I am on the phone with them so I can just add the special order item on the store side as I input their other items.
In these cases I have to complete the order without payment so I can adjust the order at the back end for pricing and then charge them.
Other times I may have already entered their order via phone, and they call back or email me and ask me to add one or more special order items to their order.
Previously I could do this easily with EO versions prior to EO5.
I can't do this with EO5 as once the order is confirmed on the store side then you have to access it on the admin side.
EO5 will not allow you to enter more than one additional duplicate item.
Once you have added that item any additional attempts to add the item are thwarted by EO and EO's "Add Product" coding simply alters the item that was already entered.
It makes no sense to me because that is what the "Edit" button next to each line item in EO is for.
Coding for the "Add Product" button should not be performing edit functions on an existing item on the invoice.
lat9 suggested I use a TEXT attribute for the "Special Order" item.
At first it seemed like a good enough idea to get around the issue I stated above.
However, in doing so it has generated a new issue where the attribute selection will not show up if you use the "Add Product" button in EO.
If you add the "Special Order" item via the store then access that line item via the "Edit" button in EO you can see the items attributes.
If you use the "Add Product" button in EO, select that item in the search box and click "Choose" you can't see the items attributes for entry.
If I change the attribute to any other Option Type i.e. "drop down" and then use the "Add Product" button the items attributes will then appear.
Having said all of the above I have done this same setup with my own store data.
I have a text attribute that was setup years ago for entering mileage that a customer wants their new speedometer set to.
If I connect the current demo store that I have been testing in with my database, make an invoice for a test customer, access that invoice on the Admin side, open EO in the invoice, click the "Add Product" button, search for the speedometer item, click "Choose" then that item will appear in the "Add Product" dialog and it shows the items attributes. If I create a new TEXT attribute in my store database and link it to a product and then access that same test invoice that i just created, click the "Add Product" button, enter that product in the search box and click "Choose" that item will appear but not the items attributes that I just added to it. This behavior seems like ZC is not linking the TEXT attribute correctly which would make it a ZC bug not an EO bug.
Because of this it just seems like there may be an issue in ZC that is causing this to occur.
Re: Possible bug but not sure
OK so this is an Edit Orders issue not a Zen Cart issue then.
Re: Possible bug but not sure
Quote:
Originally Posted by
swguy
OK so this is an Edit Orders issue not a Zen Cart issue then.
Yes but unfortunately during all this testing I have uncovered what is most definitely a ZC bug. I have found that when you change an attributes option type that change is then reflected on invoices that already have line items committed to the invoice. No data on an invoice should be susceptible to change unless an Admin implemented that change through a documented edit. I am going to do some more testing today.
2 Attachment(s)
Re: Possible bug but not sure
Quote:
Originally Posted by
wsworx
Yes, but unfortunately during all this testing I have uncovered what is most definitely a ZC bug. I have found that when you change an attributes option type that change is then reflected on invoices that already have line items committed to the invoice. No data on an invoice should be susceptible to change unless an Admin implemented that change through a documented edit. I am going to do some more testing today.
lat9 has corrected the previous attribute issue in the latest release of Edit Orders Beta 5
However, further testing shows an issue within ZC regarding attributes:
ZC 2.1 latest code direct from github with ZC demo data loaded in database
PHP 8.3
EditOrders Beta 5 current release
customer_tax_exempt_2.0.2
usps-USPS_2024_08_25_K11l
zen_TyPackageTracker-5.0.0
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 that loads with zc_install, 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?
Re: Possible bug but not sure
[QUOTE=wsworx;1406166]
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
Code:
[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.
Code:
[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.
Re: Possible bug but not sure
Quote:
Originally Posted by
wsworx
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
Code:
[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.
Code:
[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:
PHP Code:
if (zen_is_option_file($order->products[$i]['attributes'][$j]['option_id'])) {
to
PHP Code:
if (zen_is_option_file($order->products[$i]['attributes'][$j]['option_id']) && !empty($order->products[$i]['attributes'][$j]['value'])) {
Re: Possible bug but not sure
Quote:
Originally Posted by
wsworx
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.
Re: Possible bug but not sure
Quote:
Originally Posted by
DrByte
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:
PHP Code:
if (zen_is_option_file($order->products[$i]['attributes'][$j]['option_id'])) {
to
PHP Code:
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.
Re: Possible bug but not sure
Quote:
Originally Posted by
DrByte
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.
Re: Possible bug but not sure
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.
Re: Possible bug but not sure
Quote:
Originally Posted by
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.
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.
Re: Possible bug but not sure
Quote:
Originally Posted by
DrByte
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.
