Closed (fixed)
Project:
Domain Blocks
Version:
6.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Task
Assigned:
Reporter:
Created:
22 Oct 2010 at 23:56 UTC
Updated:
28 Feb 2011 at 18:51 UTC
Jump to comment: Most recent file
Since DA is out for Drupal 7, it's time to get started with D7 port of Domain Blocks as well.
| Comment | File | Size | Author |
|---|---|---|---|
| #12 | 950184patch2.patch | 2.94 KB | nonsie |
| #10 | do-950184.patch | 2.36 KB | nonsie |
Comments
Comment #1
nonsieTrying to find the best way to do it for D7:
Blocks in D6 were quite simple animals compared to D7. In D6 user would see block per theme and would have no indication the block might be enabled in some other theme. DA based filter would apply to the block no matter what theme was used.
In D7 all themes are shown on the block config screen. In D6 Domain Blocks would apply domain based filter (db_rewrite_sql) based on block's defining module and delta which used to be enough. In D7 it almost seems like it needs to be something extra so that it could be really defined per block per theme. At the same time core block visibility is still defined per module/delta combo not block id e.g. the visibility for the block in all themes is the same.
Comment #2
agentrickardOff the top of my head, I would approach this the way node visibility does. If people want per-theme and per-domain, then Domain Theme would be required.
Comment #3
nonsieDomain Theme would still not get per-theme and per-domain since Domain Blocks saves visibility per block no matter which theme it is rendered in.
But I think your approach is the most straightforward way to go even though per theme/per domain issue is doomed to come up sooner than later.
Also in D6 domain visibility settings used to appear before visibility settings fieldset - in D7 I'm going to move them there since there's no per-theme/per-domain settings and it logically makes sense to have visibility settings by pages, content types, roles, users and domains.
Comment #4
jonaswouters commentedsubscribing. Any progress?
Comment #5
nonsieCheck out HEAD. AFAIK it works but I could use someone else to verify it before I roll a release.
Comment #6
jonaswouters commentedI've tried the HEAD and most of the functionality seems to be working...
but I get the following error when opening an inactive views block:
Notice: Undefined variable: block in _domain_blocks_load() (line 313 of /domain_blocks/domain_blocks.module).
Comment #7
nonsieIs the number of records in your blocks and domain_blocks tables the same? This error would make sense if these two tables were out of sync.
Comment #8
jonaswouters commentedNo the number of records are not the same.
There are a couple of blocks missing in the domain_blocks table. All from the module 'views'
The ones missing have an unreadable delta (looks like a md5)
I'll try to delete these views tomorrow. Even if this fixes it, it should not happen?
Comment #9
nonsieI'm wondering how Views in D7 adds its blocks. It might be doing something different from D6.
Comment #10
nonsieThis patch should fix the issue
Comment #11
jonaswouters commentedPatch removed the error but also the domain options in block configuration.
Why remove "$form_id == 'block_admin_configure' " ? Restoring that returns the error...
This time the errors occurs when editing a new menu_block.
Comment #12
nonsieDuh moment.
Comment #13
nonsieComitted
Comment #14
agentrickardI assume this was targeted at DA 7.x.2. You may need to branch to support 7.x.3, but hopefully not.
Comment #15
jonaswouters commentedThanks. Released version works.
Comment #16
nonsieIt should work for both as Domain Blocks is only using domain_id field from DA. Other modules (Domain Locale/Relationships/Meta) are going to need a bigger overhaul to get them working for 7.x.3 branch.