Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.When using Ubercart in conjunction with Domain Access, the Domains are not set for new users created on the checkout process.
I noticed that you had already thought of this (mainly with core profile integration?), but you decided not to implement this because of the validation issues. (see comment below)
/**
* This code adds profile fields required for registration to the
* customer checkout pane. However, I don't have the time to fool with
* validation/submission stuff, so I'm postponing this feature. -RS
I desperately needed at least the domain-integration, so I threw my 2cents in. Here's a small patch to enable extra user-data WITHOUT VALIDATION! (ya, you can shoot me now :) ).
I don't have any ideas as how to validate the possible other data, so just staging the conversation and throwing in the patch for those looking for the Domain -integration.
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | ubercart_6.x-2.x_extraaccountdata.patch | 2.19 KB | afox |
| #3 | ubercart_6.x-2.x_extraaccountdata.patch | 2.43 KB | afox |
| ubercart_domain_user.patch | 1.9 KB | afox | |
Comments
Comment #1
TR CreditAttribution: TR commentedNew features should go into 7.x-3.x first.
@afox: You assigned this issue to yourself - are you still planning on working on this?
Comment #2
afox CreditAttribution: afox commentedAs it happens, the latest update broke compatibility with the patch. I started to fix it just yesterday (what a coincidence!) and am planning to get this fixed better now. So yes, I'm still working on it. I'll be posting something today. I'm doing it D6 first and then porting a patch to D7.
Comment #3
afox CreditAttribution: afox commentedHere's a version with extra data validation added.
Comment #4
afox CreditAttribution: afox commentedHere's a new, clean patch. Had some old comments in there.
Comment #5
afox CreditAttribution: afox commentedSetting this unassigned, so maybe maintainers will review this
Comment #6
longwaveThis will at least need a setting to optionally enable this feature, and disable it by default, as we don't want to surprise anyone who is using profile fields when they upgrade.
Comment #7
afox CreditAttribution: afox commentedThat's true, but in my original context (Domain Access), I think adding the domains would be expected default behavior and shouldn't require a separate setting. Maybe adding a separate check for domain-module and then additional profile data using a setting?
Comment #8
longwaveHow can we separate the fields created by Domain Access from other profile fields in $extra?
Perhaps this would be better if we introduced a hook here where uc_domain or a similar module could handle this for the Domain Access case, and another module could introduce full profile fields if needed?
Comment #9
afox CreditAttribution: afox commentedIntroducing a new hook would be a cleaner solution for contribs like domain, but requiring a bridge module to implement a core feature doesn't sound really nice.
The core profile module has the option to disable fields in registration, that should be used whenever extra fields are created in the UI. Then, if a module is creating those extra fields, this setting would come in hand. As D6 usage stats are going down, I would create it simply with the setting, even though it might cause some confusion for the UI using profile admins. Now they would have to allow display of profile fields in two different places.
Comment #10
TR CreditAttribution: TR commentedWe will be implementing new features in 8.x-4.x first at this point, with a backport to 7.x-3.x if there is interest.