Module Review https://www.zengenuity.com/ en Review: Node Level Blocks Drupal Module https://www.zengenuity.com/blog/2010-05/review-node-level-blocks-drupal-module <span class="field field--name-title field--type-string field--label-hidden">Review: Node Level Blocks Drupal Module</span> <div class="paragraph html"> <div class="container"> <p>The <a href="https://drupal.org/project/node_level_blocks" target="_blank" title="Node Level Blocks Module">Node-Level Blocks module</a> for Drupal is a much-needed addition that addresses a requirement I get all the time from clients. Clients want to be able to display specific blocks on specific nodes on their sites. Node-Level Blocks is the simplest system I've seen for allowing them to do this.</p><h3><img src="https://www.zengenuity.com/sites/default/files/migrated/node-level-blocks-4.png" alt="Standard Drupal Node Visibility Form" title="Standard Drupal Node Visibility Form" width="250" height="173" style="float: right;" class="imagecache-small_image img-right" />Why do we need this module?</h3><p>Drupal's block system is very powerful when it comes to displaying content in a programmatic way. It's easy to show a certain block when viewing a section of a website or on pages of certain content types. But, I find that most clients don't think this way. They tend to see everything as "page", and because of this they send requests like, "I want this item on the sidebar on this particular page."  While the Blocks administrative interface does allow you to specify individual pages for the block to be displayed,  most clients find this interface baffling. Even after you teach them how to identify which block they want, then you have to explain that they need to copy the Drupal path for the node into the visibility section. This process is further complicated when you start adding stuff like <a href="https://drupal.org/project/pathauto" target="_blank" title="Pathauto Module">Pathauto</a>, or when the paths get changed. As a result, I generally tell clients to have me manage their block visibility settings. With Node-Level Blocks, no longer!</p><h3>What does this module do?</h3><p>It adds a block management widget to the node edit form that allows content editors to choose individual blocks to be displayed on the page view for this node. This widget is configurable per content type. You can limit the blocks and the regions that the content editor can choose from.</p><h3><img src="https://www.zengenuity.com/sites/default/files/uploads/node-level-blocks-1.png" alt="Node Level Blocks Configuration" title="Node Level Blocks Configuration" width="250" height="193" class="imagecache-small_image" /> <img src="https://www.zengenuity.com/sites/default/files/uploads/node-level-blocks-2.png" alt="Node Level Blocks Content Editor Interface" title="Node Level Blocks Content Editor Interface" width="250" height="165" class="imagecache-small_image" /></h3><h3><img src="https://www.zengenuity.com/sites/default/files/uploads/node-level-blocks-3.png" alt="Node Level Blocks Finished Product" title="Node Level Blocks Finished Product" width="250" height="133" style="float: right;" class="imagecache-small_image img-right" />Does it work?</h3><p>Yes, for the most part. I tested it out and was able to display blocks on individual nodes in any regions that I wanted. The editor-assigned blocks were combined with the blocks assigned using the standard administrative interface. So, Node-Level Blocks fulfills its promise.</p><p>However, there are a few of issues that I found during my testing. First, block titles for manually created blocks are not displayed. Strangely, this seemed to only be a problem for manually created blocks. The title for a <a href="https://drupal.org/project/views" target="_blank" title="Views Module">Views</a> block that I added showed up fine. Second, the module does not prevent a block from being displayed twice on a page, even in the same region. (This is only possible if it's already been assigned to that region by the standard interface.) There should probably be an option to prevent this from happening. Lastly, you can only limit the available blocks on module-level basis. You cannot specifically allow individual blocks to be assigned. A module like Views can generate a lot of blocks, so it would be nice if there was an option to specify blocks individually. The current release is marked as a beta, and I've submitted issues on these items (<a href="https://drupal.org/node/811288" target="_blank">here</a> and <a href="https://drupal.org/node/811310" target="_blank">here</a>), so hopefully they will be fixed before a stable release.</p> </div> </div> <span>Wayne Eaker</span>May 27, 2010 <div class="tags"> <div class="container"> <span class="tag"><a href="https://www.zengenuity.com/blog/tags/blocks" hreflang="en">Blocks</a></span> <span class="tag"><a href="https://www.zengenuity.com/blog/tags/drupal" hreflang="en">Drupal</a></span> <span class="tag"><a href="https://www.zengenuity.com/blog/tags/module-review" hreflang="en">Module Review</a></span> </div> </div> Thu, 27 May 2010 20:53:00 +0000 Wayne Eaker 104 at https://www.zengenuity.com Review: Views Hacks Drupal Module https://www.zengenuity.com/blog/2010-05/review-views-hacks-drupal-module <span class="field field--name-title field--type-string field--label-hidden">Review: Views Hacks Drupal Module</span> <div class="paragraph html"> <div class="container"> <p>The <a href="https://drupal.org/project/views_hacks" target="_blank">Views Hacks module</a> is a new project that adds several useful bits and pieces to the standard <a href="https://drupal.org/" target="_blank">Drupal</a> <a href="https://drupal.org/project/views" target="_blank">Views</a> system. It consists of five separate modules:</p><h4><img src="https://www.zengenuity.com/sites/default/files/migrated/views-php-access.png" alt="Views PHP Access" title="Views PHP Access" width="150" height="150" style="float: right;" class="imagecache-icon_large img-right" />Views PHP Access Plugin</h4><p>This is a simple module that gives you the ability to add a snippit of PHP code to control views access, instead of using the standard Permission or Role based access control.</p><h4>Views Filters Auto-submit</h4><p>This module auto-submits exposed filters when they are changed. This is nice if you are using dropdown (select) type filters, however configuartion for this module is quirky. You must configure the use of autosumit at the page level with a form that looks like the Block Configure form. So, you can choose "Autosubmit works on only these pages" or "...on all pages except these pages." However, you can't change this option on a field by field basis. This means if you use both an exposted text field and a dropdown on the same view, both of them autosubmit when they are changed. Still, turning exposed dropdown filters into jump menus is handy.</p><h4><img src="https://www.zengenuity.com/sites/default/files/migrated/views-hacks-reset.png" alt="Views Hacks Reset Button" title="Views Hacks Reset Button" width="150" height="150" style="float: right;" class="imagecache-icon_large img-right" />Views Filters Reset</h4><p>This adds a "Reset" button to exposed filters. Plain and simple, this should really be part of Views.</p><h4>Views Taxonomy Summary</h4><p>This module provides a summary style plugin suitable for displaying hierarchical taxonomies. There are other modules that do this, and it can be done to some degree with the Views module alone. However, it usually requires two different views: one for the hierarchy of terms and one for the nodes once you have drilled down to the term-level.  This module combines these two functions into a single summary view.</p><h4><img src="https://www.zengenuity.com/sites/default/files/migrated/views-selective-filter-set.png" alt="Views Selective Exposed Filters" title="Views Selective Exposed Filters" width="150" height="150" style="float: right;" class="imagecache-icon_large img-right" />Views Selective Exposed Filters</h4><p>This module restricts exposed filter values to those present in the result set. I've actually needed this before myself and wrote a form_alter to do it for the specific view I was using, so I'm glad that someone has created a general solution to this problem. The configuration is straightforward, as can be seen in the screenshot to the right. Unfortunately, this module doesn't actually work right now. After enabling this feature, I got an error message when loading my view. Views Hacks does not have an official stable release yet, though. So, it's not surprising that there still some bugs. When this module is finished, it should be great for things like taxonomy terms and CCK fields.</p> </div> </div> <span>Wayne Eaker</span>May 3, 2010 <div class="tags"> <div class="container"> <span class="tag"><a href="https://www.zengenuity.com/blog/tags/drupal" hreflang="en">Drupal</a></span> <span class="tag"><a href="https://www.zengenuity.com/blog/tags/module-review" hreflang="en">Module Review</a></span> <span class="tag"><a href="https://www.zengenuity.com/blog/tags/views-hacks-module" hreflang="en">Views Hacks module</a></span> <span class="tag"><a href="https://www.zengenuity.com/blog/tags/views-module" hreflang="en">Views module</a></span> </div> </div> Mon, 03 May 2010 16:43:00 +0000 Wayne Eaker 103 at https://www.zengenuity.com