In Magento, make same customer use different quotes on different browsers - php

Unfortunately, due to circumstances beyond my control, I need to make the following configuration work:
Alice logs in as a Customer with username foo.
Then Bob logs in as the same Customer (foo) on a different browser.
Alice and Bob each have separate shopping carts. When Alice adds something to the cart in her browser, Bob's cart is not affected.
In Magento's default configuration, Alice and Bob share one cart stored on the server, and thus the cart is synchronized between them. Is there any way I can force Magento's sessions to work the way I need them to?
EDIT:
Thanks for the replies! After looking into some of the hints in Alan's
answer, I guess the crux of my question is whether quotes can be made
to apply to sessions rather than to users.
Can I hook onto some login event and do something like:
Mage::getSingleton('checkout/session')->setQuoteId(null);
And still keep the cart of the user logged in on the other browser?

That is a very odd use case, but one that doesn't seem to be related to "sessions" as much as limitations of the cart. Seems like new functionality you would need to create if you want to support multiple carts per user. Functionality which would need to include UI changes and other changes throughout the system, so as to not really confuse users who might legitimately log into the site in different browsers (perhaps on different devices) and want to see their SAME shopping cart.
So I would say if you you need to think about this on a deeper level than just changing cart behavior, and think of it more as modifying base application functionality.

I've never seen a turn-key extension or cookbook solution that would allow you to do this. You might want to try asking this question over on the StackExchange Magento site — non programming questions are more welcome over there.
If I was going to build/program this feature, my general approach would be
Find an event that fires after a customer logs in, and then setup an observer for this event
In the observer, find the last unconverted "cart" for the user that just logged in using the sales/quote object (i.e. the sales_flat_quote table).
Then, still in the observer, I'd use the setQuoteId method of the cart session to make this old quote the current quote
The above is a naive approach to the problem — I'm not sure if Magento persistant cart feature would play nice with the above, but the fastest way to find out would be to implement something, test, and iterate.
This is not a simple solution, unless this functionality is a live or die business requirement, I'd skip the feature.

Related

Magento 1.9 - Product not being added to basket for logged out users

Like most Magento related issues, banging your head against the wall is often necessary to find a solution. This time however, nothing.
I am having a strange issue for customers who are logged out and trying to add items to an empty cart. It won't work for some specific product types.
I have extended the Cart Controller to add support for user inputted values instead of the standard Magento dropdown approach. This means that users could potentially input a number that doesn't yet exist yet as an associated product to my configurable (see image below).
Therefore I have implemented a system that will create the product should it not exist, then add it to the basket. This works beautifully for logged in users (and even logged out users with existing items in the basket). But it doesn't work when a logged out user has an empty cart despite it adding the success message.
My initial thought was that it was a Session related issue because users without accounts don't access the database, and also because it randomly starts working once a logged out user has items existing in the basket.
I have attempted refreshing sessions, initialising the cart, adding it twice for good measure but still nothing. Any help on this would be greatly appreciated.
Many thanks in advance.
Thanks to Bezzie It turned out to be an emulation problem. I never knew such a thing existed. Whenever you need to do admin functionality outside the admin you must set the current store as "admin". Emulation was introduced in Magneto 1.5 for this reason. Source here.
$appEmulation = Mage::getSingleton('core/app_emulation');
//Start environment emulation of the specified store
$initialEnvironmentInfo = $appEmulation->startEnvironmentEmulation(Mage_Core_Model_App::ADMIN_STORE_ID);
/*
* Any code thrown here will be executed as we are currently running that store
* with applied locale, design and similar
*/
//Stop environment emulation and restore original store
$appEmulation->stopEnvironmentEmulation($initialEnvironmentInfo);
It seems obvious when you look at it, but figuring this one out was mad! Thanks Bezzie

Store data temporarily for a none logged in user

I'd like to store data per user without any form of login system.
The user clicks an item and this item is attributed towards them (like a shopping cart, but these aren't products and nothing is sold). So the user can browse different items then basically add them to cart, effectively. I want it to work like a traditional session would, only not using a session. I read that this is discouraged in Wordpress.
What's the best way to achieve something like this in Wordpress then? Is the Transients API appropriate for this task? Or some other means?
The transients API is of no benefit to you for this particular purpose. They'd have to be specific to each user and soon enough your options table would be huge.
You need to set a cookie instead.
You can use JS (or better, jQuery) to call PHP script using ajax/post/get internal jQuery functions and then set a cookie using PHP.

Shared shopping basket over multiple sites

I've researched 2 methods that could reproduce the functionality coolblue.nl has.
They have 83 webshops, and all shopping baskets are merged. So if you add a product
to your basket on laptopshop.nl and go to one of their other shops (ie. smartphoneshop.nl) the product is already in your basket.
But how does it exactly work?
Single Sign on? I guess not, users are not required to log in
Identifying pixel? But how is the product directly available?
Unique links? They are not using it.
Can anyone give me some detailed info how i could get this to work?
Single Sign on? I guess not, users are not required to log in
Simply share the sessions between your servers. Store everything in a central memcached server. Only limitation is the cookie placed for one domain, not directly accessable by the other domain. Maybe it's JavaScript / JSONP used to circumvent this.
I personally use memcached too because it's faster, has less disc i/o, can be clustered, integrated into PHP and is dispatched from your webserver.
Identifying pixel?
Session IDs are stored per domain, so one domain usually cannot read other domains data (security). You can circumvent this using JSON(P). So you send a JSON(P) request to your central (web)session server and ask it "is there already a session for the user, if yes, return me the id".
You'd simply reuse the session then.
But how is the product directly available?
You can be sure all their Shops share the same database server and a unique product id like SKU/EAN.

Orders being placed for wrong store

I am using Magento 1.3.2 in a multi-store setup. www.example.com is the main store, and abc.example.com, foo.example.com and bar.example.com are affiliate stores with separate subdomains, separate inventory, separate carts, separate designs.
My problem is that some orders being placed through the affiliates are showing up as coming from the main store. It doesn't happen frequently, maybe once in every 1000 orders. I notice these when I go to fulfill the order and I see that the SKU is not one of mine but rather it is one of the affiliate's, despite the fact that the website, store and store view on the order screen all show the main store. I know that the customers are adding the product to their cart from the affiliate site (we don't even list affiliate products on the main site) and they go through the checkout process on the affiliate site. Does anybody have any ideas what could be causing this?
EDIT: I wish I could recreate this so I could post some code that I think might be buggy or something else helpful, but I've tried every permutation I can think of (logging in on the affiliate site vs the main site, having two carts open, adding/removing products in various sequences) but I still can't reproduce the issue.
You should follow some steps :
Make sure affiliates use different databases. Provide them with different database username/password sets. This ensures they are not messing with your database.
Make sure you have CSRF tokens, Or some URL Redirection/DNS config would make orders of affiliates to end up on the main shop.
If you feel like it, Browse web server logs to see what happened (might be time-consuming)
Provide people you ask for help with your system configuration, e.g Web Server, Server-side Scripting Language, Database Server, Operating System, etc.
If it is 1 in a 1000 problem, Then there are two general case of triggers for that:
Some particular costumers with particular system setup / clicking habits result in that.
You have concurrency problems in your code (Database Transactions?)
Hope it helped

PHP & MySQL - How should I allow my members to delete their membership from my site?

What is the best way to allow a member to delete their account if they wish to not be a member of our community? Should I simply have them click a delete button on the site? What other measures should I use?
There are a fair few good answers already, but I will add my bit here to be sure that the couple of points I want to raise are covered off (or opened to discussion).
User Actions Required to Terminate Account
As has been pointed out by other respondents, you want to make the process of terminating an account as easy, and yet as clear/safe as possible. Having a button in the Account/Profile Settings section of your site is the best place to have this function (as it tends to be there for almost all sites). And, when the user elects to terminate an account, be sure to have a confirmation message before completing that action (nothing worse than "accidentally" killing an account).
If you are interested in user retention, having an optional quick exit survey can give you a good insight into the reason why some users may be terminating their accounts, so incorporating this into the confirmation action may be useful.
Site Actions after Termination
A practice I have seen used in a few instances (and I quite like), is for an email to be generated to the User's email account when they terminate a user account.
It allows you to try and "save" the user, if retention is an issue, again, you can offer them a way of giving feedback regarding the site, and generally let them know that their contribution will be missed.
If you use the suggestion of flagging an account as "Inactive" (but retaining their data), you can advise them, in that email, the steps they can go through should they decide to return and want their old account back.
Handling of User Data after Termination
There are a few solutions here, dependent on the kind of site you are running, how much of the content is user-generated, the terms of your user agreement, etc.
General Recommendation
The simplest, easiest, and most mistake-friendly way to handle a user termination is to have a field in the user table which allows you to simply mark an account as Active/Inactive, and, when the user terminates their account, switch that to Inactive.
This allows you to recover the account, should they change their mind, run statistics on your retention rates, etc.
Sites with alot of User-Generated Content
Simply deleting a user's account when they leave can cause you problems - links from comments/articles/other content which would normally be associated with a user will break. In these instances, and so long as the User Agreement allows for it, I would recommend that you flag their account as "Terminated"/"Inactive", so that some aspects of the account can be switched off, but still retain the details required to make the rest of the site operate OK.
Sites with User-Generated, but Private, Content
In this instance, if you are planning to delete the user's details from your databases/files, you will also have to have code which will remove anything associated with that account from wherever it may be - for instance, deleting any pictures that user uploaded, any comments, etc. they entered, etc. Anything which JOINs with the user table will need to be systematically erased.
Generally, sites make you jump through hurdles to close an account. It is frustrating for the end user.
What I would have, is a Close Account button somewhere, which takes you to a page that asks you to (optionally) leave a comment why you are closing the account. This will be helpful for you, so you know why people are feeling it necessary to close their account.
Then send them an email with a unique string, that they must click to close their account.
This prevents people who may have left their session logged in from having their account closed :).
For the technical side of things, you may want to simply DELETE in MySQL from all tables their relevant data, and clean up any file based data (such as uploaded images, user specific caches etc).
First of all, you should know if you want to keep their data (for some time at least) for if they want to recover the information.
If the anser is no (much simpler). The just add a php script that when a button is pressed (in their profile) deletes the mysql (or what ever) database...
EDIT:
Measures: They should go their accounts, go to configure settings (or similar) and then delete account, they should definitely have ONE warning page
This question is very broad and is more of a general business question (potentially) rather than programming specific question. Your options are limited only by your brain power. Really, you don't have to let people leave your community at all (probably a bad idea). What services does the user receive from being a member of your community? When they leave do these all cease? How does the user's information affect you? Could you still use it even after they have left?
These are questions that only you (and your manager) can answer. I agree that it is generally pretty frustrating to cancel some accounts. Many sites don't even give you the ability to cancel at all, but they may have a mailing exclusions list or some such.
My suggestion would be to have a flag for users in the DB. When a user quits, set the flag. Once you know that user is flagged, you can manipulate any data with respect to them in any way you see fit. Want to run a report on only active users? No problem! All inactive users are flagged. You keep their data for however long and use it as you wish, and if it was a mistake and they never wanted to leave, you take 5 seconds out of your busy day to unflag them.

Categories