So currently context just checks to see if a user is authenticated before inserting all the markup needed for editing contexts. Boo.. This breaks block styling: if you set a margin on div.block, that margin goes bye bye once the block gets wrapped in div.context-block.
Ideally, I would think this should check user access perms before adding all this jun…ahem…markup. yhahn and miccolis are not in favor of this solution as it limits what MN and Atrium are able to accomplish. Sooooo, they suggest using a variable instead.
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | context-naughty-markup-786292.patch | 2.1 KB | q0rban |
Comments
Comment #1
q0rban commentedComment #2
q0rban commentedComment #3
q0rban commentedUpdating title.
Comment #4
q0rban commentedI still don't like this solution, b/c what if I want admins to be able to edit the context blocks? grumble grumble
Comment #5
laura s commentedOne way or another, it would be nice to have some sort of option here besides some aggressive theme template overrides. Upgrading to Context 3 broke every page — not catastrophic b/c site is still in dev — but wow, two more divs around every block? That's harsh for a themer to have to clean up, all for UI "improvements" that may or may not be wanted.
Another solution might be to have themers add a "context"-specific variable into their themes (a la how skinr does it) to expose the blocks to js targeting. That way it's an opt-in thing, rather than a themers-suck-it-up-and-deal-with-it thing.
Requested with all due appreciation and cheers for an otherwise rockin module.
Comment #6
yhahn commentedNo question: the additional markup is excessive and can be a real pain to work around.
I'd like to attempt to refactor the context inline editor JS to use standard Drupal markup if possible without additional markup (requires theme to use the
#block-module-deltaconvention, some other major changes to the internals). This is pretty serious stuff but I think worthwhile.I just can't see an elegant opt-in/opt-out solution that doesn't confuse users and complicate things.
Comment #7
yhahn commentedhttp://drupal.org/cvs?commit=398520