Problem/Motivation

There is an issue with the Devel module conflicting with the Dashboard module. At admin/structure/dashboard blocks can be successfully placed into dashboards regions. However, at admin/dashboard dragged blocks don't retain their new location. This is because the Devel module, which has the "switch user" block, is converting underscores to hyphens when blocks are rearranged on the dashboard, affecting block CSS IDs and block deltas.

Steps to replicate:

  1. Go to the block admin style UI (admin/structure/dashboard) and move the 'switch user' block into one of the dashboard regions (sidebar).
  2. Go to the dashboard UI (admin/dashboard). The block is in the sidebar.
  3. Click configure.
  4. Drag the block to the main content region.
  5. Click 'Done'.

Proposed resolution

Add module-<module name> and delta-<delta> classes to enabled blocks.
Patch in #16 implements this fix for D7 and D8.

Remaining tasks

  1. Patch in #16 is RTBC.
  2. Patch needs backport to D7.

User interface changes

Two additional CSS classes will be available on dashboard blocks: module-modulename and delta-N. Blocks will be correctly ordered based on these classes.

API changes

None.

Original report by [joachim]

At admin/structure/dashboard I can place blocks into two dashboard regions, yet at admin/dashboard I still appear to be free to move them around to either region ... except that when I click 'Done', the ones set at the first page snap back.

This is confusing. In fact, the whole business of having two pages is confusing -- the UI doesn't explain why there are two and how they relate to each other.

Files: 
CommentFileSizeAuthor
#63 936798-63-dashboard-block-ordering.patch2.08 KBnwehner
PASSED: [[SimpleTest]]: [MySQL] 40,921 pass(es).
[ View ]
#38 936798-38-dashboard-malformed_module_name.patch1.04 KBkchh90
PASSED: [[SimpleTest]]: [MySQL] 39,354 pass(es).
[ View ]
#36 936798-36-dashboard-malformed_module_name.patch1.04 KBkchh90
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 936798-36-dashboard-malformed_module_name.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#30 936798-30-dashboard-block_ordering.patch2.16 KBpfrenssen
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 936798-30-dashboard-block_ordering.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#29 936798-29-dashboard-block_ordering.patch2.19 KBpfrenssen
PASSED: [[SimpleTest]]: [MySQL] 36,808 pass(es).
[ View ]
#27 936798-16-dashboard-block-ordering.patch2.08 KBpfrenssen
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 936798-16-dashboard-block-ordering.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#16 936798-16-dashboard-block-ordering.patch2.08 KBpfrenssen
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 936798-16-dashboard-block-ordering.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#7 936798-dashboard-block-ordering.patch2.33 KBmr.baileys
PASSED: [[SimpleTest]]: [MySQL] 29,894 pass(es).
[ View ]

Comments

David_Rothstein’s picture

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.

joachim’s picture

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

Ah right.

> What exactly happens, and what would you expect to happen?

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.

If the intention is that the block admin style UI is a sort of super-admin settings page where some blocks can be locked into place, then the regular dashboard UI needs to enforce that properly and not let me drag the blocks around that it's not going to let me change.

But then, part of the problem as you say is that the UI is finished and I am not sure what these two pages are meant to accomplish in tandem.

David_Rothstein’s picture

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.

joachim’s picture

Yes, the block goes to where it was put on the *other* admin page.

Steps to reproduce, which I've just done on a totally clean CVS updated D7, using Bartik as the admin theme:

1. admin/structure/dashboard -- move the 'switch user' block into dashboard sidebar.
2. admin/dashboard -- notice the block is in the sidebar
3. click configure
4. drag the block to the main content region
5. click 'Done'
6. notice the block is in the sidebar again.

This seems to only work with some blocks, and I can't see the pattern yet. 'Who's new' sticks where I put it, for instance.

Also, probably unrelated, but I get several things that look like blocks but just say '(empty)' and this warning several times:

# Notice: Undefined index: switch-user--2 in dashboard_page_build() (line 162 of /Users/joachim/Sites/7-drupal/modules/dashboard/dashboard.module).

David_Rothstein’s picture

Title:weird interactions between the two dashboard pages» Block deltas with underscores in their names can't be rearranged on the Dashboard
Priority:Normal» Major

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.

David_Rothstein’s picture

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

mr.baileys’s picture

Title:Block deltas with underscores in their names can't be rearranged on the Dashboard» Dashboard uses unreliable method for identifying blocks.
Status:Active» Needs review
StatusFileSize
new2.33 KB
PASSED: [[SimpleTest]]: [MySQL] 29,894 pass(es).
[ View ]

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...

cindyr’s picture

Status:Needs review» Active

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?

cindyr’s picture

Status:Active» Needs review
joachim’s picture

> Why wasn't it released with D7?

It needs further review...

I'm a bit wary of the need to implement a theme preprocess hook :/
Is there no other way to do this?

akanouras’s picture

Subscribing

sun’s picture

Version:7.x-dev» 8.x-dev
Priority:Major» Normal
Issue tags:+needs backport to D7

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

sun’s picture

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

ParisLiakos’s picture

Status:Needs review» Reviewed & tested by the community

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

pfrenssen’s picture

Subscribe

pfrenssen’s picture

StatusFileSize
new2.08 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 936798-16-dashboard-block-ordering.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

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.

derjochenmeyer’s picture

Works.

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

j0rd’s picture

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.

sun’s picture

Thanks, looks good!

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

GloGi’s picture

sub

GloGi’s picture

Issue summary:View changes

Issue summary template.

catch’s picture

Status:Reviewed & tested by the community» Needs work

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.

jsheffers’s picture

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?

cindyr’s picture

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".

VladSavitsky’s picture

Status:Needs work» Needs review
Issue tags:-needs backport to D7

Status:Needs review» Needs work
Issue tags:+needs backport to D7

The last submitted patch, 936798-16-dashboard-block-ordering.patch, failed testing.

pfrenssen’s picture

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

pfrenssen’s picture

Status:Needs work» Needs review
StatusFileSize
new2.08 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 936798-16-dashboard-block-ordering.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

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

Status:Needs review» Needs work

The last submitted patch, 936798-16-dashboard-block-ordering.patch, failed testing.

pfrenssen’s picture

Status:Needs work» Needs review
StatusFileSize
new2.19 KB
PASSED: [[SimpleTest]]: [MySQL] 36,808 pass(es).
[ View ]

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

pfrenssen’s picture

StatusFileSize
new2.16 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 936798-30-dashboard-block_ordering.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

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

pfrenssen’s picture

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:

<?php
  $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:

<?php
  $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.

nod_’s picture

Status:Needs review» Needs work
Issue tags:+JavaScript

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.

ryanoreilly’s picture

Status:Needs work» Needs review
ryanoreilly’s picture

Status:Needs review» Needs work
nod_’s picture

Version:8.x-dev» 7.x-dev

does not exist in D8 anymore.

kchh90’s picture

Status:Needs work» Needs review
StatusFileSize
new1.04 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 936798-36-dashboard-malformed_module_name.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

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.

Status:Needs review» Needs work

The last submitted patch, 936798-36-dashboard-malformed_module_name.patch, failed testing.

kchh90’s picture

Status:Needs work» Needs review
StatusFileSize
new1.04 KB
PASSED: [[SimpleTest]]: [MySQL] 39,354 pass(es).
[ View ]
denix’s picture

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

best regards,
Denis

Swift Arrow’s picture

Title:Dashboard uses unreliable method for identifying blocks.» Dashboard uses unreliable method for identifying blocks and gives scary notices as a result.

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....

pfrenssen’s picture

Title:Dashboard uses unreliable method for identifying blocks and gives scary notices as a result.» Dashboard uses unreliable method for identifying blocks.

@swiftarrow, have you tried the patches?

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

Swift Arrow’s picture

@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!!!

pfrenssen’s picture

@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.

Swift Arrow’s picture

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!

Dentorat’s picture

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

denix’s picture

BBC’s picture

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.

denix’s picture

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

kchh90’s picture

@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?

renat’s picture

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.

Swift Arrow’s picture

@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.

drupalerocant’s picture

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

drupalerocant’s picture

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!

xaa’s picture

Perfect Denis (#48), thank you.

Fluckysan’s picture

raiatea’s picture

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.

sabotagenl’s picture

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

sabotagenl’s picture

Issue summary:View changes

Updated issue summary.

crystaldawn’s picture

Issue summary:View changes

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

Bobík’s picture

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).

adam1’s picture

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

chien_fu’s picture

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

kevinquillen’s picture

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.

nwehner’s picture

StatusFileSize
new2.08 KB
PASSED: [[SimpleTest]]: [MySQL] 40,921 pass(es).
[ View ]

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

svenaas’s picture

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

joshuautley’s picture

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.

eric.chenchao’s picture

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 :)

David_Rothstein’s picture

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.

cilefen’s picture

abenamer’s picture

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