Dashboard uses unreliable method for identifying blocks.

I think this is mostly a duplicate of these issues:
#930670: Table-based dashboard admin page should be linked to from the dashboard only (not from the rest of the admin UI)
#601932: Allow dashboard to limit available blocks

(The UI really isn't finished yet, basically.)

But what do you mean by this?

except that when I click 'Done', the ones set at the first page snap back.

What exactly happens, and what would you expect to happen? The drag-and-drop functionality on the dashboard seems to work for me, and when I click "Done" it remembers all the changes I just made and uses them.

1. I go to the block admin style UI and put a block into one of the dashboard regions.
2. Then I go to the dashboard UI and see it there. I can move it to the other region or to the reserve at the top.
3. Then I click 'Done', and the block is back where it started.

By "back where it started", you mean back to where it was after step #1? That's definitely not what happens for me... when I try it, after clicking "Done" the block is wherever I put it last (i.e., wherever I put it at the end of step #2).

Do you have a more exact set of steps to reproduce?

The block-admin-style page is not meant to be a super-admin page, just an alternative interface for doing the same thing (mainly for accessibility reasons, although there are other potential uses too). I think most of the confusion around this can hopefully be fixed with #930670: Table-based dashboard admin page should be linked to from the dashboard only (not from the rest of the admin UI), or perhaps with some additional tweaking on top of that.

Hm, I can't reproduce that with any core blocks, but installing the Devel module (which has the "switch user" block) I can.

It looks like what's happening is that the Devel module blocks are defined with an underscore in their deltas (for example, 'switch_user' and 'execute_php'). That underscore seems to get converted to a hyphen when the blocks are being rearranged on the dashboard, and otherwise messes things up badly. Not sure what's going on - probably has something to do with http://api.drupal.org/api/function/drupal_html_id/7 converting block deltas into IDs with slightly different names, and the dashboard module getting confused by that.

I wonder if the patch I posted a long time ago at #720544: Dashboard markup and theme functions need work would help here.

To update the order of blocks when managed through the dashboard customize interface, the block's CSS id is used as identifier for an individual block. The CSS id is generated by drupal_html_id(), which (in short and amongst other transformations), does the following (with block-<MODULE>-<DELTA> as id):

1. Lowercases the id
2. Replaces ' ' => '-', '_' => '-', '[' => '-', ']' => ''

This basically is irreversible. I don't think there is a reliable way to take an id generated by drupal_html_id() and deduct the original module name and delta from this value. This also means that the scope of this issue is not restricted to just the deltas: I'm guessing that module names with an underscore will also confuse dashboard.

For example, a block CSS id "block-foo-bar-boo" could mean module = "foo" and delta = "bar_boo" (or even "bar-boo" or "baR bOo"), or it could mean module = "foo_bar" and delta = "boo". Add to that the fact that hook_block_info doesn't really impose much restrictions on allowed values for delta, and the fact that drupal_html_id() can add --<sequential_number> for ids that appear more than once on a page...

Attached is a patch that adds the module-<module name> and delta-<delta> classes to enabled blocks when displayed on the dashboard (the inactive blocks already have these classes). It's an improvement over the current situation (it fixes the issue reported in the OP), but the issue remains that CSS identifiers come with restrictions on what characters can be used, and the block's delta key does not have these restrictions, so trying to pass this data via the class attribute remains icky unless we can reliably encode/decode these or change the documentation on hook_block_info so it imposes additional constraints on the delta attribute...

Sorry, didn't mean to change the status. I tested this patch and it worked for the Devel module issues. Why wasn't it released with D7?

Subscribing

This bug is not major. However, the patch looks good. RTBC if bot passes against D8.

#7: 936798-dashboard-block-ordering.patch queued for re-testing.

bot passes, so like sun said i set it to RTBC

Subscribe

Argh this bit me again today. All my dashboard blocks vanished after updating to 7.8 :(

Rerolled the patch against the latest 8.x, and fixed some typos.

Works.

After applying the patch to recent D-7.x the empty blocks on the dashboard can be deleted.

Same problem when using user_dashboard contrib module, because it copies this code.

Makes dashboard fairly useless with contributed modules with underscores or block delta's with underscores or dashes.

Thanks, looks good!

That said: So much to HTML IDs. Good bye! We won't miss you.

sub

Issue summary template.

I'm not sure why we can't add some generic classes in the block module here rather than the preprocess - seems not impossible that contrib or custom modules might want to be able to identify blocks in a similar way. If there's a good reason for that (like that never being likely to happen and it adding extra stuff to block module only so dashboard can use it later, which is the only reason I can think of), it should be added to the preprocess function as a comment.

This patch got rid of the error, but the block will not reorder. When I save it goes back to it's original position before being drug.

Any ideas?

The patch worked against Drupal 7.12 and I can now move my blocks around in the customize dashboard screen and have it remember them when I click "done".

#16: 936798-16-dashboard-block-ordering.patch queued for re-testing.

Tried rerolling to the latest 8.x but it conflicts with #1428524: Replace all $.each() with filtered for loop, more specifically this followup (commit).

Rerolled patch from #16 against latest 8.x. Setting to 'needs review' to get some test results.

Oops I had accidentally uploaded the patch from #16 again. This is the right one.

I had left a call to console.log(). Here's a cleaned up version.

I tried to address the remarks that Catch made in #21 but adding these classes to all blocks by default is going to be messy. The problem is that we need to retain the underscores. The block module actually already adds a class that indicates the module that created the block:

  $variables['classes_array'][] = drupal_html_class('block-' . $variables['block']->module);

The problem is that it runs it through drupal_html_class() which converts the underscores to hyphens. This generates clean looking CSS classes suitable for displaying on the front end, but would not solve this issue. In effect, to make this work we would need both the underscored and the hyphened versions of the module, and the underscored version of the delta, like this:

  $variables['classes_array'][] = drupal_html_class('block-' . $variables['block']->module);
  $variables['classes_array'][] = 'module-' . $variables['block']->module;
  $variables['classes_array'][] = 'delta-' . $variables['block']->delta;

and that would result in these ugly classes:

<div id="block-dashboard-test-test-delta" class="block block-dashboard-test module-dashboard_test delta-test_delta contextual-region">

Note that the module that generates the block is duplicated, once with hyphens and once with underscores: 'block-dashboard-test' vs 'block-dashboard_test', and the delta is shown with underscores.

Please try to use the .serialize function of ui sortable to do this job. Getting the DOM element from the id every time is not a good way to go about this. See: http://jqueryui.com/demos/sortable/#method-serialize let know if you need help with this.

does not exist in D8 anymore.

Hi,

I've encountered this issue as well and I've approached the problem with a different solution where I edit the $block_string to fix the issue, replacing the dashes within the module name with underscores.

Dear all,
the patch does not stop the creation of malformed-named blocks in 7.15

best regards,
Denis

Hi I just got bitten by this bug and followed the "duplicate issue" trail to this. However, after reading through all the comments, I notice that the behavior mentioned over on #1311376: Undefined index in dashboard_page_build() is not mentioned here.

In brief, when we re-arrange some of the blocks on the Dashboard, we get messages like:
Notice: Undefined index: flag-review-block-1-2 in dashboard_page_build() (line 192 of /path/to/drupal-7/modules/dashboard/dashboard.module).

While this isn't critical since the website still works, it is highly irritating, and doesn't look good to hand over to a client!

Hope this gets fixed soon....

@swiftarrow, have you tried the patches?

And these notices are not scary at all, they are trivial.

@pfrenssen,

:) Yes, they are trivial, but not to my client :D

No, I haven't tried the patches. I've never done it before, and would like to learn how, just not when I've got the deadline of the end of this week!

Anyhow, I found a work-around: figure out how you want the dashboard to look like (don't worry about the accumulating client-scaring red notices at the top of the screen), memorize / write it down, disable and uninstall the Dashboard, then re-enable it and create your dashboard layout. Poof! No more notices, until client does something you told them not to do :)

More seriously, I'll wait till another release is rolled, (I'm hoping a bunch of modules get new releases this week!) and then will update.

Thanks for the reply!

Edit: Testimony to how Drupal is finally maturing. I've been able to build a whole database application without (so far) creating a single line of custom code! No custom modules, no "php code" inputs, even no custom theme! This, to me, says that Drupal is really progressing. Such a thing previously could only be had in Wordpress or Joomla!, and one was then severely limited in the options. Hat's Off to the developers!!!

@swiftarrow, you can find some helpful information on how to do this in the manual: Applying patches. If you do so please report back here with your findings. Also if you follow the steps that are outlined in Launching a site then your client will not see any error messages that are intended for developers.

Pfrenssen, thanks for your leads!

I don't intend to apply the patch for a couple weeks when (if) things slow down a bit. But the other link is really useful. Thanks!

Tested patch #38 on a site I'm working on and it worked for me

#30: 936798-30-dashboard-block_ordering.patch queued for re-testing.

Just tested the patch in #38. While it gets rid of the error messages, I'm now unable to update the order of or move blocks on the dashboard.

If you need a rapid solution:
- open your database (commands for mysql)
- SELECT delta, weight, region FROM block where region like "dashboard_%" and theme = "mytheme";
- UPDATE block SET weight=xxx WHERE delta='name_of_your_block';
you can also use direct write on your database to remove the annoying block errors:
- DELETE FROM block WHERE delta like "name_of_your_annoying_block-%";

and voila! keep in mind that the lowest level go on top, and the highest on the bottom.

Hope this helps,
Denis

@BBC
Can you elaborate on the details of not being able to update the order of or move blocks?

Are you receiving errors or perhaps the "Customize dashboard" link is no longer showing up for you?

In case you can live without blocks, that caused problem, placed at Dashboard, there is a quick fix to eliminate error messages - you should disable and uninstall Dashboard module. Obviously you'll have to place all unaffected blocks to Dashboard again afterwards, as it will be completely clean after re-enabling.

@pfrenssen, my apologies, I never did get around to testing that patch. The job is submitted, however, and the clients are happy. I've resumed my studies, hence my long hiatus. On the next Drupal project I'll try it out.

Just to inform that I am having the same problem in drupal 7.16
cheers

Updating to drupal 7.18 didnt remove the problem.
I patched the dashboard module with #38, removed the empty block that appeared after moving blocks and the notice dissapeared.
thanks!

Perfect Denis (#48), thank you.

#30: 936798-30-dashboard-block_ordering.patch queued for re-testing.

In Drupal 7.20.

Views sets a default block machine name with an underscore 'block_1',
hence the problem in Dashboard with custom Views blocks not correctly updated,
see #7

When manually renaming it, Views forbids the hyphen, 'block1' is ok.

tested it on D7.22 with #16. The patch still works like a charm! :)

Updated issue summary.

4 years later, what is the current status of this pretty difficult to diagnose issue.

There is another problem with Views block in Dashboard. If view is hidden because of permissions, the block is hidden (correct) but it emits notice about missing index:

Notice: Undefined index: view-name-block in function dashboard_page_build() (line: 192 in file modules/dashboard/dashboard.module).

I don't quite understand: is #16 still the patch recomended to use?

Yeah, status update? This seems kinda important...

Still occurs under 7.31. Can be replicated by adding and removing Views generated blocks to the dashboard, leaving the user with no way to neither remove the block or the 'empty' boxes that appear afterward.

The patch in #16 works just fine for me! I created a patch for Drupal 7.32 using that code. It's attached.

The patch in #63 applies and has the desired effect for me in Drupal 7.34. Thank you!

Anyone know where in the database we can remove the duplicate (empty) blocks?

Oh and Patch #63 did not work for Drupal 7.36

Note that my issue is unrelated to the Devel module as it was not installed when the error occurred.

The patch in #63 works for Drupal 7.36

@joshuautley you can go to block table. Assuming you placed views block or blocks created by other modules in dashboard_main region. You can just search region = "dashboard_main" and will see duplicate entries of same blocks. You can just delete those duplicates with weight greater than 0 or check bid first. Backup DB first :)

Linking to an issue that I just marked duplicate of this one.

I also agree with the October 10, 2010 version of myself that this should really be major priority... As far as I understand it does mess up the dashboard pretty badly, although I've never run into it myself.

#2114979: Certain module and block machine name combinations break the dashboard when blocks are added to it contains some test modules that demonstrate the issue.

Just tested the patch from #16 on Drupal 7.38. It works well.

@abenamer please test with latest patch #63

#63 works well in Drupal 7.39

If you already have errors like Notice: Undefined index: block-1 en dashboard_page_build() (línea 192 de /modules/dashboard/dashboard.module). reinstall the dashboard module afer patch.

Alek

#63 with Drupal 7.39 does not work for me.

I have a View with a name like 'custom_view' (note the underscore)

I use a block from that View.

The delta value Dashboard searches for is 'custom-view-block' but the actual name it should look for is 'custom_view-block'. The patch has no effect. Really strange is that this error showed up in Dashboard suddenly, though I had not made any changes to the Dashboard -- the View worked fine as displayed as expected without error on several refreshes of the page. Once I removed the block from the dashboard, the error STILL appears.

EDIT: Sorry it DOES work ... what happened was that the OLD block was an (empty) phantom block. The only reasonable solution was to go into the database and remove the phantom item from the 'block' table. Now I see no more errors. The patch #63 works, but if anyone experiences continued errors after patching, you may want to check for (empty) items.

#63 still applies on Drupal 7.41 and does work. I also had to delete the blocks created by this bug from the database.

Perhaps this should be done in an update script?

Attached is a patch with such an update script. I tried to consider the case when the Dashboard module is disabled when the update script runs. Also attaching an interdiff.

#63 Worked for me in D7.43

I had to manually remove the bad blocks in the devel module with:

$test= db_delete('block')
    ->condition('delta', 'irritating-block-name-here%', 'like')
    ->execute();

echo print_r($test, true);

(I miss using mysql workbench, cant use it at work).

@cpierce42 you should have tested #73 as this needs indeed an update script.

As far as I know, hook_update_N() runs on disabled modules but not uninstalled modules. So if the Dashboard module was enabled, and later disabled, but never Uninstalled, then the update runs.

#73 worked very successfully, tnx so much @jojonaloha RTBC!

RTBC

applied #73 on D7.51 (manualy) but it seems like update.php is not cleaning up the 'empty' blocks.

I applied #73 and it worked as intended.

1. +++ b/modules/dashboard/dashboard.install
   @@ -76,3 +76,74 @@ function dashboard_enable() {
   +  // If we are enabled, get list of blocks from the database
   

   Comments should (noramlly) begin with a capital letter and end with a full stop / period .

2. +++ b/modules/dashboard/dashboard.install
   @@ -76,3 +76,74 @@ function dashboard_enable() {
   +  // Go through the blocks on the dashboard and make a list of those to delete
   

   Comments should (noramlly) begin with a capital letter and end with a full stop / period .

3. +++ b/modules/dashboard/dashboard.install
   @@ -76,3 +76,74 @@ function dashboard_enable() {
   +    // If the block does not exist in all blocks, it needs to be removed
   

   Comments should (noramlly) begin with a capital letter and end with a full stop / period .

Bumped in this issue with Drupal 7.57.
Patch #84 solved this for me.

Amazing, a core issue started oct 2010 and not solved yet ....
Changed status to needs review

Patch is working fine here and makes sense.

Reroll and update the patch, mostly code style.

Fix a small comment typo.

Bumping to 7.61. This didn't make it into 7.60

+++ b/modules/dashboard/dashboard.js
@@ -212,7 +212,9 @@ Drupal.behaviors.dashboard = {
+        var block_module = $('#' + this).attr('class').match(/\bmodule-(\S+)\b/)[1];
+        var block_delta = $('#' + this).attr('class').match(/\bdelta-(\S+)\b/)[1];

+++ b/modules/dashboard/dashboard.module
@@ -423,6 +423,21 @@ function template_preprocess_dashboard_admin_display_form(&$variables) {
+  $variables['classes_array'][] = 'module-' . $variables['block']->module;
+  $variables['classes_array'][] = 'delta-' . $variables['block']->delta;

This should be using data- attributes instead of classes, which also makes the JS easier.

---

Reasoning: Both module- and delta- are way too generic classes, which could conflict with existing installations and themes.

---

The update hook makes me a little bit nervous, but there is not much we can do - as we need to clean it up.

As this is a bug this might also need a quick test to ensure no more bad blocks can be inserted.