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..Quote:
Originally Posted by RodG
Printable View
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..Quote:
Originally Posted by RodG
Quote:
Originally Posted by RodG
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 ;)Quote:
Originally Posted by DivaVocals
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.Quote:
Originally Posted by DivaVocals
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
Oh no! Don't do that!:no: Those constants are defined in the database and provide a mapping to the products_options_types table row associated with that option name.Quote:
Originally Posted by RodG
They're NOT defined in the database of the clients site that I'm working on.Quote:
Originally Posted by lat9
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
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?Quote:
Originally Posted by 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..Quote:
Originally Posted by RodG
The correct stored format is "<module_title>: <coupon_code>".Quote:
Originally Posted by RodG
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)
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).Quote:
Originally Posted by RodG
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?Quote:
Originally Posted by RodG
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)
Thanks.Quote:
Originally Posted by lhungil
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 :)Quote:
Originally Posted by lhungil
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. :)Quote:
Originally Posted by lhungil
This is partially why I provided the info about how I 'solved' the problem and asked about the possible repercussions :)Quote:
Originally Posted by lhungil
I kinda figured that my solution was a little *too* easy.
You're not wrong there. This site has been a major headache since the 1st day I started working on the upgrade.Quote:
Originally Posted by lhungil
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...
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).Quote:
Originally Posted by lhungil
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
Wonder no more. It is most certainly unique to this clients site.Quote:
Originally Posted by DivaVocals
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