Empty blocks are shown

Empty blocks are inserted into the DOM to make it possible to save their position and other info when using the inline editor. They should however never show up because of this CSS rule in plugins/context_reaction_block.css

div.context-block-hidden { display:none !important; }

Can you check that your empty blocks do indeed have the class .context-block-hidden and also whether there are any aggressive styles that are overriding this one? If that's the case, perhaps there are some additional measures we can take to make this CSS selector even more specific.

Hm, the inline editing markup should not be displayed for anonymous users nor if you do not use the inline editor (e.g. you must have jquery UI to use it). In addition, context should not render empty regions unless you explicitly tell it to using the setting in the inline editor. Do you have any theme overrides that would alter the way the theme('context_block_editable_region') theme function works?

The code in particular that I am talking about is in theme/context_reaction_block.theme.inc here:

function template_preprocess_context_block_editable_region(&$vars) {
  // Check requirements.
  // Generally speaking, it does not make sense to allow anonymous users to
  // edit a context inline. Though it may be possible to save (and restore)
  // an edited context to an anonymous user's cookie or session, it's an
  // edge case and probably not something we want to encourage anyway.
  static $requirements;
  if (!isset($requirements)) {
    global $user;
    if (module_exists('jquery_ui') && $user->uid) {
      $requirements = TRUE;
      jquery_ui_add(array('ui.draggable', 'ui.droppable', 'ui.sortable'));
      drupal_add_js(drupal_get_path('module', 'context') .'/plugins/context_reaction_block.js');
      drupal_add_css(drupal_get_path('module', 'context') .'/plugins/context_reaction_block.css');
    }
    else {
      $requirements = FALSE;
    }
  }

  // Killswitch flag allowing other preprocessors to abort editable regions entirely.
  $vars['editable'] = $requirements;

  // Show when empty?
  $vars['show_always'] = variable_get('context_ui_show_empty_regions', false);

  ...
}

Maybe you can put some debugging code in this function to see if it is working properly?

Agreed, I'm seeing the issue now.

This patch should prevent all empty blocks from ever hitting theme('block') for anon users / non-inline editor using sites.

Would love some testing before committing.

I started experiencing this issue on upgrade, and the patch seems to fix it. I'll report back after more testing but it did make the empty blocks go away.

Great, I've committed the change here: http://drupal.org/cvs?commit=402606. Feel free to continue testing with dev.

Assuming you didn't mean to change the status. Thanks!

So far I can't yet confirm what still isn't working, but I don't think this fully fixes it. For unauthenticated users, the empty blocks seem to have gone away. For authenticated users, the blocks are still there in different places.

For example, I have a context set up as follows:
Condition: Path
Path: blog
blog/*
Reactions: Blocks

One of my blocks is from the requestinvite module that only shows to users when they have not yet been invited to the site. This block is showing up as an empty block to all authenticated users and the admin role. It's not a permissions issue since everyone including anonymous can see that block. The same is true for the user login block - that shows up as an empty block to authenticated users as well. That's probably easier to test with since everyone has that block from the get-go.

I moved this back to active.

I think i know what is going on... some more questions: Does the block actually appear or are you just seeing the region that would otherwise be empty being rendered? Screenshot? : )

Would still like your feedback but in the meantime http://drupal.org/cvs?commit=402856

The block appears, it's just basically empty the same way it was for the anonymous view. The login block is 'blank' where the block shows up with no content, and the requestinvitation block shows up with a link but nothing else. The anonymous users are all good to go.

Let me try the new patch and see how it goes. If it still isn't working I'll take a screenshot or add some debug info if you like. I rolled back to the previous version for the time being so I have to re-roll this.

Thanks for the help.

subscribing

Subscribe

Addressing one usability with context ui/dashboard related to these hidden blocks in #905296: context-block-region-empty not re-added after drag out sometimes.

There's also an issue in that none existant blocks never go away due, but looking to see if there's another issue open on that.

Following up with some more information here. This was tested with 3.x-dev and 3.0.

We have a block that does not have any content and as such should not be displayed. The bug is *not* present for anonymous users.

admin toolbar is not installed
context, context layouts, and context ui are enabled

The issue appears to be in context_reaction_block::is_editable(). This should only be editable if certain criteria is met, right now that criteria is any non-anonymous user and the existence of the jquery_ui module. I think this should be governed by a permission as well as the previous two conditions. FWIW I don't use the inline editor and don't use the admin module.

Since they were requested attached are two screenshots.

In the first we have a region with block display controlled by the block titles on the left. In the first screenshot the "Posts by Auth User" is active and we see the appropriate content from that block.

Now if the user clicks on "auth user's feeds" the block visibility for 'block-views-followed-feeds-block-1" should be adjusted from 'display:none' to 'display:block'. However, this does not happen because the markup for block 'views-recent_comments-block_1' is included rather than being omitted in the page rendering. As such the block with no content is changed from 'display:none' to 'display:block'.

The second block's markup is as follows;

<div class="block context-block-hidden" id="views-recent_comments-block_1" style="min-height: 187px; display: block;"><a class="context-block editable edit-user_profile_pages" id="context-block-views-recent_comments-block_1"></a></div>

missing attachments from previous.

From the README.txt in context_ui and from Young's comments above, it seems that the inline editor should only be active if both the jQuery UI and Admin modules are enabled (AND the 'Context editor' option is selected at admin/settings/admin).

If jgraham's on the right track with context_reaction_block::is_editable() being the culprit, then there's no check for the Admin module. And, along with the check for the Admin module, the 'Context editor' option needs to be checked.

Also seems like this function's name could be a little bit misleading since it has the side effect of adding js and css along with just checking if the context_reaction_block "is_editable()."

Here's context_reaction_block::is_editable() without any modifications:

  /**
   * Determine whether inline editing requirements are met and that the current
   * user may edit.
   */
  protected function is_editable($reset = FALSE) {
    // Check requirements.
    // Generally speaking, it does not make sense to allow anonymous users to
    // edit a context inline. Though it may be possible to save (and restore)
    // an edited context to an anonymous user's cookie or session, it's an
    // edge case and probably not something we want to encourage anyway.
    static $editable;
    if (!isset($editable) || $reset) {
      global $user;
      if (module_exists('jquery_ui') && $user->uid) {
        $editable = TRUE;
        jquery_ui_add(array('ui.draggable', 'ui.droppable', 'ui.sortable'));
        drupal_add_js(drupal_get_path('module', 'context') .'/plugins/context_reaction_block.js');
        drupal_add_css(drupal_get_path('module', 'context') .'/plugins/context_reaction_block.css');
      }
      else {
        $editable = FALSE;
      }
    }
    return $editable;
  }

The attached patch resolves the issue for all users that do not have the 'use admin toolbar' permission. It also skips the extra markup entirely if the admin module is not enabled.

I think this is the correct solution as users that do not have this permission will not need the extra markup and if the admin module is disabled this exempts uid==1.

Opened a new issue to review the possibility of splitting the inline editor functionality into a separate module. http://drupal.org/node/986470

Still not there. Is there a way to add region markup only after admin toolbar is opened? Content editor must see same page visitor see, otherwise it's hard to understand administration tasks.

This issue only exists because people keep 'Show all regions' option on and its hard to blame them :)

Following issue has nice patch that allows to display empty regions on request by pressing button in admin toolbar, allows turning off 'Show all regions' and renders this issue fixed (works as designed), but in my mind it needs some UX/AJAX love. #815600: Add Show empty regions toggle button

This issue is present regardless of whether or not "Show all regions" is checked. So response in comment @23 is irrelevant.

This patch adds in an additional test for the context_reaction_block_all_regions variable, which is what's behind the "Show all regions" setting at admin/build/context/settings.

I think this is now correct since the description of the "Show all regions" setting says "Show all regions including those that are empty. Enable if you are administering your site using the inline editor."

Updated patch from 25 that works with drush make.

I can confirm that patch from #26 works great for empty blocks and it solves the problem when (properly) counting blocks in region. For example, you want to add a class for last block in region, you won't be able to do it without this patch. Tested against 6.x-3.0 version. Would love to see this commited.

I've used inline editing without admin, so this would break my site at least. (Spaces Dashboard uses the inline functionality, and it has it's own set of permissions unrelated to admin).

Context 6.x-3.x-dev is no longer supported any more. Please verify if issue still occurs on context for Drupal 7 or Drupal 8.
So I'm closing it. Please reopen if error persists.