Splitting this off from #1545922: [META] Issue page redesign so it's an actionable task someone can claim and implement.
We need to be able to display a table of the current issue metadata values when viewing an issue. Although it'd be nice not to do a bunch of custom code for this, the core UI doesn't really cut it here. We could certainly click things together in the default node type we ship so as to hide all these fields from regular display, but then we need to stuff them all into a block or something we can place on the page where we want it to make the UI nice and clean.
If we were running Panels on d.o we could do some fancy panels magic, but that's not going to fly.
So, probably we just want a custom-coded block that takes an issue node as context and renders all the fields we care about into a block.
One complication is knowing which fields to render. ;) We don't want body, title, the file field(s), related issues/etc. We also don't want to hard-code those assumptions. It'd be cool if we could define our own display mode and then just allow sites to configure what fields should be displayed in that mode via the UI. Or something. ;) I don't want a custom UI for this, though. So, I'm open to suggestions (although I might have more good ideas when it's not 2am).
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | 1628122-9.issue-metadata-viewmode.patch | 7.07 KB | dww |
| #8 | 1628122-8.issue-metadata-viewmode.patch | 7.88 KB | dww |
| #7 | 1628122-6.issue-metadata-viewmode.patch | 7.85 KB | dww |
| #5 | 1628122-5.issue-metadata-viewmode.patch | 2.26 KB | dww |
Comments
Comment #1
mustanggb commentedUse Block API and create it as a fieldable block entity.
Comment #2
dww@akamustang: Thanks for the suggestion, but I don't understand what making a fieldable block entity will do to help us here. The fields are already stored in the issue node/entity. We don't want duplicate storage, since then we have problems syncing the values, and that's going to take way more custom code to get right. Plus, we don't want large new external dependencies. I'd rather have a small hook we invoke to figure out what fields should go into this block or something and tell sites that customize things to use this hook. I'm not saying that's the best solution, and there might be a good way to do this via display/build modes or something. But I'm nearly positive that Block API is the wrong solution for this.
Comment #3
mustanggb commentedAh yes good points, it would probably make life harder rather than easier.
Perhaps I was thinking too far along the lines of not hard coding assumptions and that the manage fields UI is pretty.
Basically giving the option to rearrange fields rather than just turn them on and off.
Comment #4
dwwYeah, it'd be nice to somehow allow the field UI to impact this. I thought you could define your own build/display modes (e.g. what's now just "full" vs. "teaser") and that those would show up in the UI so you could specify what fields are displayed in a given mode. But, I couldn't figure out how to do that via the UI. Maybe those have to be declared in code and then they show up in the UI?
Comment #5
dwwI'm working on this as part of #1696872: Create a block that shows the issue metadata
Here's a preliminary patch to add our own custom view mode for this, and a helper function to get the metadata fields for a given issue node.
I'd like to export the default config for the fields to go into this view mode, too, hence 'needs work', but that's proving to be a bit of a PITA, so I wanted to at least post this as a start...
Comment #6
moshe weitzman commentedproject_issue_get_metadata() might be better named project_issue_metadata_build() as 'build' is how refer to making a render array.
Dunno if
unset($build['#contextual_links']);will NOTICE if contextual links are disabled.Also, the custom alter hook seems unnecessary given that there are at least two alter hooks in node_view().
Otherwise, looks good.
Comment #7
dwwNow with code to define the configuration for these view modes on the default project_issue node type we're creating.
Comment #8
dwwOh, I missed Moshe's comment since I asked for it in IRC and he didn't ping me there. ;) Thanks for the review!
- Renamed to project_issue_metadata_build() -- that seems good.
- The unset() is safe even on things that don't exist.
- I wanted to add the alter hook in case folks wanted to restore #theme or something. But then I realized that so far, we're still not actually calling drupal_render() anywhere, so in theory, call sites to set their own #theme if they wanted. So maybe it's really not needed.
Anyway, tested this on a fresh install and all the view mode configuration is getting created as expected, so I think this is basically good.
Comment #9
dwwHere it is again without the custom alter hook. Any other preferences/thoughts on which way to go?
Thanks,
-Derek
Comment #10
dwwAnother thing to note: this default view mode config hides all the metadata fields from the default issue view mode. However, we're not automatically rendering this "table" of metadata values, and some (most?) sites probably don't want to do this via a block (e.g. #1696872: Create a block that shows the issue metadata). For example, I imagine many sites would rather place this stuff via panels and page_manager, not blocks. But, since we can't assume we know how the whole issue node is being rendered, should we only hide these fields in the d.o case where the block is being used and leave them available in the default view mode by default? I.e. out of the box, all those fields are just visible inline at the top of the issue node? Maybe that's a problem to hash out over at #1545922: [META] Issue page redesign or something? Thoughts?
Comment #11
dwwI thought about this a bit while I was AFK tonight. To answer #10, I decided it's better to leave the metadata fields all visible in the default (full node) view mode and let sites hide fields themselves if they want to use another method to display them (e.g. #1696872: Create a block that shows the issue metadata, page_manager once we support it, etc).
So, I pushed a simplified version of #9:
http://drupalcode.org/project/project_issue.git/commit/33b34ee
Tested on a freshly rebuilt site and it's all working lovely.