Posted by chx on October 24, 2010 at 1:06am
25 followers
| Project: | Drupal core |
| Version: | 8.x-dev |
| Component: | dashboard.module |
| Category: | task |
| Priority: | major |
| Assigned: | Unassigned |
| Status: | postponed |
| Issue tags: | Increases learning curve, Issue summary initiative, Needs committer feedback, Platform Initiative, Usability |
Issue Summary
It's a pile of hacks upon the ancient blocks system. This is the real fix.
| Attachment | Size | Status | Test result | Operations |
|---|---|---|---|---|
| dashboard_real_fix.patch | 39.82 KB | Idle | FAILED: [[SimpleTest]]: [MySQL] 26,487 pass(es), 12 fail(s), and 0 exception(es). | View details | Re-test |
Comments
#1
I actually agree with chx on this one, after testing #601932: Allow dashboard to limit available blocks. I don't think the dashboard as it stands adds much, if any, value to Drupal core, and there is no API currently that I know of which contributed module developers can use to specify where their blocks should show on the dashboard by default.
Let's leave the idea of a dashboard to be implemented correctly in contrib, by things like Panels module.
#2
The last submitted patch, dashboard_real_fix.patch, failed testing.
#3
Will fix the patch but here are more reasons:
Blocks have a global binary status. Dashboard status is more complicated, that's what the other issue is about. It can be said that status is "block available to dashboard" / "block not available to dashboard" but what happens with "block visible on dashboard dy default".edit: i figured this one out.#4
Also note http://drupal.org/node/544360#comment-2083786
#5
Hopefully this passes tests.
#6
The last submitted patch, dashboard_real_fix.patch, failed testing.
#7
#5: dashboard_real_fix.patch queued for re-testing.
#8
I have to agree. Dashboard should have implemented its own panes and just used hook_block to get candidate content blurbs that the admin might want to insert. This nicely bypasses both theme and block systems. See the madness we have made at #950878: Disabling the dashboard module permanently removes all blocks from the dashboard and #951212: Dashboard blocks should be configured completely independently from the default/admin theme blocks.
We tried, but we fell short for D7. Dashboard is not yet core worthy. Respect for everyone who tried.
#9
I'll bet there are opinions on both sides so lets let committers chime in.
#10
Chimed in.
#11
It is very tempting to remove it. It has no maintainer, no one is paid to work on it, and no one wants to work on it.... yet it needs some real work. The only people actually writing or reviewing patches for it (I shouldn't speak for others, but this is my impression) are doing it out of some sense of obligation, not because this is really the way they want to spend their Drupal time. Not a great start for a new module in Drupal 7 :)
All that said, the above describes a lot of other modules in Drupal core too, and the world hasn't ended because of them. From an end-user perspective, the Dashboard module works fine right now (in my opinion, #951212: Dashboard blocks should be configured completely independently from the default/admin theme blocks removes the last couple of things that could really confuse people in the UI), it has no critical bugs, and it has the potential to be a killer feature, if things break right. There is no good way to do it in contrib because how would module authors be convinced to go out and write all these administrative blocks aimed at the dashboard without a critical mass of Drupal sites that have a dashboard module installed?
There are some hacks in the code but I don't think they're overwhelming. It is pushing the block module to its limits (and beyond) but doing it without the block module seems like it would lead to many worse hacks; we'd then have two independent page management systems in Drupal core. If the block module is improved (or replaced) in Drupal 8, the Dashboard module could be improved right along with it, and it's a great test case for any attempt to do that.
#12
Actually some sense of ever releasing D7. Seriously, I don't think *anyone* gives a flying hoot about this module. I'm not convinced that @David does either, but props for being diplomatic ;) I work on the dashboard module because I want to clear the issue queue and release D7. Removing it to contrib would certainly straighten our priorities. We maintain a lot of mission-critical stuff in core that is way more important than babysitting petty UX stuff for the dashboard that no one uses or cares about! +1
#13
By the way, there are already a plethora of contrib dashboard modules which can be customized per-user, per-role, etc. Our version in core looks lame in comparison. Who are we kidding? A dashboard that can't be customized for your own account...
#14
What part of "Chimed in" wasn't clear here?
We have one last critical bug to fix that's 95% fixed. Let's fix it, and move on with our lives. We don't need more distractions.
#15
@webchick: According to all the people who had been working on the issue (who were in disagreement for a long time), it was fixed *enough* that we were in agreement to get something committed, but then you bumped it down to "needs work". If you want anyone else to work on the issue more, I think you're going to have to tell them precisely what more is needed.
#16
There's no rush in removing it right now. Let's wait and see how people like it now that D7 is out.
#17
Looks like people actually like it, according to some posts on Drupal Planet.
I think the best way forward would be to refactor the blocks system, as chx has suggested for D8, and then have a new dashboard module based on the refactored blocks system.
#18
Per #1050616: Figure out backport workflow from Drupal 8 to Drupal 7, major and critical bugs are now preventing development in other areas of Drupal core. Unless this issue is actually a bug (data loss, functionality not working), we can mark this as a "major feature request" or a "normal bug", but not a "major bug". I'm not really sure if this is a "task" or "feature", but let's not mark it a bug (unless you don't want other things to move forward in Drupal core until this is fixed).
#19
lala, tag
#20
Subscribble etc.
#21
Tagging issues not yet using summary template.
#22
subscribe
#23
Srry if this hurts people...
#24
The last submitted patch, remove-dashboard.patch, failed testing.
#25
Srry xjm for driving you nuts.
#26
I could not agree more with this statement. The changes made to the "Recent content" block should also be reverted (in a follow-up, of course) because it was completely destroyed in the name of this module.
#27
Just a note. I worked in the French company that used to fund the development of the Homebox module that basically was integrated into core as Dashboard. They were proud to say that they somehow contributed to D7 core, but even them couldn't fix it, they had to fork it for an internal project and couldn't fix the fork anyway. Truly, it's so buggy it does not deserve its place into core. I'm all for removing it.
#28
Here's what I got trying to apply on the latest pull of HEAD. Maybe, just needs to be re-rolled? Sorry for not being more useful, would like to help see this move forward though.
dev-vm drupal (8.x) $ git show-branch
[8.x] - Patch #1263902 by cweagans: Code style: filetransfer.inc.
dev-vm drupal (8.x) $ git apply -v remove-dashboard-v2.patch
Checking patch MAINTAINERS.txt...
Hunk #1 succeeded at 166 (offset -3 lines).
Checking patch modules/block/block.module...
Checking patch modules/dashboard/dashboard-rtl.css...
Checking patch modules/dashboard/dashboard.api.php...
Checking patch modules/dashboard/dashboard.css...
Checking patch modules/dashboard/dashboard.info...
Checking patch modules/dashboard/dashboard.install...
Checking patch modules/dashboard/dashboard.js...
Checking patch modules/dashboard/dashboard.module...
error: while searching for:
<?php
/**
* Implements hook_help().
*/
function dashboard_help($path, $arg) {
switch ($path) {
case 'admin/help#dashboard':
$output = '';
$output .= '<h3>' . t('About') . '</h3>';
$output .= '<p>' . t('The Dashboard module provides a <a href="@dashboard">Dashboard page</a> in the administrative interface for organizing administrative tasks and navigation, and tracking information within your site. The Dashboard page contains blocks, which you can add to and arrange using the drag-and-drop interface that appears when you click on the <em>Customize dashboard</em> link. Within this interface, blocks that are not primarily used for site administration do not appear by default, but can be added via the <em>Add other blocks</em> link. For more information, see the online handbook entry for <a href="@handbook">Dashboard module</a>.', array('@handbook' => 'http://drupal.org/handbook/modules/dashboard', '@dashboard' => url('admin/dashboard'))) . '</p>';
$output .= '<h3>' . t('Uses') . '</h3>';
$output .= '<dl>';
$output .= '<dt>' . t('Tracking user activity') . '</dt>';
$output .= '<dd>' . t("By enabling blocks such as <em>Who's online</em> and <em>Who's new</em>, site users can track who is logged in and new user signups at a centralized location.") . '</dd>';
$output .= '<dt>' . t('Tracking content activity') . '</dt>';
$output .= '<dd>' . t('By enabling blocks such as <em>Recent blog posts</em>, <em>New forum topics</em> and <em>Recent comments</em>, site users can view newly added site content at a glance.') . '</dd>';
$output .= '</dl>';
return $output;
case 'admin/dashboard/configure':
// @todo This assumes the current page is being displayed using the same
// theme that the dashboard is displayed in.
$output = '<p>' . t('Rearrange blocks for display on the <a href="@dashboard-url">Dashboard page</a>. Blocks placed in the <em>Dashboard (inactive)</em> region are not displayed when viewing the Dashboard page, but are available within its <em>Customize dashboard</em> interface. Removing a block from active dashboard display makes it available on the main <a href="@blocks-url">blocks administration page</a>.', array('@dashboard-url' => url('admin/dashboard'), '@blocks-url' => url("admin/structure/block/list/{$GLOBALS['theme_key']}"))) . '</p>';
return $output;
}
}
/**
* Implements hook_menu().
*/
function dashboard_menu() {
$items['admin/dashboard'] = array(
'title' => 'Dashboard',
'description' => 'View and customize your dashboard.',
'page callback' => 'dashboard_admin',
'access arguments' => array('access dashboard'),
// Make this appear first, so for example, in admin menus, it shows up on
// the top corner of the window as a convenient "home link".
'weight' => -15,
);
$items['admin/dashboard/configure'] = array(
'title' => 'Configure available dashboard blocks',
'description' => 'Configure which blocks can be shown on the dashboard.',
'page callback' => 'dashboard_admin_blocks',
'access arguments' => array('administer blocks'),
'type' => MENU_VISIBLE_IN_BREADCRUMB,
);
$items['admin/dashboard/customize'] = array(
'title' => 'Customize dashboard',
'description' => 'Customize your dashboard.',
'page callback' => 'dashboard_admin',
'page arguments' => array(TRUE),
'access arguments' => array('access dashboard'),
'type' => MENU_VISIBLE_IN_BREADCRUMB,
);
$items['admin/dashboard/drawer'] = array(
'page callback' => 'dashboard_show_disabled',
'access arguments' => array('administer blocks'),
'type' => MENU_CALLBACK,
);
$items['admin/dashboard/block-content/%/%'] = array(
'page callback' => 'dashboard_show_block_content',
'page arguments' => array(3, 4),
'access arguments' => array('administer blocks'),
'type' => MENU_CALLBACK,
);
$items['admin/dashboard/update'] = array(
'page callback' => 'dashboard_update',
'access arguments' => array('administer blocks'),
'type' =>
error: patch failed: modules/dashboard/dashboard.module:1
error: modules/dashboard/dashboard.module: patch does not apply
Checking patch modules/dashboard/dashboard.test...
Checking patch modules/system/system.admin.inc...
Hunk #1 succeeded at 2452 (offset 41 lines).
Checking patch modules/system/system.test...
Hunk #1 succeeded at 1515 (offset -16 lines).
Checking patch profiles/standard/standard.info...
Checking patch profiles/standard/standard.install...
Checking patch themes/seven/style-rtl.css...
Checking patch themes/seven/style.css...
#29
rerolled :)
#30
The last submitted patch, remove_dashboard_from_core-1054616-29.patch, failed testing.
#32
also removing it from the standard install profile this time. :)
#33
The last submitted patch, remove_dashboard-950956-32.patch, failed testing.
#34
If people still want Dashboard, we should move them to contrib at Dashboard module.
#35
The patch applies cleanly and tests pass on the latest head.
I ran through a standard install, and it worked as expected with no errors.
The patch itself is very straight forward, and so I would mark that this is ready to go pending an ok from a core maintainer.
I'm going to be bold and mark it RTBC.
#36
So what's the actual rationale for removing it?
Looking back through the issue it seems the most recent relevant comments were these, and I don't believe they've been discussed or addressed since then:
#37
I think #26 is relevant as well, where Jacine agrees with the statement that it is a pile of hacks on the blocks system.
But I don't think we should be in a rush to remove it. Let's keep it in for now, and see whether it can be re-architected to work with the "Context" object once WSCCI moves along to Phase 3.
Tagging with "Needs committer feedback" in light of that.
#38
My committer feedback doesn't count for D8, but IMO I think Dashboard is a wonderful proof of concept module for what the block system should be capable of doing without any hacks. Therefore, if it requires hacks, let's fix the underlying block system. Additionally, removing feature modules like this makes building Snowman harder.
#39
It's tempting to remove it, yes, but right now I see absolutely no reason to do it. A year ago yes because I didnt want it in D7. Until iit blocks anything in D8, why nuke it? I would wait for Snowman.
#40
For me personally I think we should have refactored the block system before adding dashboard, but we can't go back in time two years to do that.
If it turns out to be difficult to refactor the block system because it keeps breaking dashboard tests due to reliance on quirks of the current API, then I'd be happy to do things like comment out all dashboard tests while refactoring is going on (adding a critical bug to make them pass again or similar).
In terms of just removing it, I'd like to see feedback from yoroy, Bojhan and eaton on here, which there is currently none, so I'm putting this back to CNR, but also assigning to Dries (since I have spent much of the past four years opening issues like this then having them not committed I am a bit too biased towards nuking stuff).
#41
Please use "Needs usability review" for feedback from the UX-Team, if you cant assign.
I don't think feedback from the UX-Team is needed here though. At the time that Dashboard went in we concluded that it was not up to the standards of UX in core. It was pushed in anyway, with the expectation set by Dries that this would be solved in the polish phase and by contrib provided blocks.
Sadly the latter hasn't happend. I've tried to persuade a number of contribs such as Google Analytics and Mollom to make a beautifull block, but it either resulted in a ugly one or not one at all. It simply isn't a priority for most if not all contrib maintainers.
We could employ a strategy that improves the current dashboard blocks. But I am very hesitant, because I never understood why its part of our product strategy. In Drupal the concept of a "administrative home" has laregly been mitigated by concepts such as toolbar and admin_menu. You really need it in tools such as Wordpress, Movable Type, Expression Engine etc. because you navigate to admin first, and than to your actionable items - this is not the case in Drupal. If its in, because we need to compete on functionality - than we are doing a really bad job.
This is really Dries his baby, so I will leave it up to him to give feedback that will hopefully help decide.
#42
tag
#43
Thanks, Bojhan - it's great to hear your perspective. Do you think contrib maintainers would be more interested in providing blocks for Dashboard if it were a more feature-rich system with a better UI, like the Homebox module?
#44
I still think it needs to be removed from core, because it doesn't add anything useful on it's own. If we're leaving it to contrib to make dashboard into an actual dashboard - then the dashboard itself should live in contrib.
I certainly don't think this gets in the way of Snowman, since snowman can't use contrib modules - and Dashboard is not very useful without contrib. On it's own, it just causes confusion.
#45
I agree with people that want to remove it : it's just another interface for the existing blocks management page with drag and drop. I also understand chx when he says that we should revamp the block system (well, I think everybody agrees with him). But if we wait too long before taking any action, we may not have enough time to make anything else than just remove it from core.
#46
I also agree with Dejbbz. The blocks system is already getting a revamp in D8 - and the existing dashboard will probably need to be thrown out and rebuilt anyway. Let's start now :)
#47
Bojhan gives a good overview of the UX & product considerations.
I suspect you'll find more full dashboard replacements in contrib than contribs that provide blocks for core dashboard. What I do not understand is the hurry to remove it. Does it hamper the underlying block system refactoring? It's a good test case for what a new and smarter block system should be able to support.
#48
I agree with yoroy. chx originally opened this issue back when Dashboard was blocking 7.x stable release. Now it's not blocking anything. We might as well keep it in for now as a test case, and then remove it prior to 8.x release if it seems like it's not going to be useful.
Accordingly, I think this should be marked "postponed".
#49
For me, the bottom line is that this module is currently below every standard that we have. It does not meet UX standards, code elegance standards, etc. We should not keep such code in core and hope that someone brings it up to par. I agree with Jen that it should be removed now, and a subsequent patch can bring it back when it has a better case to make. It is demoralizing to the dev team to keep subpar code in core. Who is standing up and saying "I use this module and love it and want it to stay?" I have not heard anyone. That's telling.
#50
We could fork the Drupal core version of Dashboard over to the 8.x branch in http://drupal.org/project/dashboard . The demand for it will be proved in contrib if people help support it over there.
#51
I still believe that a functional dashboard would be a great addition to Drupal core -- as proven by many other systems, good dashboards can make a big difference. Drupal has real challenges when left to use by mere humans such as editors, and we need to look for ways to address these.
I'd like to keep the dashboard module in core for the time being so we can help make sure that the block system refactoring fulfills its promise. I will revisit this decision 6 months from now on June 1st, 2012. Hopefully we'll have made some progress on improving the Dashboard module by then.
I'm marking this 'postponed' for the time being. Feel free to re-assign this to me on June 1st, 2012.
#52
Take a look at this video: http://www.youtube.com/watch?v=dzPH5t2q-Pk
It's a video of the my.fcc.gov prototype built in Drupal. It is using Drupal with a partial node.js backend.
Some of the Dashboard blocks are really neat (e.g. mini views).
Pretty cool, if you ask me. Good example of why we need WSCCI and node.js integration.
#53
Are they using Homebox or the Dashboard module from core? It looks like Homebox
#54
It looks like a Drupal 6 site, so they can't be using Dashboard.
#55
Who cares what module or version it is, what Dries is mostly aiming at is the UX it offers through new technologies(although I don't get that part).
What are the takeaways that make our dashboard better?
#56
We should keep in mind that we aren't going to have views in core - so what the dashboard can actually provide (in terms of usefulness) will be quite limited.
I still hold that this should live in contrib unless we can *actually* make it into a useful dashboard - and without views that's going to be really hard. But let's see where we are in June :)
#57
This issue isn't about improving the UX of the Dashboard module, though. It's about whether or not the module fundamentally belongs in core.
So is there a strategic mistake? The idea of Dashboard in core is really just that modules can define blocks intended for it, and those can be treated specially in the UI. It's much harder for a contrib dashboard to introduce a concept like that (and none do as far as I know), unless there were a single contrib dashboard that absolutely everyone used. So far, though, core blocks don't use this feature as much as they should (Snowman definitely could help though), and contrib modules haven't picked it up much either. That's where we're at.
Where the my.fcc.gov dashboard might be relevant for this issue is as an example to look at concerning what kinds of blocks it actually uses. What kind of contrib modules would need to start doing some dashboard-strategy-homework in order for it to actually be successful?
When I watch the video, it strikes me that pretty much everything there is a custom-made block, and most of them look like Views. So maybe more than patches for lots of contrib modules, do we actually just need a patch for Views to add something like a "this block should be available on the site's administrative dashboard" checkbox to block displays? A simple feature like that might go a long way in allowing the Dashboard's usefulness (as a centralized core feature) to be properly evaluated.
#58
I apparently cross-posted with @jenlampton who was also thinking about Views :)
So it's definitely true that not having Views limits how useful the dashboard can be. But then again, not having Views limits how useful a site can be too (at least for most kinds of sites). I'm not sure I would agree that the "lack of Views" limits the dashboard proportionally more than it limits the overall site.
I think if you've managed to build a semi-useful site with core only, you could probably then build a dashboard that's equally useful, if you throw enough core blocks onto it. For example, between recent comments, recent content, recent users, the statistics module blocks, etc... you can probably get a pretty good overview of what's going on with your website. This would definitely be useful for Snowman to explore, IMO.
#59
I only asked because Homebox is much better right now than the Dashboard module. And one of the reasons, at least the way I see it, is because Homebox lives in contrib.
I do agree with Dries when he says that we need a good Dashboard, I really do, but I also think that we could have a better Dashboard if it is in contrib and not in core. Views wouldn't be half the module it is right now if it was in core.
Anyway, we'll talk again next year.
#60
@David Sorry for being so harsh :) I just didn't like the discussion steering towards, it would be soo much better with X, in core rather than dashboard.
Yhea, I will revist this issue in half a year when all the magic has happend and the Dashboard is awesome.
#61
I'm also concerned that having such a bad example of "how to create a context" in core isn't going to help anyone learn to code for Drupal. Hopefully by D8 (after WSCCI gets somewhere) this won't be such a huge issue anymore, but for now I'm tagging this issue for learnability.
#62
My first D8 core patch was an attempt to make the default dashboard more useful, but got held up on the "Will aggregator/dashboard be part of D8?" question (grumble, grumble). See #1266310: Add a "Drupal news" block to the dashboard in Standard profile.
I think we can actually do quite a bit of smallish patches like that to make the dashboard in the standard profile much more useful, even without Views.
#63
D.o. news block would be nice, I'd love to see the software create some more links back to the mothership d.o. like that. Snowman should have enough wiggle room to add its own custom block if necessary as well.
I think everyone agrees the current implemenation is no good. The value of the dashboard concept *for core* remains to be determined I think. Dreaming up useful widgets that provide people with meaningful status info would be a good start (silly ones work too).
#64
Per #57, I don't agree that it's no good, and gave some specific evidence to support that...
Either way, if people have real, actionable ideas for a better implementation it would be useful to create issues for them (and cross-link them here). Otherwise this issue isn't really postponed on anything specific, so when June 1 2012 comes it's very unlikely that anything will have changed.