Closed (fixed)
Project:
Ubercart Addresses
Version:
6.x-1.x-dev
Component:
Miscellaneous
Priority:
Normal
Category:
Support request
Assigned:
Reporter:
Created:
7 Dec 2009 at 21:37 UTC
Updated:
16 Dec 2009 at 22:28 UTC
I thought this function might be native to the Ubercart core since Ubercart is integrated with Drupal.
Thanks for any help,
Jeff
Comments
Comment #1
freixas commentedTough question to answer. I think the answer is "no", but maybe it's "yes".
The module adds address information to the user's profile and it does have an option for pre-populating the checkout address fields with these values (and of populating the user's profile with the address values entered in the checkout form). In that sense, yes, it does what you are asking.
However, this module does not support taking arbitrary profile data and placing it in arbitrary checkout fields. If you create your own address fields, this module won't help you.
Have I answered your question?
Comment #2
webservant316 commentedYes, thanks for the answer.
Do you know of another similar function module that can map arbitary fields?
Comment #3
webservant316 commentedI was following a thread on this module on the ubercart site and someone said "From what I can tell the best option right now is using hook_form_alter to pull addresses in from user profiles". I am a little surprised that the Ubercart integration doesn't do this out of the box. Basically I am hoping that if a Drupal user already has an account with contact info that it will prepopulate their Ubercart check if the happen to use the store AND if they check out of the store without a Drupal account that the contact info entered at checkout would be used to complete their profile if they choose to create a Drupal account. Also if they modify one or the other the changes should be reflected in the Drupal account and the Ubercart account or at least provide a means to define what happens in this case.
Does your module do that or is hook_form_alter a better choice? Where can I learn about hook_form_alter?
Thanks again for any help,
Jeff
Comment #4
freixas commentedA couple of points:
uc_addresses builds both sides of the system. It adds addresses to the user's profile and it integrates these addresses with the checkout form.
If you already have a system with addresses, you will need to create custom code to hook up your addresses with Ubercart's checkout form.
You can use the code in uc_addresses as a guide. As far as where to learn about hook_form_alter(), you may want to buy Pro Drupal Development (search Amazon) or just Google hook_form_alter(). If you've never programmed for Drupal, I will warn you that this is probably more than a half-hour of coding.
One advantage of using uc_addresses is that it is designed to use the addresses for e-commerce. In other words, it stores not just the user's address, but multiple addresses that the user may want to ship to. Each of these can have a short nickname. If you are familiar with SQL, you may find it more productive to install uc_addresses and copy your addresses into the uc_addresses database (look at the code and database to figure out how). I don't know how you added addresses to the profile, but whatever method you used will need to be removed. Once the addresses are ported, you would just use uc_addresses to enter and manage the addresses.
I'm sorry I can't walk you through every step of the process as my time is very limited. Good luck!
P.S. Of course, if you are willing to pay for my services, I would suddenly have a lot of time available! :-)
Comment #5
webservant316 commentedmy website is pre-production so I do not have any user data to worry about.
However, I am trying to make wise choices as I set the thing up. I think I
will try you module and delete the address fields I had already created in
my user profile.
One thing, will I still have control over what profile fields are public and private
like I do when defining my own profile fields with Drupal? I do not want the
user's address info to be public.
Thanks,
Jeff
Comment #6
freixas commentedYes, you can control the visibility of the addresses. Check the permissions that are added. Admin should get all, regular users should get none (in most cases). A user can always see and edit their own addresses. No one else can see them unless you give them permission.
Comment #7
webservant316 commentedI see this module is still in dev. Any idea when you will be ready to move to the first stable release? Drupal has so many modules available and I cannot risk introducing unstable software to the website I am building I have just established a policy of not installing modules unless they are listed as stable releases....though I really need this one. Maybe I could be presuaded to break my own rule.
Comment #8
freixas commentedRead the information on http://drupal.org/project/uc_addresses, particularly note #2.
Also, keep in mind that the module developers get to choose when to designate something stable or not stable. It is a somewhat arbitrary designation. Some people's dev releases are way better than other people's stable releases.
Finally, what's your alternative? Do your own coding? How will that produce a "stable" product? If you were really going to go that route, you would be better off starting with uc_addresses, testing it, fixing any problems and donating the patches back to me.
If you want this feature, I don't think there are any alternatives. If you can live without it, that's fine with me.
Comment #9
webservant316 commentedgood points. i hope to install and test your software on my drupal install.
this does raise a larger question about how someone like me is supposed to evaluate contributed modules. searching for and test driving contributed modules has been one of the most challenging aspects of using drupal. I was thinking about proposing a user and editor rating system like found on download.com OR anything that would help the better modules rise to the top. yours is the only one providing the function I need and the 'dev' notation was scaring me away and you point out that there is not a well defined path to move from dev to alpha to beta to rc to production. that could also help people like me chose contributed modules with more confidence if those designations had more meaning.
none-the-less you are confident about your module and so I will dive in!
Thanks again,
Jeff
Comment #10
freixas commentedHmmm...there might be some Drupal module ratings around somewhere. I know some people have a top 10 list.
Another possibility is to look at the Usage Statistics link on the main module page—and maybe look at the Issue list to see what kind of problems people might be having. If there is a lot of use and few complaints, it's a good sign.
Finally, the first Release Candidate has just come out, thanks to having one person fixing a major problem. The RC1 should work well, even for international sites.