Multiple Attributes on product Info Page

[mc12345678]

Someone please check that I'm not crazy. Downloaded ZC 1.5.5 from github about 4 hours ago. 100% replaced/updated files that had been used for beta testing. At all times a vanilla install no plugins included. In review of files that only ones that had not been removed from the final test site were linkpointapi files just cuz I was lazy about them and have never had that module active and did want to see if any errors would be caused by their continued existence.
PHP 5.6
Database was upgraded from 1.3.8 using the zc_install of a few days ago, so for all I know this could be related to the database upgrade, but...
Occurs in both "classic" templates.
Looking at the product info page (one level deeper than the product listing page)
Product has more than one option name applied to it.
Then no attributes available to select...
Product has just one attribute, option(s) appear.

Am I crazy or is this reproducible by others?

[mc12345678]

For others not yet familiar with ZC 1.5.5, one of the changes made was to offer dropdowns for product that have a single attribute to allow the selection of the single attribute from locations such as a category list or places such as new products, etc...

I also would have provided a link to the site that is currently down for maintenance; however, because of changes made to permit query results to be treated as an array in situations like a loop, there is currently data provided when the php print_r function is used that I have presented a question to the ZC team about. At the moment I am not able to modify the code that I added to the includes/modules/attributes.php file to support troubleshooting so that that portion of the results are not presented to anyone/everyone. It may be a non-issue, but I'd like to hear something from someone official before presenting that link. In the meantime anyone that has installed ZC 1.5.5 with the sample products ought to be able to confirm or deny the above condition by looking at products 1 or 2 within the store: /index.php?main_page=product_info&products_id=1

[lat9]

I'm not seeing it (with the released version).

[mc12345678]

I'm not seeing it (with the released version).

Ok, thanks I'll take a lap through the files to reverify what's going on. Was trying to confirm that a different issue had been resolved and came across this. Will download the fileset referenced on this website and see what went wrong where. I wonder if I inadvertently installed test files that force the problem I saw instead of just the download files. In my last application of changes, I didn't review each one, just applied...

[mc12345678]

Problem solved...

As eventually suspected, there was a problem with the database... Simple problem as it may have been...

Background:
(Recap) Database was from a ZC 1.3.8 store. It got updated to ZC 1.5.4 last year. Yes memory served that there was some issue with attributes, but a year later I couldn't directly recall. So.. I did the following to figure out the problem/solution.

I had setup data exports of queries in the includes/modules/attributes.php file (not making a functional modification so I did not see the need to go through with copying the file to an override and modifying further, besides I could always restore with an original copy.) They were to print_r($products_options_names) and print_r($products_options) each immediately after execution of the query. All satisfactory results. Then as the last thing to do in the file print_r($options_names), but the result was 1... Not an array, not a list, not anything other than the value 1. So... thought to check all of the data that is provided by the database in processing the attributes.

From within phpmyadmin I copied all of the sql statements one at a time and substituted the associated values to verify that each query was returning data and that the data made sense.

It did. Then in review of the attributes.php file, $options_names is assigned within each of the sections applicable to the option_name's option type... Well, all of the option name's products_options_type were 0... Cross referencing with the option names manager, 0 is/was supposed to be a dropdown... Going back to includes/modules/attributes.php, and reviewing the switch for Option Name Type Display, a Dropdown is expected to be displayed if:

$products_options_names->fields['products_options_type'] == PRODUCTS_OPTIONS_TYPE_SELECT

Searching the database from within phpmyadmin and from within the ZC admin, no result...

This meant that the newly "created" default case:

                  default:
                  $zco_notifier->notify('NOTIFY_ATTRIBUTES_MODULE_DEFAULT_SWITCH', $products_options_names->fields, $options_name, $options_menu, $options_comment, $options_comment_position, $options_html_id);
                  break;

Which would be fine for the most part if there were a notifier that was listening for that condition and the above three values were missing... (Only PRODUCTS_OPTIONS_TYPE_SELECT is/was important here.) Guess could create one that tests for the existence of the PRODUCTS_OPTIONS_TYPE_SELECT configuration value, if not present, could create it where it is expected. Could further cause the file to delete itself; however, that really is up to those that care one way or another... I think it would be an easy file for these more recent ZC versions... I'm thinking about putting it together momentarily.

Went to install sql and the zc_install directory and did a word search on PRODUCTS_OPTIONS_TYPE_SELECT. Found the install sql to repopulate the database. Ran the query to install PRODUCTS_OPTIONS_TYPE_SELECT as found in a fresh ZC install. Also recalled that at one point PRODUCTS_OPTIONS_TYPE_SELECT and a few others (UPLOAD_PREFIX and TEXT_PREFIX) were assigned to the group id of 0 back in the day and that some plugins that were incorrectly written for install/removal would erase the values from the database. In one or more of the recent versions of ZC these values were moved to gID=6 and "out of the way" of being so inadvertently erased. After running the queries, my problem was resolved.

Unfortunately, the upgrade SQL does not restore these values if they have been removed, but will move them if they are present and not already in configuration_group_id 6 at least in the ZC 1.5.3 and ZC 1.5.5 upgrade scripts:

UPDATE configuration set configuration_group_id = 6 where configuration_key in ('PRODUCTS_OPTIONS_TYPE_SELECT', 'UPLOAD_PREFIX', 'TEXT_PREFIX');

Anyways, problem solved by performing the following:

INSERT 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 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 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);

For those that perform upgrades, the following could be used for ZC 1.5.5 after the database upgrade has been performed to ensure that necessary components to display attributes are present. This was became more necessary when the changes requested at: https://www.zen-cart.com/showthread....l-option-types were implemented as a result of historical plugins that tried to manipulate data that had a configuration_group_id of 0 through incorrect queries and the deletion of the above three keys. Previously this condition would not be fully noticable except for perhaps where files and uploads were of concern. Now that this constant has become a central part of the attributes.php file, and there is no file that is a part of the ZC code or zc_install process that will ensure it's continued presence/use once or while a database has been upgraded.


One could store the following in includes/classes/observers/auto.option_name_type_select.php

<?php
/**
 * User: mc12345678
 * Date: 3/20/16
 * Time: 5:09 PM
 */
class zcObserverOptionNameTypeSelect extends base {
    function __construct(){
        $attachNotifier = array();

        $attachNotifier[] = 'NOTIFY_ATTRIBUTES_MODULE_START_OPTION';

        $this->attach($this, $attachNotifier);
    }

    // This function is called to ensure that when the missing data is needed below that it is available.
    function updateNotifyAttributesModuleStartOption(&$callingClass, $notifier){
        global $db;

        if (!defined('PRODUCTS_OPTIONS_TYPE_SELECT')) {
            $db->Execute("INSERT 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);");
            define('PRODUCTS_OPTIONS_TYPE_SELECT', '0');
        }
        if (!defined('UPLOAD_PREFIX')) {
            $db->Execute("INSERT 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);");
            define('UPLOAD_PREFIX', 'upload_');
        }
        if (!defined('TEXT_PREFIX')) {
            $db->Execute("INSERT 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);");
            define('TEXT_PREFIX', 'txt_');
        }
        // @unlink(__FILE__); // To delete this file after execution delete the first 2 characters of this line.
    }
}

[ravynw34]

I am wondering if this may be the same issue I am now having with upgrade.
Original version upgraded from 1.50 to 1.54 about a year ago. upgraded to 1.55 yesterday using only the database in a Dev. Attributes are not showing at all in product info page. However, in Admin they are all showing when displaying the product under attribute controller.

[mc12345678]

So as part of investigation and determination of the cause of this issue, I reported this thread and the central topic as a bug that could occur for ZC 1.5.5. Particularly in a database upgrade situation. DrByte provided a simple query which acts similar to the above code. My thing was that if code was going to exist on a server, I didn't want to force a database query every time attributes were loaded, so I tried to keep things to use the least resources possible, but in some way to exist beyond the initial install. The ideal location would be the ZC database upgrade script. That script already relocates an existing assignment to the "safer" location, but doesn't recreate it if missing.

Anyways, the quickest fix if you know this problem is currently occurring and want to just correct it is posted HERE.

[ravynw34]

Thank you for that info. Worked perfectly.