Hi,

when you want to perform a script on each domain, fired from 1 domain, you can do this:

$domains = domain_domains();
foreach ($domains as $domain) {
  
  domain_set_domain($domain['domain_id'], TRUE);
  
  ... your script ...

}

// reset
domain_reset_domain(TRUE);

This is documented in API.php at the domaincron() section.

However, I noticed an annoying bug: domain_set_domain(0, TRUE); for the root domain, does not bootstrap.

Follow this:

domain_set_domain(2, TRUE); 
// we are now using domain 2 db prefixes

domain_set_domain(0, TRUE); 
// !BUG we are STILL using domain 2 db prefixes!!

I hope I make it clear, but the domain_set_domain(0, TRUE); does not bootstrap the main domain. Which leads to problems, because you start reading from the wrong tables.

CommentFileSizeAuthor
#7 883180-prefix-bug.patch1.65 KBagentrickard
#3 883180-prefix-bug.patch1.41 KBagentrickard

Comments

Anonymous’s picture

Anonymous (not verified) commented

Is it possible that domain_set_domain(0, TRUE) causes a domain_load() >> domain_lookup() to return "-1" / FALSE? That would explain the failing over the bootstrap for domain 0.

Whatever is happening,

- either we demove domain 0 from $domains = domain_domains(); (so you have to run a separate script on the main domain)
- or we let domain_set_domain(0, TRUE); bootstrap the root domain (so you can do a full domaincron cycle, including the root domains)

Anonymous’s picture

Anonymous (not verified) commented
Title: domain_set_domain(0, TRUE); does not work » domain_set_domain(0, TRUE); does not bootstrap main domain
agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented
Status: Active » Needs review
StatusFileSize
new 883180-prefix-bug.patch1.41 KB

I think the problem here is in domain_prefix_domain_bootstrap_full(), which doesn't account for a domain reset.

Try this patch.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

I suspect Domain Conf may have the same issue, but no simple solution. Essentially, hook_domaincron() and such scripts expect to be fired from the primary domain.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

This does not affect Domain Conf, which already accounts for this condition with _domain_conf_load_primary().

Anonymous’s picture

Anonymous (not verified) commented

I'll ty the patch from #3 later tonight.

Im indeed running the script from the root domain, but my domain_domains() is like this:

2 - France
3 - Netherlands
0 - USA

I think this could be related to the "domain-sorting" choice in the admin? I set it to alphabetic by name. Maybe that is why this happens.

If you sort it by ID, it would not be a problem, then it would start with the main domain (0).

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented
StatusFileSize
new 883180-prefix-bug.patch1.65 KB

Right. This fix is proper. Problem is, as written, it doesn't account for existing prefixing. We need to trap the initial prefix value in a static var.

New patch from domain root.

zserno’s picture

zserno commented
Status: Needs review » Reviewed & tested by the community

Patch from #7 works as expected. I used the following php snippet on /devel/php (provided by devel module).

global $db_prefix;

domain_set_domain(2, TRUE); 
// we are now using domain 2 db prefixes
dpm($db_prefix);

domain_set_domain(0, TRUE); 
// NO BUG! We are NOT using domain 2 db prefixes anymore!
dpm($db_prefix);
agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented
Status: Reviewed & tested by the community » Fixed

Committed to 6.x and to Domain Prefix HEAD.

Thanks!

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.