OK my client wants to show a buy both feature in the cart, if they have 1 particular item type in the cart they want it to show up for another particular item type so if they buy both they can save $50 off the total. I am trying to wrap my head around what would be the best way to set this up so it couldn't be easily hacked (ie: adding both to the cart then removing one and keeping the discount)
does anyone have some general ideas in theory?
Thanks.
Why not perform the check right before they submit the order? that way, everytime they get to the submit order page, it will check if both items are present.
easy enough - always calculate the final price on the fly based on the current cart contents. The issue you mention seems like it would only be a problem if you were calculating the final price and caching it somehow.
usualy it'd done by creating a new bundle item. It's a bit dirty but works :)
Are they using a system already, or is this a custom job on your part?
Add the discount to the cart and use another table to keep track of the discount's dependencies. Whenever an item is removed from the cart, check to make sure the discount is still valid. If it is, great. If not, remove it and recalculate the cart price.
Related
I have a strange problem in magento. Everything I change in the "Inventory" tab of a product, gets resettet after I click on "save".
Has someone had a similar problem in the past?
Is there a way to simulate the saving progress step by step, so I can see where the error appears?
Until now I have tried to:
Disable all addons
Reindex everything new
Delete the complete cache in backend/via SQL/via ssh
Delete all products and categorys
Sorry for the lack of information. If you need any information please feel free to ask.
Thank you for your help!
Please try below solution may help you
I tracked this down into app/code/core/Mage/CatalogInventory/Model/Observer.php.
The event catalog_product_save_after calls the saveInventoryData method which in turn calls the _prepareItemForSave method.
Around line 225:
$originalQty = $product->getData('stock_data/original_inventory_qty');
if (strlen($originalQty)>0) {
$item->setQtyCorrection($item->getQty()-$originalQty);
}
If you comment out this line:
$item->setQtyCorrection($item->getQty()-$originalQty);
It seems to correct the problem & stock levels now stay correct when saving a product whilst simultaneously creating / canceling an order on both the front & back-end of the website.
I figured out, where the problem was:
I have over 4000+ different product attributes. Everytime I save a product, the information of all 4000 attributes are getting transmitted over post-method. This seems to be too much, and the URL are getting cutted after a fixed value of characters. So the quantity information does not getting transmitted.
Every product has only 1-30 attributes filled with information, the rest is blank. But which attributes are filled depends on the specific product. I have choosen this method of creating an attribute for each information, because I would like to set individuality if information is searchable or filterable.
The solution was to increase max_input_vars in php.ini.
Thank you!
Humm..After trying so many shopping cart codes by customizing according to my requirements I still not got proper solution.:(
I have two tables products and productoptions in which i stored the color or size of product. One product can have different sizes and colors.
Now the problem is I am unable and frustrated to integrate/ customize the code according to above scenario. There are issues coming like I can't add one product with two different colors and remove one of them. While removing one of them, the cart becomes empty.
Can anyone please suggest me how should I achieve the shopping cart with above scenario? Any online reference examples or any relevant source demo will be helpful if someone had done this type before.
Friends please suggest. I doing this first time. Thanks in advance.
It's simpler than you think.
Use sessions.
So let's say these two products have an id of 1.
Let's also admit there's no stock check, and you have an unlimited amount of products.
Whenever you add a product to your cart, add to $_SESSION['products'][]['item'] id of 1. You can also add ['color'] and such. But this will be one item.
At this point, you'll have to loop over your $_SESSION array to display your products.
Do it, and mark the div containing your product with the index that corresponds to its slot in your $_SESSION created earlier, with an input hidden for example.
Now whenever you'll click on delete, you should send the index marked in the div to the code deleting the product from cart.
With the index, delete the corresponding array in $_SESSION['products'].
Once this is done, only the remaining products will be displayed and counted in the cart.
This is only one method among many. Using AJAX is advised for a better user experience, it'll be more fluid.
But if you're new to all this, starting with simple PHP is advised.
I'm completely new on working with Magento and I'm going to create a module in order to validate and in some cases manipulate some cart/order information.
To be specific I'm gonna restrict the customer from buying an item more than X times.
I've started working on this a bit, but I'm not so satisfied with the solution.
This is how I've done it so far:
I've created a new module with a controller which subclasses Mage_Checkout_CartController and there I've implemented the addAction-method. So every time a product is added to the cart I search through the user's order history and look for previous orders containing this product. Then I prevent it from being added and trigger an error-message.
It has a lot of shortcomings. For instance, if the customer isn't logged in at the time he can add the product, you can update the cart with too many... etc.
I would be me comfortable if I could hook on events, but I don't know where to start. Haven't found so good guides about this.
I want to do this verification when listing cart, updating cart and before submitting order.
So, my questions are:
How do I add observers on these events in my module? I couldn't get config.xml-configuration for event observing to work. I also need to know the names of these events.
How do I manipulate the quantity of an item in cart / delete it? When updating cart with too many of the products I want to change the quantity and trigger an error.
If you have any other ideas on a better solution for this, you're very welcome to comment.
I appreciate any help. Thanks.
I think this article should answer on all your questions. See events list at the bottom of this article. Do not forget delete cache after each change made to config.xml and other xml files in your module etc folder.
I need the add to cart form on each product to display separate quantity fields so items of different attributes can be added at the same time. This is for a photography site, so it makes sense for the customer to order 2 6x4 prints and one 10x8.
Right now the add to cart form is something like this:
Here is a mockup of what I want to have:
I have no idea which hooks to use, or if it's even possible to add multiple product variants in one POST. Is anyone familiar enough with the Ubercart api to tell me how I can go about doing this.
I found this googling for a solution to the same problem. Unfortunately I couldn't find anything.
So I made a patch and sent it in to an issue with a similar request - http://drupal.org/node/782154#comment-3925090
The patch isn't tested very well yet, but I will be going live with it or a subsequent solution in a couple of weeks.
Hope it helps.
Say i have a Laptop for 600.00. Say i change it to $650.00. How do shopping carts handle that? Like do they store the price in the cart or the item? How do they make sure they get the price they wanted but not bill the customer the new change without asking them? Or do most store them in both?
I was thinking maybe i could store it in both.
So if the current price is over the cart price for a item, don't remove it/bill them from their cart. Then after, tell them what was billed/email a receipt for the items that didn't change that was billed(say they had more then one item) and remove it from the cart. For the items that did change, say something like "Items left in cart due to price change, please check if you still want to buy the items at the new price." So leave the items that changed in the cart but update the price in the cart.
Thats my idea on how to do it. I don't think the language should matter. Guess this is more of a logical type question. Do most shopping carts do it this way or is there a better way?
Simple shopping carts are just arrays of products that are maintained through sessions and cookies. You can do anything you want. Just make sure users can't do anything they want such as change prices through the url. But most of all make it very, very, very easy for the user to checkout.
Most developers will create an array with product objects so if any changes are made to a product shopping carts will reflect this change. However, if you change your prices then obvious you will have a problem if a user clicks on on price but then you change it and the uses doesn't see this change until after they paid or become confused why the price went up mid shopping experience.
In terms of maintaining the line item if you have users sign in before they can add things to a cart then you don't need to worry about creating a cookie/session to store the array of the line items until they do checkout and the line items are saved with their information for later reference.
In this case what you will want to do is create a line item which is associated to the object so you can get all the products information but at the same time store the price in that actual LineItem model so if you do update your price it will not affect shoppers mid buying experience.
And if you want users to pay higher prices because you change your mind and want to use the line item model you can just do what is sated in the last paragraph and check the price right before a user decides to checkout. If it is different then let them no that this product is now x amount to purchase and don't forget to apologize.
The short answer, it all depends on how it was coded.
I assume the transaction that you are talking about is in process. If the price changes after the user completes the transaction, then it would be considered a "Bad Thing" in the terms of customer service, and may potentially be illegal in the eyes of your payments processor.
I like your idea of comparing the price in the cart vs the newest price. However if the user can change the value of the price of an item in the request to view the cart, it could cause many problems with what they actually get charged. For example, if the user changed the price of the laptop to $1200, and in your code you reduced the value in their cart by the difference, they could get that laptop for $0, which would be a "Bad Thing".
$1200 - User Input
$600 - Actual Price
-$600 - Adjustment against price
$0 - price customer is charged?
Another example would be if you make the price of the item a value that the user can edit, and they are a malicious user, they could potentially change the price to -$600.00, which again would be a "Bad Thing".
The more secure way to do it would be to store the item ID of the item in the cart in the link to view the cart, then retrieve/update the price of the item in the cart every time the properties (total, etc) of the cart are requested. That way if a malicious user tried the plus or minus trick, they would just get a message that the price has been updated to the "current price".
The OWASP site has some open source security tools that can help test your code against situations where the user tries to high jack a shopping cart. Their address is http://www.owasp.org
If the cart simply contains a reference to the item (such as the id/primary key), you don't need to store the price in two places at all. You simply load the objects from the cart when you need them, and prices will automatically reflect the change. In most cases, the changes will be infrequent enough that it is not a big deal from a user perspective.