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.
To run on d.o, we can't have a PHP filter for the header for the default issue views, even though that'd be the easy way to have the nice little set of links across the top of the issue pages, and for #359130: Convert the "My projects" page to a view.
Comment | File | Size | Author |
---|---|---|---|
#10 | queue-links-366542-10.patch | 3.22 KB | mikey_p |
#8 | post_render_it.patch | 3.44 KB | bdragon |
#1 | 366542-1.project_issue_display_plugin.patch | 4.12 KB | dww |
Comments
Comment #1
dwwHere's a start of a display plugin, and views sees it as a choice, but when I try to add it, I get JS errors and other badness. Not sure how to actually debug this.
Comment #2
dwwWhoops, I forgot about this issue when I submitted #406578: Replace hook_help() hacks with a cleaner solution for the dynamic headers on issue views ;)
The plan I listed there was:
- extend the attachment display plugin into a "Project issue header" subclass
- in this kind of attachment display, have the options I need to select what kinds of links you want
- in the display plugin's render() method, invoke the right function to generate the desired links
- fix the default issue views to use a properly configured attachment
- rip out the nasty inside project_issue_help()
I haven't messed with attachments yet, but this should hopefully be fairly straight forward...
Also, the fact we're using hook_help() is causing grief for the d.o redesign, we should make sure we have a real solution before the redesign launch...
Comment #3
fuzzy_texan CreditAttribution: fuzzy_texan commentedTagging for #439958: Document issues left before 6.x official release
Comment #4
marcp CreditAttribution: marcp commentedIs the
hook_help()
hack one we can live with for now, or is it still a 6.x-1.0 blocker?Comment #5
dwwIt's pretty whack. I'd really like to replace it. It looks completely stupid on a lot of sites that have themes which don't just render the help text at the top of the page. The redesigned drupal.org theme, for example, does completely weird things with the help div. I've run into at least 2 other sites that had this problem, too...
Comment #6
dwwThere might be a native solution for this in views via #510284: Header/footer/empty text and more areas pluggable, and merlinofchaos might even agree to backport that to Views2 since we need it on d.o. That'd be a lot better than what I proposed at #2...
Comment #7
lisarex CreditAttribution: lisarex commentedLinking this from the Redesign project #661692: Meta issue for modules Project and Project issue tracking because this issue was tagged 'drupal.org redesign'
Comment #8
bdragon CreditAttribution: bdragon commentedHey hey.
I read the comment in the module file and went off and hacked on things for a while. Here's what I came up with:
We can do the links from hook_views_post_render() by directly affecting the view output. As a bonus, we can ask the view directly for the project id argument (and therefore not have to worry about what arg() it is in).
I left the 'project/issues/statistics' and 'project/issues/subscribe-mail' cases in hook_help() in this patch. Those ones can probabaly just be distributed off to their respective page handlers, right?
Comment #9
dwwExcellent, thanks! I haven't tested, but that could probably go in as-is.
However, if we really wanted to be nice, there'd be a variable_get() for the array of view names where this should happen, and instead of the switch(), we'd use array_search(). Even if there was no UI for it at first (or ever), at least having a variable for it would be nice.
I'd also love to get merlinofchaos's opinions of this approach, but assuming it works, it can't possibly be worse than hook_help(). ;)
Thanks!
-Derek
Comment #10
mikey_p CreditAttribution: mikey_p commentedmerlinofchaos commented:
So it looks like this is the best approach for now. I added the variables and provided defaults that match the previous switch statement. I've rerolled and tested this locally and on scratch.d.o as well.
Just to note that this may need a theme fix in bluebeach or in bluecheese, since the markup around these links will change. Please see the attached images:
Before:
After:
Comment #11
mikey_p CreditAttribution: mikey_p commentedstatus
Comment #12
hunmonk CreditAttribution: hunmonk commentedmore redesign tags
Comment #13
mikey_p CreditAttribution: mikey_p commentedI'd say that this is RTBC as it stands.
OSInet and I discussed briefly with hunmonk another approach to this, and that would be to turn all of these pages into actual callbacks, with an entry in hook_menu(). I believe project probably already has a loader function that we could use for a dynamic menu path. Then the page callback could look something like this:
I don't know if this would have any merit for the issue queue views themselves, but it seems like a better approach for the my projects page since it's a whole other view that is being added.
At any rate the current patch here is definitely cleaner than the hook_help hack that is in use now.
Comment #14
dwwFinally had a chance to review this and try it out. Yeah, I think it's more flexible to go with #10 than to hard-code some page handlers and embed views manually. This would let other sites change the URLs and page structure if they wanted, since it's still all views based (sort of -- it's actually mostly hard-coded in various ways, but whatever). ;)
Anyway, I went ahead and fixed the subscribe and statistics page callbacks to output the links directly, completely removing the hook_help() hack. Committed to HEAD: http://drupal.org/cvs?commit=430248
Thanks folks!
-Derek