I have a fully functional cart, programmed with PHP that uses session cookies. My site will host items from multiple sellers and to avoid getting into PayPal parallel payments (just now) I need to be able to limit each session to items from 1 seller only per checkout. What is the best way to go about this?
I have tried counting seller IDs and running an if statement (if >1) to redirect to a slightly altered cart page requesting items from multiple sellers to be removed in order to continue.
The problem with this approach seems to be with counting the arrays (it will only count 1 id that relates to one particular item in the cart array).
Any suggestions would be greatly appreciated.
After your client choose his first item, you may refresh the pages, displaying only the newly allowed items (the ones that are from the same sellers as the first choosen item).
But it seems strange to force the user to do that...
i know this is old but it can be of help to any one searshing something like this
this is something i was working on recently so i came with this idea to group the sellers with their items
so you checkout by the seller but they still can add more items
this is much more easy to make than to limit it to one seller like how you said
Related
I had a mod made for opencart enabling me to allow my local customers add additional item to their order 24 hours before local delivery.
Basically my shop is made up of one-off items and the quantity is generally 1
The modification that was made works fine but..
Say the conditions are: Iv'e added 3 items to my cart and processed my order for local delivery.
Then.. I go to add more to my order.
The form below on my pastebin allows me to add additional items to the order but when it does it re-checks the other items on the order and because they are technically out of stock they get removed from the amend order page.
I hope ive made sense and someone wants to help. Thanks!
CODE: http://pastebin.com/CsHts0FR
Simply put a flexible check out paypal button using your own shopping cart.
one that sends each product plus quantity to the paypal payment page.
I've seen codes for multiple products, but those are not flexible. for example Payment for 2 unique items. but what about if the user buys X amount of different products? when only allows a fixed amount.
Referring to This page
Is this possible to do in PHP? If so I was thinking of something easy like an array listing each product with in the button form.
This would be possible. However, you would want to have some logic on your side that would check to see that amount that they are wanting to order and check it against your database to see the quantity that you have on hand. If they try to order more than you have on hand, you would give them a pop up telling that you only have x number on hand and that they can not order more than x amount. Then you would just populate the details and quantity that they ordered, and pass it over using the cart upload method similar to the example you provided.
What is the proper way to reindex a single item after modifications have been made to it.
Example context:
Our company relies on a third party inventory management platform called Stone Edge. We also sell items on multiple storefronts those include Magento, Amazon, Ebay and Buy.com
Once every 10 minutes Stone Edge will download all orders from the sites and then send the inventory adjustments back to our Magento store. This is done by sending a simple http request to a php script stored on our webserver with an array of key value pairs for each of the items in inventory that have had an inventory change since the last update.
After the save function is completed on each of these, the item is then re-indexed so as not to reflect a 0 inventory in-between the time of the update and the next sitewide re-index.
I've located on the Magento forums discussion about how to re-index the item:
$item->setForceReindexRequired(true);
Mage::getSingleton('index/indexer')->processEntityAction($item,Mage_CatalogInventory_Model_Stock_Item::ENTITY,Mage_Index_Model_Event::TYPE_SAVE);
Prior to this set of instructions you would see something like
$item = Mage::getModel('cataloginventory/stock_item')->loadByProduct($entityid);
$item->addQty($change);
$item->save();
However, after completing this, a problem became apparent. The items themselves were re-indexed, but if they were a member of a grouped product, then the group product was not updated.
There is an obvious issue that I will need to address. What is the best approach to this problem?
I will post an answer if I happen to come up with one.
Kindly note that the production collection related to grouped product will try to join the price index.
So you would need to run the price index and then you would see the result.
To run only price index you can run, got to magento root folder and then:
php shell/indexer.php --reindex catalog_product_price
Best of luck !
First of all, thanks for the per-product reindex code. Was looking for that.
As for updating the parents, I would collect the parent ID's of products in an array when updating the simple products.
$masterIds[] = Mage::getModel('catalog/product_type_configurable')
->getParentIdsByChild( $product->getId() )
And when you're done with the simple products, just go over the masters and set them up to be reindexed as well with ->setForceReindexRequired(true)
I'm a noob at Magento, but I was wondering if it was possible to get the users previously purchased products in his account pages?
Like last time he ordered coke and fanta. He can go to his account page and have a listing of these to re-order them quickly.
Can you tell me a) is it possible? and B) Some basic outline steps on how I could get to that.
Thanks a bunch for the help.
As #clockworkgeek said, it's totally do-able. An easy (but not very clean) way to make it would be to load all his orders, and then foreach orders load the items, then you filter the duplicates. But that could be quite consuming.
The clean way would be to build a proper query. If I remember well, there should be a table for "ordered items", it could be easily done with a join on those two tables.
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.