Custom Code in PHPtemplate

The following functions were added to PHPtemplate in the lasqueti theme to obtain the required functionality.  Some of these should probably be made into a custom module.

Custom Node (page) titles using images

see: HowTo: Replace node title with a related image | drupal.org

<code>

// This function is used to substitue the node title with an image of the same name.
// Really good candidate to turn into a small module.
function _phptemplate_variables($hook, $vars = array()) {
  switch ($hook) {
    case 'page':
    // substitute node title with an image, if a suitable replacement can be found.
    // save original title text for use in head and breadcrumb.
    $vars['breadcrumb_title'] = $vars['title'];
    $vars['head_title'] = $vars['title'];
    // Substitute title only for nodes...
    if (arg(0) == 'node' && is_numeric(arg(1))) {
      $node = node_load(arg(1));  // (expensive, unless arg(1) is already loaded, which is should be at this point.)
      // ... of one of the listed types - add node types to process to the array.
      if (in_array($node->type, array('page', 'page_layout_b'))) {
        // convert title to suitable filename and derive both file system path and URL.
        $titleFile = clean_title($vars['title']) . '.gif';
        $titleImage = base_path() . "files/images/titles/" . $titleFile;
        $titleURL = "http://" . $_SERVER['SERVER_NAME'] . $titleImage;
        $titlePath = $_SERVER['DOCUMENT_ROOT'] . $titleImage;
        // $vars['title'] = $titleURL;   // DEBUG - see what's being produced

        // Determine if a suitable replacement image for title can be found, and make substitution.
        if ( file_exists($titlePath) ) {
          $newTitle = '<img alt=\'' . $vars['title'] .'\' src=\'' . $titleURL .'\' />';
          $vars['title'] = $newTitle;
        }
      }
    }
    break;
  }
 
  return $vars;
}

// Prepare some general title text for use as a file name.
// Remove special HTML characters, trim whitespace, convert to lower-case
// repace spaces with underscores.
function clean_title($string)
{
    $cleanString = htmlspecialchars_decode( strtolower(trim($string)), ENT_QUOTES );
    $cleanString = str_replace(array("& ", "'"), '', $cleanString);
    // $string = strtolower(preg_replace("/[^a-zA-Z0-9 ]/", "", $string));  // slower, but more general purpose.
    return str_replace(' ', '_', $cleanString );;

}
</code>

Custom Theming for Summary Views

<code>
 
// Create a mock-menu from a view's summary (usually for a block view)
// See Example: How to Display a Summary View as a Mock Menu http://drupal.org/node/42605
function _summary_menu($view, $level, $nodes) {
  foreach ($nodes as $node) {
    $list .= '<li class="leaf">' . views_get_summary_link($view->argument[$level]['type'], $node, $view->real_url) . "</li>\n";
  }

  if ($list) {
    return "<div class='menu'><ul>$list</ul></div>";
  }
}

// Photo albums are per-user, so agrument is user ID UID
function phptemplate_views_summary_photo_albums($view, $type, $level, $nodes, $args) {
  if ($type == 'block') {
    return _summary_menu($view, $level, $nodes);
  }
  else {
    drupal_add_css(drupal_get_path('theme', 'lasqueti') .'/css/image_gallery.css', 'theme');
    // Need generic way to get image file info? - must use name of CCK field.
    // Replace this with the name of your image field.
    // Uncomment the print_r below to figure out what it is.
    $cck_fid_field = 'node_data_field_image_field_image_fid';
    $content .= '<ul class="galleries">';
    $title = "'s Personal Photo Album";
    $baseUrl = $view->url;
    // Build a small, single node teaser for each query in the summary and
    //   use it as a link to the actual view page with that argument.
    foreach ($nodes as $query) { 
       // Get the argument for this view from the query.
       $uid = $query->uid;     // argument is user id;
       $user = $query->name;   // query also has user's name.
       // Build a 1 item query to grab the first node in this view
       $result = views_build_view('items', $view, array($uid), false, 1);

       // Grab the image from that node to display in our summary.
       // The file id comes from the node info. we got back from views.
       // print_r($result['items'][0]);
       $fid = $result['items'][0]->$cck_fid_field;
       $modDate = $result['items'][0]->node_changed;

       // Query the database to get the file object
       $file = _imagefield_file_load($fid);
       $imgTag = theme('imagecache', 'Thumbnail', $file['filepath'], 'Latest image from gallery', $user . $title);

       $url= $baseUrl .'/'. $uid;
       $linkText = $imgTag .' '. $user . $title;
       $content .= _theme_gallery_summary($imgTag, $url, $user.$title, $query->num_nodes, $modDate, NULL);
     }
    $content .= "</ul>\n";

    return $content;
  }
}

// Produce the themed output for the image gallery summary.
// This code was ripped from the image gallery module.
function _theme_gallery_summary($imgTag, $url, $title, $count, $modDate, $description=NULL)
{
   $content = "";
   $content .= '<li class="clear-block">';
   if ($count>0) {
     $content .= l($imgTag, $url, array(), NULL, NULL, FALSE, TRUE);
   }
   $content .= "<h3>". l($title, $url) ."</h3>\n";
   if ($description) {
      $content .= '<div class="description">'. check_markup($description) ."</div>\n";
   }
   $content .= '<p class="count">'. format_plural($count, 'There is 1 photo in this gallery', 'There are @count photos in this gallery') ."</p>\n";
   if ($modDate) {
     $content .= '<p class="last">'. t('Last updated: %date', array('%date' => format_date($modDate))) ."</p>\n";
   }
   $content .= "</li>\n";
   return $content;
}

// Photo galleries are per-term, so argument is taxonomy term.
function phptemplate_views_summary_photo_gallery($view, $type, $level, $nodes, $args) {
  if ($type == 'block') {
    return _summary_menu($view, $level, $nodes);
  }
  else {
    drupal_add_css(drupal_get_path('theme', 'lasqueti') .'/css/image_gallery.css', 'theme');
    // Need generic way to get image file info? - must use name of CCK field.
    // Replace this with the name of your image field.
    // Uncomment the print_r below to figure out what it is.
    $cck_fid_field = 'node_data_field_image_field_image_fid';
    $content .= '<ul class="galleries">';
    $title = " Photo Gallery";
    $baseUrl = $view->url;
   
    // Build a small, single node teaser for each query in the summary and
    //   use it as a link to the actual view page with that argument.
    foreach ($nodes as $query) { 

       // Get the gallery description from the term's vocab.
       $term = $query->letter;  // argument for taxonomy terms;
       $tid = $query->tid;      // term IS the argument!
       $termObj = taxonomy_get_term($tid);
       $description = $termObj->description;
       
       // Build a 1 item query to grab the first node in this view
       $result = views_build_view('items', $view, array($term), false, 1);

       // Grab the image from that node to display in our summary.
       // The file id comes from the node info. we got back from views.
       // print_r($result['items'][0]);
       $fid = $result['items'][0]->$cck_fid_field;
       $modDate = $result['items'][0]->node_changed;

       $file = _imagefield_file_load($fid);
       $imgTag = theme('imagecache', 'Thumbnail', $file['filepath'], 'Latest image from gallery', $term . $title);

       $url= $baseUrl .'/'. $term;
       $linkText = $imgTag .' '. $term . $title;
       $content .= _theme_gallery_summary($imgTag, $url, $term.$title, $query->num_nodes, $modDate, $description);
     }
     $content .= "</ul>\n";

     return $content;
  }
}

Theme the node add / edit forms for custom CCK types

    This simply addes a collapsible fieldset for the CCK fields in the "Market Page" type, and hides the Categories fieldset from non-admins, to try to improve useability. See http://drupal.org/node/101092#comment-748013 for details.

function phptemplate_page_layout_b_node_form($form) {
  // Collapse the taxonomoy fieldset by default (as this rarely changes).
  $form['taxonomy']['#collapsed'] = true;
 
  // enforce crude access rights on the taxonomy terms.
  global $user;
  if (!($user->uid==1 || in_array('contributor',$user->roles)) ) {
    unset($form['taxonomy']);
  }
  // These are the fields that should be in the fieldset
  $fields = array('field_teaser_image', 'field_bio_image', 'field_bio');
 
  // Add fieldsets to the page_layout_b input form & render it.
    _add_fieldset($form, 'Images', $fields);
    return drupal_render($form);
}

/**
 * Add the given fields to a new fieldset on the form.
 * @form - the form to add the fieldset to
 * @name - a string name of the fieldset
 * @fieldsInSet - field ids (names) for the fields in
 *     the form that should go into the fieldset.
 */

function _add_fieldset(&$form, $name, $fieldsInSet) {
  // Add a fieldset to the form to hold related fields.
  $form[$name] = array (
     '#type'        => 'fieldset',
     '#title'       => $name,
     '#collapsible' => 1,
     '#collapsed'   => 0,
     '#weight'      => -2,
     '#tree'        => 1,
  );
 
  // Move all the related fields into the new fieldset.
  foreach ($fieldsInSet as $field) {
    if ($form[$field]) {
      $form[$name][$field] = $form[$field];
      $form[$name][$field]['#parents'] = array ($name, $field);
      unset($form[$field]);
    }
  }
}

Custom theme the book navigation links.

    When a node's page is viewed in a tab, we don't want to show any book navigation.

function phptemplate_book_navigation($node) {
  if ($node->inTab)
    return NULL;
  else
    return theme_book_navigation($node);
}
 

Custom display of Views exposed filter

  Exposed filters allow the user to have control over what nodes are viewed by selecting from a widget.  The default layout is to have the widget displayed above the view, in the page - yuck - very ugly and poor usability.   This  "snippet" hides the default exposed filter for a view with the name "test" - it can be copied for any View where you want to do this.  Then a custom block is created to display the exposed filter widget off to the side, or "rolled-up"!  Much nicer.
See http://www.angrydonuts.com/displaying_views_exposed_filters

function phptemplate_views_display_filters_test() {
    // Do absolutely nothing.
  }
 

Custom Forms

Anywhere the user can enter data is a form.

Mostly, these forms are generated by Drupal and the sequence the fields are presented is controlled using the field weights (manage fields under Content Types).  However, there were a few cases where input forms were customised to improve their usability (mostly to make them less daunting to the community).

1. Page node input forms.  These forms display when the a new Page node is created or when a Page node is editted. Customized node forms include page_layout_b (Market Page).  These are long, fairly complicated forms, so I grouped some of the fields into fieldsets to make them easier to manage.  Code includes:
   • phptemplate_node_form($form) - selects forms to be modified and applies custom template
   • also provides a crude access control mechanism to hide the Taxonomy selectors, which generally don't need to change for these types of nodes once they have been set (by the admin on page creation).
   • See http://drupal.org/node/101092#comment-748013 for details
2.  

 

Custom Templates

Any page, node, or block can have a custom template that defines its look.  This is a very easy way to subtly alter the look of different parts of the site, or to customize the display of different types of data.

page.tpl.php

Heavily modified the Denver Theme version to remove almost all conditional theming and unused divs.  Made a few other customizations to:

• permit 2- or 3- column layout, depending on if there is a block in rightsidebar
• added include of page_footer.inc to display the custom footer.
• added copyright notice and "powered by Drupal" icon in page bottom region.
• added new "help-block" region (see: Add a drop-down, context-sensitive, overlaid help block | drupal.org)

node.tpl.php

Basically, this is straight from the Denver theme, but with:

• "teaser" class added to the "node" div to allow custom styles for teasers (used to float image right on node page, but left on teaser view).

page_footer.inc

Defines the footer portion of the page that includes the "Our Community" and "MarketPlace" random image blocks.

node-page_layout_b.tpl.php

Defines a custom layout for the "Market Page".  Basically, this just adds the code to pull in the "mini-gallery" at the bottom of the page.

commments.tpl.php

Added this to customize the look and feel of comments. 
See Theming Drupal Comments, Exemplifying with Garland | All Drupal Themes

Modulettes

Some things just can't be developed as a full-fledged module...
Sometimes a hard-coded argument is required (e.g., specify vocabulary for a view), sometimes the code just needs further development to create a nice, general-purpose module.  In any case, these small "modulettes" are less than a full-fledged module, but more than simply a snippet.  They all perform some custom theming, often for a summary view of some sort. 

Custom Menus (tabs)

The menus module in Drupal core allows you to manipulate the system menus through the admin GUI interface (admin >> build >> menus)

However, it does not give you control over at least two key aspects of the menu:

1. Access control - does not allow any specification of who can access the menu item;
2. Tabbed menu - not possible to add or edit tab-style (local task) menu items;

These can be controlled if the menu is built programmatically.  For these reasons, I created a custom lasqueti menu module (lasqueti_menu).  This module does the following:

• Creates the menu items for this Design Notes book, and restricts access to only those who have 'access administration pages' privleges.   Otherwise the Design Notes can either not be placed on a menu, or will show up to authenticated users on the site (in their personal menu - the Navigation menu). 
  An alternative would be to use the "menu-per-role" module, but this seemed overkill for hiding one book, and the module requires a core "hack", so not nicely maintainable.

• Creates the "tabbed" menu pages under the Primary Menu tabs.  The module does two things of interest:
  1. creates the basic structure of the tabbed menu system;
  2. handle display of single node pages that appear on tabs, where required.
  3. handle display of teaser views that appear on tabs, where required.

See the following pages for more information about working with and maintaining these tabbed menus.

 

Farmer's Market

Pages in the Farmer's Market, with their associated produce lists, represent a fairly complex set of inter-relations.  Understanding how the various node types, cck fields, categories, and views fit together will take some time.  However, setting up and maintaining a Farmer's Market page is not hard, but you need to be quite careful to get the relationships right:

• Add a new term to the "Lasqueti Market" category  for the new producer.
  ** This term must be the same as the path of the Market page (case insensitive). 
  These terms are used to create the Farmer's Market (market_products view), listing products for each farm - it shows a list of available products tagged with each term.
• Add a new Market Page for the new producer.
  ** This must be a Market Page so that the "mini-gallery" (created by template.php using the product_gallery view) can be attached . 
  ** The page must be tagged with Topic category term "Farmer's Market".
  ** The URL path for this page must be the same as the Lasqueti Market category term (case insensitive).  This allows Taxonomy Redirect to redirect links from the category term directly to the page (since the term name and the page's URL path are the same).

Thus, a "Famer's Market page" is a Market Page, tagged with Topic "Farmer's Market, with the same URL path as a term in the Lasqueti Market category.  These rules are used to identify these pages in the code - so pages that don't adhere will not be considered part of the Farmer's Market, and won't work correctly.  This is a little sketchy, perhaps even a bit hacky, and limits the re-use of the Product node type ouside the Farmer's Market - but it was expedient, and seemed cleaner than creating a new node type or yet another taxonomy.  Although the Topic category is used to identify Farmer's Market pages,  the Lasquti Market term and URL path still need to be identical for Taxonomy Redirect to work.
The Author of a correctly configured Farmer's Market page will see two new tabs on their page: 

• Edit Product List
  This shows the my_products view that allows the author to edit, delete, and change the availability of their produce.
• Add Product
  This is simply a short-cut to the Add Product form.

These two tabs are created by the custom Lasqueti Menu module - they are "dynamic" local menu items.  It is important to note that only the page author will see these tabs, so once the admin gives authorship over to another user, they won't see these tabs anymore.  I could not figure out how to make this work so admin always sees all.

There are three distinct "Product List" views:

• market_products view is used to display the "products-by-producer" lists on the Farmer's Market page.  The most staightforward way to create this view was by using a taxonomy (since I already had a module to list nodes-by-term).  This is why each product must be tagged with the correct "Lasqueti Market" category.  The alternative would be some custom code that first finds all Farmer's Market pages, then, for each one, selects all product nodes that have a node reference to that page.  This will be quite a bit slower, and represents a significant effort - thus I adopted the taxonomy route because it was easy to implement, expedient, and efficient.  Note that this view does not use the node reference field at all!
• product_gallery view is used to display a list of products related to a given producer, in their Market Page's mini-gallery.  Again, I already had the code to produce a mini-gallery using a node reference.  In this case, using the node refernce was the expedient and effiecient way to generate the view, because you already have the Market Page node itself (it is the one being displayed!).   It would be possible to use the taxonomy term (which is the same as the Market Page title, remember!) to create this view, using the term as an argument passed into the view.  That would eliminate the need for the node reference field in the Product node.  Hmmm... seems like a reasonable idea now that I think of it - but that would mean the Product node would lose its "This product is related to...." link - although the Market page would still be linked from the product via the taxonomy term and Taxonomy Redirect.   Perhaps worth investigating to simplify things a bit.
• my_products view is used to display a list of products authored by an individual, and is shown on the "Edit Product List" tab for Farmer's Market pages.   This could be confusing if one person is "owner" of multiple Market pages, because I could not find a simple way to filter the products by the node being viewed (since I don't have that context).   I suspect this will be possible with Views2.  For now, this lists all of a user's products, regardless of which page they relate to.

The upshot?
When user's create a new product,  they need to select both the correct Lasqueti Market taxonomy (so the product is listed correctly in the Farmer's Market) and the correct Market Page node reference (so the product is added to their mini-gallery).  The node reference selector uses the user_pages view to restict them to selecting references to only pages they own.  This is good because it avoids confusion and mistakes, but it is bad because it means the admin cannot create these node reference links without first "masquarading" as the author of the page.  The Lasqueti Market category terms would be more difficult to restrict in this way, so they are open, and thus prone to error.
This reliance on authorship for a number of the functions (e.g., edit tab availablitity, node editing access, node reference list, etc.) also implies that only one person can manage a given market page.  It is certainly possible to set-up group access and do things based on groups rather than author, but there would be a lot of overhead (and extra work!).  An easy workaround would be to create a group ID for the website that all members of the group could use to update the shared resource.

Custom Modules?

Almost everything I ever thought of has been done in Drupal by someone else - it's a beautiful thing.  But there have been a few things I've imagined would be really useful that I couldn't find anywhere...
I'd consider writing these myself one day, if time ever permits...

Expiry Date

This module would define a new CCK date type (using Date API) to define an expiry date for a node.  The node owner would get an e-mail reminding them that their node was about to expire, and if no action was taken, the node would simply be removed.   This would be very handy for announcements and to create a CCK classified ads module.  Code could largely be ripped from ed_classified module.

Replace Title

This module would look for an image in a specific directory with a name "similar" to the node title.  If a suitable image is found, then replace the node title with the image.  Use hook_node_?
DONE: But code in template.php - need to move it to a custom module.

Publishing Options Access

This small module uses a hook_form_alter to create per-role access rights to elements of the Publishing Options fieldset on the node-edit form.  This would allow admin to grant rights to user-roles to, for example, promote to front page.
I have already made a good start on this module and will look to contributing it.

Summary Views Plugins

A View with an argument creates a "summary view" when the argument is missing.  The default summary view is simply a list of potentail argument values, linked to their repsepective view "pages".   I could only find one example of a customized summary view (Example: How to Display a Summary View as a Mock Menu | drupal.org ).  I used this to create the "pop-open" menus when browsing the photo gallery, for example. 

I heard a rumour that Views Theming is going to get MUCH easier in Drupal 6, so this may be a wait-and-see.

But there are some other summary views I'd find a great use for:

• Image Gallery - the photo albums and galleries on lasqueti.ca are built with views, using user id, and taxonomy term, respectively, as arguments.  The "summary view" is custom coded in the phptemplate file of the lasqueti theme.  It would be nice to turn this into a real view plugin that shows the individual gallery views as a Bonus Grid.
  DONE: but currently coded in template.php - need to move to a custom module
• List All - it would be nice if the summary view could simply list all of the nodes, with a pager, in some order.  This could be as title links only, or as teasers, or, preferably, customisable.   To make this work flexibly, Views would have to support a different view-type selector for the summary view.
  TRY: Setting the argument option to List All in the View - probably does this?
• Nodes-by-Argument summary - would show all node titles, with links, organized by the argument values (e.g., by the taxonomy tree, for example.)  I have written a preliminary version of this module named nodes-by-category.  Perhaps directory plugin?  or nodes-by-category summary?
  Started: custom Nodes-by-Category views plugin.
  TRY: Views Group-by to group nodes by term in the summary?
• Single-Node- for views that return just a single node (e.g., random image block), the table or list markup is superfulous and requires special styling to make it invisible.  This view simply outputs one node, with no layout formatting.
  DONE: custom views plugin written.

 

 

 

Module Customization

Forgive me Drupal, for I have sinned...

One of the key benefits of Drupal is that you DON'T (usually) need to "hack" away at existing code to customize it - you can use the hook_ and theme_ systems to add your custom code, thus making upgrading much easier.  Nonetheless, there were a couple modules that I needed to "hack" a little, just to suit my finicky tastes... These changes now need to be "re-implemented" any time these modules are updated (unless you want the old behaviour to revert)...

• Module     File                          Modification
• notify        notify.module        changed name on user's tab to "Notify Me"
• ads        ed-classified.module    changed name on user's tab to "My Ads"
• imce        imce.module            changed name on user's tab to "My Files"
• views   modules/views_node.inc  applied patch: http://drupal.org/node/163889#comment-587923
  (hopefully this will be fixed in next version of Views)
• views   views.module               added $view parameter to theme_views_more() http://drupal.org/node/227669#comment-756961
• date    date_views.inc           added new views filter http://drupal.org/node/230176
• lightbox lightbox2.module    theme_imagefield_image_imagecache_lightbox2 altered to use image title as the description text instead of the alt text.  Due to imagefield using image filename as default alt text - yuck.  Better fix would be to patch imagefield to use title text as default if alt text not set.
   

 

 

Useful Modules?

I have tried to install only modules that I needed to meet the immediate designs I was trying to achieve.  In my travels, though, I thought these modules looked very interesting and worth checking out:

- Hovertips and Clicktips | drupal.org  - uses JQuery (AJAX) to create nice pop-up or roll-down tips.  Really useful for displaying complex information or hiding stuff that's not used much (e.g., hide all comments current user has already seen.

- Panels | drupal.org  - provides API and UI for creating sophisticated panelled layouts.  With related "mini-panel" modules to add AJAX tabbed panels and carousel panels Mini Panels demo | Wim Leers

- Node Queue | drupal.org - allows you to display items from a "queue" that automatically drops last item when a new one is added.  Can be used manually for creating "top 5" type lists, or integrated with actions module to automate.

- module_builder - I install this locally to make custom module development easier.  It simple creates a template for a new module based on a few settings.  Only useful for developing a new custom module from scratch.

- form_inspect - a companion for the devel module, this is useful if you are working with forms (say implementing a hook_form_alter), and want an easy way to see view the form data structure.

- chipin - for collecting money for a cause  ** NOT AVAILABLE in 5.0 YET **

- nodewords - meta tag (description, keywords) for each page.

- rsvp - enables rsvp for events (probably won't work with the CCK event types I defined :-(   Perhaps re-develop for CCK date field?)

- volunteer_timeslots - for organising events where volunteers sign up for a timeslot - ditto!

- spam - spam blocking tools. 

- taxonomy_access - access control for users based on taxonomy categories.

-taxonomy_role - access control to taxonomy field on node-edit forms.  Useful to allow admin to place "hidden" taxonomy term in a node, probably for organisational purposes.

- cck_role - same thing for a CCK field.  Could be handy.

- Notifications - a potential replacement / upgrade for Notify and/or Subscriptions?

- Custom Breadcrumb - format breadcrumbs for custom views.