"Starting at" price not the lowest price

[RixStix]

I call myself looking in the v1.5.x upgrade forum and the bugs forum and did not see anything related.

Product Price "Starting at" displayed is the price of the default attribute selection instead of the lowest priced attribute.

Checked using my desired template.
Checked using Classic Green.

Looked in v1.5. upgrade forum & bugs forum
Did not wipe the install and test from scratch v1.5.1 install
Link to Sandbox: srevaewniahc .info (space inserted before the (dot)
Link to product example: http://srevaewniahc .info/index.php?main_page=product_info&cPath=2_16&products_id=256 (space inserted before the (dot)
v1.5.1 with database upgraded from 1.3.9H
Upgraded using upgrade procedure.
plugins:

confirm email address
email addr exporter
orders exporter
IP blocker
CKeditor
email archive manager
monthly sales & tax summary
sales report
encrypted master password
USPS shipping
Fedex shipping
snapshot
zen colorbox

PHP 5.3.28
MySQL 5.5.37

Sandbox install prepping to go live.

[Ajeh]

If you make any edit to the product in your Zen Cart Admin and save/update, does it fix it?

[RixStix]

If you make any edit to the product in your Zen Cart Admin and save/update, does it fix it?

Add a space to the description, save, update. no change
Add a space to the product name save, update, no change
Remove 'arrow' at the end of the product name, save, update, no change

Edit one attribute price, save, update, no change.
Edit the default attribute selection price, save, update, Starting At price displayed changed to lowest priced attribute.

So, that tells me to visit all the attribute prices and edit the 'default attribute' price. Hopefully, that tells you what caused it, since I know what to do to fix it.

TNX Linda. I can visit each product to fix that unless you have a quicker fix.


I did forget to mention one plugin not listed"

DrByte's MySQL DB charset converter

[Ajeh]

Actually, the idea is:

1 there is a master_categories_id set on the Product

2 the products_price_sorter is up to date

3 Starting at Price uses the lowest price in each Attribute Option Name Group based on who is marked to be Include in Base Price in the Attributes Controller
By Default, this is figured out for you and you should not have to exclude any of the Attributes from this
Only if you want to alter the automatic calculation of the Starting At Price, would you ever need to change the default setting (YES) for:

Include in Base Price
When Priced by Attributes

Edit the default attribute selection price, save, update, Starting At price displayed changed to lowest priced attribute.

Setting the Default Attribute should have no affect to the Starting At price ...

If doing that fixed it, try and Edit/Update with no changes, does that also fix it?

[mc12345678]

Setting the Default Attribute should have no affect to the Starting At price ...

If not mistaken the change that was made was not the flag of default or not, but the price associated with the item that was marked default. Does that change the requested action/concept?

[RixStix]

Actually, the idea is:

1 there is a master_categories_id set on the Product

2 the products_price_sorter is up to date

3 Starting at Price uses the lowest price in each Attribute Option Name Group based on who is marked to be Include in Base Price in the Attributes Controller
By Default, this is figured out for you and you should not have to exclude any of the Attributes from this
Only if you want to alter the automatic calculation of the Starting At Price, would you ever need to change the default setting (YES) for:




Setting the Default Attribute should have no affect to the Starting At price ...

If doing that fixed it, try and Edit/Update with no changes, does that also fix it?

Sorry, that just went over my head.

Are you saying that it is a setting that I used incorrectly or a setting that is functioning as designed but not as I expected or "Rick had a brainfart when he upgraded the database" or none of the above.

Just visiting the attribute does not appear to change anything. An attribute field must be edited to see a change in the "Starting At" price.

• I found an example where the "Starting At" price is not that of the default selection and not the lowest price.
• So far, editing a datafield associated with the attribute currently being presented as the "Starting Price" will cause the "Starting at" price to be changed.
• In the example of the "Starting at" price not being the default selection, the Starting At price was changed to the HIGHEST PRICED attribute of the group.

[dbltoe]

One important thing Ajeh taught me long ago. You should always have a default, for display only attribute that forces the user to make a selection. Otherwise, the user might accidentally make a selection they did not want.

[RixStix]

Maybe I missed something but everything is functioning as expected in the live v1.3.9H site for these categories.
Same DB upgraded into the sandbox v1.5.1 site, appears to be functioning randomly different.

In most cases, it is the Default price that is being displayed as the Lowest, Starting At price instead of the actual lowest priced attribute.

I'm pretty sure that the attribute settings are correct, but below is a representative screen print.

Attachment 14212

I just realized that I have other categories, priced by attributes, that are not displaying "Starting at" text in V1.5.1. Only the base price is shown regardless of attribute adders. But those categories do not show the "Starting At" text in v1.3.9H either.

[DrByte]

DrByte's MySQL DB charset converter

You mean that experimental thing that says "use at own risk"?

[RixStix]

You mean that experimental thing that says "use at own risk"?

Yes DrByte. You beat me to confessing that the DBcharset converter was found to have inserted invisible characters (possibly randomly different & invisible) that were originally blank in the price_prefix and weight_prefix of the products_attributes table. If I knew those were the only invisible gremlins resulting from the use of the DBconverter, I would probably make the edits and keep the UTF8 version. Since I can't do that, I'll step back and just not use the converter.

After using the charset converter, I had looked through the DB for out of place characters and seeing none had thought all was fine.

Thankfully, Ajeh saved my bacon & figured it out while still in the sandbox. It would have been a bugger to correct if discovered weeks or months after going live.
I learned something to put in my "do not do or look for invisible gremins" memory.
I forgot how long it takes to restore the database and website files with a 1Mb connection.

Ajeh also found/fixed an unrelated problem with the 'keep_alive' timer that should not have existed. The website and DB backups were made immediately prior to installing keep_alive. Restoring the backup files did not remove all traces of keep_alive for some reason.