Typo:
is_array
Is a function, not an array. Therefore the first [ and last] should be replaced with their () equivalent.
Line should read:
Code:if (is_array($products[$i]['attributes'])) {
Printable View
Thanks - changing the coding in that file took the error away.... but for some reason the drop down attributes are not showing up on the product page. It just says "Please Choose" but doesn't show the attributes / name / value under it.
Dev site is here:
http://www.elkkids DOT com/store2/index.php?main_page=product_info&cPath=28_47&products_id=471
compare to LIVE 1.5.0 site:
http://www.elkkids DOT com/store/index.php?main_page=product_info&cPath=28_47&products_id=471
Any ideas?
BTW - I can get the 1.5.4 code from github to show the attributes .... but the problem is that it shows ALL of the attributes stock - even if there is zero stock for the option value. I was HOPING this newer "combo" code would rectify that. If not... then I can switch back to the 1.5.4 since I know it works and the combo one apparently isn't working.
Do other attribute types show?
If so, then it would appear that the site is missing a few keys that would have been removed from sql code of other plugins. The install evolution should address/correct that issue. Other attribute types that would likely be affected would be text and file upload. Try a radio button and see if the attribute types come back. Should be able to provide the sql statement needed if the issue persists.
Also, are these product in that category also already populated in SBA?
I was trying to remember the brain twister that ends with something like, the light is green, what do you do at a stop light.
Apparently at the time of writing that line, ithe code snippet ends with arry, and so I did what is done with arrays, used the square brackets...
As seen above though and as I had locally corrected the code should use the parentheses to work as suggested/provided. I thought I had uploaded that fix, but apprently not.
Changing it to checkbox makes the attributes show up.... but unfortunately ALL the option values show up..... not just the ones that are in stock for that item
See this one:
http://www.elkkids DOT com/store2/index.php?main_page=product_info&cPath=28_2&products_id=120
Only one color is in stock.
Attachment 16600
Since other attribute types show on screen, but the classic dropdown doesn't, this seems to confirm my suspicions of a few keys being removed from the database which well... doesn't happen as much now-a-days and is reversed by installation of ZC 1.5.5 and/or running the install of this plugin.
Doing so will/should execute the query(ies) below to restore the missing attribute types (any existing variants will remain untouched, but for now the SBA configuration settings will get reset to "factory default", then after the install, you will want to change the option name type to the added SBA basic/simple dropdown to get the desired results:
Code:UPDATE configuration set configuration_group_id = 6 where configuration_key in
('PRODUCTS_OPTIONS_TYPE_SELECT', 'UPLOAD_PREFIX', 'TEXT_PREFIX');
INSERT IGNORE INTO configuration (configuration_title, configuration_key, configuration_value, configuration_description, configuration_group_id, sort_order, last_modified, date_added, use_function, set_function) VALUES ('Product option type Select', 'PRODUCTS_OPTIONS_TYPE_SELECT', '0', 'The number representing the Select type of product option.', 6, NULL, now(), now(), NULL, NULL);
INSERT IGNORE INTO configuration (configuration_title, configuration_key, configuration_value, configuration_description, configuration_group_id, sort_order, last_modified, date_added, use_function, set_function) VALUES ('Upload prefix', 'UPLOAD_PREFIX', 'upload_', 'Prefix used to differentiate between upload options and other options', 6, NULL, now(), now(), NULL, NULL);
INSERT IGNORE INTO configuration (configuration_title, configuration_key, configuration_value, configuration_description, configuration_group_id, sort_order, last_modified, date_added, use_function, set_function) VALUES ('Text prefix', 'TEXT_PREFIX', 'txt_', 'Prefix used to differentiate between text option values and other option values', 6, NULL, now(), now(), NULL, NULL);
I am in the process of upgrading a site from ZC 1.3.9d to 1.5.5a. Because upgrades have not been done progressively (amongst other no,no,no's), I am now faced with making SBA workable on the updated site.
Downloaded the latest version of SBA combined from Github.
Question: How does the new installer supposed to be handled? I just see the file admin/stock_by_attr_install.php to effect this.
Am I supposed to run the file stock_by_attr_install.php manually or what is the intention (can't find any updated documentation for this version on Github)?
TIA / Frank
There has been no change in the intention of running the install file from any previous documentation. It is not installed or updated without accessing that file and choosing to upgrade/install. The sba variant table if it exists will remain and if it requires modifications (none made since potteryhouse's version of 1.5.3) then those will be applied. Otherwise the general instructions provided by the documentation for sba at pottryhouse's github still apply. There just is more functionality available now.
Does the potteryhouse version get the "out of stock" attributes not to show up in the dropdown - like the older version of SBA used with 1.5.0?
For some reason the combo version still shows all the option values - marked "out of stock", but would prefer it if any option value is not in stock that it just doesn't show up. Am I missing a configuration somewhere?
I have to go back and 1) look at the current code and 2) look at changes that were made. For some reason I recall a constant being used to do that, but it was based on the store as a whole and I thought I didn't see the relationship. I say this because in navigating the demo site I saw that product were desired to remain displayed even if the product was out-of-stock. Because of that, SBA would require a separate setting than what the store has. Ie. Store allows out-of-stock product to be displayed, while SBA product option listings would hide the display of out-of-stock attribute options.
Such capability already exists when using dynamic dropdowns for the applicable quantity of option names (attributes). Thing is I haven't done much if anything to make sure that the multiple attributes options settings (to be used for product having a single option name) is fully functional. I saw problems with it early on but since potteryhouse had a functional version didn't see the need to modify that code especially if someone already had it reworked and transferred their version to their new/upgraded site.
In my tests yesterday (not 100% exhaustive) I came across the same issue you described that the attribute options continued to display even when the attribute option was out-of-stock. Now, that said and because the sql query posted here was run instead of the install, it appears that some settings are not in place/set to prevent selection of an out-of-stock attribute. What was seen was that an item that is out-of-stock could be selected, and an attempt made to add to the cart which would guide the individual to an empty cart without a notification (issue that existed in ZC 1.5.4)
On the 1.5.0 site that I am upgrading... the "not in stock" attributes don't show up - and if there is just one attribute left that has a stock amount, the item shows up as a radio button instead of a dropdown.
I definitely need this capability, because my client is NOT going to be happy seeing the "out of stock" ones displayed. Any suggestions on what I should do from here?
Thanks Chad for your assistance!
@stellarweb:
In admin/stock_by_attr_install.php
Find Lines 741-743:
And modify to below (changing the end of the last line to remove the "; in red) and adding below it (in blue):Code:('SBA Display Attributes Images', 'SBA_SHOW_IMAGE_ON_PRODUCT_INFO', '1',
'Allow swap of the attribute image with the main image or prevent the display of the Attribute Image (and allow swap) on the product information page:<br /><br /> Default: 1 (Swap and display)<br />0 - No swap, display image ZC default<br />1 - Swap and display attr img<br />2 - Swap, but hide attribute image',
9,".$result.",now(),null,'zen_cfg_select_option(array(\'0\', \'1\', \'2\'),'),";
To add/install the above without going through the install process (not recommended to go this way unless the install process has been followed as included in the most recent version):Code:('SBA Display Attributes Images', 'SBA_SHOW_IMAGE_ON_PRODUCT_INFO', '1',
'Allow swap of the attribute image with the main image or prevent the display of the Attribute Image (and allow swap) on the product information page:<br /><br /> Default: 1 (Swap and display)<br />0 - No swap, display image ZC default<br />1 - Swap and display attr img<br />2 - Swap, but hide attribute image',
9,".$result.",now(),null,'zen_cfg_select_option(array(\'0\', \'1\', \'2\'),'),
('SBA Display Non-DD Out-of-Stock Attributes', 'SBA_SHOW_OUT_OF_STOCK_ATTR_ON_PRODUCT_INFO', '1',
'Allow display of attributes that are out-of-stock and are not managed by Dynamic Dropdowns.<br /><br /> Default: 1 (Show out-of-stock attributes)<br />0 - Hide out-of-stock attributes<br />1 - Show out-of-stock attributes',
9,".$result.",now(),null,'zen_cfg_select_option(array(\'0\', \'1\'),'),";
If the above query doesn't add the new option, then more than likely the configuration_key in the first query doesn't exist which is a key in the configuration of the plugin that is installed when running the install process. Which would be further more reason to go back to incorporate the above code (if not already updated in the install package) and run the installation.Code:SELECT @sortorder := c.sort_order
FROM configuration c WHERE c.configuration_group_id = 9 AND configuration_key = 'STOCK_SET_SBA_SEARCHBOX';
INSERT INTO `configuration` (configuration_title, configuration_key, configuration_value,
configuration_description, configuration_group_id, sort_order,
date_added, use_function, set_function)
VALUES
('SBA Display Non-DD Out-of-Stock Attributes', 'SBA_SHOW_OUT_OF_STOCK_ATTR_ON_PRODUCT_INFO', '1',
'Allow display of attributes that are out-of-stock and are not managed by Dynamic Dropdowns.<br /><br /> Default: 1 (Show out-of-stock attributes)<br />0 - Hide out-of-stock attributes<br />1 - Show out-of-stock attributes',
9, @sortorder,now(),null,'zen_cfg_select_option(array(\'0\', \'1\'),');
Then to take advantage of the above setting, modify the store front code as below:
In includes/classes/observers/class.products_with_attributes_stock.php
beginning at line 326 find:
Change to:Code:$sql = "select distinct pov.products_options_values_id,
pov.products_options_values_name,
pa.*, p.products_quantity,
" . (($this->_products_options_names_count <= 1 || ($process_this == true && isset($noread) && $noread->fields['total'] == 1))? " pas.stock_id as pasid, pas.quantity as pasqty, pas.sort, pas.customid, pas.title, pas.product_attribute_combo, pas.stock_attributes, " : "") . " pas.products_id
from " . TABLE_PRODUCTS_ATTRIBUTES . " pa
left join " . TABLE_PRODUCTS_OPTIONS_VALUES . " pov on (pa.options_values_id = pov.products_options_values_id)
left join " . TABLE_PRODUCTS . " p on (pa.products_id = p.products_id)
left join " . TABLE_PRODUCTS_WITH_ATTRIBUTES_STOCK . " pas on
(p.products_id = pas.products_id and FIND_IN_SET(pa.products_attributes_id, pas.stock_attributes) > 0 )
where pa.products_id = :products_id:
and pa.options_id = :options_id:
and pov.language_id = :languages_id: " .
$order_by;
Reasoning or explanation of the added SQL statement portion.Code:$sql = "select distinct pov.products_options_values_id,
pov.products_options_values_name,
pa.*, p.products_quantity,
" . (($this->_products_options_names_count <= 1 || ($process_this == true && isset($noread) && $noread->fields['total'] == 1))? " pas.stock_id as pasid, pas.quantity as pasqty, pas.sort, pas.customid, pas.title, pas.product_attribute_combo, pas.stock_attributes, " : "") . " pas.products_id
from " . TABLE_PRODUCTS_ATTRIBUTES . " pa
left join " . TABLE_PRODUCTS_OPTIONS_VALUES . " pov on (pa.options_values_id = pov.products_options_values_id)
left join " . TABLE_PRODUCTS . " p on (pa.products_id = p.products_id)
left join " . TABLE_PRODUCTS_WITH_ATTRIBUTES_STOCK . " pas on
(p.products_id = pas.products_id and FIND_IN_SET(pa.products_attributes_id, pas.stock_attributes) > 0 )
where pa.products_id = :products_id:
and pa.options_id = :options_id:
and pov.language_id = :languages_id: " .
((($this->_products_options_names_count <= 1 || ($process_this == true && isset($noread) && $noread->fields['total'] == 1)) && defined('SBA_SHOW_OUT_OF_STOCK_ATTR_ON_PRODUCT_INFO') && SBA_SHOW_OUT_OF_STOCK_ATTR_ON_PRODUCT_INFO == '0' && (PRODINFO_ATTRIBUTE_DYNAMIC_STATUS !=1 && PRODINFO_ATTRIBUTE_DYNAMIC_STATUS !=3)) ? " AND (pas.quantity > '0' OR (pas.quantity IS NULL AND pa.attributes_display_only = '1')) ": "" ) .
$order_by;
The test logic is,
- basically if querying data to apply to the Option name type of SBA Select List (Dropdown) Basic (single effective option name) and single option name product are not controlled by dynamic dropdowns then want to show only items that have a quantity greater than 0 or if the attribute (option value for this product) is marked as display only. By default SBA doesn't count display only attributes as having stock therefore, the query result of the tables being "merged" is NULL so test for that against all of the other factors as well.
This particular statement may need to be modified further down the road as someone points out a flaw with it, but for now it works for the following condition:
A product that has a single attribute with multiple option values,
one of the option values being display only,
variants are populated in the SBA table for each of the assigned attributes except for one of the stockable attributes (and not for the display only attribute),
one of the variants of the product has a 0 quantity the rest have a quantity greater than 0.
The variant with 0 quantity is hidden as applicable to the admin setting that is added to the configuration->Stock menu. With the newly added SBA option set to hide out-of-stock product, the deleted variant does not appear in the dropdown, though prior to this revision, the non-variant attribute (one that was deleted from the SBA table) would appear in the list, but would not be successfully added to the cart, so that may need to still be addressed somewhat separately. The above SQL pretty much takes care of that in a round about way and the option may be applied, but for now was trying to address the issue desired to be resolved. I can't say that I searched high and low for the historical background, but I also seem to recall that with moving code out of the attributes file that there perhaps was an option that didn't follow because of having to carry over information from one location to another, but this did the trick. :)
Besides the suggested modification provided above (which will allow acting as described as desired), might look into if the old store has an updated includes/classes/pad_multiple_dropdowns.php file (updated is something of a relative term, but applies to the file being different than what is provided in this package).
What was provided in this package is nearly the exact same thing that has been available for years as a separate plugin but is currently merged to an extent into this plugin to try to maintain some semblance of consistency and continue to provide a means to keep an existing front end but improved backend of the program.
Forgot to include applicable deletion code. The deletion code should be applied (because of line numbers) after the insertion code has been incorporated when working with the file directly. Plan is to push all of this information into a single commit to github which is not possible in my current computing environment.
In admin/stock_by_attr_install.php
Find Lines 741-743:
And modify to below (changing the end of the last line to remove the "; in red) and adding below it (in blue):Code:('SBA Display Attributes Images', 'SBA_SHOW_IMAGE_ON_PRODUCT_INFO', '1',
'Allow swap of the attribute image with the main image or prevent the display of the Attribute Image (and allow swap) on the product information page:<br /><br /> Default: 1 (Swap and display)<br />0 - No swap, display image ZC default<br />1 - Swap and display attr img<br />2 - Swap, but hide attribute image',
9,".$result.",now(),null,'zen_cfg_select_option(array(\'0\', \'1\', \'2\'),'),";
To add/install the above without going through the install process (not recommended to go this way unless the install process has been followed as included in the most recent version) [modified to advise how/where to apply the sql] after logging into the admin area goto tools->Install SQL Patches and paste the following:Code:('SBA Display Attributes Images', 'SBA_SHOW_IMAGE_ON_PRODUCT_INFO', '1',
'Allow swap of the attribute image with the main image or prevent the display of the Attribute Image (and allow swap) on the product information page:<br /><br /> Default: 1 (Swap and display)<br />0 - No swap, display image ZC default<br />1 - Swap and display attr img<br />2 - Swap, but hide attribute image',
9,".$result.",now(),null,'zen_cfg_select_option(array(\'0\', \'1\', \'2\'),'),
('SBA Display Non-DD Out-of-Stock Attributes', 'SBA_SHOW_OUT_OF_STOCK_ATTR_ON_PRODUCT_INFO', '1',
'Allow display of attributes that are out-of-stock and are not managed by Dynamic Dropdowns.<br /><br /> Default: 1 (Show out-of-stock attributes)<br />0 - Hide out-of-stock attributes<br />1 - Show out-of-stock attributes',
9,".$result.",now(),null,'zen_cfg_select_option(array(\'0\', \'1\'),'),";
If the above query doesn't add the new option, then more than likely the configuration_key in the first query doesn't exist which is a key in the configuration of the plugin that is installed when running the install process. Which would be further more reason to go back to incorporate the above code (if not already updated in the install package) and run the installation.Code:SELECT @sortorder := c.sort_order
FROM configuration c WHERE c.configuration_group_id = 9 AND configuration_key = 'STOCK_SET_SBA_SEARCHBOX';
INSERT INTO `configuration` (configuration_title, configuration_key, configuration_value,
configuration_description, configuration_group_id, sort_order,
date_added, use_function, set_function)
VALUES
('SBA Display Non-DD Out-of-Stock Attributes', 'SBA_SHOW_OUT_OF_STOCK_ATTR_ON_PRODUCT_INFO', '1',
'Allow display of attributes that are out-of-stock and are not managed by Dynamic Dropdowns.<br /><br /> Default: 1 (Show out-of-stock attributes)<br />0 - Hide out-of-stock attributes<br />1 - Show out-of-stock attributes',
9, @sortorder,now(),null,'zen_cfg_select_option(array(\'0\', \'1\'),');
Then to take advantage of the above setting, modify the store front code as below:
In includes/classes/observers/class.products_with_attributes_stock.php
beginning at line 326 find:
Change to:Code:$sql = "select distinct pov.products_options_values_id,
pov.products_options_values_name,
pa.*, p.products_quantity,
" . (($this->_products_options_names_count <= 1 || ($process_this == true && isset($noread) && $noread->fields['total'] == 1))? " pas.stock_id as pasid, pas.quantity as pasqty, pas.sort, pas.customid, pas.title, pas.product_attribute_combo, pas.stock_attributes, " : "") . " pas.products_id
from " . TABLE_PRODUCTS_ATTRIBUTES . " pa
left join " . TABLE_PRODUCTS_OPTIONS_VALUES . " pov on (pa.options_values_id = pov.products_options_values_id)
left join " . TABLE_PRODUCTS . " p on (pa.products_id = p.products_id)
left join " . TABLE_PRODUCTS_WITH_ATTRIBUTES_STOCK . " pas on
(p.products_id = pas.products_id and FIND_IN_SET(pa.products_attributes_id, pas.stock_attributes) > 0 )
where pa.products_id = :products_id:
and pa.options_id = :options_id:
and pov.language_id = :languages_id: " .
$order_by;
The deletion code is to locate in:Code:$sql = "select distinct pov.products_options_values_id,
pov.products_options_values_name,
pa.*, p.products_quantity,
" . (($this->_products_options_names_count <= 1 || ($process_this == true && isset($noread) && $noread->fields['total'] == 1))? " pas.stock_id as pasid, pas.quantity as pasqty, pas.sort, pas.customid, pas.title, pas.product_attribute_combo, pas.stock_attributes, " : "") . " pas.products_id
from " . TABLE_PRODUCTS_ATTRIBUTES . " pa
left join " . TABLE_PRODUCTS_OPTIONS_VALUES . " pov on (pa.options_values_id = pov.products_options_values_id)
left join " . TABLE_PRODUCTS . " p on (pa.products_id = p.products_id)
left join " . TABLE_PRODUCTS_WITH_ATTRIBUTES_STOCK . " pas on
(p.products_id = pas.products_id and FIND_IN_SET(pa.products_attributes_id, pas.stock_attributes) > 0 )
where pa.products_id = :products_id:
and pa.options_id = :options_id:
and pov.language_id = :languages_id: " .
((($this->_products_options_names_count <= 1 || ($process_this == true && isset($noread) && $noread->fields['total'] == 1)) && defined('SBA_SHOW_OUT_OF_STOCK_ATTR_ON_PRODUCT_INFO') && SBA_SHOW_OUT_OF_STOCK_ATTR_ON_PRODUCT_INFO == '0' && (PRODINFO_ATTRIBUTE_DYNAMIC_STATUS !=1 && PRODINFO_ATTRIBUTE_DYNAMIC_STATUS !=3)) ? " AND (pas.quantity > '0' OR (pas.quantity IS NULL AND pa.attributes_display_only = '1')) ": "" ) .
$order_by;
admin/stock_by_attr_install.php at or around lines 324-330.
and keep that plus add the following (blue):Code:
$sql = "DELETE IGNORE FROM `".TABLE_CONFIGURATION."` WHERE `configuration_key` = 'ATTRIBUTES_SBA_DISPLAY_CUSTOMID'";
$db->Execute($sql);
if($db->error){
$msg = ' Error Message: ' . $db->error;
}
array_push($resultMmessage, '• Deleted ATTRIBUTES_SBA_DISPLAY_CUSTOMID ' . $msg);
To delete the key directly (ie if attempting this in a test environment where the install sql has been entered in the code and then the plugin has been uninstalled or attempted to be installed again without having the above removal code or basically if receive a myDebug error that indicates that the key 'SBA_SHOW_OUT_OF_STOCK_ATTR_ON_PRODUCT_INFO' already exists), then from within the tools->Install SQL Patches area enter the following:Code:
$sql = "DELETE IGNORE FROM `".TABLE_CONFIGURATION."` WHERE `configuration_key` = 'ATTRIBUTES_SBA_DISPLAY_CUSTOMID'";
$db->Execute($sql);
if($db->error){
$msg = ' Error Message: ' . $db->error;
}
array_push($resultMmessage, '• Deleted ATTRIBUTES_SBA_DISPLAY_CUSTOMID ' . $msg);
$sql = "DELETE IGNORE FROM `".TABLE_CONFIGURATION."` WHERE `configuration_key` = 'SBA_SHOW_OUT_OF_STOCK_ATTR_ON_PRODUCT_INFO'";
$db->Execute($sql);
if($db->error){
$msg = ' Error Message: ' . $db->error;
}
array_push($resultMmessage, '• Deleted SBA_SHOW_OUT_OF_STOCK_ATTR_ON_PRODUCT_INFO ' . $msg);
Code:DELETE IGNORE FROM configuration WHERE `configuration_key` = 'SBA_SHOW_OUT_OF_STOCK_ATTR_ON_PRODUCT_INFO';
Your recommended changes did the trick!!! WHOO HOO!! Thank you so much!! :hug:
FYI, thinking about it a little more, READ ONLY attributes (Option Name having the Read Only type) are or can be negatively impacted by the above code and herein is where things really start getting complex (if it hasn't already) and one reason why dynamic dropdowns doesn't yet offer read only attributes. Also in review, it appears that GRID related product may be affected as well, so I've made the below modification to the new query that is found in the includes/classes/observers/class.products_with_attributes_stock.php file.
Trying to add the maximum usage of this "feature" with minimal impact on other potential uses of SBA and without forcing too many hoops to be jumped through (ie. readonly option values being marked as display only which is kind of unnecessary since they are already for display, but it does appear that some have used it for other things based on code remnants and options). Funny thing about it though, is that so many have striven to be able to show out-of-stock attributes and here's a case where it is desired to not show them. :)
In admin/stock_by_attr_install.php
Find Lines 741-743:
And modify to below (changing the end of the last line to remove the "; in red) and adding below it (in blue):Code:('SBA Display Attributes Images', 'SBA_SHOW_IMAGE_ON_PRODUCT_INFO', '1',
'Allow swap of the attribute image with the main image or prevent the display of the Attribute Image (and allow swap) on the product information page:<br /><br /> Default: 1 (Swap and display)<br />0 - No swap, display image ZC default<br />1 - Swap and display attr img<br />2 - Swap, but hide attribute image',
9,".$result.",now(),null,'zen_cfg_select_option(array(\'0\', \'1\', \'2\'),'),";
To add/install the above without going through the install process (not recommended to go this way unless the install process has been followed as included in the most recent version) [modified to advise how/where to apply the sql] after logging into the admin area goto tools->Install SQL Patches and paste the following:Code:('SBA Display Attributes Images', 'SBA_SHOW_IMAGE_ON_PRODUCT_INFO', '1',
'Allow swap of the attribute image with the main image or prevent the display of the Attribute Image (and allow swap) on the product information page:<br /><br /> Default: 1 (Swap and display)<br />0 - No swap, display image ZC default<br />1 - Swap and display attr img<br />2 - Swap, but hide attribute image',
9,".$result.",now(),null,'zen_cfg_select_option(array(\'0\', \'1\', \'2\'),'),
('SBA Display Non-DD Out-of-Stock Attributes', 'SBA_SHOW_OUT_OF_STOCK_ATTR_ON_PRODUCT_INFO', '1',
'Allow display of attributes that are out-of-stock and are not managed by Dynamic Dropdowns.<br /><br /> Default: 1 (Show out-of-stock attributes)<br />0 - Hide out-of-stock attributes<br />1 - Show out-of-stock attributes',
9,".$result.",now(),null,'zen_cfg_select_option(array(\'0\', \'1\'),'),";
If the above query doesn't add the new option, then more than likely the configuration_key in the first query doesn't exist which is a key in the configuration of the plugin that is installed when running the install process. Which would be further more reason to go back to incorporate the above code (if not already updated in the install package) and run the installation.Code:SELECT @sortorder := c.sort_order
FROM configuration c WHERE c.configuration_group_id = 9 AND configuration_key = 'STOCK_SET_SBA_SEARCHBOX';
INSERT INTO `configuration` (configuration_title, configuration_key, configuration_value,
configuration_description, configuration_group_id, sort_order,
date_added, use_function, set_function)
VALUES
('SBA Display Non-DD Out-of-Stock Attributes', 'SBA_SHOW_OUT_OF_STOCK_ATTR_ON_PRODUCT_INFO', '1',
'Allow display of attributes that are out-of-stock and are not managed by Dynamic Dropdowns.<br /><br /> Default: 1 (Show out-of-stock attributes)<br />0 - Hide out-of-stock attributes<br />1 - Show out-of-stock attributes',
9, @sortorder,now(),null,'zen_cfg_select_option(array(\'0\', \'1\'),');
Then to take advantage of the above setting, modify the store front code as below:
In includes/classes/observers/class.products_with_attributes_stock.php
beginning at line 326 find:
Change to:Code:$sql = "select distinct pov.products_options_values_id,
pov.products_options_values_name,
pa.*, p.products_quantity,
" . (($this->_products_options_names_count <= 1 || ($process_this == true && isset($noread) && $noread->fields['total'] == 1))? " pas.stock_id as pasid, pas.quantity as pasqty, pas.sort, pas.customid, pas.title, pas.product_attribute_combo, pas.stock_attributes, " : "") . " pas.products_id
from " . TABLE_PRODUCTS_ATTRIBUTES . " pa
left join " . TABLE_PRODUCTS_OPTIONS_VALUES . " pov on (pa.options_values_id = pov.products_options_values_id)
left join " . TABLE_PRODUCTS . " p on (pa.products_id = p.products_id)
left join " . TABLE_PRODUCTS_WITH_ATTRIBUTES_STOCK . " pas on
(p.products_id = pas.products_id and FIND_IN_SET(pa.products_attributes_id, pas.stock_attributes) > 0 )
where pa.products_id = :products_id:
and pa.options_id = :options_id:
and pov.language_id = :languages_id: " .
$order_by;
Code:$sql = "select distinct pov.products_options_values_id,
pov.products_options_values_name,
pa.*, p.products_quantity,
" . (($this->_products_options_names_count <= 1 || ($process_this == true && isset($noread) && $noread->fields['total'] == 1))? " pas.stock_id as pasid, pas.quantity as pasqty, pas.sort, pas.customid, pas.title, pas.product_attribute_combo, pas.stock_attributes, " : "") . " pas.products_id
from " . TABLE_PRODUCTS_ATTRIBUTES . " pa
left join " . TABLE_PRODUCTS_OPTIONS_VALUES . " pov on (pa.options_values_id = pov.products_options_values_id)
left join " . TABLE_PRODUCTS . " p on (pa.products_id = p.products_id)
left join " . TABLE_PRODUCTS_WITH_ATTRIBUTES_STOCK . " pas on
(p.products_id = pas.products_id and FIND_IN_SET(pa.products_attributes_id, pas.stock_attributes) > 0 )
where pa.products_id = :products_id:
and pa.options_id = :options_id:
and pov.language_id = :languages_id: " .
((($this->_products_options_names_count <= 1 || ($process_this == true && isset($noread) && $noread->fields['total'] == 1)) && defined('SBA_SHOW_OUT_OF_STOCK_ATTR_ON_PRODUCT_INFO') && SBA_SHOW_OUT_OF_STOCK_ATTR_ON_PRODUCT_INFO == '0' && (PRODINFO_ATTRIBUTE_DYNAMIC_STATUS !=1 && PRODINFO_ATTRIBUTE_DYNAMIC_STATUS !=3) && $products_options_name->fields['products_options_type'] != PRODUCTS_OPTIONS_TYPE_READONLY && (defined('PRODUCTS_OPTIONS_TYPE_GRID') ? $products_options_name->fields['products_options_type'] != PRODUCTS_OPTIONS_TYPE_GRID : true)) ? " AND (pas.quantity > '0' OR (pas.quantity IS NULL AND pa.attributes_display_only = '1')) ": "" ) .
$order_by;
The deletion code is to locate in:
admin/stock_by_attr_install.php at or around lines 324-330.
and keep that plus add the following (blue):Code:
$sql = "DELETE IGNORE FROM `".TABLE_CONFIGURATION."` WHERE `configuration_key` = 'ATTRIBUTES_SBA_DISPLAY_CUSTOMID'";
$db->Execute($sql);
if($db->error){
$msg = ' Error Message: ' . $db->error;
}
array_push($resultMmessage, '• Deleted ATTRIBUTES_SBA_DISPLAY_CUSTOMID ' . $msg);
To delete the key directly (ie if attempting this in a test environment where the install sql has been entered in the code and then the plugin has been uninstalled or attempted to be installed again without having the above removal code or basically if receive a myDebug error that indicates that the key 'SBA_SHOW_OUT_OF_STOCK_ATTR_ON_PRODUCT_INFO' already exists), then from within the tools->Install SQL Patches area enter the following:Code:
$sql = "DELETE IGNORE FROM `".TABLE_CONFIGURATION."` WHERE `configuration_key` = 'ATTRIBUTES_SBA_DISPLAY_CUSTOMID'";
$db->Execute($sql);
if($db->error){
$msg = ' Error Message: ' . $db->error;
}
array_push($resultMmessage, '• Deleted ATTRIBUTES_SBA_DISPLAY_CUSTOMID ' . $msg);
$sql = "DELETE IGNORE FROM `".TABLE_CONFIGURATION."` WHERE `configuration_key` = 'SBA_SHOW_OUT_OF_STOCK_ATTR_ON_PRODUCT_INFO'";
$db->Execute($sql);
if($db->error){
$msg = ' Error Message: ' . $db->error;
}
array_push($resultMmessage, '• Deleted SBA_SHOW_OUT_OF_STOCK_ATTR_ON_PRODUCT_INFO ' . $msg);
Code:DELETE IGNORE FROM configuration WHERE `configuration_key` = 'SBA_SHOW_OUT_OF_STOCK_ATTR_ON_PRODUCT_INFO';
I'm updating SbyA with the most recent github files (downloaded today, Aug 22 2016) and I threw in the change in the autoinstall from a few posts back.
I am currently using zc 1.5.5a and ResponsiveSheffiledBlue adapted to 1.5.5a with changes suggested by rbarbour, drB and others.
There are two files: admin/incl/init_incl/initzc154compatability and admin/autoinstallers/config154compatability.
Do I/should I keep those two files, or remove - ie are they applicable only to 1.5.4 or "1.5.4 and later"
Actually, neither. :) they are to provide compatibility of older ZC versions to work (at least in part) with software written for plugins to be compatible with ZC 1.5.4 and higherto less than ZC 1.5. that use functionality that was added in ZC 1.5.4 (admin database change logging). In other words, they are non-essential for plugins running on ZC 1.5.4 and above and can be safely removed from a store that includes all of the functionality of an existing ZC 1.5.4 store (or higher).
I've got SBA Version 1.5.4 for Zen Cart Version 1.5.4 and it's been running fine for months.
Today, I've added a downloadable product but can't add it to the shopping cart. I get 'Your shopping cart is empty'. Error log says:
PHP Warning: Missing argument 1 for queryFactoryResult::__construct(), called in /home/ACCOUNT_NAME/public_html/includes/templates/herbally/templates/tpl_modules_attributes.php on line 28 and defined in /home/ACCOUNT_NAME/public_html/includes/classes/db/mysql/query_factory.php on line 550
I've checked the product is set-up correctly for a downloadable product.
I was a little unclear if the option value needed to get set to Read Only or not, so tried both.
Suggest trying one of the updated versions of the file which can be found in the main install. The file in question is as reported: includes/templates/YOUR_TEMPLATE/templates/tpl_modules_attributes.php. That file was updated in April of this year to address that particular error. At least as things appear in the history for that file and that line number... Though not entirely sure how that error plays into the adding of the product to the cart. Further, think would need more information about how things are setup in order to advise further on a downloadable only product, especially with having an older version of the file(s).
I had been using the more recent version from the ZC 1.5.4 series. I tried the 1.5.5 version but same problem.
Attached are how I've got the product set-up.
My confusion is this is not an SBA attribute, so it should just ignore it. I feel like I missing something that expresses this.
Attachment 16645
Attachment 16646
Attachment 16647
Well, I would actually say that something else is installed that is interfering.
Reason is, the error shown on the previous post at line 28 of includes/templates/YOUR_TEMPLATE/templates/tpl_modules_attributes.php for the version of the file between April and about June of this year began passing the database credentials for generation of the queryfactoryresult class variable. This only became necessary in ZC 1.5.5 because of changes made to includes/classes/db/mysql/query_factory.php. In previous versions of ZC, that variable was not needed, and in fact if it was passed to the function, would be ignored by a default install because it would be an excess parameter that is/was not handled by ZC and therefore would not cause a problem. If though, that zc file were replaced by some other plugin, the additional variable may become necessary and if the template file of the current set was used, it would attempt to pass it properly and not through an error.
That said and as questioned, the line 28 code would only be run if the product for any of many different reasons was not to be displayed as a SBA tracked product, one that matters specifically to adding the product to the shopping cart is whether the products_id is listed at all in the products_with_attributes_stock table (all such entries appear in the admin control screen for SBA under the catalog dropdown).
Now, the other thing, which was an issue with ZC 1.5.4, is that there are error messages not pushed to the screen when there is a problem with adding product to the cart. Unfortunately I don't recall the specific work around that was necessary, but it may be addressed in the known issues with ZC 1.5.4. I do know that Ajeh had weighed in on the matter in one of the past/previous threads.
Beyond that, SBA doesn't evaluate any of the settings shown in the previous images in relation to non-SBA tracked product (products_id not identified in the PWAS table), so the issue would not specifically be with SBA processing, but instead something else that has been done/installed and that a file modified by SBA is showing the result of that other change.
It is something I have wanted to remove so that code like what is found on your version of the template file is no longer "necessary" as it was added at one point to make the file "easier" to follow and require less alternate/additional code. Now it just seems to complicate modification and be seen as the reason for some other mistake unrelated to SBA.
While I was using SBA Version 1.5.4, it was an older version of that version. It was one of the early versions from GitHub. I've updated the installed version to the current one from GitHub and problem solved. I never bothered to update it as everything was working fine. You know, "if it ain't broke, don't fix it". Hope it helps someone else.
I'm sorry if this has been asked already, but I'm getting duplication of attribute options on the frontend. Not sure why this is happening. I attached some images for you to check out. It also says GREY with any size is out of stock which is not how I have it set up. Let me know if anything is set up wrong. Running ZC 1.5.4. Thanks!
Attachment 16660
Attachment 16661
Attachment 16662
That type of duplication was seen with the version that was provided for download in the plugins area, but is corrected in the version discussed over the last several pages and is to make its way to the plugins once a few other improvements are made to expand its functionality and interoperation with other "typical" software.
Anyways, suggestion is to apply the software available at https://github.com/mc12345678/Stock_...butes_Combined. The files in the includes and admin directories should be applied first (merged as applicable), then to go into the sub-folder for your version of ZC and the files/changes also applied/merged with your template.
Well, actually it was a problem identified when trying to further it's use in more recent ZC versions and maintain operability of multiple option names such as you have setup. There are a number of other improvements made since that time as well. Not so sure that the particular issue would have been easy to find in the thread.
If anything, might have suggested reading through these last couple of pages to get an idea of the status of the software and what is going on to keep it accessible to those that wish to use it. :) the images were informative to at least identify my suspicions that it was occurring because of use of the older version(s).
Besides, if don't ask a question, may not ever find an answer. :)
Quick question, I've upgraded a site to the current version of this plug-in which solved some issues. Out of Stock attributes are identified as such in the drop down but are still selectable. Is having them grayed out and not selectable a setting I'm missing?
Difficult to answer without more information: product attributes, one option name or more than one, dynamic dropdowns enabled only for multiple attributes? What are the first three stock settings? Is it allowed for one to checkout with product being out of stock? If you were to say that the designation of out-of-stock wasn't present, then would suggest verifying the option name type.
You can't read what I'm thinking? Probably better than way....
Product has a single attribute, size.
dynamic dropdowns enabled only for multiple attributes: yes.
Check stock level: true
Subtract stock: true
Allow Checkout: false
The option is listed at out of stock, so I can select it, but cannot add it to the cart successfully. I get an empty cart. So the issue is just the missing disabled="disabled" on the attribute option.
I see this referenced it two files:
\includes\classes\observers\class.products_with_attributes_stock.php
\includes\modules\YOUR_TEMPLATE\attributes.php
and confirmed the correct and current version is on the server.
Well, those settings should result in an out-of-stock product being disabled if using the SBA select list as the option name type for that product.
In a search of the github repo the use of disabled was also found in includes/templates/YOUR_TEMPLATE/jscript/jscript.form.js, though at the moment I'm not sure of the interaction of that script with the observed issue.
Haven't had a moment (though plan to later) but is this item either at the beginning or end of the list, do things change if more than one is made to go out-of-stock (quantity of 0)?
Welcome. That's a whistle planned to be added to the admin stock populating side once a separate, but related aspect is addressed with making the data fields easier to programmatically identify and manipulate. Don't want to start writing in extra options that will have to be recoded and cause issues with cut/paste/replace, etc...
Hello,
I downloaded this mod and it messed up my admin I just had a blank page. I put all the folders where they should go... I replaced the files with my backup and admin is now fine, My problem is now when I view an item that has an attribute on my site I get the following error WARNING: An Error occurred, please refresh the page and try again. Does anyone know why this is happening?
Thanks
Can only help with your assistance.
Downloaded this module: from where?
Got an error: details of errors are logged by ZC in the directory applicable to one's ZC version, so what ZC version: FAQ to help is: https://www.zen-cart.com/content.php...-and-try-again
Loading of the files, were the changes of this plugin merged with your existing file(s) or did the files of this plugin just simply replace what was on your server?
How did the install of this to your demo or backup site go? Did it have the same issue(s)?
Again, help us help you, if you could also further address the items of the posting tips, that would be great.
Hi sorry for the lack of information. I downloaded this from the zen cart addon
I downloaded these files directly over my current files
I don't have a backup/demo??
Log File
`[18-Sep-2016 20:57:15 UTC] PHP Fatal error:
1146:Table '*******_zenc307.zenyj_products_with_attributes_stock' doesn't exist :: SELECT pas.stock_id, pas.quantity
FROM zenyj_products_with_attributes_stock pas
WHERE pas.products_id = '3208'
AND pas.stock_attributes = '4' ==> (as called by) /home/*****/public_html/includes/modules/ashley_pink/attributes.php on line 126 <== in /home/********/public_html/includes/classes/db/mysql/query_factory.php on line 155
Hoping this helps a bit??
Thanks for your patience!!
It does in part. The version made available on the ZC website associated with the most recent upload can be made functional with a more recent ZC version, but really only applies to the version published with it.
Right now the specific problem on your site with a file uploaded as a part of the package is includes/modules/ashley_pink/attributes.php as it is looking for something that has not been installed or has been removed if it did get installed.
As for a test site, it is always suggested that when placing new software that it be tested first on something that won't cause a problem with a live site. As to installing something that is far less likely to cause a problem I am limited on recommendations at this point, again more info needed.
As to the other files that got overwritten, they may need to be replaced with the original version(s), also there are files that may need to be removed that likely did not get removed by your system restore (which probably just restored existing files without removing new ones).
I installed it and it says it installed properly but my front-end is getting a 500 error and the error log says "Class 'products_with_attributes_stock' not found in /home/piratesp/public_html/store/includes/autoload_func.php on line 79"
I saw that someone else is having a similar issue but I can't seem to figure out why this is happening on my end. Any help would be appreciated or if you need to email me separately - christian [at] piratespress.com
Thanks!
UPDATE:
Fixed it!
Of course! So disclaimer, using ZC 1.5.4. I didn't build or set up the ZC so I'm going off of what the previous person did. So the ADMIN folder had a screwy name and messed me up initially.
My biggest thing was making sure all of the files went where they were supposed to be. It was tough (for me as a non-programmer) to combine the files that were updated for EVERY ZC version vs. the ones that were changed for different versions of ZC. It was meticulous and I had to go back through MANY times to find out that there was a file misplaced or missing.
So, there is/was no need to combine the two sets of files before applying them to the site. They actually have been put together so that you could put the "all" files on the server and operation of the site continues like it is not installed or otherwise affecting purchases. Even once all the files are in place, operation of the store continues as if it is not installed (there is a minor exception to that where older stores have slightly corrupted database records which are corrected upon install. I'll have to look closer at that aspect.) anyways, glad that you were able to get it installed and to explain the issues experienced. It certainly should help others that may experience the same issue(s).
PHP Fatal error: Call to a member function Execute() on null in /home/austink9/public_html/store/ADMIN/includes/classes/observers/class.products_with_attributes_stock.php on line 205
I'm getting this when trying to delete an Option Name. The name is not in use, so is safe to delete. This is on a Zen Cart 1.5.5a using SBA 1.5.4 from GitHub.
Doh, on line 201 add a new line below the commented text and add:
Committed to github with correction. Affects all versions of ZC using that code.Code:global $db;
https://github.com/mc12345678/Stock_...27d98aec9de505
And a few more corrected in that same observer class also related with option name/value deletion:
https://github.com/mc12345678/Stock_...f775936fb0eaca
A couple of questions please.
I'm running 1.5.5a on PHP 7.0.12, with this work OK.
Also, say if I have T-shirts in different sizes and a particular size becomes out of stock, will it continue to be available for sale or not?
Thanks
Dene
Nothing has denoted that the version available from github won't work on that version of PHP. As for out-of-stock saleability, it is primarily up to how your store is setup as to whether an out-of-stock specific attribute can be "oversold" or not. It has been designed to follow the overall settings of your store such that if your store does not allow selling product that are considered out-of-stock then the plugin will prevent the same at some point in the purchase process.
I have a few things to push to github for further improvements, but as with all plugins, I would suggest installing to a trial location before applying to your live store.
For those wondering about the improvements, well, have modified the stock reporting capabilities so that the listing in the dynamic dropdowns area is expected to only show items that can exist as defined in the admin (ie. Currently out-of-stock options are those that could theoretically exist based on the selections made on the attributes controller. On an upcoming github upload that "stock" display (absence of stock on identified/designated) will be added for dynamic dropdowns when using the default "filter" for multiple product.
Also, some javascript improvements have been made both on the catalog and admin sides. There are/may be some other improvements to be added depending on various factors, but trying to finish cleaning up the javascript before pushing it.
I'm an idiot. I tried to install this but didn't backup first now I can't get into my admin panel.
Any ideas?
Code:[31-Oct-2016 22:16:12 UTC] PHP Fatal error: Uncaught Error: Call to undefined function zen_get_ip_address() in /var/www/vhosts/localhost.localdomain/httpdocs/IQ/shop/NOTMYADMIN/includes/init_includes/init_sessions.php:31
Stack trace:
#0 /var/www/vhosts/localhost.localdomain/httpdocs/IQ/shop/includes/autoload_func.php(48): require()
#1 /var/www/vhosts/localhost.localdomain/httpdocs/IQ/shop/NOTMYADMIN/includes/application_top.php(171): require('/var/www/vhosts...')
#2 /var/www/vhosts/localhost.localdomain/httpdocs/IQ/shop/NOTMYADMIN/index.php(10): require('/var/www/vhosts...')
#3 {main}
thrown in /var/www/vhosts/localhost.localdomain/httpdocs/IQ/shop/NOTMYADMIN/includes/init_includes/init_sessions.php on line 31
Very unusual error messages, but when you say "this" can you please elaborate to ensure we are all referencing the same software.
If had downloaded the version from github, what had been installed or attempted to be installed? Did you get to the point of trying to install version specific files or did you only get the "all versions" files (includes and admin directories) installed?
https://www.zen-cart.com/downloads.php?do=file&id=202
I downloaded 1.5.3, changed the folder names to match my theme/admin and uploaded. I actually did back up the files that it wanted to overwrite first.
I then went to load stock_by_attr_install.php which is when I got the blank screen. I tried to then go to admin but blank screen. I then copied back the files that I had backed up:
admin/invoice.php
admin/orders.php
admin/packingslip.php
admin/includes/functions/general.php
admin/includes/classes/order.php
includes/classes/order.php
includes/functions/functions_lookups.php
includes/functions/extra_functions/products_with_attributes.php
includes/modules/pages/checkout_shipping/header_php.php
includes/modules/pages/shopping_cart/header_php.php
But still get the blank screen :-/
Oye. Okay. So 1) the version currently offered on this website is for ZC 1.5.1. There's a lot that has changed related to it. If I'm not mistaken some of the additional files that exist in directories like includes/auto_loaders (store or admin) might cause the issue that you are seeing.
Would appear that almost none of the last page or two has been reviewed nor the previous message I posted indicating that would need to download from github to support ZC 1.5.5 (and honestly right now would be the best source for any 1.5.1-1.5.x install as it contains files compatible with all versions (except 1.5.2) and doesn't have the issue reported above.
It hasn't been pushed to the ZC site because of two things: 1) instructions need updating from all the hard work that potteryhouse did and 2) doesn't seem to me to be at the quality level I would like to be able to call it a ZC plugin. There are areas where a store owner could cause oneself trouble because the code doesn't notify them that what they are doing is not right or it doesn't prevent the action. Some of those things I'd rather just make possible instead of strictly prohibiting. I may not directly deal with them, but by staying open minded they can be addressed later.
Anyways, glad you had backups of the files to be overwritten, now need to remove (or overwrite with those from github) the ones that were added new.
Another thing. Did the error message change?
OK, i've downloaded the 1.5.5. files from GitHub and uploaded them. Still getting blank Admin:
My 1.5.5a ZenCart uses a database that I imported from an old 1.3.8 installation where I used to use the old version of Stocks By Attributes. Could this be a cause for any of the issues I am having here?Code:[01-Nov-2016 14:40:10 UTC] PHP Fatal error: Uncaught Error: Call to undefined function zen_get_ip_address() in /var/www/vhosts/localhost.localdomain/httpdocs/IQ/shop/ADMIN/includes/init_includes/init_sessions.php:31
Stack trace:
#0 /var/www/vhosts/localhost.localdomain/httpdocs/IQ/shop/includes/autoload_func.php(48): require()
#1 /var/www/vhosts/localhost.localdomain/httpdocs/IQ/shop/ADMIN/includes/application_top.php(171): require('/var/www/vhosts...')
#2 /var/www/vhosts/localhost.localdomain/httpdocs/IQ/shop/ADMIN/index.php(10): require('/var/www/vhosts...')
#3 {main}
thrown in /var/www/vhosts/localhost.localdomain/httpdocs/IQ/shop/ADMIN/includes/init_includes/init_sessions.php on line 31
Thanks
Dene
Check your includes/functions/functions_general.php file to see if the function zen_get_ip_address exists.
That is the function reportedly missing. I realize that the file is not modified by this code and don't really see a specific reason that the file would have been touched, but that's the first place I would look.
Then having looked at the load sequence for ZC, the other thing(s) that seem like it could be is something say that was off about the added admin/includes/auto_loaders file for SBA, though I thought the filename remained the same in all of these edits so the newest install would correct whatever was a problem there.
As to historical things, well in a post on the previous page you indicated that the download overwrote an admin/includes/functions/extra_functions file. ZC doesn't come with any files in that directory and the fact that it was one to be overwritten indicates that one or more other files from a previous version of SBA existed. As such, it is difficult to identify what files are interacting poorly or to that extent without being identified what other changes have been made to the store that could be causing this.
No the database modifications made by SBA, whether current or historical would not cause an issue provided files aren't looking for/acting on those changes.
Uploaded several changes to the github location. Seems to me that would consider uploading to ZC after a little work on the customid management. But let me try to identify some things that might be of interest:
1. Supports edit orders. Tested on version 4.1.7. As currently written, EO does require at least the insertion of one line if you use the SBA added option type of 'SBA Select List (Dropdown) Basic'. If using the current version of Product Attribute Grid, then one additional line would be necessary or a modification to a few lines in that plugin which is to be updated shortly. If you don't use either the PAG plugin or the added option name then no modification to EO is necessary.
Locate in admin/edit_orders.php a section that has this code (at or around line 998):
and add before the first case statement:Code:switch($optionInfo['type']) {
case PRODUCTS_OPTIONS_TYPE_ATTRIBUTE_GRID:
case PRODUCTS_OPTIONS_TYPE_RADIO:
case PRODUCTS_OPTIONS_TYPE_SELECT:
So that it would look like:Code:case PRODUCTS_OPTIONS_TYPE_SELECT_SBA:
case PRODUCTS_OPTIONS_TYPE_GRID:
Features added to as part of EO: when adding a product, if the SBA attribute selection does not exist then the product will not be added, with an error message provided. Also when adding a product, if the store is set to prevent overselling product then the admin will be notified if the quantity entered will cause the product quantity to go below 0. Such a restriction does not exist for editing a product mostly because there are so many additional variations available as to what is going on or what is to happen next. But when updating, if the SBA attributes selected are non-existent then the product will be updated with whatever data has been entered except the attributes. The problem attributes are listed in the provided error message as well as references to identify which record's attributes were not updated.Code:switch($optionInfo['type']) {
case PRODUCTS_OPTIONS_TYPE_SELECT_SBA:
case PRODUCTS_OPTIONS_TYPE_GRID:
case PRODUCTS_OPTIONS_TYPE_ATTRIBUTE_GRID:
case PRODUCTS_OPTIONS_TYPE_RADIO:
case PRODUCTS_OPTIONS_TYPE_SELECT:
2. Dynamic Dropdowns now support Read-Only Attributes and still be able to show the quantity of stock available at whatever the last available selection is.
3. Dynamic Dropdowns now offers only attribute combinations that have been defined as a variant when showing out-of-stock quantities (Ie. if a product with attribute 2 value 1 is only offered with attribute 1 value 1 then when selecting attribute 1 value 2 that "special" option will not be shown as out-of-stock unless the variant exists in the database. Or in "real world" discussion, if blue shoe laces can only be offered with yellow shoes, then when presenting blue shoes, the blue shoe laces should not even be visible). From my reading the term for this appears to be dependent attributes; however, there is no current support to provide some alternate option such as instead of laces to change to tread trim. Tread trim would have to have already been defined as one of the attributes associated with the shoe.
4. It is in part possible but not necessarily advised to control read only attributes as products/variants such that specific read only attributes are applied to specific combinations of other attributes. Changing of the read only content is not yet afforded, but basically the read only attribute(s) displayed would serve as an attribute option and would show up on the shopping cart and beyond as a selected attribute. This feature does not appear to currently be supported by Edit Orders.
5. Improvements/modifications were made to the code for the admin products SBA/PWA entry area:
a. the search text box was made as a default area when the page loads.
b. when selecting a box/field for edit in the table the field is made active with the cursor at the beginning of the field.
c. the javascript was put through a javascript evaluator to ensure compatibility/functionality with improvements made.
d. the designation used for field recognition was modified to a more human readable format instead of using a numerical designation that had no specific relationship. This change in process will allow the addition/growth of other related fields and make them easier to update.
e. a link to the attribute controller for the product was added to make reaching the modification area of the product's attributes easier.
Potentially a few other improvements depending on when you last downloaded the code.
Enjoy, and please let me know if there are issues with the code, I'd be glad to get it resolved/fixed.
Actually, with regards to the above about PRODUCTS_OPTIONS_TYPE_GRID, I've submitted an updated copy of Product Attribute Grid to have the grid product type established/set so that it will work with Edit Orders. This means that only PRODUCTS_OPTIONS_TYPE_SELECT_SBA needs to be addressed. I will be submitting a request to edit orders to add that attribute type to the program. An unfortunate alternative is to work through all of the javascript that might be needed in order to visually support the option(s). While that is desirable it would/will take a bit of time to implement considering how edit orders handles/displays attributes far differently than how the ZC store front does.
Question with regard to 1.5.5b comparability. Is it necessary to download from GitHub (https://github.com/mc12345678/Stock_...butes_Combined) or does the 5.1.3 link in the Plugin area have the same files (https://www.zen-cart.com/downloads.php?do=file&id=202)?
Also, if GitHub is required do you install just the 1_5_5 files or do you first install 1_5_1 then 1_5_3/4 then 1_5_5 to get all the required files? Also, on GitHub there is a second set of admin and includes folders at the top level (not down in 1_5_5). Are these also installed at some point in the process?
Thanks for this highly useful feature for ZenCart.
As a good zenner, by now you probably have already downloaded the software and on your test site, you have begun trying to install it. Further then you may have begun to see how the file layouts apply, how if you applied the files of the earlier fileset that, one probably the store doesn't work in some ways/regards, two you'll be redoing a lot of things, three as additional observers have been added to ZC, some of the code changes have become unnecessary and are addressed through observers, so files would be unnecessarily modified to support operation already supported by ZC.
Anyways, I believe that all of the questions asked above are answered in the following posts (and I'm sure there are more that are similar in this thread as well as in others).
Please see/read posts #2659, #2648, #2587, and #2571.
Basic thing: github is up-to-date, ZC version of the software at this time works only for older ZC versions, but there are some that have been able to get it to work through incorporation of the applicable changed portions of the code. All systems need the base includes and admin folders, then the files applicable to the current ZC version can be installed/merged.
Has anyone tried this plugin using version 1.5.5?
Stock by Attributes - Version: 1.5.3
Version 1.5.3 as available for download in the plugins version is strictly compatible with ZC 1.5.1, would require care to merge with any more recent version, and is missing a large number of improvements that have been made to the plugin. If I may suggest, please read backwards in this forum on how to obtain a copy of the plugin that has been made compatible with ZC 1.5.5 and previous versions of ZC 1.5.x.
I want to thank the github user @jodeantn that pointed out an issue with the ZC 1.5.5 file(s) includes/templates/YOUR_TEMPLATE/templates/tpl_checkout_confirmation_default.php and equivalently includes/templates/YOUR_CLASSIC_RESPONSIVE/templates/tpl_checkout_confirmation_default.php. Apparently when arriving at the checkout_confirmation page, an error was generated in the logs folder and the remainder of the page/final checkout was affected. Issue #43 at the github storage location provides some more detail. The error was similar to:
Where YOUR_TEMPLATE would be expected to be the foldername for the active template for the user visiting.Code:PHP Fatal error: Call to undefined method payment::process_form_params() in public_html/includes/templates/YOUR_TEMPLATE/templates/tpl_checkout_confirmation_default.php on line 205 Line 205 echo zen_draw_form('checkout_confirmation', $form_action_url, 'post', 'id="checkout_confirmation" onsubmit="submitonce();"' . (is_array($payment_modules->modules) ? $payment_modules->process_form_params() : ''));
The fix involves removing a portion of code that was incorporated into the SBA provision of the files for ZC 1.5.5 in December 2016, expecting that the PayPal InContext code provided/referenced in the solution would be used/considered. That appears to still be out for debate, but I didn't remove the following snippet until today about 15 minutes ago.
Applicable only to copies that were downloaded sometime between December 18, 2016 and today January 31, 2017:
To fix existing installations/downloads of the ZC 1.5.5 templates (although this code was not specifically marked as being applicable to SBA) then need to modify as applicable both
includes/templates/YOUR_TEMPLATE/templates/tpl_checkout_confirmation_default.php
and
includes/templates/YOUR_CLASSIC_RESPONSIVE/templates/tpl_checkout_confirmation_default.php
and change this: (portion to be removed in red color)
to this:Code:echo zen_draw_form('checkout_confirmation', $form_action_url, 'post', 'id="checkout_confirmation" onsubmit="submitonce();"' . (is_array($payment_modules->modules) ? $payment_modules->process_form_params() : ''));
See issue #1192 on the ZC github for updates on incorporating the PayPal Incontext code that would be needed to support keeping the file(s) the way they were.Code:echo zen_draw_form('checkout_confirmation', $form_action_url, 'post', 'id="checkout_confirmation" onsubmit="submitonce();"');
I'm running SBA v1.5.4 with Zencart v1.5.5d with a Sheffield Blue template on PHP v5.4.45.
Although it seems to be working, when an order is placed, there is an intermittant problem in that the stock levels are not updated. I've tested it and it always seems to work, but when real orders some in, about 1 in 3 does not have the stock levels updated.
Any idea where to start looking?
Stock adjustment code resulting from a purchase is located in the includes/classes/order.php flowpath. SBA latches onto that operation using the observer class on the catalog side in includes/classes/observers. Next is the notifiers with the order class.
Could you please identify when the files were downloaded?
@ttfan,
Also, the product to which this is being reported against, how are it's variants populated? Is it product that has only one option name (one attribute) or product that has multiple option names (multiple attributes)? If multiple option names, is the stock populated such that each attribute has its own stock quantity or as a combined variant where a set of attributes each has its own quantity?
Files were downloaded about 2 months ago, it was installed by Anne from Picaflor Azul.
Each product has one attribute,called "colour/thickness", and the options are for example "red 2.2mm", "black 2.0mm". There are different quantities for each of these options.
As I mentioned, when I test this, it seems to work properly, and the quantity (both the total and the particular attribute) is updated correctly, but it fails regularly for actual orders.
Okay. I want to make sure that we are both talking about the same "setup" because each of the three "styles" of listing product as a variant has a different consideration and can take different paths in the code.
So, in the catalog option names area, you have one option name that is called colour/thickness. And when you go to the option values menu, in the dropdown to add a new option value you have a single selection in that list that reflects colour/thickness. And then for every possible combination of those you have an option value listing black 2.0mm, or red 2.2 mm.
Then in the attributes controller, you have one option name group of colour/thickness with all of these combinations listed as a single row for each combination.
Then in the products with attributes stock table under the catalog option, you have for a product that is to be tracked by stock again a single row for each combination and when you go to add variants for the product you have a single dropdown with text boxes below it. All correct so far?
And then you are able to adjust the quantity of the individual variants from the admin screen.
Now you are saying that when you try to make a purchase on your own, the quantities are being reduced, but somehow you are saying/identifying that when others are permitted access and make a purchase that the quantities are not reducing.
I'm curious about how you have identified the lack of reduction and if you can determine anything about what is going on at the store at the time when it seems like stock is not being reduced. I also question the date on which the software was obtained because there was some changes to the stock decrement portion that were made on Oct 11th because the code was not robustly considering all three of the above options. All three styles/methods were tested without issue, but it seems that somehow from the above that perhaps the testing was not robust enough to identify the issue(s) similar to what you are claiming.
So were there multiple people shopping at the time of the issue? Were they all working with the same product, did some of them have items stored in theirtfom a previous browse? Did they all submit their purchase at the same time?
All-in-all I might suggest placing the files that are in the base includes and admin folders over your existing version of those files and trying/seeing again how things go. Of course would rather have the new files compared against the old to see what has changed in the observer that might affect that operation, but seems better to get back on track and know that the recent files are in place rather than guess.
Trying to also see if there is a database cache issue, does it seem to relate to the number of SBA tracked items in the cart and/or the mix of those? (like all items of the same product but different attributes?) I plan on running some more tests but would like to try to target them as much as possible.
I continue to read through the code to see what issues seem likely/plausible.
Thank you so much for looking into this. Sorry I've taken so long to reply, but I'm struggling to get my head around how this works, as I'm no programmer.
Yes that is correct
We don't have high volume sales, and although we have a large catalogue of item, we only have small quantities of each. We keep double records while we're testing, which is how we know it's failing regularly.
It's highly unlikely multiple orders were placed at the same time, as out shop is low volume, and in most cases different items are purchased.
All of the "consternation" is understandable. There's a lot of things that have to fall together to first even get results, then there are a number of twists and turns that could exist and explain why one feature or another doesn't work as expected.
From the description of the setup, right now I'm considering without additional "this is how I can make it happen again" data, that the issue is either out-dated code because there was a period around Oct 11th, 2016 when the stock decrement calculations/actions were changed with the expectation of handling the decrease of stock for any type of "allowed" variant combination. In your case, it appears that a variant is a single entry, no combinations with other things.
Couple of answers to questions can help resolve the issue, the first is to identify if the code contains expected information. If you could please access the file: includes/classes/observers/class.products_with_attributes_stock.php and then around line 442 possibly as far down as line 489, look for the function: updateNotifyOrderProcessingStockDecrementBegin.
If you could please copy the code of that function.
Then if you could reply to this message, select the # symbol in the message box toolbar to generate [CODE][/CODE] tags. The cursor should be between the two of those tags, and then paste the code.
So another question is how is the includes/classes/order.php file different from the standard/vanilla version of that file?
What other plugins are installed?
When looking at the product, purchases, type of product in the order(s), etc, what commonalities are found? Did the lack of decrease observed have anything to do with the remaining amount and the amount purchased? (ie. Was that the last available quantity and it didn't go out of stock, or any other information to help.)
Do the product have a maximum and is it limited by a mixture? Ie. Is there a case involved that limits the total quantity that can be purchase say to 5 and the customer can pick a total of 5 of the associated items, but only a total of 5, not 5 of each type of attribute? That type of thing.
Another relates (though I don't think it would be a specific reason for the issue) is the setting of using Dynamic Dropdowns, is it as most robust set to be active only when multiple attributes are involved?
Here is the code you requested:
Very few plugins are installed at this stage, as we're still trying to get things working. The plugins are: CK editor & image handler, as well as stock by attributes of course.Code:function updateNotifyOrderProcessingStockDecrementBegin(&$callingClass, $notifier, $paramsArray, &$stock_values, &$attribute_stock_left = 0){
global $db; //, $pwas_class;
$this->_stock_values = $stock_values;
if ($this->_orderIsSBA && $stock_values->RecordCount() > 0) {
// kuroi: Begin Stock by Attributes additions
// added to update quantities of products with attributes
// $stock_attributes_search = array();
$attribute_stock_left = STOCK_REORDER_LEVEL + 1; // kuroi: prevent false low stock triggers
$this->_attribute_stock_left = $attribute_stock_left;
// mc12345678 If the has attibutes then perform the following work.
if(isset($this->_productI['attributes']) and sizeof($this->_productI['attributes']) > 0){
// Need to identify which records in the PWAS table need to be updated to remove stock from
// them. Ie. provide a list of attributes and get a list of stock_ids from pwas.
// Then process that list of stock_ids to decrement based on their impact on stock. This
// all should be a consistent application.
// mc12345678 Identify a list of attributes associated with the product
$stock_attributes_search = $_SESSION['pwas_class2']->zen_get_sba_stock_attribute(zen_get_prid($this->_productI['id']), $this->_productI['attributes'], 'order');
$stock_attributes_search_new = $_SESSION['pwas_class2']->zen_get_sba_attribute_info($this->_productI['id'], $this->_productI['attributes'], 'order', 'ids');
if (isset($stock_attributes_search_new) && $stock_attributes_search_new === false) {
} elseif (isset($stock_attributes_search_new) && is_array($stock_attributes_search_new) && count($stock_attributes_search_new) == 0) {
} elseif (isset($stock_attributes_search_new) && $stock_attributes_search_new && count($stock_attributes_search_new) > 0) {
foreach ($stock_attributes_search_new as $stock_id) {
// @todo: address in PWAS table whether particular variant should be altered with stock quantities.
$get_quantity_query = 'SELECT quantity from ' . TABLE_PRODUCTS_WITH_ATTRIBUTES_STOCK . ' where products_id=' . zen_get_prid($this->_productI['id']) . ' and stock_id=' . (int)$stock_id;
$attribute_stock_available = $db->Execute($get_quantity_query, false, false, 0, true);
if (true) { // Goal here is to identify if the particular attribute/stock item should be affected by a stock change. If it is not, then this should be false or not performed.
$attribute_stock_left_test = $attribute_stock_available->fields['quantity'] - $this->_productI['qty'];
$attribute_update_query = 'UPDATE ' . TABLE_PRODUCTS_WITH_ATTRIBUTES_STOCK . ' SET quantity="'.$attribute_stock_left_test.'" where products_id=' . zen_get_prid($this->_productI['id']) . ' and stock_id=' . (int)$stock_id;
$db->Execute($attribute_update_query, false, false, 0, true);
if ($attribute_stock_left_test < $attribute_stock_left) {
$this->_attribute_stock_left = min($attribute_stock_left_test, $this->_attribute_stock_left);
$attribute_stock_left = $this->_attribute_stock_left;
}
}
}
}
/* $get_quantity_query = 'select quantity from ' . TABLE_PRODUCTS_WITH_ATTRIBUTES_STOCK . ' where products_id="' . zen_get_prid($this->_productI['id']) . '" and stock_attributes="' . $stock_attributes_search . '"';
$get_quantity = $_SESSION['pwas_class2']->zen_get_sba_attribute_info($this->_productI['id'], $this->_productI['attributes'], 'products', 'stock');
// mc12345678 Identify the stock available from SBA.
$attribute_stock_available = $db->Execute($get_quantity_query, false, false, 0, true);
// mc12345678 Identify the stock remaining for the overall stock by removing the number of the current product from the number available for the attributes_id.
$attribute_stock_left = *//*$attribute_stock_available->fields['quantity']*//* $get_quantity - $this->_productI['qty'];
// mc12345678 Update the SBA table to reflect the stock remaining based on the above.
$attribute_update_query = 'update ' . TABLE_PRODUCTS_WITH_ATTRIBUTES_STOCK . ' set quantity='.$attribute_stock_left.' where products_id="' . zen_get_prid($this->_productI['id']) . '" and stock_attributes="' . $stock_attributes_search . '"';
$db->Execute($attribute_update_query, false, false, 0, true);
//$this->_attribute_stock_left = $attribute_stock_left;*/
}
$attribute_stock_left = $this->_attribute_stock_left;
}
}
/*
* Function that is activated when NOTIFY_ORDER_PROCESSING_STOCK_DECREMENT_END is encountered as a notifier.
*/
// Line 776
/**
* @param $callingClass
* @param $notifier
* @param $paramsArray
*/
I can see no commonalities between orders that pass/fail, except that the ones fails always have the atrributes discussed above. Items with no attributes work properly.
That appears to be the latest code which supports the rewritten stock decrement functionality for all three variant styles of:
1) One option name for a product with one option value per variant entry.
2) Multiple option names, each option name's value listed one time such that no two option values are combined in one entry.
3) Multiple option names with combinations of option values from different option names all entered in a single variant.
So, that said, I tried to look through the code to find something that might cause a spurious result and found two queries "buried" in the process that do not clear the query cache. Is that the cause? I don't know because haven't been able to repeat the issue and no further information has yet been provided/analyzed to be able to verify that the problem has been resolved. In fact, I'm not even sure that by making the changes (or not) if there is a way to validate that the problem has been solved, but anyways...
The suggested fix is available from: https://github.com/mc12345678/Stock_...3ab46ef5a4aa0e
and affects only one file in two places. The file is: includes/classes/class.products_with_attributes_class_stock.php
The lines affected are 416 and 1506 with the same fix applied to both of effectively adding to the query:as can be seen at the above link.Code:, false, false, 0, true
Feedback would be appreciated.
Thank you so much!
I have implemented the 2 changes. I've tested it myself, and it seems to work fine, so now I'll wait for the orders to come in, so that I can check it's all working. I'll report back here.
Would be interesting to see if it happens again, though by not knowing any information about how it occurred the first time(s) there's really little to be able to tell that the issue is resolved...
That said, the condition I could possibly see under the previous code and maybe causing the reported result is if a product was in the cart that was not tracked by SBA and after that a product was present that was tracked by SBA but caching recordered it "not" being SBA. The other is that data was returned for a different product and either no decrement occurred, or a different product's quantity was reduced.
Haven't yet been able to reproduce either situation but it is something conceptually possible if caching were the cause of the issue(s).
Look forward to results!
Unfortunately it did not work. The very next order failed to update the quantity of the attribute, while the total quantity was reduced properly.
I just had one thought though, it may not be related. When I test the module, I always use the 'bank deposit' payment option, as this goes straight through, and I don't have to make a dummy payment via paypal. However at least some of the orders that failed (possible all, I did not take note), were using payment via paypal. A Paypal payment forces the user to go to the paypal site to make the payment, then return to the shop to update the order and empty the cart. So perhaps this is where the attributes fails to update?
Okay, so can you tell me about the order, the product and the particular setup?
Ie. How many products were in the order?
When thinking about the product from the perspective of SBA, which had attributes, what attribute(s), what type of attribute(s)?
In the pwas table under catalog, if you search for the products_id of the product in question, what are all of the variants (rows) listed for the product?
What was the quantity of each product ordered? How many were present before the order?
What are the settings for the product in relation to mixed quantity? Is there a maximum applied for the product?
Need details of how I can reproduce the issue so that I can fix the issue.
I don't need to know things like the products_description or what it does/is, just "data", sort orders, setup. If you can provide that, then perhaps I can repeat the situation.
BTW, any error logs in your logs directory possibly as a result of the purchase/sale?
What method of PayPal is enabled?
Though that doesn't make sense either, because the only place that stock is reduced is through the includes/classes/order.php file which (should have) has the notifiers present to trigger the SBA decrement and if the total quantity went down, that should mean that the applicable SBA code would execute. But that said, I'll have to take a look at how session data is managed along that path, because currently the decrement code is session related and if in the process that is removed, then two things: 1) an error should be generated because the code can't be found, and 2) the stock wouldn't decrease. But, I thought that in previous review of what happens with the session, is that only PayPal and possibly cart related session data was modified. :/
Here is one warning from the log file, the only one that seems related:
#1 trim() called at [/includes/functions/general.php:441]
#2 zen_not_null() called at [includes/classes/upload.php:61]
#3 upload->parse() called at [attributes_controller.php:310]
[08-Feb-2017 17:03:46 Australia/Sydney] PHP Warning: trim() expects parameter 1 to be string, object given in /includes/functions/general.php on line 441
I'm using the Paypal Website Payment Standard only.
Okay, so with regards to using PayPal standard do you consistently receive the email from the store and PayPal with the full order being stored in the database, or do you find that you sometimes have to go back and request the purchaser to provide more information or any related issue(s)?
Yes the full information is in the Paypal Email, including the attributes.
After looking at the orders over the last 24h, I can confirm that only the orders that were paid via paypal fail to update the attributes, the ones paid via other methods (none of which use an external website), all work properly.
Right now I'm thinking that the problem would be resolved by using PayPal express, so perhaps at an impass...
It certainly gives me reason to re-consider the use of the session to store the functions that are used again and again, but generally speaking PayPal standard is discouraged in favor of PayPal express for a number of reasons.
In order for me to rewrite the code to not use the session style, I'd have to do a good bit of testing because the leap from before to now was easily made but going backwards in that regards and not having everything offered up as an extra function (ie. Compartmentalizing the code so that is possibly less of a system burden means a decent amount of verification.) it's also not something that is going to be revised overnight.
Again, considering that the only identified (as of the last 24 hours) possible consistency has been the use of PayPal standard, my suggestion would be (whether there had been a problem or not) to use PayPal express if PayPal is going to be used for a general store.
Does Paypal Express still allow you to pay with a credit card directly (using the paypal gateway, not a paypal account), or only payment with a Paypal account? This is important to us, as we prefer not to use another site just for processing credit cards.
I'll certainly install Paypal Express and test it, hopefully it will resolve this issue.
Just in case I did not mention it earlier, I really appreciate the time and effort you've spent helping me, a big THANK YOU from me! :blush:
So I recently saw someone say that when using PayPal express with in context payment that possibly the customer was forced to have, get, or use a PayPal account, because of a setting in the code that supposedly (per a PayPal tech) is no longer required to be set/written the way it is. That said, in my testing with PayPal express, I have been able to select/enter a credit card without being required to have, get, or use a PayPal account. Of course they want you to create/have/use one, but doesn't mean they necessarily limit operation to its use. Oh, and my testing included full use of PayPal in context.
As for the assistance, hopefully you understand also that I sort of have a vested interest in it working as written. Any and all that have chosen to use it are likely questioning it's operation at the moment and why questions have been asked to be answered. The less people to which the issue applies, the more at ease they are to be. Mind you I have pushed some minor changes to github, just in case there might have been something odd with the queries (ensured a space to each side of an equals when dealing with a SQL script.), I hadn't pushed the execute query changes from earlier yet to the master because they didn't fix the current issue, therefore I didn't see a necessarily good reason to clear the cache for those two items. At least not yet. :)
I'm happy to report that it appears to be working fine now, when I replaced the old Paypal module with the Paypal Express one!:smile:
Depends on which Paypal you are using.
There is Paypal paments (what you traditionally think of as Paypal) and then there is Paypal Merchant Processing.
Paypal Merchant Processing (ie: PayPal Payments Pro) will stay on your site.
Paypal Payments (like Express Checkout, or the very old PayPal Standard) will take you to Paypal. Once on Paypal you can either use your Paypal account or just enter a credit card.
I installed the 1.5.1 version on my 1.5.1 Zen Cart. I can create quantities for attributes in admin but when viewing the product it states that it is out of stock when it is not out of stock. I have synced the quantities and they are correct.
Any ideas?
Sure that all parts of the software were installed, and I assume (right or wrong) that the github version was used? Regarding the install, were files "blindly" replaced, or where the file existed were the changes made for SBA incorporated into the existing file(s)?
After/along with that: please identify the characteristics involved: ie. one attribute (option name) or more than one? Are the default settings for dynamic dropdowns being used? Out-of-stock, showing where? Each attribute? Full product? If the product is showing out of stock I'd be surprised as nothing really is modified that would cause that.
Might have more questions, but answers to those should at least guide to something.