editable_block breaks block rendering

I am having the same problem.

Adding tag for tracking

The main issue is that the content is already rendered so adding a sibling key to content (context in this case) doesn't actually result in that markup being added to the page and when using the inline editor blocks aren't saved. Attached is a patch which moves prefix and suffix as well to see how that works for you.

I agree that this is a major issue. The problem is that modules and themes that alter the page content need to know, in a deterministic fashion, where the page element occur. If the location of the page elements start moving around based on permissions, things start breaking. The patch in #1 prevents the nesting, which is a step in the right direction, but breaks the inline editing of the context blocks (as mentioned in #4). The patch in #4 doesn't fix anything, because the nesting still happens.

My solution is to implement a theme_wrapper that inserts the proper markup for each block. This handles the case in #4, and does not modify the existing render array stucture. Please review.

This is great.

I added this patch so that I could stop the a tag from being added at all and only then did I realise that I had been working around this problem (my code broke when I added this patch because I was working around the extra content array).

Can someone clarify for me what this link is actually for and when it is used?
It seems to be for inline context editing, am I right?

If so it should not even be added if inline editing is not being used.

I am not using inline editing and these links are never actually visible, but having them in the markup causes me problems (I need to wrap my block content in a link but links in links = bad).

If I'm not way off track I will open a new ticket regarding not adding the link when it shouldn't be added.

Nit pick code review (I think it's probably RTBC after this):

+++ b/plugins/context_reaction_block.inc
@@ -299,15 +299,7 @@ class context_reaction_block extends context_reaction {
-      }
+      $block->content['#theme_wrappers'][] = 'context_block_edit_wrap'; ¶

Trailing space.

+++ b/theme/context_reaction_block.theme.inc
@@ -128,3 +128,11 @@ function template_preprocess_context_block_browser_item(&$vars) {
+/**
+ * Theme wrapper for editable blocks

Comments should end with a full stop.
Theme functions generally should be:
@ingroup themeable

Also, when this is committed there needs to be a notice in the release notes for the next version that it changes the array structure as it will possibly break peoples sites if they are working around this current behaviour.

Deleted erroneous post.

I have made the extremely minor changes mentioned in #6.

Since I didn't actually do any of the functionality for this patch I'm RTBCing it so it can hopefully get more attention and a commit.

Small clarification at the end

The patch in 8 (and the patch in 4) suffer from a problem where a block uses a render array for content with a prefix and suffix to wrap it in a div makes the block non positionable using the inline editor. Attached is an adjustment of #8 to change the items selector along with a small module providing blocks of various forms for testing. See if this works for you and if not it would be helpful to amend the test module with a block that demonstrates the structure of any blocks that are still problematic.

#9 is working for me on a couple of sites.

The changes make sense.

Back to RTBC for maintainer review.

Adding note to the committer about making a notice in the release notes about this change in the next release.

Committed in f1a8021.

I'll add a note to the release notes.