Domain Access and Domain Block (7.3 branch) compatibility

Which version of Domain Access are you running? This error message sounds more like 7.x-3.x version of Domain Access. Also which version of Custom Breadcrumbs?

I've had a similar thing happen on my test site.

Here's my setup:

Drupal 7.9
Domain Access 7.x-3.0-rc4
Domain Blocks 7.x-2.0
Custom Breadcrumb 7.x-1.0-alpha1

Here's what happened (hopefully this makes sense):

I upgraded a Drupal 6 site to Drupal 7. After enabling only Domain Access I received the error described in the original post. After performing the update all of my blocks were hidden, I had to go to the block configuration page and re-save each block to make it reappear. I received the error again when I enabled Domain Blocks. After performing the second update the blocks disappeared again, this time I had to do what morningtime described to get the blocks to reappear. Finally I received the error when I enabled Custom Breadcrumb along with Taxonomy Breadcrumb and Menu Breadcrumb, this time after performing the update only the blocks which weren't assigned to any specific domains disappeared.

It's because Domain Blocks 7.x-2.0 works with Domain Access 7.x-2.x branch, essentially there needs to be a separate Domain Blocks release for DA 7.x-3.x branch.
There's 3 ways we can get there :
1. someone will step forward and contribute a patch
2. one of my clients will need it and I'll port it for them
3. I'll suddenly have extra time on my hands

Here's a patch which starts to convert Domain Blocks to work with the 7.x-3.x branch of Domain Access.

This patch does not fix the problem where a block will not show if it has not been assigned to a domain, but it should remove the warning that appears when the module is enabled.

Thanks! I hope to finish up the rest this week and hopefully roll a release for people using DA 7.x-3.x branch

@nonsie any progesses with the Domain Blocks DA 7.x-3.x branch? Please roll out a release, we're waiting :-)

I am hoping for it too!

Here's a bit better patch - essentially all references to "domain_site" grant need to have domain id -1. DA does not allow having a 0 value in domain_id field.

I've tested the patch from comment #8. It works in so far as removing all references to domain_id 0, but still doesn't fix the original problem (then again my patch in comment #4 didn't fix the problem either).

In the course of testing I found an unrelated bug. This bug causes an error to be thrown when trying to remove a block from a domain. I've re-rolled the patch from comment #8 to include the one-line fix for this bug.

Thanks!
Note that I've committed the code so far to 7.x-3.x-dev so that everyone can follow along

Hi,
I'm attaching patch that hopefully solves all problems with 7.x-3.x branch. At least it works for me. :-)

The domain access module is IMHO a little bit to aggressive when checking for 0 in domain_id columns,
probably it should allow it if realm is domain_site. -1 is not a valid for unsigned int column, domain module
doesn't like 0, so I'm using the default domain id in this case and simply ignore the value when checking.

It also fixes the bug that causes that records were not deleted when block was - this one was here since upgrade to Drupal 7.

The assumption for DA is that domain_id is always a foreign key. Domain Source for example uses -5, I've set it to -1 in the previous patch. The issue is setting the field to signed instead of unsigned.

Here's a go against 7.x-3.x dev branch - completely untested though but you'll get the idea

I need someone else besides me to review it - it worked on my local install.

I tried applying the patch and got the following error: (against 7.x-3.x)

7.x-3.x-1333788-13.patch:39: trailing whitespace.
// Determine if there are any entries in {domain_blocks} table that would
7.x-3.x-1333788-13.patch:45: trailing whitespace.

7.x-3.x-1333788-13.patch:49: trailing whitespace.

7.x-3.x-1333788-13.patch:54: trailing whitespace.
'type' => 'int',
7.x-3.x-1333788-13.patch:55: trailing whitespace.
'not null' => TRUE,
fatal: corrupt patch at line 134

Got it to apply by doing:

wget -q -O - http://drupal.org/files/7.x-3.x-1333788-13.patch | git apply -

Wonder why it wouldn't applying regularly?

Problems:

All blocks are turned off when module is enabled for all domains, blocks should be visible on all domains if visibility is NOT selected.

This was happening because I previously installed domain blocks and never did a clean uninstall, so I am guessing hook_install never ran.

Working Great!

In testing I've found an issue related to the issue in comment #17. If a block assigned to specific domains is then removed from all domains then that block is no longer visible. This happens even if the block was assigned to domains long after the upgrade, uninstalling and reinstalling the module will not fix this.

I know how to fix this bug, but the specific fix will all depend on how blocks assigned to the domain_site realm should be handled. Therefore @nonsie, I have a couple of questions about realms.

If a block is assigned the realm domain_site does that mean that the block should be visible on all domains, or does it mean that it should be visible on the default domain only?

domain_site means the block is visible on all domains (it's been used in DA and its contrib modules since 5.x version). I'd like to keep it this way for consistency.
So, domain_id realm means it's available on a single domain only. The domain is determined by domain_id field, domain_site means all domains, no record - no domains.

Thanks for the clarification @nonsie. I've attached a patch which fixes the issue in comment #19 and all of the updates from the patch in comment #13.

Hopefully this will fix all the disappearing blocks issues, however I haven't been able to test it.

I applied this patch and installed the module with no issues.

I successfully set two different blocks to two different domains (one was the primary) and things worked as expected. I also saved a block with no checkboxes selected and this also saved correctly.

Since this resolves some fairly big issues, I want to set this to rtbc, but I will let the maintainer make that call. It would be great to see this committed and individual followup issues created.

One minor addition to a new feature of Drupal 7, specify the version in the info file:

- dependencies[] = domain
+ dependencies[] = domain (3.x)

I applied patch and it solved the issue of blocks not showing up at all, now blocks show. That said I am not sure it is working properly or I don't understand how it is supposed to work. I am trying to differentiate between two domains - main and sub1 both using the same theme. I would like block to show up on main and not sub1 (or vice versa). The only choice I am shown in the block config is a drop down showing my three domains and message
Limit block display to these affiliates. This block is visible on all domains by default using this theme.

Well one of domains uses a different theme. You mentioned check boxes, I see none.

"mentioned check boxes, I see none"

This is a domain access setting, http://www.example.com/admin/structure/domain/settings under "Domain selection format" form field.

From what I can gather, the block visibility is a combination of the theme block settings (per theme) and domain block settings (per domain).

Bingo, that did it. If you don't select that option then you cannot select blocks per domain - you definitely need the check boxes option to select blocks per domain. So the patch works as long as you set the check boxes under the Domain selection format.

Thanks everyone for pitching in. I'll roll all the patches into dev branch so that more people can get their eyes on it. Also, definitely need to fix the checkboxes vs select issue before a stable release.

I ran some tests and found that when 'Domain selection format' is set to 'select list' then on the block configuration screen a single item select list is displayed instead of the expected multiple item select list.

I've re-rolled my patch from comment #21 to include a fix to the above issue. I've also tried changing the wording of the help text to (hopefully) make it clearer.

I've tested the patch on my installation and had no issues so far.

Since this is intended for the DA 3 branch only, flagging as needs work, as it should also use the built-in Drupal requirements flag. Things can go critically bad if you are running domain (2.x)

- dependencies[] = domain
+ dependencies[] = domain (3.x)

I discovered this new additional D7 feature when looking at agentrickard's module Domain menu block.

PS: We haven't had any issues yet either with this patch.

I've committed the changes to the dev branch. We'll need to get some fresh eyes on this one before it's ready to be released though.
If there are any new issues they should be opened as new issues against 3.x branch.

I do not think that the patch applied correctly:

http://drupalcode.org/project/domain_blocks.git/commitdiff/10323fe050a5c...

Commit fail:( No -a flag = no modified files added.
I'll do a new comit once I get to my computer.

And the files are finally committed.

Does this mean a release is in the near future?

I've tested the 7.x-3.x-dev version and so far haven't found any issues.

I've rolled alpha1 for now until more people have tested it. So far it has been a limited pool of people.
It should show up under releases shortly.