Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
It's a pile of hacks upon the ancient blocks system. This is the real fix.
Comment | File | Size | Author |
---|---|---|---|
#89 | drupal-950956-89.patch | 56.31 KB | tim.plunkett |
#76 | drupal-950956-76.patch | 56.3 KB | tim.plunkett |
#73 | drupal-950956-73.patch | 245.12 KB | tim.plunkett |
#34 | dashboard.patch | 54.74 KB | RobLoach |
#32 | remove_dashboard-950956-32.patch | 49.91 KB | jenlampton |
Comments
Comment #1
EvanDonovan CreditAttribution: EvanDonovan commentedI 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.
Comment #3
chx CreditAttribution: chx commentedWill 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.Comment #4
chx CreditAttribution: chx commentedAlso note http://drupal.org/node/544360#comment-2083786
Comment #5
chx CreditAttribution: chx commentedHopefully this passes tests.
Comment #7
chx CreditAttribution: chx commented#5: dashboard_real_fix.patch queued for re-testing.
Comment #8
moshe weitzman CreditAttribution: moshe weitzman commentedI 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.
Comment #9
moshe weitzman CreditAttribution: moshe weitzman commentedI'll bet there are opinions on both sides so lets let committers chime in.
Comment #10
webchickChimed in.
Comment #11
David_Rothstein CreditAttribution: David_Rothstein commentedIt 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.
Comment #12
carlos8f CreditAttribution: carlos8f commentedActually 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
Comment #13
carlos8f CreditAttribution: carlos8f commentedBy 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...
Comment #14
webchickWhat 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.
Comment #15
EvanDonovan CreditAttribution: EvanDonovan commented@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.
Comment #16
Jody LynnThere's no rush in removing it right now. Let's wait and see how people like it now that D7 is out.
Comment #17
EvanDonovan CreditAttribution: EvanDonovan commentedLooks 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.
Comment #18
quicksketchPer #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).
Comment #19
Bojhan CreditAttribution: Bojhan commentedlala, tag
Comment #20
yoroy CreditAttribution: yoroy commentedSubscribble etc.
Comment #21
xjmTagging issues not yet using summary template.
Comment #22
jenlamptonsubscribe
Comment #23
aspilicious CreditAttribution: aspilicious commentedSrry if this hurts people...
Comment #25
aspilicious CreditAttribution: aspilicious commentedSrry xjm for driving you nuts.
Comment #26
JacineI 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.
Comment #27
DjebbZ CreditAttribution: DjebbZ commentedJust 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.
Comment #28
coderintherye CreditAttribution: coderintherye commentedHere'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.
Comment #29
jenlamptonrerolled :)
Comment #32
jenlamptonalso removing it from the standard install profile this time. :)
Comment #34
RobLoachIf people still want Dashboard, we should move them to contrib at Dashboard module.
Comment #35
coderintherye CreditAttribution: coderintherye commentedThe 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.
Comment #36
David_Rothstein CreditAttribution: David_Rothstein commentedSo 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:
Comment #37
EvanDonovan CreditAttribution: EvanDonovan commentedI 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.
Comment #38
webchickMy 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.
Comment #39
chx CreditAttribution: chx commentedIt'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.
Comment #40
catchFor 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).
Comment #41
Bojhan CreditAttribution: Bojhan commentedPlease 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.
Comment #42
Bojhan CreditAttribution: Bojhan commentedtag
Comment #43
EvanDonovan CreditAttribution: EvanDonovan commentedThanks, 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?
Comment #44
jenlamptonI 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.
Comment #45
DjebbZ CreditAttribution: DjebbZ commentedI 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.
Comment #46
jenlamptonI 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 :)
Comment #47
yoroy CreditAttribution: yoroy commentedBojhan 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.
Comment #48
EvanDonovan CreditAttribution: EvanDonovan commentedI 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".
Comment #49
moshe weitzman CreditAttribution: moshe weitzman commentedFor 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.
Comment #50
RobLoachWe 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.
Comment #51
Dries CreditAttribution: Dries commentedI 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.
Comment #52
Dries CreditAttribution: Dries commentedTake 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.
Comment #53
lelizondo CreditAttribution: lelizondo commentedAre they using Homebox or the Dashboard module from core? It looks like Homebox
Comment #54
David_Rothstein CreditAttribution: David_Rothstein commentedIt looks like a Drupal 6 site, so they can't be using Dashboard.
Comment #55
Bojhan CreditAttribution: Bojhan commentedWho 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?
Comment #56
jenlamptonWe 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 :)
Comment #57
David_Rothstein CreditAttribution: David_Rothstein commentedThis 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.
Comment #58
David_Rothstein CreditAttribution: David_Rothstein commentedI 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.
Comment #59
lelizondo CreditAttribution: lelizondo commentedI 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.
Comment #60
Bojhan CreditAttribution: Bojhan commented@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.
Comment #61
jenlamptonI'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.
Comment #62
webchickMy 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 an appropriate administrative area in the 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.
Comment #63
yoroy CreditAttribution: yoroy commentedD.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).
Comment #64
David_Rothstein CreditAttribution: David_Rothstein commentedPer #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.
Comment #65
Bojhan CreditAttribution: Bojhan commentedDries his deadline has past. I think we made no changes to the dashboard, that impact UX. It looks like no one in the core community at least, is interested in improving it. So I still stand by my decision, that this has such bad UX - that it has no place in core.
Comment #66
moshe weitzman CreditAttribution: moshe weitzman commentedAssigning to Dries for a decision as per #51.
Comment #67
Dries CreditAttribution: Dries commentedIn #51 I said I would revisit this on June 1st. No progress was made the past six months.
There is a lot of evidence that the idea of having a good dashboard is still valid and very important. For example, it is one of the reasons why people pick WordPress over Drupal. It just happens to be that (i) core's technical implementation of the dashboard module may be poor, (ii) that the dashboard has poor usability, but most importantly, in my opinion, that (ii) we lack good content and functionality on the dashboard.
I'm going to spend some time on this with the Spark team. Everyone is welcome to get involved too. However, I'd like to compare the dashboards of different CMSes, re-envision what a dashboard could be, and figure out how we can arrive to a good, functional dashboard in Drupal that users love.
I do think it could be good to innovate on this outside of core. But if we nail it, and we come back with a great dashboard that content authors or admins love, I do feel it belongs in core. So I'm comfortable removing it from core now, but I will bring it back into core given positive feedback from users.
Thoughts?
Comment #68
moshe weitzman CreditAttribution: moshe weitzman commented#34: dashboard.patch queued for re-testing.
Comment #69
Bojhan CreditAttribution: Bojhan commented@Dries I think that would be a great approach! This is a major win, in terms of creating a UX standard that core needs to adhere to - something I am personally happy about.
I would like to add, that people aren't just welcome to join in, but really should! Because in the end, core needs to have a community that is willing to maintain a Dashboard in core - that's one thing we learned from D7UX.
Comment #71
tim.plunkettI'm rerolling this patch.
Comment #72
tim.plunkettOoops, sorry for unassigning. I can't fix that myself. But yeah, I'm midway through rerolling this (there is data in the DB dumps that can be killed off).
Comment #73
tim.plunkettOkay this removes all dashboard data from drupal-7.bare.standard_all.database.php.gz as well, but it was very tedious so I'm going to hold off on drupal-7.filled.standard_all.database.php.gz until someone confirms that this needs to be done for this issue.
Comment #74
catchActually it's fine to leave the dashboard in those db dumps, since it still exists in D7 and if it goes back into 8.x later we'll need a tested upgrade path anyway.
Comment #75
webchickThis is not major.
Comment #76
tim.plunkettThis should do it.
Comment #77
moshe weitzman CreditAttribution: moshe weitzman commentedLooks right to me too. Wait for green before commit.
Comment #78
Bojhan CreditAttribution: Bojhan commentedI am sure @catch would be happy to remove it.
Comment #79
Dries CreditAttribution: Dries commented@Bojhan: I don't understand why you assign this patch to catch?
@All: before we commit this patch, I'd like to work with webchick to setup a contrib project for it. Give me a couple more days.
Comment #80
Bojhan CreditAttribution: Bojhan commented@Dries You can commit it too.
Comment #81
David_Rothstein CreditAttribution: David_Rothstein commentedI pointed out above that the evidence we have (from actual user testing) shows the opposite to be true. If we remove the Dashboard module, we'll be removing one of the easier-to-use interfaces that currently exists in Drupal core.
With the possibility of Views in core, it seems like that would be a really good opportunity to change the default dashboard content (as well as giving users much better opportunities to add their own content to it). But I'm not sure that interface would all really come together in time for Drupal 8.
Comment #82
webchickCreated an issue at #1659368: Move core dashboard module to this project in 8.x branch? to move this into contrib.
Comment #83
yautja_cetanu CreditAttribution: yautja_cetanu commentedSurely with the layouts iniative the dashboard makes sense now?
Layouts + views in core would make the dashboard a really cool example use-case of what can be done with layouts and views. I realise that this would probably mean completely rebuilding the dashboard though.
Comment #84
Crell CreditAttribution: Crell commentedSure, the Layouts initiative should (if successful) make it possible to build a really solid dashboard.
Such a SCOTCH-based dashboard would be so far conceptually and architecturally from the current dashboard module, however, that it would be easier to implement from scratch rather than trying to evolve the current one. That's why we want to just euthanize the current one first, as that makes it *easier* to build a new one after we've razed the old one to the ground.
Dries, it's been more than a couple of days... :-)
Comment #85
webchickWe had to wait two weeks for the abandoned module process at #1659368: Move core dashboard module to this project in 8.x branch?:. It's now been two weeks, but I'm on-site in Boston and in meetings 24/7. I'll try and get to it if I can, but it may be middle of next week when I'm back home. It doesn't seem to be overly urgent.
Comment #86
RobLoach#76: drupal-950956-76.patch queued for re-testing.
@webchick: The only person that got back to me from the email I sent two weeks ago was agentrickard, and he said he didn't have access to the project administration.
Comment #88
webchickOk, per #1659368: Move core dashboard module to this project in 8.x branch? I've assigned myself as a co-maintainer of this module, and pushed the latest 8.x code into http://drupalcode.org/project/dashboard.git/tree/refs/heads/8.x-1.x
I believe this just needs a re-roll and then we can remove it.
Comment #89
tim.plunkettRerolled.
Comment #90
Bojhan CreditAttribution: Bojhan commentedComment #91
webchickOk, committed and pushed to 8.x.
There's a CHANGELOG.txt notice, but we should probably also have a change notice too.
Comment #92
tim.plunkettAdded http://drupal.org/node/1697190
Comment #93
webchickLooks good, thanks!
Comment #95
eMPee584 CreditAttribution: eMPee584 commentedawesome!
...and it took only two years to rip it out.
Comment #96
xjm