go to Packt Publishing's Open Source CMS Award Web site before October 30 and cast your vote in the following categories:



• Hall of Fame
• Best Open Source PHP CMS

Use an indent of 2 spaces, with no tabs.

Lines should have no trailing whitespace at the end.

Files should be formatted with \n as the line ending (Unix line endings), not \r\n (Windows line endings).

Create forms that submit a search to an external search engine, like Google, Yahoo!, Wikipedia, Last.fm or any other engine that uses query strings for form submissions (GET). External Search comes with predefined settings for a lot of common search engines in the following categories:



• Dictionaries and encyclopediae
• General Search sites
• Media
• Programming



If you would like a form for a search engine that isn't predefined, you can enter its settings at the External Search administration page.

Available Modules




There are many modules that provide some sort of slideshow / rotator functionality.



• Dynamic display block - Enables you to create and present blocks of content in a dynamic way. Uses the jQuery Cycle Plug-in.
• Views Rotator - a Views style plugin using the Cycle jQuery plugin with a small number of options for controlling transition behaviour.
• Views Cycle - a Views style plugin using the Cycle jQuery plugin, with an option for tabs, several transition effect options and other transition behavior settings.
• Views Slideshow - a Views style plugin using its own JavaScript for the rotation, also including a tabs option and a small number of transition behavior options. The Drupal 6 (dev) version is an extensible API that allows other cycles, rotators, and carousels to plug into the module, so they don't need to recreate the Views functionality.
• Views Slideshow: ImageFlow - offers an ImageFlow option to Views Slideshow, similar to Apple's CoverFlow.
• Slideshow Creator - adds an input format filter to allow you to add slideshow creation code to the body of a node. This module has been deprecated
• Featured Content Slider - select nodes based on content type and create up to 3 blocks of featured content.
• Slider - create a "slider" content type with a multi-value nodereference field to create carousel-style sliders of the referenced nodes.
• EasySlider - create a list-style view with a block display and the view results are displayed in a carousel style slider.
• Node Carousel - create carousels of nodes based on nodequeue or custom values using a hook in your own module.
• Views Carousel - a Views style plugin using the jCarousel jQuery plugin for the rotation, suitable for e.g. a scrollable thumbnail viewer.

The node access system determines who can do what to which nodes.

In determining access rights for a node, node_access() first checks
whether the user has the "administer nodes" permission. Such users have
unrestricted access to all nodes. Then the node module's hook_access()
is called, and a TRUE or FALSE return value will grant or deny access.
This allows, for example, the blog module to always grant access to the
blog author, and for the book module to always deny editing access to
PHP pages.

If node module does not intervene (returns NULL), then the
node_access table is used to determine access. All node access
modules are queried using hook_node_grants() to assemble a list of
"grant IDs" for the user. This list is compared against the table.
If any row contains the node ID in question (or 0, which stands for "all
nodes"), one of the grant IDs returned, and a value of TRUE for the
operation in question, then access is granted. Note that this table is a
list of grants; any matching row is sufficient to grant access to the
node.

In node listings, the process above is followed except that
hook_access() is not called on each node for performance reasons and for
proper functioning of the pager system. When adding a node listing to your
module, be sure to use db_rewrite_sql() to add
the appropriate clauses to your query for access checks.

To see how to write a node access module of your own, see
node_access_example.module.

In early 2009, The American Society of Media Photographers (ASMP) embarked on a website redevelopment project with Context, a web development firm based just outside of Philadelphia.

With over 7,000 members and an expansive website consisting of hundreds of pages ranging from informational tutorials to event registration to their national "Find a Photographer" service, the ASMP had quite a project in front of them, and were looking for guidance in determining which system would be able to meet their requirements.

After reviewing the ASMP's 11 page request-for-proposal and the wonderfully clean and organized designs provided by Chicago's Grillo Group, Context decided that Drupal was the only CMS that would make the project practical.

The development of Drupal Field API obligates us to look at taxonomy.module to keep it relevant and modern. The concerns At Drupalcon DC, Benjamin Melançon (ben-agaric) and Benjamin Doherty (bangpound) began to look at this problem and untie it. Here's what we propose.

Module reorganization

Taxonomy.module should primarily contain features for the management of controlled vocabularies: CRUD of vocabularies and terms, describing the hierarchy of terms, and other features that may or may not be fully developed yet: synonymy, term relationships.

A new module called term.module will be the field module that will replace all or most of taxonomy.module's nodeapi functionality. Hopefully it will do more, too.

Field widgets also need some development. Currently, we're using Options.module select widgets, but we shouldn't limit ourselves only to that widget. Tagging autocompletion widget will need to be built.

Tagging features live in taxonomy.module because there had been a significant overlap in the functional, UI and data requirements with taxonomy.module's support for controlled vocabularies. However, this overlap will become much less significant. I'd like to solicit the community's ideas about how to move tagging into a rational place in Drupal 7 and this proposal. We certainly do not propose abandoning tagging at all. We simply need to know where it fits in a Drupal 7 where taxonomy.module lets us manage vocabularies and term.module lets us put terms on things.

SportBusiness Group is the world's leading supplier of information, media and B2B marketing services to the sports industry and, with its network of partners and agents, assists companies from all over the globe in achieving their business goals.

The latest incarnation (site version 11, 3rd Drupal version) of the Sportbusiness.com website has finally brought us into the world of Drupal 6. We initially moved the site over to Drupal almost 3 years ago (back in the Drupal 4.7 days) after months of data conversion from a proprietry Oracle-based CMS. We've never looked back. The upgrade to Drupal 6 has just finished; the site has been redesigned and several major changes have been implemented.

Getting up to 10,000 page impressions a day certainly doesn't make this a high-traffic site by comparison to some of the other sites we have at Electric Word plc (parent company to SportBusiness), but the visitors to the site demand equally high levels of quality and content. This was something we had to maintain from previous releases.