Support uc_ups and other shipping methods per domain

I changed a combination of permissions and enabled modules, and I might be getting somewhere. Problem is, these shipping modules use the system_settings_form and other forms don't. So the system settings forms will save their settings individually per domain, but functionality leading up to that point doesn't.

Each domain can set individual shipping settings via system_settings_form, but when selecting which shipping methods per domain to use in uc_quote for example, that form doesn't use a system_settings_form form. Is this where _domainconf() hook comes into play? Sorry for all the questions, just when you think you know your way around drupal a module like this comes along and you realize you don't know squat. Plus the therickards.com/api gives me a parked page :(

In sites/all/modules/ubercart/shipping/uc_quote/uc_quote.admin.inc there is a function that doesn't use system_settings_form, but many of its own variable_sets. Yet to configure these available methods individually a system_settings_form is used. I need to know the best way to tap into the non-system_settings_form submit functions and save these settings per domain. I apologize for all the talking aloud above. I have since disabled domain_prefix, and if I can figure this out should be on my way...

function uc_quote_method_settings_submit($form, &$form_state) {
  $enabled = array();
  $method_weight = array();
  foreach ($form_state['values']['methods'] as $id => $method) {
    $enabled[$id] = $method['uc_quote_enabled'];
    $method_weight[$id] = $method['uc_quote_method_weight'];
  }

  variable_set('uc_quote_enabled', $enabled);
  variable_set('uc_quote_method_weight', $method_weight);
  variable_set('uc_quote_type_weight', $form_state['values']['uc_quote_type_weight']);
  variable_set('uc_store_shipping_type', $form_state['values']['uc_store_shipping_type']);
  drupal_set_message(t('The configuration options have been saved.'));
}

Besides hacking things and replacing with domain_conf_variable_set.

Thanks for the help. I began a new module with 2 functions to see how it goes. function mymodule_form_alter and function mymodule_this_form_submit. mymodule_form_alter checks if its the form in question, and changes the submit handler to mine. The submit_handler of mine is basically the same code as above using domain_conf_variable_set instead of variable_set.

Seems to be working fine. Is this the right/best approach?

So far so good using form_alters. However I'm only saving stuff as of now and not actually using it anywhere yet. What do you see as the biggest obstacles? Re-writing several functions where variable_gets and _sets are used? If that's the bulk of it then I'm game to copy and paste a bunch of stuff into form_alters and use domain_conf_variable_sets and gets instead.

I don't completely understand the hook_domainconf method. If there was a better example around I'd love to study it. The user_picture example in the API uses form elements within a fieldset and I was having trouble getting it to work on uc_ups where there are no fieldsets in the form. Do you just make a "function uc_ups_domainconf()" and within it re-define the form elements that will be domain specific? What if there is no fieldset? Is there a difference? Or maybe I just didn't do it right...

And what if a module has multiple forms/functions within it, how do you distinguish in the hook what form elements belong to what function? Since the hook only needs to be prefixed with the module name.

Thank you very much for the fast reply.
1. So form_alters it is, since each store will need to enter in their own shipping settings. There may be a number of forms the store owner would need to fill out; in mymodule_form_alter I'll have a switch between all the form_id's to override each form. This could make for a lengthy file. Still okay?

2. Then on the conditional actions side, if a store wants to offer different shipping methods for different reasons - how would a guy approach that? Create a seperate ca_predicates table for each store? Maybe with some limited options and default predicates built-in that would be intuitive enough for the store admin to figure out with some instructions? That sounds scary. A better way might be to specify the shipping method per product via node_form_alter in a different module...

Your thoughts and comments are appreciated.

Thanks again for the advice. I'm using FORM_ID_alter now, much better. I have a problem when doing updates on the primary domain where the domain ID is 0. I'm getting a "Duplicate entry '0' for key 'PRIMARY' query: INSERT INTO domain_conf (domain_id, settings) VALUES (0, ...".

Strange I don't think this wasn't happening when just using form_alters. What's wrong here? And can you enlighten me any on what the static $check variable is about? I can't find anything about it.

At the bottom of domain_conf.module, domain_unserialize() is returning nothing in the domain_conf_variable_save function. Using drupal_set_message I determined everything has a value going in, but coming out of domain_unserialize I get nothing. So instead of trying to update, it tries to insert, causing the warning, and not saving settings for the primary domain.

Figured it out, kind of, I just emptied the domain_conf table and started again. Must have been some of the experimenting I was doing. I had a huge blob for the primary domain.

Anyway, these functions domain_settings_form_alter and _submit, I would like the user to be able to fill out some of these system_settings_forms themselves but not be able to apply it to any domain other than their own. So I re-wrote it, called it setdomain_form_alter and _submit and basically if it's a form that doesn't have domain_settings_form_submit in the #submit handler already (because the user won't have the permission, yet applies to store admins on their own domain), to save the setting for the applicable domain. The domain ID is called in the _submit so it can't be changed. That also may have interfered, so far working good.

I copied CA and made a merchant CA module with limited options and triggers. Merchants will be using this to setup their own CA. I have prefixed ca_predicates, uc_flatrate and uc_taxes so each store can save their own data for those mods. I made an example store with some default predicates enabled (eg. update order status) and when a new merchant is created they get a copy of the example store predicates. These cannot be changed but they can be enabled/disabled, and the store admin can add more *limited* predicates. Like for uc_flatrate for example. Taxes are working.

Comments questions welcome.

Since a customer can only checkout products from one domain at a time, I need checkouts to happen on the domain of the store whose products are being checked out.

Can anyone give me an idea how to preprocess the shopping cart block, and/or all checkout links so I can send them to checkout on the correct domain? I tried template.php but I can't get anything to take. Clearing caches and all.

function mytheme_preprocess_block_uc_cart(&$vars, $hook) {
	global $_domain;

...
	
}

It's one of the last meaty things I need before I have a working multi-seller seperate shipping environment. Need to rewrite all checkout links to checkout on the domain of the products in the cart.