[Closed] FEEDBACK ON BETA of v1.5.5

[stellarweb]

Ok thanks Linda - will keep that in my arsenal of upgrade things not to forget! lol

However.... we are still left with the core / vanilla 1.5.5 issue of not being allowed to add a text attribute to a product without first creating a "fake" non/text option name and value.

This happens when there are NO option names or values entered - which is the core settings. Guessing someone needs to revise that - otherwise people are not going to have a clue that they need to create that "fake" attribute in order to get a text attribute to work. This could be as simple as to just to include a "sample" option name and value in the core SQL. That would solve the issue as long as no one deletes that... has the page empty of attributes, then tries to enter a text attribute.

Had those been there, there would have been a slightly different setting as the upgrader fo v155 would have run:

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

You should run that in the Tools ... Install SQL patches .. to bring them up to date on the configuration_group_id to switch from 0 to 6 ...

[Ajeh]

However.... we are still left with the core / vanilla 1.5.5 issue of not being allowed to add a text attribute to a product without first creating a "fake" non/text option name and value.

This happens when there are NO option names or values entered - which is the core settings. Guessing someone needs to revise that - otherwise people are not going to have a clue that they need to create that "fake" attribute in order to get a text attribute to work. This could be as simple as to just to include a "sample" option name and value in the core SQL. That would solve the issue as long as no one deletes that... has the page empty of attributes, then tries to enter a text attribute.

I think you lost me ...

What is the "fake" attribute that you are referring to?

[stellarweb]

Plain / vanilla / fresh install of 1.5.5 code from yesterday without any demo products ....

Went to Catalog>Option Name Manager>Created an Option name of "enter your text here" with an option type of "text"
Went to Catalog>Attributes Controller>So I could apply this text option to a product and I get the following error at the top of the screen "Warning: No Option Values have been defined"
So... I cannot add a text option to my product right out of the box.
BUT... if I go to Catalog>Option Name Manager> and create a "fake" option name, and then create a value that is NOT a text option (eg checkbox, radio, etc) THEN when I go to Attributes controller, I can add my text box to my product.

That is why I am saying that if a "fake" or "example" attribute were added to the core sql, then this would not happen unless someone goes in and removes the "example" one.

I have no clue if other versions other than 1.5.5 are this way. I only tested 1.5.5

Hope that is clearer than mud!

PS - Linda let me know if you need access to my install and I will pm it to you.

I think you lost me ...

What is the "fake" attribute that you are referring to?

[DrByte]

I know this is pretty petty but one thing I have always struggled with is styling the "display price".

Maybe it would be possible to add a span in functions_prices.php, I alter this file for this reason on every template or client site I have ever designed or re-designed.

line 255:

        if ($product_check->fields['product_is_free'] == '1') {
          $show_normal_price = '<s>' . $currencies->display_price($display_normal_price, zen_get_tax_rate($product_check->fields['products_tax_class_id'])) . '</s>';
        } else {
          $show_normal_price = $currencies->display_price($display_normal_price, zen_get_tax_rate($product_check->fields['products_tax_class_id']));
        } 

perhaps something like:

        if ($product_check->fields['product_is_free'] == '1') {
          $show_normal_price = '<span class="productFreePrice"><s>' . $currencies->display_price($display_normal_price, zen_get_tax_rate($product_check->fields['products_tax_class_id'])) . '</s></span>';
        } else {
          $show_normal_price = '<span class="productBasePrice">' . $currencies->display_price($display_normal_price, zen_get_tax_rate($product_check->fields['products_tax_class_id'])) . '</span>';
        } 

Done. https://github.com/zencart/zencart/pull/795

[keneso]

I am not sure if this is the right place, in case I apologize.

Why isn't still available the grid layout for product listing, as to give more flexibility, and being a common feature on other carts, and quite requested?
In the few carts I installed Zen Cart it was not such a hard task to add the plugin, hence IMHO making it native shouldn't be overlooked.

[Ajeh]

Plain / vanilla / fresh install of 1.5.5 code from yesterday without any demo products ....

Went to Catalog>Option Name Manager>Created an Option name of "enter your text here" with an option type of "text"
Went to Catalog>Attributes Controller>So I could apply this text option to a product and I get the following error at the top of the screen "Warning: No Option Values have been defined"
So... I cannot add a text option to my product right out of the box.
BUT... if I go to Catalog>Option Name Manager> and create a "fake" option name, and then create a value that is NOT a text option (eg checkbox, radio, etc) THEN when I go to Attributes controller, I can add my text box to my product.

That is why I am saying that if a "fake" or "example" attribute were added to the core sql, then this would not happen unless someone goes in and removes the "example" one.

I have no clue if other versions other than 1.5.5 are this way. I only tested 1.5.5

Hope that is clearer than mud!

PS - Linda let me know if you need access to my install and I will pm it to you.

When you first go to the Catalog ... Option Name Manager and Created an Option name of "enter your text here" with an option type of "text" ... did you have any other Option Names before you tried to make it?

[DrByte]

Back at the problems with the 1.3.9h to 1.5.5 upgrade...
When doing:

1. complete new install of 1.5.5 zip using download from last night.
2. new database populated by 1.5.5 install
3. delete tables on new install
4. import tables from old site
5. run database upgrade using zc_install
6. upgrade stops saying we are not at 1.5.3 and cannot upgrade to 1.5.4
7. backing up to the zc_install directory and selecting database upgrade once again.
8. Get Attachment 15947
9. Go to admin and get Attachment 15948
10. Look at database with Navicat and get Attachment 15949

Nothing we do can get us past this point.

Thanks for the test database. I found a way to log some more detailed errors, and it flagged up an error related to your customers table.
Also using Navicat I discovered that you have a single customer record in your particular DB whose customers_dob is set to '0000-00-00 00:00:00' (which is invalid in modern MySQL versions) instead of '0001-01-01 00:00:00'. Changing that lets the installer properly update the schema in the customers table for the v153 changes, and lets the installer proceed.

I can't find where customers_dob was ever set to zeros by default, so I'm reluctant to start adding SQL to the upgrade to deal with userland data problems.

[mc12345678]

When you first go to the Catalog ... Option Name Manager and Created an Option name of "enter your text here" with an option type of "text" ... did you have any other Option Names before you tried to make it?

From the couple of times identified above, it looks like a blank database (tables created to support ZC 1.5.5 created) with no attributes of any type added to table(s) before adding the one text option_name which does not populate the option_values table.

Looking at admin/attributes_controller.php lines 15-24 option related data is identified present in series.. First for option_names, then by option_values. Option_value search does not account for option_names existing that also do not have dependent option_values (text and file uploads)... An independent "search" would in some way help with this to accept/consider that the option_names that came back are those that don't have option values... Not well said:

If no option_names: error message.
If no option_values:
Cycle through the option_names, if any option_name is not text or file upload, then error like currently, otherwise carry on to next check...

And actually, even that is incomplete, because there is no test of whether the option_values relate to the option_names... But...

[mc12345678]

Thinking a little further on that... Perhaps a new function that receives pertinent data and returns whether the option_name is expected to have an option_value or nnot with a notifier included for others that may develop/have developed an option_name that inherently doesn't carry an option_value... Of course can always go the reverse and identify if the option_name does carry an option_value, either would resolve that "issue".

This second one though, would require the contributor to include a step to add the option_name to the "yes have values" list as compared to the less frequent "no don't have values" list which pretty much is an abnormality... :/

[mc12345678]

Created pull request #799 to potentially address the issue identified by stellarweb of beginning with a blank database (no attributes either option name or option value) and adding only an option name that does not have a corresponding option value required/expected. IE. Text attribute or file upload... This is unfortunately untested as a "thought experiment". Added a notifier to allow developers to "chime in" on option names that have been created that do not have option value assignments. All other added option_names would be expected to have an option value. (I considered this the more "conservative" action.)