13 replies [Last post]
gjmokcb's picture
Offline
Uber Donor
Joined: 11/17/2008
Juice: 60
Was this information Helpful?

Yikes! In my multisite environment, changing a payment setting on one site changes the same setting on all sites. I don't think it's supposed to work that way. Site-specific payment settings are mission-critical. Is there a trick? Someplace I should look for a problem?

Thanks.

Ryan's picture
Offline
Joined: 08/07/2007
Juice: 15438
Re: Multisite Payment Settings

It seems like this could only be happening if you're sharing the variables table... are you?

gjmokcb's picture
Offline
Uber Donor
Joined: 11/17/2008
Juice: 60
Hard-code it?

I suppose I could hard-code the settings in each site's settings.php file, but that seems clunky. Is there a better way?

Ryan's picture
Offline
Joined: 08/07/2007
Juice: 15438
Re: Hard-code it?

My question was more related to how you've configured your multi-site setup. Payment settings are stored in a site's variables table, which (afaik) is supposed to be unique for each site.

gjmokcb's picture
Offline
Uber Donor
Joined: 11/17/2008
Juice: 60
Variable table

My multisite setup didn't result in separate variable tables. Don't know why or whether, it just didn't. I've been wondering about that.

What I've done with other elements (store name, store address) is just hard-code them into the settings file like this:

$conf = array(
'site_name' => 'New Site',
'theme_default' => 'x_newsite’,
'anonymous' => 'Guest',
'site_frontpage ' => 'newfrontpage',
'site_mail' => 'newemail@newemail.com',
'uc_store_name' => 'newname',
'uc_store_owner' => 'newowner',
'uc_store_phone' => 'newphone',
'uc_store_postal_code' => 'newzip',
'uc_store_city' => 'newcity',
'uc_store_street1' => 'newstreet1',
'uc_store_street2' => 'newstreet2',
'uc_store_zone' => 'newstate',
);

and I could add:

'uc_credit_payment_method' => '0',
'uc_check_mailing_company' => 'newsitecompany',
'uc_check_mailing¬_name ' => 'contact@newsite.org',
'uc_check_mailing¬_street1 ' => ' newsite street one',
'uc_check_mailing¬_ street2' => ' newsite street two',
'uc_check_mailing¬_city' => 'newsite city',
'uc_check_mailing¬_ zone' => '[get uc state code; tx is 57]',
'uc_check_mailing_postal¬_code' => 'zip code',
'uc_check_mailing_country' => '840',

but I thought multisite was supposed to let me do it through the administration interface. If now, I guess I'll survive.

By the way, your responsiveness is fantastic and greatly appreciated. I think I'll donate.

gjmokcb's picture
Offline
Uber Donor
Joined: 11/17/2008
Juice: 60
Install?

Hmmm, wonder if it's because I didn't run install.php in each new subsite directory.....?

gjmokcb's picture
Offline
Uber Donor
Joined: 11/17/2008
Juice: 60
Nope.

Nope, that's not it. You gotta hard-code the settings file. Or you could do shared/separate tables as mentioned somewhere on the Drupal site, but that creates new tables in the db and means that nothing from the variable file will be shared. I want most variables shared, but a few not.

Ryan's picture
Offline
Joined: 08/07/2007
Juice: 15438
Re: Nope.

Hmm... it sounds based on your last comment (just before my prior post) that you might not want a traditional multisite setup. You might just take a moment to post up your goals w/ the installation so I can know what your target is.

Ryan's picture
Offline
Joined: 08/07/2007
Juice: 15438
Re: Install?

Yeah, it sounds to me like maybe multisite wasn't configured properly. The gist of it, if we're thinking of the same thing when we say "multisite", is you should...

  1. Install Drupal to the web server.
  2. Setup your domain names and subdomains to point to that single install of Drupal.
  3. Setup a new sites/* folder for each domain/subdomain using the special directory naming mentioned in the comments in settings.php.
  4. Then you should have to setup a separate database for each site and perform an install at each domain/subdomain.

This will let you configure each site independent of the settings, modules, themes, etc. installed on the other sites. The advantage of a setup like this is then you only have to maintain a single code base... so you'd only have to update Drupal or Ubercart in a single location to affect all the sites. You'd still have to go through and run update.php individually at each site, though.

Also, thanks for your kind words. Any donation would be gladly accepted. Smiling

gjmokcb's picture
Offline
Uber Donor
Joined: 11/17/2008
Juice: 60
Errata

correction for those who are trying this out: the field to enable/disable credit cards at checkout is uc_payment_method_credit_checkout, not uc_credit_payment_method.

Ryan's picture
Offline
Joined: 08/07/2007
Juice: 15438
Sounds awesome. Thanks for

Sounds awesome. Cool Thanks for taking the time on the write-up. I'm not sure if you're familiar with it or not (or if it even applies) but there's been work done around a module called Domain Access. I'm not sure it will work without subdomains, though.

Jurgen8e's picture
Offline
Joined: 10/02/2008
Juice: 83
Re: Sounds awesome. Thanks for

Some simple notes (and a question) about using domain access with Ubercart can be found here:
http://www.ubercart.org/forum/support/9068/uc_store_domainconf_multisite...

gjmokcb's picture
Offline
Uber Donor
Joined: 11/17/2008
Juice: 60
OK and How-To

Everything is lovely now. I will explain the circumstance and the correct config so that others might find it. This is mainly a how-to for others.

My setup is "multisite" in that visitors will access a single Drupal install from a number of separate domains. We do that by redirecting their domain to the correct Drupal subsite.

Our Drupal install is in the base url of othersite.com. Our server does not like subsite folders in the base url (url would read subsite.othersite.com) and insists that the subsites be only in the sites directory (url reads othersite.com/subsite, but the actual subsite folder is sites/othersite.com.subsite). That's fine, because we want to share a single database. Only subsites that do not share a common database need to be in the base url.

My site has a great deal of shared content, thus the single database. If I have subsites bonkers, wonkers, and wankers, a member of any of them can see the shared content.

I also have content that is specific to a single subsite. A member of bonkers can see the site-specific content of bonkers, but cannot see the site-specific content of wonkers and wankers. I handle this through taxonomy, using the Taxonomy Access Lite module.

The same taxonomy allows UberCart products to vary between bonkers, wonkers, and wankers. A member of bonkers can see common products and can see bonkers site-specific products, but cannot see site-specific wonkers or wankers products. One key product type is memberships. I create a membership product for each site, and use Workflow-ng to grant the membership role corresponding to the site on which the membership was purchased. Thus I have separate membership types, and separate membership roles, and separate membership product workflows, for each site. It's easier than it sounds. Three quick settings. If you buy a membership on bonkers, you are granted a bonkers membership role and can see (and create) the content that bonkers members can see.

In the same way, a bonkers administrator can change selected settings for bonkers, but not for wonkers and wankers. I use basic Drupal access to determine which settings they can change, and TAC Lite to determine which site they can administer.

Unlike with memberships, I set up a single administrator role, rather than separate site-specific administrator. I (manually) upgrade a site member to administrator on their profile page, where I also use the ability of TAC Lite to create taxonomy access rights (to bonkers, wonkers, or wankers) applicable to that one administrator. I could do this with members, too, but doing manual settings for zillions of members would make me crazy, thus I create separate site-specific roles for members.

All members have access to the store, where they buy memberships and other things. As mentioned above, TAC Lite determines which products they can see. But in my situation, each site is in fact a separate organization. Different people own and run the individual organizations that share the Drupal site. Bonkers, wonkers, and wankers share the Drupal install, and share some content, but they are different people who do not share bank accounts. They are separate entities. I do not care to channel all of their transactions through my credit card accounts, because I would have to do a lot of bookkeeping. So I need to have separate payment setups for each subsite. Hmmm.

I do that by hard-coding each subsite's setup.php file, in their subsite folder. I separately specify whether each site takes checks. If they do, I separately specify the address to which the checks should be sent. I can separately specify whether each site takes credit cards, what cards they take, and what their account numbers, etc. are. It is just a matter of identifying the correct field in the database's "variable" table, and specifying a custom value in the settings.php file. The code to do so is already at the bottom of settings.php. All you do is add some fields. The process is detailed in an earlier post of mine, above.

Now I have multisites with a common database. They share a lot of content, and don't share other content. The settings.php file allows them distinct names, addresses, and so forth. They share a store in which their members can buy common products and site-specific products. The settings.php file allows each site to independently decide whether to take checks or credit cards, and to specify their own addresses and credit card account details. (Of course, I control access to the settings.php file, so I make those settings for them when they set up their subsite.)

And, of course, I have a variety of themes from which each subsite can choose. A different look, different logo, different graphics, different block layout for each subsite. (Drupal tracks block layouts and some other stuff nicely for multisites that share a single database, even though it won't separately track content without taxonomy. Strange but true.)

It works for me.

brandontrew's picture
Offline
Joined: 11/04/2008
Juice: 35
Brilliant! But I need your help PLEASE!

Hello

Your solution may have saved my life.
My understanding of the "domain access" module, is that it enables separate products and store "look and feel" to be generated for each new domain, however the PAYMENT details and CURRENCY remain the same in all domain instances. Is this right?

What I need is what you have suggested, which is that all products are the same (and look and feel is the same) except only CURRENCY and PAYMENT are different (as in a multi-country solution for a company)

PLEASE can you help me, by publishing a complete list (if the one you demonstrated above isn't complete) of all of the variables I need to manually set?

I need some countries to pay by credit card through one 3rd party provider, and other countries to pay by credit card through other 3rd party providers. How did you go about finding out what these settings should be?

In setting up your multi-site, did you install ubercart in the default directory, then change settings.php in all sub sites, or did you install separate instances of ubercart in all subsites?

Are there any other tables within ubercart that i need to share, or make sub-site specific, in order to get this solution to work?

This would save my life.

Thanks!!!!