May Toronto Meetup

Great summary Kevin, thanks for posting it. :)

I'd like to propose a presentation on developing mobile Drupal websites. By the time of our May meeting, I'll have completed development of an event-based mobile version of a standard Drupal website.

i definitely agree DrupalCamp should be on the agenda but i'm not sure about it being the focus. We'll have separate DCTO organizing meetings for those who want to be more in depth.

I just checked the booking... it will be Room 120. Just up the short set of stairs to left of elevator (or you can take the elevator 1/2 floor).

Hey Heatherann,

I stole your suggestion for using a php input format in a view header extract from a header node (so as not to scare the pants off clients wanting to edit it), but I made one little change that you might find useful.

One thing that I thought was missing was the equivalent of the "hover link" that drupal displays for admins, allowing for quick-editing of a view. Since this feature isn't available to clients without giving whole-view access, I rigged up something comparable. The idea was to get a single "Edit View Header" block to display on each view page, which would provide a link to edit the respective header.

Example: http://ow.ly/i/1SK3

Here's how I did it:

1. Create a new view called something like "admin_views_headers".
2. Add a block display type.
3. Add a single "Node: Edit link" field with no label, and display text set to something like "Edit header text".
4. Now the nifty part: Add an argument for "Node: Nid".
5. Under "Action to take if argument is not present", set "Provide default argument", and set the argument type to "PHP code".
6. Under "PHP argument code", set up a switch statement like so:
   
   switch(arg(0)) {
  case 'news':
    return 20;
  case 'staff':
    return 21;
  case 'mandates':
    return 25;
...
  case '<unique-path-arg-for-view>':
    return <nid-of-header-node>;
}
7. Check "Validate that user has access to the node". This way, you don't have to worry about controlling access at the view and block level -- if the user has access to edit the header node, then the block will have content and they'll see it.
8. Set up the rest of the argument settings to your liking, (validators, etc.). One thing I'd suggest is removing the wildcard settings, just to simplify.
9. Place the block either above the content area, or in a column beside it.

So to explain, I've currently got this set up for a site with a very simple structure with views at paths like www.mysite.com/news, www.mysite.com/mandates, etc. So if the page is at any of those paths (or deeper!), then it will pass a nid argument according to the switch statement above, and an edit link will be displayed. A bonus is that the "Node: Edit link" field always attaches a ?destination=PREV_PATH, so when they save the header node, they're redirected back to the view.

Hopefully this helps!