Edit Orders v4.0 Support Thread

[DivaVocals]

But NOT in the edit orders code.

I've traced this back to the source and the bug is in the stock by attributes code.

I'll follow this up with the details in the appropriate forum tomorrow.

Must get sleep.... its been a loooong day.

Cheers
Rod

If the issue is in SBA (and you are going to address this on the SBA support thread), but will affect Edit Orders, could you share your findings here as well..

[lhungil]

...
Oh, while I'm on the topic, it took me a bit of head scratching to get the Discount Vouchers to work within the editor. It kept giving "Warning: The coupon code was not found in the title. The title / text of a coupon must be formated like "Discount Coupon : coupon_code :".
Sure enough, when I entered the data exactly like the warning suggests it worked as expected. ...

Not a bug.. this is how it works, and I believe the readme covers this..

Yup this is how it works (and why we added a message to tell people). Why? Because ot_coupon stores the coupon name and code as the "title" for the order total. So basically the title needs to be formatted to match what ot_coupon expects ;)

[RodG]

If the issue is in SBA (and you are going to address this on the SBA support thread), but will affect Edit Orders, could you share your findings here as well..

I'm still chasing this rabbit down the hole. .. and after following many threads it once again appears to be an Edit Orders issue and not directly related to the SBA mod.

Here's where I'm currently at:

ile: /admin/edit_orders.php


------------------ Updated to avoid the need for the strange syntax current required (my clients have a bit of a problem following the instructions, and would prefer to just enter the coupon code_


----------------- Original code ----------------------------------------
case 'ot_coupon':
preg_match('/([^:]+)[^:]+):/', $order_total['title'], $matches);
//DEBUG echo '<div>Coupon Matches</div><pre>'; var_dump($matches); echo '</pre>';
if(count($matches) > 2) {
$order_total['title'] = trim($matches[1]);
$cc_id = $db->Execute(
'SELECT coupon_id FROM `' . TABLE_COUPONS . '` ' .
'WHERE coupon_code=\'' . trim($matches[2]) . '\''
);
if(!$cc_id->EOF) $_SESSION['cc_id'] = $cc_id->fields['coupon_id'];
else {
$messageStack->add_session(WARNING_ORDER_COUPON_BAD, 'warning');
$order_total['title'] = '';
$order_total['value'] = 0;
}
}
else {
$messageStack->add_session(WARNING_ORDER_COUPON_BAD_FORMAT, 'warning');
$order_total['title'] = '';
$order_total['value'] = 0;
}


break;


------------ Replacement code ----------------------------------------------
case 'ot_coupon':
$order_total['title'] = "Discount Coupon:" . $order_total['title'] .":" ;

preg_match('/([^:]+)[^:]+):/', $order_total['title'], $matches);
//DEBUG echo '<div>Coupon Matches</div><pre>'; var_dump($matches); echo '</pre>'; die ;
$order_total['title'] = trim($matches[1]);
$cc_id = $db->Execute(
'SELECT coupon_id FROM `' . TABLE_COUPONS . '` ' .
'WHERE coupon_code=\'' . trim($matches[2]) . '\''
);


if(!$cc_id->EOF) $_SESSION['cc_id'] = $cc_id->fields['coupon_id'];
else {
$messageStack->add_session(WARNING_ORDER_COUPON_BAD, 'warning');
$order_total['title'] = '';
$order_total['value'] = 0;
}
break;
-------------------------------------------------------------------------------------


This same file /admin/edit_orders.php has a
switch($optionInfo['type']) block, with case references to:


PRODUCTS_OPTIONS_TYPE_RADIO
PRODUCTS_OPTIONS_TYPE_SELECT
PRODUCTS_OPTIONS_TYPE_TEXT
PRODUCTS_OPTIONS_TYPE_FILE
PRODUCTS_OPTIONS_TYPE_READONLY
PRODUCTS_OPTIONS_TYPE_CHECKBOX


These don't appear to be defined anywhere, so nothing matches. (bug?)


I've 'fixed' this problem by making the following edits to
/admin/includes/classes/attributes.php
(I thought this was from the SBA mod, but I've since found it to be from the Edit orders mod)


Added these defines at the beginning of the file
------------------------------------------------------------
define('PRODUCTS_OPTIONS_TYPE_RADIO', 'Radio') ;
define('PRODUCTS_OPTIONS_TYPE_SELECT', 'Dropdown');
define('PRODUCTS_OPTIONS_TYPE_TEXT', 'Text') ;
define('PRODUCTS_OPTIONS_TYPE_FILE', 'File') ;
define('PRODUCTS_OPTIONS_TYPE_READONLY', 'Read Only') ;
define('PRODUCTS_OPTIONS_TYPE_CHECKBOX', 'Checkbox') ; // is this a valid option? It doesn't appear in the database as such?
-------------------------------------------------------------


These are probably best suited in another datafile, or at the very least, add a check to ensure they don't try to get redefined.


---- replaced the get_attributes_options with this ---------------


function get_attributes_options($zf_product_id, $readonly = false) {
global $db;


$query = 'SELECT attr.products_attributes_id, attr.products_id, attr.options_id, opt.products_options_name,
type.products_options_types_name, type.products_options_types_id,
val.products_options_values_name, opt.products_options_type,
products_options_size, opt.products_options_rows ' .
'FROM ' . TABLE_PRODUCTS_ATTRIBUTES . ' AS attr ' .
'LEFT JOIN ' . TABLE_PRODUCTS_OPTIONS .
' AS opt ON attr.options_id = opt.products_options_id ' .
'LEFT JOIN ' . TABLE_PRODUCTS_OPTIONS_VALUES .
' AS val ON attr.options_values_id = val.products_options_values_id ' .
'LEFT JOIN ' . TABLE_PRODUCTS_OPTIONS_TYPES .
' AS type ON type.products_options_types_id = opt.products_options_type ' .
'WHERE attr.products_id = \'' . (int)$zf_product_id . '\' ' .
'AND val.language_id = \'' . (int)$_SESSION['languages_id'] . '\' ' .
'AND val.language_id = opt.language_id ';


// Don't include READONLY attributes if product can be added to cart without them
if(PRODUCTS_OPTIONS_TYPE_READONLY_IGNORED == '1' && $readonly === false) {
$query .= 'AND opt.products_options_type != \'' . PRODUCTS_OPTIONS_TYPE_READONLY . '\' ';
}


$query .= 'ORDER BY `opt`.`products_options_sort_order`, `attr`.`options_id`';


if($this->cache_time == 0) $queryResult = $db->Execute($query);
else $queryResult = $db->Execute($query, false, true, $this->cache_time);


$retval = array();
while (!$queryResult->EOF) {

$retval[$queryResult->fields['products_attributes_id']] = array(
'id' => $queryResult->fields['options_id'],
'name' => $queryResult->fields['products_options_name'],
'value' => $queryResult->fields['products_options_values_name'],
// 'type' => $queryResult->fields['products_options_type'],
'type' => $queryResult->fields['products_options_types_name'],


'length' => $queryResult->fields['products_options_length'],
'size' => $queryResult->fields['products_options_size'],
'rows' => $queryResult->fields['products_options_rows']
);
$queryResult->MoveNext();
}

return $retval;
}


---------------------------------------------------------------------------------------------------------


These changes seems to cure most of the problems I was having with the site I'm working on.

Cheers
Rod

[lat9]

This same file /admin/edit_orders.php has a
switch($optionInfo['type']) block, with case references to:


PRODUCTS_OPTIONS_TYPE_RADIO
PRODUCTS_OPTIONS_TYPE_SELECT
PRODUCTS_OPTIONS_TYPE_TEXT
PRODUCTS_OPTIONS_TYPE_FILE
PRODUCTS_OPTIONS_TYPE_READONLY
PRODUCTS_OPTIONS_TYPE_CHECKBOX


These don't appear to be defined anywhere, so nothing matches. (bug?)


I've 'fixed' this problem by making the following edits to
/admin/includes/classes/attributes.php
(I thought this was from the SBA mod, but I've since found it to be from the Edit orders mod)


Added these defines at the beginning of the file
------------------------------------------------------------
define('PRODUCTS_OPTIONS_TYPE_RADIO', 'Radio') ;
define('PRODUCTS_OPTIONS_TYPE_SELECT', 'Dropdown');
define('PRODUCTS_OPTIONS_TYPE_TEXT', 'Text') ;
define('PRODUCTS_OPTIONS_TYPE_FILE', 'File') ;
define('PRODUCTS_OPTIONS_TYPE_READONLY', 'Read Only') ;
define('PRODUCTS_OPTIONS_TYPE_CHECKBOX', 'Checkbox') ; // is this a valid option? It doesn't appear in the database as such?
-------------------------------------------------------------

Oh no! Don't do that! Those constants are defined in the database and provide a mapping to the products_options_types table row associated with that option name.

[RodG]

Oh no! Don't do that! Those constants are defined in the database and provide a mapping to the products_options_types table row associated with that option name.

They're NOT defined in the database of the clients site that I'm working on.

They ARE defined in the configuration database of my own test site though (not associated with the clients site).

(That's why I suggested they should probably be checked to prevent a possible redefine).

I've not figured out how or where they got defined on my site, or more importantly, why they *didn't* get defined on the clients site during whatever upgrade performed this function.

Time to follow this lead to see where it takes me. It'll probably avoid the need for those other changes I made :)

.... Other than the case 'ot_coupon' changes (which was for a different issue). If you can foresee any potential problems with that could you please let me know?

Thanks
RodG

[lat9]

They're NOT defined in the database of the clients site that I'm working on.

They ARE defined in the configuration database of my own test site though (not associated with the clients site).

(That's why I suggested they should probably be checked to prevent a possible redefine).

I've not figured out how or where they got defined on my site, or more importantly, why they *didn't* get defined on the clients site during whatever upgrade performed this function.

They've been part of the Zen Cart "standard" database install since at least v1.3.8a (I've got a client that started with v1.3.7 and the constants are in that database). What Zen Cart version did your client start out with?

[DivaVocals]

They're NOT defined in the database of the clients site that I'm working on.

They ARE defined in the configuration database of my own test site though (not associated with the clients site).

(That's why I suggested they should probably be checked to prevent a possible redefine).

I've not figured out how or where they got defined on my site, or more importantly, why they *didn't* get defined on the clients site during whatever upgrade performed this function.

Time to follow this lead to see where it takes me. It'll probably avoid the need for those other changes I made :)

.... Other than the case 'ot_coupon' changes (which was for a different issue). If you can foresee any potential problems with that could you please let me know?

Thanks
RodG

Honestly Rod, the discount coupon thing aside (which is a functional issue not a "bug"), I'm starting to wonder if the "bugs" you are finding are UNIQUE to the client site you are working on.. Otherwise it would stand to reason that others would have reported the same issues you are having..

[lhungil]

------------------ Updated to avoid the need for the strange syntax current required (my clients have a bit of a problem following the instructions, and would prefer to just enter the coupon code_

The correct stored format is "<module_title>: <coupon_code>".

Just a couple warnings about your code:

• The module title is not static (and may vary depending upon store language and / or modifications).
• Indexes on an array are not checked to verify they exist before using them (PHP 5.4+ potential issue).
• It will break when the correct full title is passed (such as a order created by the checkout process).

Most users have not had any problems understanding the warning which is printed on the top of the screen by Edit Orders and taking the appropriate action. On the other hand, I do like the idea of allowing the entry of just the coupon code. With the upcoming 4.1.3 release, I have been focusing on usability, compatibility, and automatically finding / fixing certain common database issues (caused by errant code in OTHER modules).

I'll add the updating the handling of ot_coupon to the list for Edit Orders 4.1.3. :o)

...
PRODUCTS_OPTIONS_TYPE_CHECKBOX

These don't appear to be defined anywhere, so nothing matches. (bug?)

Not a bug. These are core database entries relating to attributes in the Zen Cart database. Means the store you are working on has some serious database damage... You should re-add the appropriate entries to the database (and verify the SBA code is not incorrectly removing these).

...
---- replaced the get_attributes_options with this ---------------

Not needed if you fix the core database entries relating to attributes. Also why did you change the code to use the "product's option's type" name instead of id? What happens if in the future the names are in a localized language? Or someone changes the name?

Other Thoughts
Sounds like your client's store has a large number of modifications (both to the database and files) including damage to some of the core Zen Cart database entries relating to attributes... I cannot say what introduced these "changes", but I would make sure it was not the SBA module you are using...

You will probably want to correct the current issues in the specific store you are working on instead of modifying the "Edit Orders" code (to work around the issues specific to the client's site). Applying bandages instead of stopping the root cause could cause problems down the road (such as when a new version of Zen Cart or Edit Orders is released).



NOTES: If the SBA module includes something to indicate it's presence (like EO_VERSION identifies Edit Orders is installed and which version)... And the SBA module does not break existing Zen Cart core attribute handling... I'm more than willing to add some additional code / code blocks to help "support" the SBA module... So if you do find what exactly is changed by the SBA module during the product selection and checkout process... Contributions are welcome (but expect them to be looked at to ensure they do not introduce unnecessary risks). :o)

[RodG]

The correct stored format is "<module_title>: <coupon_code>".

Thanks.

Just a couple warnings about your code:

• The module title is not static (and may vary depending upon store language and / or modifications).
• Indexes on an array are not checked to verify they exist before using them (PHP 5.4+ potential issue).
• It will break when the correct full title is passed (such as a order created by the checkout process).

I find your 3rd point the most disconcerting. I'll need to check this before the client discovers this before I've taken steps to mitigate it :)

Most users have not had any problems understanding the warning which is printed on the top of the screen by Edit Orders and taking the appropriate action.

I could dispute this and suggest that most users simply haven't reported or commented about the issue, or that most users have probably never even attempted to use the discount coupons when editing an order. :)

On the other hand, I do like the idea of allowing the entry of just the coupon code. With the upcoming 4.1.3 release, I have been focusing on usability, compatibility, and automatically finding / fixing certain common database issues (caused by errant code in OTHER modules).

I'll add the updating the handling of ot_coupon to the list for Edit Orders 4.1.3. :o)

This is partially why I provided the info about how I 'solved' the problem and asked about the possible repercussions :)
I kinda figured that my solution was a little *too* easy.

Sounds like your client's store has a large number of modifications (both to the database and files) including damage to some of the core Zen Cart database entries relating to attributes...

You're not wrong there. This site has been a major headache since the 1st day I started working on the upgrade.
In hindsight if I were to do this one again I would have started with a fresh install of V1.5.1 and basically rebuilt it from scratch.

I can normally do such upgrade in a matter of hours. This one has had me going around in circles for weeks. (Thankfully the client has been very understanding and quite generous).

I cannot say what introduced these "changes", but I would make sure it was not the SBA module you are using...

You will probably want to correct the current issues in the specific store you are working on instead of modifying the "Edit Orders" code (to work around the issues specific to the client's site). Applying bandages instead of stopping the root cause could cause problems down the road (such as when a new version of Zen Cart or Edit Orders is released).

I agree 100%. I thought I *had* fixed all the 'current issues' (without any code patches) until this reported problem (which on first inspection appeared to be a simple bug in the code).
Thanks to you guys I now have another lead to follow up on. :)

FWIW, in regards to the missing CONSTANTS in the DB configuration table, I had a *very quick* look at this before calling it quits last night, and discovered that these entries are created (re-created?) when I went to the attributes controller and created some new entries. Alas, there still seems to be an issue (using unmodified code), so there is still a little more to the puzzle. I hope to get back onto it further later today. I suspect it is probably related to the fact that the current entries still have missing or incorrect data somewhere. At least now I have a means of comparison. :)

I seriously don't like the idea of adding bandaids/patches, especially with code modules that I'm unfamiliar with.

Cheers
Rod

[RodG]

Honestly Rod, the discount coupon thing aside (which is a functional issue not a "bug"), I'm starting to wonder if the "bugs" you are finding are UNIQUE to the client site you are working on.. Otherwise it would stand to reason that others would have reported the same issues you are having..

Wonder no more. It is most certainly unique to this clients site.
Until this thread I really wasn't sure (and arguably, could still be in doubt), because this is the 1st store in which I've had the combination of

-----------------------------------
ZenCart V1.5.1
Edit Orders 4.1.2
Super Orders 4.0.7
Stock by Attribute 1.5.1.2
-----------------------------------

Although I'm now pretty much convinced the problem(s) pertain to the store/data itself, can you (or anyone) be 100% sure that there *isn't* a bug with this specific combination of inter related modules?

Again, I will stress that I'm now of the opinion that when I find what else is amiss with the data in this store that these versions of these modules will almost certainly behave as expected. Without reporting the 'bugs' and what I've needed to do to 'fix' them I don't think I could have gotten the feedback I needed to put me back on the right track. :)

Cheers
Rod