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.
Some initial function scoping for Dashboard API elements. See the comments. In particular, I think we can abstract the 'Dashboard' concept using hook_dashboard().
Doing so will allow for the creation of user, group, and administrative dashboards while using the same underlying mechanism.
Comment | File | Size | Author |
---|---|---|---|
#6 | 426646-hook-dashboard.patch | 7.33 KB | agentrickard |
#3 | dashboard.patch | 4.49 KB | drumm |
#2 | 426646-hook-dashboard.patch | 8.97 KB | agentrickard |
#1 | dashboard.txt | 3.15 KB | agentrickard |
Comments
Comment #1
agentrickardFile attachment died.
Comment #2
agentrickardHere is a proof-of-concept patch for hook_dashboard() that does not seem to break anything.
Comment #3
drummI think all of the menu items should stay in the menu hook if possible. Extensions can use hook_menu_alter() if they need to do anything inconsistent. hook_dashboard() should have only metadata. This incomplete patch has the concept, but the loader and permissions need to be abstracted.
Comment #4
agentrickardYes. Simpler == better.
I think we should dynamically alter the permission, though, and possibly the loader function.
The idea of the original patch was to provide sensible defaults for these, and not force module's to implement hook_menu_alter().
Will mess around some more this week.
Comment #5
drummYes, the permission and loader do need to be altered too. There can probably be a common loader that does all the work.
I think using hook_menu_alter() is okay. That's what it is there for and I don't like adding more layers than necessary. We either force modules to use the standard hook_menu_alter() or a new set of hooks. The dashboard menu should have sensible defaults and use metadata from hook_dashboard().
Comment #6
agentrickardOK, I think this patch incorporates those notes.
I took one liberty. The 'widgets' callback, I renamed to 'gadgets' for consistency -- but it can be changed back.
However, I did insert a loader function into that path as well, since we will need to load the current dashboard to see what widgets a user already has, since there is no point in displaying 'additional gadgets' that are already in a collection.
Comment #7
drummGadget/widget will be problematic. The current terminology was chosen to match the redesign prototype and OpenSocial on the inside. We are no longer using OpenSocial for gadgets since everything comes from *.drupal.org, which we trust to not send malicious JavaScript. OpenSocial may be implmented in the future, but is not a priority. I think it should be widgets all the way down, but that is another issue.
Comment #8
drummCommitted.