ATM the only way $user is populated with location data is when Domain User Default is enabled.
Steps:
1. add domain_geolocalization_store_user_locative_information to domain settings
2. remove dependencies on Domain User Default/Domain Session Default and use Session API instead
3. (if 1 is set as true) in domain_geolocalization_init() check if Domain User Default is enabled, if not populate $user based on current domain's locative data if it is not yet set(first time visit) or possibly update $user if the user had switched between domains
Thoughts?
| Comment | File | Size | Author |
|---|---|---|---|
| #11 | 679232-domain_geolocalization-DRUPAL-6--1.patch | 19.19 KB | nonsie |
| #10 | 679232-domain_geolocalization-take4.patch | 13.48 KB | nonsie |
| #5 | 679232-domain_geolocalization-take3.patch | 7.2 KB | nonsie |
| #4 | 679232-domain_geolocalization-take2.patch | 6.23 KB | nonsie |
| #2 | 679232-domain_geolocalization-DRUPAL-6--1.patch | 6.23 KB | nonsie |
Comments
Comment #1
nonsieDigging a little deeper storing user's locative information in general should be optional eg. when domain_geolocalization_store_user_locative_information in domain settings is enabled user data (authenticated and anonymous) will be stored in domain_geolocalization_location_instance table and available in $user object. If this setting is turned off, all Domain Geolocalization will do is provide location information for the domain and not for the users browsing it.
Comment #2
nonsiePossible patch attached. Not quite sure what to do with domain_geolocalization_international_domain_selector_form_submit() though.
Comment #3
jhedstromUnfortunately I don't have my multi-domain testing environment up and running so I can't quickly test if this actually works, but looking at the patch itself, this looks like a solid approach.
One very minor nitpick:
Passing a variable in by reference will throw errors or warnings on newer versions of php:
instead, the function, if it isn't already, should define that the $account parameter is passed by reference:
and then, when calling the function, the $account parameter is passed normally:
Comment #4
nonsieCorrected patch attached.
What's your opinion of providing update functionality for this feature? I'm thinking that for users with Domain User Default enabled storing user data should be turned on while a notification should be displayed for the rest.
Comment #5
nonsieTake 3 with an update
Comment #6
jhedstromThe update hook would only apply to sites that have both user default and geolocalization enabled right?
Comment #7
nonsieThat's correct since an update wouldn't run for a module that is not enabled.
Comment #8
nonsieComment #9
nonsie@todo - User zip code is not stored on form submit
Comment #10
nonsieThe approach was not quite accurate. We want to keep user's zip code if the user's "new" domain is the domain the user is currently on. We also only need to update user data if:
1. the zip code entered does not match current domain (user is redirected to the same domain)
2. user is redirected to a new domain
Comment #11
nonsieBetter patch attached