I have 2 contexts created:

global (Condition: Sitewide | Reaction: Main Menu Block in Header)
front (Condition: Path: | Reaction: Adds various blocks to regions)

Now when you update the 'front' context with the context editor/admin and click done->save changes, the global and front contexts both get saved and the 'main menu' block disappears. This does not occur when using the structure -> context administration pages, only with the drag and drop context editor UI.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

michaellander’s picture

The title of this might not be the best, though I don't believe I can edit it. I don't think it has anything to do with the 'sitewide' condition, but rather the context editor incorrectly removes blocks from other active contexts when you go to 'save changes'.

loze’s picture

I am experiencing similar behavior. I too thought it was 'sitewide' contexts at first.

I realized that if a block does not output the $block->content variable in the block theme, context editor will ignore the block. Context editor injects some html into this variable that allows it to work with the editor js. If its not in there, it thinks it's an empty block and removes it from the context when you save.

It looks likes the context editor also needs the blocks default id "block-[module]-[delta]" if that is changed, context editor will also ignore the block.

In my case I was excluding the $block->content output and adding content to the block template for some block overrides. These blocks disappeared when i clicked save in the context editor.

loze’s picture

Title: Sitewide context blocks dissapear when editing page context with context editor. » Blocks dissapear when editing page context with context editor.
tekante’s picture

Status: Active » Needs review
FileSize
2.55 KB

Attached is a patch which should ensure blocks are not empty if the inline editor appears on the page and which should result in blocks being correctly saved. @loze - there are some items added to the content of a block that the editor hooks into so I'm not sure this path will resolve the issue if you are ignoring the content output.

febbraro’s picture

I think something might be wrong with the patch.

+      $context_ui_editor_present = &drupal_static('context_ui_editor_present');
+      $context_ui_editor_present = FALSE;          //<----------------------------------always changes static to FALSE?
+      foreach ($context_blocks as $r => $blocks) {
+        if (isset($blocks['context_ui-editor'])) {
+          $block = $blocks['context_ui-editor'];

Looks like some testing code is still in there?

tekante’s picture

That's the initialization of the value to explicitly indicate the context_ui editor is deemed not present by default. I see that is better done during the call to drupal_static. Reroll attached using new git patching steps.

febbraro’s picture

Status: Needs review » Closed (fixed)

Nice, thanks for the debugging tekante.

Commited: http://drupalcode.org/project/context.git/commit/3007df8

Jon_B’s picture

Version: 7.x-3.0-alpha2 » 6.x-3.x-dev
Status: Closed (fixed) » Needs review
FileSize
650 bytes

The problem isn't quite sorted - it doesn't quite fix the issue for menu blocks. I've created a patch that sorts this problem out.

Jon_B’s picture

Version: 6.x-3.x-dev » 7.x-3.x-dev

Sorry people, that patch was for 7.x-3.x-dev.

e2thex’s picture

FileSize
879 bytes
883 bytes

I do not think checking #markup will do we need to see what happens if we render it before we check #markeup

fuzzy76’s picture

I am experiencing something very similar to this on D6. Is it possible that this bug also exists there?

fuzzy76’s picture

This is definitely present in 6.x. We use an OpenAtrium-like setup, and our OG's comes with two blocks enabled by default. One is an activity stream, the other is an info block for general description. The info block is empty at first (the administrator needs to write the text for it). If I delete the activity stream block before writing content for the info block, both blocks are removed.

bnash2501’s picture

Is anyone able to reproduce this in D7 with the latest version of Context and Blocks?
I attempted to reproduce this using the latest of both (tried both dev and beta version of context) and in both cases, the empty menu and blocks are able to be added via reactions and moved around by both the UI and normalm context editor.

If the issue present is in fact due to empty content, then the Boxes fixes ( #1394064: Allow for inline editing of empty boxes and #1440178: Display empty block content for admins when title is marked as <none> ) should have fixed this issue.

Bibliotechie’s picture

Version: 7.x-3.x-dev » 7.x-3.0-beta3

I'm using D7 and did an upgrade on 5/4. All seemed okay but then I noticed that Body and Description fields weren't appearing on edit screens. On 5/7, I found out that backup was unavailable due to backup machine failure on 5/6. Searched and found a solution: CKEditor configuration required selection of a toolbar. Problem solved. (I mention all this as it might be related to my current problem with my site. I don't know but don't want to leave out what might be important.)
Now, Context has started to malfunction. I had installed Context 7.x-1.9 during the upgrade so that may have affected it. I'm not sure.
Here's the problem: My front page context was partially completed and nodeblocks and custom buttons were on the front page. I tried to make a change to the context, and all of the Reactions I had set in the context disappeared when I clicked Save. I have tried rebuilding the context several times but saving is sporadic at best. Any time I try to move a nodeblock or add a nodeblock, all of the nodeblocks disappear from the front page and Reaction portion of the Context UI. I can still see my nodeblocks (and feeds, etc.) with their checkboxes on the right. But, it's as if I never added the Reaction(s). The Reactions disappear so my nodeblocks don't appear on my front page. Oddly, the Context path to the front page portion selection of the context remains, that is it remains saved if I open or close the front page context.
I have searched drupal.org and other sites for answer. The Context behaviors described in this thread are the most similar I've come across so I thought I'd request help here.
Any suggestions?

tekante’s picture

I posted a patch in #1076706: menu blocks is gone after saving an existing context comment 13 that may be of interest for those whom context is dropping blocks on when using the inline editor.

ianthomas_uk’s picture

This is a duplicate of http://drupal.org/node/751062

  • febbraro committed 3007df8 on 8.x-4.x
    Issue #996426 by tekante: Context inline editor removes empty blocks.
    
    

  • febbraro committed 3007df8 on 8.x-0.x
    Issue #996426 by tekante: Context inline editor removes empty blocks.
    
    

  • febbraro committed 3007df8 on 8.x-1.x
    Issue #996426 by tekante: Context inline editor removes empty blocks.