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.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

dww’s picture

Status: Active » Needs work
FileSize
4.12 KB

Here'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.

dww’s picture

Title: Add display plugin for issue views to do our own custom header without PHP filter » Replace hook_help() hacks with a cleaner solution for the dynamic headers on issue views
Status: Needs work » Active
Issue tags: +drupal.org redesign

Whoops, 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...

fuzzy_texan’s picture

marcp’s picture

Is the hook_help() hack one we can live with for now, or is it still a 6.x-1.0 blocker?

dww’s picture

It'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...

dww’s picture

There 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...

lisarex’s picture

Linking this from the Redesign project #661692: Meta issue for modules Project and Project issue tracking because this issue was tagged 'drupal.org redesign'

bdragon’s picture

Status: Active » Needs review
FileSize
3.44 KB

Hey 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?

dww’s picture

Assigned: dww » Unassigned
Status: Needs review » Needs work

Excellent, 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

mikey_p’s picture

FileSize
3.22 KB

merlinofchaos commented:

[13:45] mikey_p: In Views 2 that's probably better, yes. You can add it to the attachments_after variable.
[13:45] In Views 3 you'd prefer an area handler.

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:
Search issues for Drupal | drupal.org

After:
Search issues for Drupal | d6.drupal.org

mikey_p’s picture

Status: Needs work » Needs review

status

hunmonk’s picture

more redesign tags

mikey_p’s picture

Status: Needs review » Reviewed & tested by the community

I'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:

/**
 * Page callback for issue queue.
 */
function project_issue_queue_page($project_name) {
  $output = $links; // Get the links using the same functions were using now

  $output .= views_embed_view('view_name', 'display_name', $project_name); // the first two arguments are standard and any after that are arguments to the view

  return $output;
}

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.

dww’s picture

Status: Reviewed & tested by the community » Fixed
Issue tags: +drupal.org redesign sprint 5

Finally 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

Automatically closed -- issue fixed for 2 weeks with no activity.