Drupal Developer's Log and Instruction Manual

This book contains PHP patches and modifications made to Drupal CMS. The hope is to provide a more reliable, stable and usable instruction manual for new users of Drupal and the would be developers. These pages contain many changes that can be done to improve Drupal. Most are ones that do not happen as part of developement at Drupal.org. So this is a log of changes made by Hiveminz Magazine and other webmasters and developers.

If you are a PHP beginner making modifications to a system like Drupal makes for a good learning experience. You will also gain insights on how to use a MySQL or Postgresql database and other web technology.

Contributed Modules

This section contains information on modules contributed to Drupal or those that are not part of the Drupal.org repository. Frequently a module devloper creates an to Drupal CMS but does not want to maintain the module on the same schedule that the Drupal CMS project does.

atom.module

Provides an Atom feed and an implementation of the Atom API. This module does not change the default feeds but makes an additional feed format available. Atom feeds are considered to be more mordern and configurable than other types of RSS feeds.

audio.module

The audio module allows users to add audio media content to a site. Audio is an important medium for community communication. The recent rise of the podcast phenomenon is an example of the trend towards audio content. The audio module enables music, spoken word, and voicemail messages to be played on a site.

The audio module allows a user to create a new audio post. An audio post lets you upload, stream, and download audio files, and uses the getID3 library to read and write ID3 tag information from the audio file. The getID# library is required. This module comes with a handy flash player that can be embeded in your site. Audio files can be submitted by browsing users computer for files to upload. Audio posts can also be configured to allow the files to be downloaded. Audio administration allows the path for audio files to be uploaded to be configured. The getID3 library can also be configured in audio administration.

You can:

* listen to the most recent audio files added in your user profile at my account.
* add an audio file at create content >> audio.
* enable the latest audio and random audio blocks at administer >> block.
* administer audio module at administers >> settings >> audio.
* download and install the required getID3 library from getID3 sourceforge page.

Change the player type and style by over riding the function 'theme_audio_player($params)' in your theme level.

automember.module

This module provides automated role management for a single role. It also provides special pages that list contributed nodes by a certain author who is in the target role.

Applications of this module include:

automatically granting frequent and reliable contributers a special role.
automatically granting new users a special role byselecting a combination of criteria that users must meet before automatically gaining the target role. For a balanced eco-system, also specify the criteria that users must meet before automatically losing the target role.

NOTE: Cron is required. This is version 1.14.2.9. Cron last ran at Tue, 2005-05-03 19:09, and values will be recalculated again around Wed, 2005-05-04 19:09.

Example of membership criteria:

Target Role: Author

Max number of Authors : 10

Responsibilities:

Authors are required to maintain a high standard when participating in any capacity. Forum moderation, support and authoring are just a few of the participation tasks. Authors are also responsible for site administration when their access allows.

Premiums:

Authors gain access to all products and articles for the term of the role gained. If an Author is demoted then that author is required to pay the normal subscription rate. There is no refund for a previously paid subscription if and when a user gains Author access to Hivemindz.com.

Authenticated users must announce their interest by checking the appropriate checkbox in their profile.

The position is by invitation of the presiding Author group.

Minimum Criteria for a invitation:

minimum post rate of per week: 4
minimum post rate period: 4 weeks
an accumulated number of posts: 50
must be an authorized user for: 60 days

Karma Plus:

A member must post about material and topics that are intrinsic to web development, programming, IT etc.

Karma Minus:

Off-topic posts are not counted. Topics and posts with spam, politcal, religious and inflammatory content will count as minus points and cannot be cancelled out. A waiting period of 6 months minimum and up to a year will be set for any member deliberatly posting material of this sort. Authors participating in the commission of the previously mentioned will be demoted.

To maintain Author role:

minimum post rate of per week: 2
minimum post rate period: 4 weeks

bittorrent.module

The BitTorrent module allows the distribution of large files via the BitTorrent network technology. By sharing the cost of downloading as well as uploading with a network of other users no one site has to carry the burden of every download. This is very important for a network of community sites that want to share media such as podcasts, video blogs, and participatory culture media. BitTorrent should not be used to distribute copyrighted material. It is an open system and law enforcement officials can easily track and prosecute users who attempt to pirate content. This module provides a BitTorrent tracker which coordinates the sharing of content via a map of the content pieces in a .torrent file.

There is a list of torrents that are being tracked. You can set the explanation of BitTorrent for users of your site in general settings. You can also make a list of torrent announce URLs that your tracker will use. This module is not currently being distributed. It was developed by Digital Bicycle and will be distributed by CivicSpace Labs in a manner to avoid its use as a piracy tool.

You can:

* view a list of torrents at BitTorrent tracker.
* administer the BitTorrent general settings at administer >> settings >> BitTorrent.
* administer the BitTorrent tracker settings at administer >> settings >> BitTorrent >> tracker.

commentrss.module

This module adds comment RSS serving capabilties to Drupal, which is
suitable for some tracking of comments for your users. The module adds
feeds for the following points:

* complete site feed
* per vocabulary feeds
* per term feeds
* per node feeds
* per node type feeds (only in the 4.5 version)

This module might also be handy as an alternative to subscriptions, since
your users don't need to provide their email addresses, but still can follow
discussion on forums and other nodes. Due to the limited capabilities of RSS,
threading and such is not preserved, the comments are listed in reversed
time order.

The url to access the comment feed is http://www.domain.com/[drupal installation]/crss

i18n.module

Fully configurable module for internationalization (i18n) of Drupal sites. Provides content translation -nodes-, interface translation for anonymous users -with the locale module- and browser language detection. Includes a block for language selection.

i18n.inc

This is a accessory file to the i18n.module It contains most of the working code used in the internationalizaton of a Drupal website.

node_privacy_byrole.module

Node_privacy_byrole is a contributed module that allows user to set what groups (roles) can see their post. This FAQ contains information on the use of this module and code modifications.

nodequeue.module

If you have or are starting a jounalism, news or community site where the content needs to be controlled then you should try the node queue module. It will allow you to pick the content and choose the order that it is served to vistors. This goes far beyond the standard Drupal choices of frontpage and sticky. When you use the frontpage and sticky controls for content then maintenance increases. There is no list of nodes that have been promoted to frontpage and sticky. Demoting nodes after a time becomes difficult because of this. If you have a hundred nodes promoted then you have to go to each one and demote them. You are also limited to a single queue when doing this. With node queue there is an administration interface telling you what nodes have been put into the queue. You can have several queues. Rather than having to maintenance a lost of node one at a time you can delete an entire queue.

The Node Queue module allows an administrator to arbitrarily put nodes in a group for some purpose; examples of this might be to highlight one particular node, as in a typical news site's Lead Article. Another use might be to create a block listing teasers for 5 forum posts that the admin thinks are important. Another use might be to create a group of nodes, and then have a block or the front page offer one of these randomly.

Future uses include putting nodes into a queue that can be acted on automatically, such as a publishing queue where at a certain interval the front of the queue is promoted, or has a workflow state change, or some other automatic operation.

Once the module and the mysql file for the module are installed, an admin can go to admininister->nodequeue and create a new queue.

Queues can be set to allow only certain types of nodes to be added to the queue. Queue can be a fixed size or of infinite length. And the admin can select which roles have permission to add nodes to a given queue.

Once a queue is set up, a new tab will appear on eligible nodes for eligible users. This tab will allow the user--regardless of edit permissions--to add or remove that node from the queue. Queue admins can view the nodes in the queue, and can modify the order of items already in the queue.

When a node is added to the queue, it is added to the back of the queue. If a queue is full when a node is added, the front of the queue is removed.

In order to actually do something useful with a node queue, the admin is required to use a small PHP snippet. This is a very small snippet, and while it would have been possible to write code to avoid this, the PHP allows a much greater flexibility to the admin than to keep it all configured through menus, though it is somewhat less intuitive. You can use this snippet in phpTemplate which give you even greater flexiblility in layout design.

To Create a Block to Display Node Titles of a Queue

You'll need the Queue ID, which is easily extracted from the URL on the queue administration page.

Create a new block, and insert the following PHP snippet into the block:

<?php print nodequeue_node_titles(QUEUEID); ?>

If you want this queue to be printed in the reverse order, you can tell it to print backward:

<?php print nodequeue_node_titles(QUEUEID, '', true); ?>

The '' in the line above is an optional title field. Feel free to put
something here, but it's not terribly necessary in a block.

To Create a Page to Display Node Teasers of a Queue

Like above, you'll need the Queue ID.

Create a new page (or a new dashboard!) or any node type you like, really, and set the input filter to PHP. Insert the following PHP snippet:

<?php print nodequeue_nodes(QUEUEID); ?>

There are a few more options available here; changing the order of the nodes, whether or not to use teasers or full nodes, whether or not to display the links, and how much of the queue to display. See below.

To Show Just The First or Last Element of a Queue

Starting with the examples above, but use the following:

<?php print nodequeue_fetch_front(QUEUEID); ?>

<?php print nodequeue_fetch_back(QUEUEID); ?>

Remember that the front of the queue will have the least recently added nodes (unless it was rearranged manually), and the back will have the most recently added.

Available Functions and Descriptions

nodequeue_node_titles($qid, $title = '', $backward = true)
Display a title list of the queue. If backward is true (the default) the list will be from back (newest) to front (oldest).

nodequeue_nodes($qid, $backward = true, $teasers = true, $links = true,
$from = 0, $count = 0)
Display the nodes of a queue. If backward is true (the default) the
list will be from back (newest) to front (oldest). If $count
is set to non-zero, it will use a range. For example, passing
$from = 2 and $count = 2 will show the 3rd and 4th elements of
the queue. ($count starts at 0, not 1.)

if $teasers is true, the node teaser will be shown; otherwise the full node will be shown.

nodequeue_fetch_front($qid, $teasers = true, $links = true)
Fetch the node at the front of the queue.

nodequeue_fetch_back($qid, $teasers = true, $links = true)
Fetch the node at the back of the queue.

function nodequeue_fetch_random($qid, $teasers = true, $links = true) to fetch a random node from the queue

Actions Module Integration

The node queue module provides two actions, so that workflow can add and remove items from queues.

paypal_framework.module

PayPal provides an easy way to send and receive money online, and this module allows you to use this system so that users can pay regularly via PayPal.

The paypal_framwork.module provides communication resources for other modules. Paypal uses secure HTTP communication to recieve and respond to requests made from other websites. Transaction information is logged via the paypal_framework.module in real time. This transaction information is consumed by paypal subscription, ecommerce , and donation modules.

paypal_subscription.module

PayPal provides an easy way to send and receive money online, and this module allows you to grant special status to users who pay regularly via PayPal. Transaction information is logged via the paypal_framework.module in real time. When paypal_framework.module logs the information, this module is prompted to act. Additionally, this module updates periodically on its own using cron.

If a user paid enough money via PayPal for the right item and during the right time period, this module grants them a role on this web site. Access permissions and other things can be defined per role using other Drupal modules. See the Drupal module list for more information.

weblink.module

The weblinks module is used to create links to other websites or pages.

The weblink monitor tracks or crawls other interesting web sites and
displays their latest modification dates. Vistors to the host site
learn about relevant sites and can easily see if there is new content.
Here is how it works:

The site administrator selects certain weblinks for monitoring from the administration page.
Drupal's
cron function triggers the weblink module to check all the monitored
web sites for recent changes or updates. A page is updated when there
is a x-byte difference since the last time it was checked, where x is a configuration option.
The module exports both a page and a block that displays the registered sites ordered by their last modification date.

administer settings

The settings and configuration area is where a lot of commonly used functionality can be set. Email adresses, custom 404(page not found), 403 (access denied) and other items are found here.

aggregator.module

Thousands of sites (particularly news sites and weblogs) publish their latest headlines and/or stories in a machine-readable format so that other sites can easily link to them. This content is usually in the form of an RSS feed (which is an XML-based syndication standard).

You can read aggregated content from many sites using RSS feed readers, such as Amphetadesk.

Drupal provides the means to aggregate feeds from many sites and display these aggregated feeds to your site's visitors. To do this, enable the aggregator module in site administration and then go to the aggregator configuration page, where you can subscribe to feeds and set up other options.
How do I find RSS feeds to aggregate?

Many web sites (especially weblogs) display small XML icons or other obvious links on their home page. You can follow these to obtain the web address for the RSS feed. Common extensions for RSS feeds are .rss, .xml and .rdf. For example: Slashdot RSS.

If you can't find a feed for a site, or you want to find several feeds on a given topic, try an RSS syndication directory such as Syndic8.

To learn more about RSS, read Mark Pilgrim's What is RSS and WebReference.com's The Evolution of RSS articles.

NOTE: Enable your site's XML syndication button by turning on the Syndicate block in block management.
How do I add a news feed?

To subscribe to an RSS feed on another site, use the aggregation page.

Once there, click the new feed tab. Drupal will then ask for the following:

* Title -- The text entered here will be used in your news aggregator, within the administration configuration section, and as a title for the news feed block. As a general rule, use the web site name from which the feed originates.
* URL -- Here you'll enter the fully-qualified web address for the feed you wish to subscribe to.
* Update interval -- This is how often Drupal will scan the feed for new content. This defaults to every hour. Checking a feed more frequently that this is typically a waste of bandwidth and is considered somewhat impolite. For automatic updates to work, cron.php must be called regularly. If it is not, you'll have to manually update the feeds one at a time within the news aggregation administration page by using update items.
* Latest items block -- The number of items selected here will determine how many of the latest items from the feed will appear in a block which may be enabled and placed in the blocks administration page.
* Automatically file items -- As items are received from a feed they will be put in any categories you have selected here.

Once you have submitted the new feed, check to make sure it is working properly by selecting update items on the aggregation page. If you do not see any items listed for that feed, edit the feed and make sure that the URL was entered correctly.
Adding categories

News items can be filed into categories. To create a category, start at the aggregation page.

Once there, select new category from the menu. Drupal will then ask for the following:

* Title -- The title will be used in the news by topics listing in your news aggregator and for the block created for the bundle.
* Description -- A short description of the category to tell users more details about what news items they might find in the category.
* Latest items block -- The number of items selected here will determine how many of the latest items from the category will appear in a block which may be enabled and placed in the blocks administration page.

Using the news aggregator

The news aggregator has a number of ways that it displays your subscribed content:

* News aggregator (latest news) -- Displays all incoming items in the order in which they were received.
* Sources -- Organizes incoming content by feed, displaying feed titles (each of which links to a page with the latest items from that feed) and item titles (which link to that item's actual story/article).
* Categories -- Organizes incoming content by category, displaying category titles (each of which links to a page with the latest items from that category) and item titles (which link to that item's actual story/article).

Pages that display items (for sources, categories, etc.) display the following for each item:

* The title of the item (its headline).
* The categories that the item belongs to, each of which links to that particular category page as detailed above.
* A description containing the first few paragraphs or a summary of the item (if available).
* The name of the feed, which links to the individual feed's page, listing information about that feed and items for that feed only. This is not shown on feed pages (they would link to the page you're currently on).

Additionally, users with the administer news feeds permission will see a link to categorize the news items. Clicking this will allow them to select which category(s) each news item is in.
Technical details

Drupal automatically generates an OPML feed file that is available by selecting the XML icon on the News Sources page.

When fetching feeds Drupal supports conditional GETs, this reduces the bandwidth usage for feeds that have not been updated since the last check.

If a feed is permanently moved to a new location Drupal will automatically update the feed URL to the new address.

banner.module

In order to properly install and configure the banner module, you might need some knowledge of PHP, the Drupal themeing system, and of using tools such as patch. This module can be difficult to install.
The following document attempts to make the installation process more clear. Please follow these steps carefully and exactly as written before filing a support request. It is advised that you review this entire document before you try and install this module.

Preparation

Properly configure 'File system' support for your Drupal installation. Goto :: administer -> settings :: then find "File system settings". Follow the directions on this page to set a proper "File system path" and "Temporary directory". When this is properly configured, you will not see any errors.

Installation:

The first thing to do is to update your database, adding the 'banner' table. This can easily be done from the command line by copying the included 'banner.mysql' file to your webserver, then running a command something like:

$ mysql -u<username> -p<password> <database> < banner.mysql

For example, if your username is 'drupal', your password is 'secret', and
your database is called 'drupal', you'd type the following command:

$ mysql -udrupal -psecret drupal < banner.mysql
Move 'banner.module' into your modules/ directory.
Move 'banner_db.php' and 'banner_file.php' into your top level Drupal directory. Give these files proper permissions so that they can be read by the webserver. These files are added for performance reasons. By utilizing these files the banner.module can display different banners to different people even on cached pages. The actual performance gain is realized by not including Drupal's include files each time a banner needs to be displayed.
Now you need to log in to your site and enable the new banner.module. Goto :: administer -> modules :: then check 'banner'.

Configuration:

Configure the banner module. At minimum, it is _HIGHLY_ recommended that you enable the file caching mechanism built into this module. The rest of the settings can be left at their defaults for now. Goto :: administer -> settings -> banner . The file-caching mechanism used by this module greatly increases banner-display performance. It is not required, but you will not get very good performance from this module without it.

Setup banner module permissions. Goto :: administer -> users -> configure -> permissions:

Give 'show banners' permission to users that should see the banners.
Give 'manage banners' permission to users that should be allowed to track view/click statistics for their own banners.
Give 'upload banners' permission to users that should be allowed to upload new banners. Usually you would also give those users 'manage banners' permission at the same time.
Give 'administer banners' permission to users that should be allowed to add/edit/delete all banners on your site.

Uploading graphical banners:

Upload a new banner via the administrative interface. Goto :: administer -> banners -> add.
1. give the banner a descriptive title. (when you are managing lots of banners, it becomes important that this title describe the banner)
2. enter a URL where you want clicking on the banner to take you.
3. set the status to 'enabled' so that the banner is displayed.
4. scroll to the bottom of the page and click 'browse' to select a banner image to upload. (it is important that the filename of your image end in three characters indicating the filetype. Supported image types are: jpg, jpeg, gif, png, bmp and tiff)
5. click save. For now, we'll leave the rest of the options set to their defaults. Once everything is confirmed to be working on your installation, then you can worry about the more complicated configuration options.
Preview the newly uploaded banner. Goto :: administer -> banners. You should currently see a list of all the banners you've uploaded. Find the name of the banner you just uploaded, and click 'view' in the options column. You should now see your banner at the top of the page, along with general information and statistics about the banner. If you don't see the banner you just uploaded, something has gone wrong. If you're seeing garbage text instead of the image, then the module failed to recoginze the file type and is instead trying to display the image as text. Be sure the file name is something like "banner.jpg" or "banner.png", specifically including the three letters at the end appropriate to the file type.

Uploading text advertisements:

Prepare the text ad. Text ads require a little extra manual effort. Specifically, you must add a link within the the text of the ad that points to the banner's appropriate link url. After the banner is created, you can find the banner's id at "administer -> banners". This means you will need to upload the banner twice. The first time you upload the banner you won't know the new banners id. Assuming the banner has an id of 13, you will need to include a link in the banner's text to the URL "/banner/13". For example:

<a href="http://mysite.com/banner/13">banner text</a>

Note: Do NOT link directly to where the banner is actually taking you, or the clicks will NOT be counted. When uploading the banner, you will be able to set the end URL.
Upload a new banner via the administrative interface. Goto :: administer -> banners -> add.
1. give the banner a descriptive title. (when you are managing lots of banners, it becomes important that this title describe the banner)
2. enter a URL where you want clicking on the text ad to take you.
3. set the status to 'enabled' so that the text ad is displayed.
4. scroll to the bottom of the page and click 'browse' to select the text file to upload. (it is advised that the filename of your text ad end in with '.txt'. If you do not do this, the banner module may not recognize your ad as being text and it may not display properly.)
5. click save. For now, we'll leave the rest of the options set to their defaults. Once everything is confirmed to be working on your installation, then you can worry about the more complicated configuration options.
Preview the newly uploaded text ad.(Goto :: administer -> banners) You should currently see a list of all the ads you've uploaded. Find the name of the text ad you just uploaded, and click 'view' in the options column. You should now see your text ad at the top of the page, along with general information and statistics about the ad. If you don't see the text from the ad you just uploaded, something has gone wrong. Try renaming the text file to end with '.txt' and uploading it again.

Displaying banners and text ads from blocks:

The easiest way to display banners and text ads on your site (easiest because then you do not have to edit your theme) is to display them from a Drupal block. (Goto :: administer -> blocks -> add)

set a title for the block, such as 'Advertisement'
set the input format to 'PHP code'
In the block body, enter the following:

<?php return banner_display(); ?>
optionally enter a block description
click 'Save block'
at "administer -> blocks' enable your new block

Displaying multiple ads on one page:

The banner module currently supports up to ten different unique groups of banners. The default display group is 0. You can also display banners from groups 1 thorugh 9. This allows you to for example display banner ads at the top of your page, and text ads in a block on the side. The display group of a given ad is set when you add the banner, or later by editing it. To display banners in a different group, you need to pass in the group number when calling banner_display. For example, to display banners from group 3 you would use the following call:

<?php return banner_display(3); ?>

Displaying banners and text ads from your theme:

To display a banner from your theme, you will need to modify the theme. How this is done is different for each theme. Essentially though, you need to add a call to banner_display() in the appropriate place. Finding the appropriate place is the challenge. For some simple examples, refer to the sample patches that come with the banner.module. The sample patches are in contributed/theme.

Sorry, I am unable to provide sample patches for all available themes. Please refer to the provided sample patches to better understand how you can patch your favorite themes yourself.

FAQ

Q. I don't see any images. What's wrong?

A. Be sure you installed 'banner_db_php' and 'banner_file.php', and properly set the permissions on these files so they can be read by your webserver. (See above)

Q. I did install the files correctly, but I still don't see any images.What's wrong?

A. Try refreshing the banner cache. Go to: administer >> banner >> refresh cache

Q. I've refreshed my cache, but I'm still not seeing images. What's wrong?

A. Edit the banner and be sure that the MIME type was properly detected. Go to: administer >> banner >> list then click 'edit' next to problematic banner. At the bottom of the page you can update the MIME type.

block.module

Blocks are the boxes visible in the sidebar(s) of your web site. These are usually generated automatically by modules (e.g. recent forum topics), but you can also create your own blocks.

The sidebar each block appears in depends on both which theme you're using (some are left-only, some right, some both), and on the settings in block management.

Whether a block is visible in the first place depends on four things:

* It must have its "enabled" box checked in block management.
* If it has its "custom" box checked in block management, the user must have chosen to display it in their user preferences.
* If the "path" field in block management is set, the visitor must be on a page that matches the path specification (more on this later).
* If the block has its throttle box checked, the user will only see the block if the site throttle level is low.

The block management screen also lets you specify the vertical sort-order of the blocks within a sidebar. You do this by assigning a weight to each block. Lighter blocks (smaller weight) "float up" towards the top of the sidebar. Heavier ones "sink down" towards the bottom of it.

The path setting lets you define the pages on which a specific block is visible. If you leave the path blank it will appear on all pages. The path uses a regular expression syntax so remember to escape special characters! The path expression is matched against the relative URL of a Drupal page, e.g. book, node/12, admin.

In case you do not know what a regular expression is, you should read about them in the PHP manual. The chapter to look at is the one on Perl-Compatible Regular Expressions (PCRE).

However, for basic tasks it is sufficient to look at the following examples:

If the block should only show up on blog pages, use <^blog>. To display on all node views use <^node>. The angular brackets are used as delimiters of the regular expression. To show up on either forum or book pages use <^(forum|book)>. The round brackets form a group of expressions, divided by the | character. It matches if any of the expressions in it match. A more complicated example is <^node/add/(story|blog|image)>. Blocks which have their paths set to this expression will show up on story, block, or image composition pages. If you want to show a block an all pages, but not the search page, use <^(?!search)>.
Administrator Defined Blocks

An administrator defined block contains content supplied by you (as opposed to being generated automatically by a module). Each admin-defined block consists of a title, a description, and a body which can be as long as you wish. The Drupal engine will 'render' the content of the block.

blog.module

Drupal's blog module allows registered users to maintain an online weblog (commonly known as a blog), often referred to as an online journal or diary. These can be filled with daily thoughts, poetry, boneless blabber, spiritual theories, intimate details, valuable experiences, cynical rants, semi-coherent comments, writing experiments, artistic babblings, critics on current facts, fresh insights, diverse dreams, chronicles and mumbling madness available for public consumption.

Blogs are made up of individual entries (nodes) that are timestamped and are typically viewed by day as you would a diary. Blogs often contain links to things you've seen and/or agree/disagree with. A typical example of a long term blog can be seen at http://www.scripting.com/.

The blog module adds a "user blogs" navigation link to the site, which takes any visitor to a page that displays the most recent blog entries from all the users on the site. Personal user menus gain a "create a blog entry" link (which takes you to a submission form) and a "view personal blog" link (which displays your blog entries as other people will see them). On the bottom of each of your own blog entries, there is an "edit this blog entry" link that lets you edit or delete that entry.

If a user has the ability to post blogs, then the import module (news aggregator) will display a blog-it link (b) next to each news item in its lists. Click on this and you will be taken to the blog submission form, with the title, a link to the item, and a link to the source into the body text already in the text box, ready for you to add your explanation. This actively encourages people to add blog entries about things they see and hear elsewhere in the Drupal site and from your syndicated partner sites.

blogapi.module

This module adds support for several XML-RPC based blogging APIs. Specifically, it currently implements the Blogger API, MetaWeblog API, and most of the Movable Type API. extensions. This allows users to contribute to Drupal using external GUI applications, which can often offer richer functionality that online forms based editing.

This module also allows site administrators to configure which node types can be posted via the external applications. So, for instance, users can post forum topics as well as blog posts. Where supported, the external applications will display each node type as a separate "blog".

book.module

The book organises content into a
nested hierarchical structure. It is particularly good for manuals,
Frequently Asked Questions (FAQs) and the like, allowing you to have
chapters, sections, etc.

A book is simply a collection of nodes that have been linked together. These nodes are usually of type book page, but you can insert nodes of any type into a book outline. Every node in the book has a parent
node which "contains" it. This is how book.module establishes its
hierarchy. At any given level in the hierarchy, a book can contain many
nodes. All these sibling nodes are sorted according to the weight that you give them.

Book pages contain a log message
field which helps your users understand the motivation behind an edit
of a book page. Each edited version of a book page is stored as a new
revision of a node. This capability makes it easy to revert to an old
version of a page, should that be desirable.

Like other
node types, book submissions and edits may be subject to moderation,
depending on your configuration. Similarly, books use permissions
to determine who may read and write to them. Only administrators are
allowed to create new books, which are really just nodes whose parent
is <top-level>. To include an existing node in your
book, click on the "outline"-tab on the node's page. This enables you
to place the node wherever you'd like within the book hierarchy. To add
a new node into your book, use the create content » book page link.

Administrators may review the hierarchy of their books by clicking on the collaborative book
link in the administration pages. There, nodes may be edited,
reorganized, removed from book, and deleted. This behavior may change
in the future. When a parent node is deleted, it may leave behind child
nodes. These nodes are now orphans. Administrators should periodically review their books for orphans and reaffiliate those pages as desired. Finally, administrators may also export their books to a single, flat HTML page which is suitable for printing.

Maintaining a FAQ using a collaborative book

Collaborative
books let you easily set up a Frequently Asked Questions (FAQ) section
on your web site. The main benefit is that you don't have to write all
the questions/answers by yourself - let the community do it for you!

In order to set up the FAQ, you have to create a new book which will hold all your content. To do so, click on the create content » book page
link. Give it a thoughtful title, and body. A title like "Estonia
Travel - FAQ" is nice. You may always edit these fields later. You will
probably want to designate <top-level> as the parent of this page. Leave the log message and type
fields blank for now. After you have submitted this book page, you are
ready to begin filling up your book with questions that are frequently
asked.

Whenever you come across a post which you want to include in your FAQ, click on the administer link. Then click on the edit book outline button at the bottom of the page. Then place the relevant post wherever is most appropriate in your book by selecting a parent. Books are quite flexible. They can have sections like Flying to Estonia, Eating in Estonia and so on. As you get more experienced with the book module, you can reorganize posts in your book so that it stays organized.

Notes:

Any
comments attached to those relevant posts which you designate as book
pages will also be transported into your book. This is a great feature,
since much wisdom is shared via comments. Remember that all future
comments and edits will automatically be reflected in your book.
You may wish to edit the title of posts when adding them to your FAQ. This is done on the same page as the Edit book outline button. Clear titles improve navigability enormously.
Book
pages may come from any content type (blog, story, page, etc.). If you
are creating a post solely for inclusion in your book, then use the create content » book page link.
If you don't see the administer link, then you probably have insufficient permissions.

codefilter.module

The codefilter module is in charge of control if and how server-side code or browser code is presented. The PHP version used must be taken in account as this module uses PHPs highlight_string() function. The hightlight_string()function is different on PHP5. PHP4 still uses font tags and other non XHTML compliant code. PHP5 uses the span tag and other XHTML compliant code.

comment.module

When enabled, the Drupal comment module creates a discussion board for each Drupal node. Users can post comments to discuss a forum topic, weblog post, story, collaborative book page, etc. An administrator can give comment permissions to user
groups, and users can (optionally) edit their last comment, assuming no others have been posted since.

User control of comment display

Attached to each comment board is a control panel for customizing the way that comments are displayed. Users can control the chronological ordering of posts (newest or oldest first) and the number of posts to display on each page. Additional settings include:

Threaded — Displays the posts grouped according to conversations and subconversations.
Flat — Displays the posts in chronological order, with no threading whatsoever.
Expanded — Displays the title and text for each post.
Collapsed — Displays only the title for each post.

When a user chooses save settings, the comments are then redisplayed using the user's new choices. Administrators can set the default settings for the comment control panel, along with other comment defaults, in administer » comments » configure. NOTE: When comment moderation is enabled, users will have another control panel option to control thresholds (see below).

Additional comment configurations

Comments behave like other user submissions in Drupal. Filters, smileys and HTML that work in nodes will also work with comments. Administrators can control access to various comment module functions through administer » users » configure » permissions. Know that in a new Drupal installation, all comment permissions are
disabled by default. The choice of which permissions to grant to which roles (groups of users) is left up to the site administrator. The following permissions:

Access comments — Allows users to view comments.
Administrate comments — Allows users complete control over configuring, editing and deleting all comments.
Moderate comments — Allows users to rate comment postings (see more on moderation below).
Post comments — Allows users to post comments into an administrator moderation queue.
Post comments without approval — Allows users to directly post comments, bypassing the moderation queue.

Notification of new comments

Drupal provides specific features to inform site members when new comments have been posted.

Drupal displays the total number of comments attached to each node, and tracks comments read by individual site members. Members which have logged in will see a notice accompanying nodes which contain comments they have not read. Some administrators may want to download, install and configure the notify module. Users can then request that Drupal send them an e-mail when new comments are posted (the notify module requires that cron.php be configured properly).

The tracker module, disabled by default, displays all the site's recent posts. There is a link to the recent posts page in the navigation block. This page is a useful way to browse new or updated nodes and comments. Content which the user has not yet read is tagged with a red star (this graphic depends on the current theme). Visit the comment board for any node, and Drupal will display a red "new" label beside the text of unread comments.

Comment moderation

On sites with active commenting from users, the administrator can turn over comment moderation to the community.

With comment moderation, each comment is automatically assigned an initial rating. As users read comments, they can apply a vote which affects the comment rating. At the same time, users have an additional option in the control panel which allows them to set a threshold for the comments they wish to view. Those comments with ratings lower than the set threshold will not be shown. To enable moderation, the administrator must grant moderate comments permissions. Then, a number of options in administer » comments » configure must be configured.

Moderation votes

The first step is to create moderation labels which allow users to rate a comment. Go to administer » comments » configure » moderation votes. In the vote field, enter the textual labels which users will see when casting their votes. Some examples are

Excellent +3
Insightful +2
Useful +1
Redundant -1
Flame -3

So
that users know how their votes affect the comment, these examples include the vote value as part of the label, although that is optional. Using the weight option, you can control the order in which the votes appear to users. Setting the weight heavier (positive numbers) will make the vote label appear at the bottom of the list. Lighter (a negative number) will push it to the top. To encourage positive voting, a useful order might be higher values, positive votes, at the top, with negative votes at the bottom.

Moderator vote/values matrix

Next go to administer » comments » configure » moderation matrix. Enter the values for the vote labels for each permission role in the vote matrix. The values entered here will be used to create the rating for each comment. NOTE: Comment ratings are calculated by averaging user votes with the initial rating.

Creating comment thresholds

In administer » comments » configure » moderation thresholds, you'll have to create some comment thresholds to make the comment rating system useful. When comment moderation is enabled and the
thresholds are created, users will find another comment control panel option for selecting their thresholds. They'll use the thresholds you
enter here to filter out comments with low ratings. Consequently,
you'll probably want to create more than one threshold to give users
some flexibility in filtering comments.

When creating the thresholds, note that the Minimum score
is asking you for the lowest rating that a comment can have in order to
be displayed. To see a common example of how thresholds work, you might
visit Slashdot and view one of their comment boards associated with a story. You can reset the thresholds in their comment control panel.

Initial comment scores

Finally, you may want to enter some initial comment scores. In administer » comments » configure » moderation roles you can assign a beginning rating for all comments posted by a particular permission role. If you do not assign any initial scores, Drupal will assign a rating of 0 as the default.

comment.module has been adjusted to only allow those that have book maintenance previleges to create comments on book pages. This was done to filter out posts that are questions or comments concerning material but are not helpful in authoring a better page. Comments that are related to the material written about but do not contain educational or informative content should be made in the forum. Reference to the book page may be given if necessary.

This adjustment to the comment section of the book area makes the book collaboration more Wikipedia like and allows for authors to discuss changes before commiting them to the age.

common.inc

This page contains many of the frequntly used HTML functions. It is a common repository for those items that are shared by pages within the Drupal CMS.

drupal.module

The "Drupal" module features a capability whereby other drupal sites may call home to report their existence. In turn, this enables a pod of Drupal sites to find, cooperate and advertise each other.

Currently, the main application of this feature is the Drupal sites page. By default, fresh Drupal installations can use drupal.org as their directory server and report their existence. This reporting occurs via scheduled XML-RPC pings.

Drupal administrators should simply enable this feature to get listed on the Drupal sites page. Just set your site's name, e-mail address, slogan and mission statement on the administer » settings page. Then make sure that the field called Drupal XML-RPC server on the administer » settings » drupal page is set to http://www.drupal.org/xmlrpc.php, and enable this feature using the dropdown directly below.

The listing of your site will occur shortly after your site's next
cron run. Note that cron.php should be called using the domain name
which you want to have listed at drupal.org.
For example, don't kick off cron by requesting
http://127.0.0.1/cron.php. Instead, use a publicly accessible domain
name such as http://www.example.com/cron.php.

Also note that your installation need not use drupal.org as its
directory server. For example, this feature is perfectly capable of
aggregating pings from all of your departmental drupal installations
sites within an enterprise.

feedback.module

Users with the correct permissions can send feedback
to the site admin via email from a form on the site.

To enable its use, a user needs the "access feedback" permission.

The site admin specifies the email address that the users send to, as well as other
parameters, such as what fields to show the user to fill (name, address, email), whether
the user address is to be validated, and whether to log all attempts to use this form.

The email address is never visible to the users, and therefore cannot be used by SPAM
harvesters.

forum.module

Creating a forum

The forum module uses taxonomy to organize itself. To create a forum you first have to create a taxonomy vocabulary.
When doing this, choose a sensible name for it (such as "fora") and
make sure under "Types" that "forum" is selected. Once you have done
this, add some terms to it. Each term
will become a forum. If you fill in the description field, users will
be given additional information about the forum on the main forum page.
For example: "troubleshooting" - "Please ask your questions here."

When you are happy with your vocabulary, go to administer » settings » forum and set Forum vocabulary
to the one you have just created. There will now be fora active on the
site. For users to access them they must have the "access content" permission and to create a topic they must have the "create forum topics" permission. These permissions can be set in the permission pages.

Icons

To disable icons, set the icon path as blank in administer » settings » forum.

All
files in the icon directory are assumed to be images. You may use
images of whatever size you wish, but it is recommended to use 15x15 or
16x16.

How to create and use dynamic menus in Drupal 6

I wanted to create a dynamic menu and store it in a variable like the default $primary_links or $secondary_links. This is so that the site administrator could update and create links for the footer without having to do HTML.

Step one was go login as the administrator and go to menus->add menu.

Create a new menu. Following the instructions under the textfield create a menu called "footer". Title the menu with "Footer links" so it is easy to find.

The system automatically adds a prefix to the menu name so the name in the database will be menu-footer.

Now that I have a menu and know its name I only had to find the right Drupal function and use the following code,

<?php
$footer_links = theme('links',menu_navigation_links('menu-footer'),array('class' => 'links', 'id' => 'footlist'));
?>

The above code was okay but it uses the default formatting. I wanted to do something slightly different. This not the exact code but something to give you an idea of how to do things in a more custom fashion.

<?php $footer_links = menu_navigation_links('menu-footer');?>
<div id="navigation">
<?php if (is_array($footer_links)) : ?>
<ul id="foot-list">
<?php foreach ($footer_links as $link): ?>
<li><?php print $link?></li>
<?php endforeach; ?>
</ul>
<?php endif; ?>
</div>

I added this to the bottom of page.tpl.php. I only had one last step and that was to start creating some links for the menu. I went to the menus area and saw a new link called "Footer links". Clicking on this brought a form for adding links and I could see the parent would be set as "<Footer links>". I added a few more links and I was done. The next thing I did was to add a page and use the menu settings in the form to add a link to the footer.

Happy publishing!

How To's

How to create and use dynamic menus in Drupal 6

locale.module

printer-friendly version

locale.module

Most programs are written and documented in English, and primarily use English to interact with users. This is also true for a great deal of web sites. However, most people are less comfortable with English than with their native language, and would prefer to use their mother tongue as much as possible. Many people love to see their web site showing a lot less English, and far more of their own language. Therefore Drupal provides a framework to setup a multi-lingual web site, or to overwrite the default English texts.

How to interface translation works

Whenever Drupal encounters an interface string which needs to be displayed, it tries to translate it into the currently selected language. If a translation is not available, then the string is remembered, so you can look up untranslated strings easily.

Drupal provides two options to translate these strings. First is the integrated web interface, where you can search for untranslated strings, and specify their translations via simple web forms. An easier, and much less time consuming method is to import translations already done for your language. This is achieved by the use of GNU gettext Portable Object files. These are editable with quite convenient desktop editors specifically architected for supporting your work with GNU Gettext files. The import feature allows you to add strings from such files into the site database. The export functionality enables you to share your translations with others, generating Portable Object files from your site strings.

mail.module

The mail module lets your users
with appropriate permissions send mail to registered site users. Emails
are also saved to the site database for future reference.

Mails
sent from the admin account are tagged with the site name and come from
the site admin email address. Mail sent from other accounts have that
account's email as a return address and are tagged with a name in the
form "username at site" where username is the user name of the user
doing the posting and site is the name of the site.

administer » configuration » modules » mail

User access permissions for mail

send emails to users:
Allows a role to post email to users. They cannot edit or delete
stories, even if they are the authors. You must enable this permission
to in order for a role to create a mail message.

mailhandler.module

The Mailhandler module allows registered users to create or edit nodes and comments via e-mail. Authentication is usually based on the From: e-mail address. Users may post taxonomy terms, teasers, and other node parameters using the Commands capability.

It also provides an API to other modules.

Administration

First, setup a POP3 mailbox, an IMAP mailbox, or a local folder that will be used to collect incoming e-mails. This mailbox should be used only for this function as Mailhandler will try to process all e-mails that arrive in this mailbox.

Next, visit the $link->add page ... The e-mail address for this mailbox is displayed when a user views his own user page along with instructions for posting via e-mail. Then add the appropriate connection details ... Admins may optionally require a password in the Commands section of the e-mail for additional security ... Usually, mailhandler sends an e-mail reply to invalid submissions, but admins may disable this feature. Disabling replies is a good idea when the Sender is a mailing list, to avoid spamming the list ... A set of default Commands may be associated with each mailbox. These commands may be overridden by the Commands included in the submission. Still, default commands provide an easy way to add meta-data to e-mail posts when users are unwilling/unable to include Commands in their submission.

For example, consider setting up a mailbox for linux@mysite.org. Then add taxonomy: [technology, linux] as a default command for this mailbox. Then, nodes posted via this e-mail address will automatically include relevant taxonomy terms.

Email signatures may optionally be stripped from submissions, if they begin with the admin's designated signature separator.

This mailbox will then be checked on every cron run. Admins may also initiate a manual retrieve of messages on the


admin/mailhandler

Sender:

Usage - an example

Subject: Ninth Symphony, Fourth Movement
From: ludwig@mysite.org
In-Reply-To: nid=5&sid=8

type: song
taxonomy: [music,symphony,composition]
promote: 1
pass: freude

Freude, schöner Götterfunken,
Tochter aus Elysium,
Wir betreten feuertrunken,
Himmlische dein Heiligtum.
Deine Zauber binden wieder,
Was die Mode streng geteilt;
Alle Menschen werden Brüder,
Wo dein sanfter Flügel weilt

--
Ludwig v. Beethoven
Composer
I will seize Fate by the throat. It will not wholly conquer me!
Oh, how beautiful it is to live - and live a thousand times over!

Usage - overview

Email submissions are divided into 4 parts - header, commands, node body and signature. You may visualize each by noting the blank lines between each section in the example above.

Header

The e-mail header contains three fields which are important. The first is the e-mail's Subject:, which automatically becomes the Title of the node or comment. The address in the From: header is usually used to determine the Author of the resulting post (a Command may override the From: address if desired). The Message-ID and In-Reply-To headers are also used by determine where to post the reply. In the example above, Ludwig's e-mail results in an edit to node 5 and sid 8.

Commands

The Commands section begins with the start of the e-mail body and ends at the first line which does not contain an : in its first word.

A submission may optionally contain Commands. These name/value pairs are automatically parsed and passed to the node_save() or comment_post() function. In the example above, you see that Ludwig is posting a song node. Mailhandler happily accepts submissions for all standard and custom node types. Ludwig then lists 3 taxonomy terms which should be associated with his post. Next, Ludwig specifies that his submission should be immediately promoted. If Ludwig has the administer nodes permission, this command is processed. Finally, Ludwig sends his password as a command, thus meeting his admin's requirement for high security from e-mail submissions.

Note that the taxonomy command is surrounded by brackets. These brackets instruct the Mailhandler to parse items separated by commas. This capability enables e-mail users to submit arrays to node_save().

status: 0 = not published, 1 = published

moderate: 0 = NOT in moderation queue, 1 = in moderation queue

revision: 0 = no revision, 1 = a revision

comment: 0 = disabled, 1 = read only, 2 = read/write

promote: 0 = not promoted, 1 = promoted to front page

sticky: 0 = not sticky, 1 = sticky at the top of the page

title: DO NOT USE THIS, use the mail subject only, if you use both, the title will be a combination of both subject and title (like "Welcome ! Welcome !")

path: to set an alias

body: not checked yet, but i just guess it will be combined with the main content

format: 1 = "normal" , 2 = php, 3 = complete html --> formats depend on your input filter settings

more tips

You can bypass most of the commands, if you set up a flexinode and change the workflow for this new node type, e.g. set "published" to default

Body

The node body begins at the beginning of the e-mail body if no commands are present. Otherwise, it begins after the first blank line. Bodies may be in HTML or plain text. Admins may choose to disallow HTML posting via e-mail if desired.

Signature

The signature section begins whenever the signature separator is found at the beginning of a line. This line, and all lines below it are ignored. Admins may disable signature stripping in the Mailbox configuration.

API

Module authors can utilize mailhandler to enable their modules to receive e-mails. Note that the In-Reply-To: (or References: ) header is parsed by mailhandler and all name/value pairs are added to the node/comment object. Thus, Message-ID mail header is an excellent place for module authors to maintain threading information, because e-mail clients almost always include these pairs in replies. Mailhandler expects the value of Message-Id to have a syntax similar to a querystring.

For every received e-mail, the mailhandler hook is called once. That is, if you put a function <your_module_name>_mailhandler into your module it will be called with five arguments. These arguments are:

\$node: An object containing the new node or comment. You should accept this parameter by reference, and change elements as needed.
\$stream: The number of the opened imap stream.
\$msg_number: The number of the current message in the mailbox.
\$header: An object containing email headers. See imap_header()
\$mailbox: Array containing info about the mailbox the message is from.

Thus a module has access to all possible info about the submitted mail. After looping through all _mailhandler functions, the node or comment is saved, if it is not destroyed in your or another module.

For an example module using mailhandler have a look at the project module from the contrib-cvs.

Notes

Mailhandler currently provides a termName -> termID mapping service so that users may submit taxonomy names instead of IDs (IDs are still acceptable though)
A submission is assumed to edit a current node when a nid parameter is found in the Message-Id or in a Command.
If mailalias.module is installed, mailhandler authentication will consider e-mail aliases
MS Outlook uses the STRONG tag to indicate bold. You may want to add that tag to the allowed HTML tags list. Or disable that filter altogether.

To Do (contributions welcome)

many e-mail clients force line breaks before 80 characters. This looks bad on the web. Figure out how to reflow text nicely.
add uid token to failed authentication replies so user may easily resubmit.
allow for sending nested arrays via a command
allow for passing a date via a command (such as passing a 'modified' date)
delete a node via e-mail. delete should include a special op=Delete Command. check for these operations
create a Block with e-mail posting instructions for each mailbox. Display only on blog compose page?

node.module

The core of the Drupal system is the node. All of the contents of the system are placed in nodes, or extensions of nodes.
A base node contains:

A Title: Up to 128 characters of text that titles the node.
A Teaser: A
small block of text that is meant to get you interested in the rest of
node. Drupal will automatically pull a small amount of the body of the
node to make the teaser (To configure how long the teaser will be click here). The teaser can be changed if you don't like what Drupal grabs.
The Body: The main text that comprises your content.
A Type: What kind of node is this? Blog, book, forum, comment, unextended, etc.
An Author: The author's name. It will either be "anonymous" or a valid user. You cannot set it to an arbitrary value.
Authored on: The date the node was written.
Changed: The last time this node was changed.
Sticky at top of lists: In
listings such as the frontpage or a taxonomy overview the teasers of a
selected amount of nodes is displayed. If you want to force a node to
appear on the top of such a listing, you must set it to 'sticky'. This
way it will float to the top of a listing, and it will not be pushed
down by newer content.
Allow user comments: A node can have comments. These comments can be written by other users (Read-write), or only by admins (Read-only).
Revisions: Drupal has a revision system so that you can "roll back" to an older version of a post if the new version is not what you want.
Promote to front page: To
get people to look at the new stuff on your site you can choose to move
it to the front page. The front page is configured to show the teasers
from only a few of the total nodes you have on your site (To configure
how many teasers click here).
In moderation queue: Drupal
has a moderation system. If it is active, a node is in one of three
states: approved and published, approved and unpublished, and awaiting
approval. If you are moderating a node it should be in the moderation
queue.
Votes: If you are moderating a node this
counts how many votes the node has gotten. Once a node gets a certain
number of vote it will either be approved or dropped.
Score: The score of the node is gotten by the votes it is given.
Users: The list of users who have voted on a moderated node.
Published: When
using Drupal's moderation system a node remains unpublished --
unavailable to non-moderators -- until it is marked Published.

Now that you know what is in a node, here are some of the types of nodes available.

Node type: personal blog entry

A blog is a regularly updated journal made up of individual entries,
often called posts, that are time stamped and typically arranged by the
day, with the newest on top (a diary is the reverse). They tend to be
quite personal, often containing links to things you've seen, or to
editorials that you find interesting. Some blogs also contain original
material written solely for the blog. Since a Blog is personal, you and
only you have full control over what you publish. The most interesting
blog entries or those blog entries that fit the site's topic well might
get promoted to the front page by the community or by users with the
access do this.

Node type: book page

Node type: upload file

Node type: forum topic

A forum is a threaded discussion, enabling users to communicate about a particular topic.

Node type: mail

A mail post can be sent to users of selected roles.

Node type: page

Node type: poll

A poll is a multiple-choice question which visitors can vote on.

Node type: story

Node type: webform

Node type: weblink

Weblinks allow you to link to other websites and pages.

How node access works

A little explaination of node access pulled fronm the code comments of the module.

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.

Description

This is an example illustrating how to restrict access to nodes based on some criterion associated with the user.

Database definition:

DELETE FROM node_access; INSERT INTO node_access (nid, gid, realm, grant_view, grant_update, grant_delete) VALUES (0, 1, 'example', 1, 0, 0)

This SQL needs to be run before the module will work properly. The installer system will probably perform this work in the future. The first line removes any existing grants, including (most importantly) the universal grant installed by default that gives read access to every node for everyone. The second line grants read access to every node for users with the "access private content" permission; in the scheme we're defining here, each node will either be private (in which case it can always be read by anyone with that permission) or public (in which case it can be read by everyone).

Description

Implementation of hook_nodeapi().

Most of a node access module's work will be done via this hook. Several values of $op will require responses:

* "form admin", "form pre", and/or "form post": The module will need to provide some mechanism for the access rights of a node to be managed. Some sort of form element on the node editing form is a typical means to accomplish this.
* "delete", "insert", and "update": The module must take care of updating the node_access table appropriately when nodes are modified, probably using the form element mentioned above. Only the realm(s) handled by the module should be affected, so that multiple node access modules can peacefully coexist.
* "validate": Depending on the user interface provided in the node form, the selection may need to be verified and validated here.
* "settings": Modules may wish to provide default grants per node type using this hook.

How to add text to node creation form body

I found that I was using lot's of HTML repetatively in creating a node. So I wanted to add the preformatted HTML the the body textarea if it was empty. To do this you just find the $hook_form function in a module and set in the following PHP code. This makes it easier on the fingers and memory if there is a large template to be used. YOu can even use and included file as a template to make global changes without having to dig through the code again.

<?php
if(trim($node->body) == ''){
          $node->body = '<h3 id="storytype">Desciption</h3><p align="justify"><span class="em-first"></span></p>';
    }
  $output .= form_textarea(t("Body"), "body", $node->body, 50, 15);
?>

page.module

The page module is used when you
want to create content that optionally inserts a link into your
navigation system. You can also, however, create pages that don't have
this link by skipping the link text field in the page form. At this
time, not all themes support the link insertion behavior. Some themes,
like xtemplate, provide alternative mechanisms for link creation. Pages
are also unique in that they shortcut the typical lifecycle of user
generated content (i.e. submit -> moderate -> post ->
comment).

User access permissions for pages

create pages:
Allows a role to create pages. They cannot edit or delete pages, even
if they are the authors. You must enable this permission to in order
for a role to create a page.

edit own pages:
Allows a role to add/edit pages if they own the page. Use this
permission if you want users to be able to edit and maintain their own
pages.

path.module

Background

A very powerful feature of Drupal is the ability to have control
over all paths. The path module is the tool that provides this
functionality and is part of the basic Drupal installation, although it
is not enabled by default. Some examples of re-mapping paths are:

user/login => login

image/tid/16 => store

taxonomy/term/7+19+20+21 => store/products/whirlygigs

node/3 => contact

This functionality integrates seamlessly into node forms and also
provides the administrator an interface to view all aliases that have
been created.

Aliases have a many to one relationship with their original Drupal
URLs. In other words you can have many different aliases map to a
single path. An example of where a multiple aliases come in handy is
creating a standard RSS feed URL:

node/feed => rss.xml
node/feed => index.rdf

When Drupal generates links for a path with multiple aliases it will
choose the first alias created per system URL. So in our above example,
Drupal would use rss.xml as the default alias rather than index.rdf. To
change this behavior, delete the aliases for node/feed and create the
index.rdf alias before rss.xml.

Permissions

Two permissions are related to URL aliasing: create url aliases and administer url aliases.

create url aliases - Allows users to create
aliases for nodes. Enabling this permission will display a path field
to the user in any node form, allowing them to enter an alias for that
node. They will be able to edit/delete the alias after it is created
using the same form.
administer url aliases -
Allows users to access the alias administration interface. This
interface displays all aliases and provides a way to create and modify
them. This is also the location to build aliases for things other than
nodes. For example, you can create an alias for a taxonomy URL or even
re-map the admin path (although the original admin path will still be
accessible since aliases do not cancel out original paths).

Mass URL aliasing

Drupal also comes with user defined mass URL aliasing capabilities.
You might like to see completely different URLs used by Drupal, or even
URLs translated to the visitors' native language, in which case this
feature is handy. Only an administrator with access to the website
source code can set up this kind of aliases. You can define a


conf_url_rewrite

function conf_url_rewrite($path, $mode = 'incoming') {
  if ($mode == 'incoming') { // URL coming from a client
    return preg_replace('!^display/(d+)$!', 'node/1', $path);
  }
  else { // URL going out to a client
    $aliased = preg_replace('!^node/(d+)$!', 'display/1', $path);
    if ($aliased != $path) { return $aliased; }
  }
}

This function will shorten every


node/$node_id


display/$node_id


display/3


conf_url_rewrite

You cannot only use this feature to shorten the URLs, or to
translate them to you own language, but also to add completely new
subURLs to an already existing module's URL space, or to compose a
bunch of existing stuff together to a common URL space. You can create
a


news


news/15


news/sections/3


node/15


taxonomy/term/3

pathauto.module

Path aliasing is more search engine friendly than the typical querystring that is used to produce dynamic content. But search engine friend URLs are sometimes hard to create. The pathauto.module takes the title of the created content and uses it to make a path alias automatically.

This module allows you to write the paths as you want them, using the placeholders listed below:

[title]: The title of the page, with spaces and punctuation replaced by the chosen separator
[nid]: The id number of the node.
[user]: The name of the user who created the node.
[vocab]: The vocabulary that the page's first category belongs to.
[cat]: The first category that the page belongs to.
[catpath]: As category, but including its supercategories.
[type]: The node type (e.g., "page", "story", etc.).
[book]: For book pages, the title of the top-level book.
[yyyy]: The year the node was created.
[mm]: The two-digit month (01-12) the node was created.
[mon]: The three-letter month (jan-dec) the node was created.
[dd]: The two-digit day of the month (00-31) that the node was created.
[day]: The three-letter day of the week (sun-sat) that the node was created.
[hour]: The two-digit hour (00-23) the node was created.
[min]: The two-digit minute (00-59) the node was created.
[sec]: The two-digit second (00-59) the node was created.
[week]: The week number (1-52) of the year the node was created.

Examples:

The
following examples of aliases generated from various patterns are all
based on a node titled "This is a (sample) node", created on February
6, 2005, with a category of Sports, which is a subcategory of News, in
the vocabulary Topics.

Separator=_, Pattern=[title]: this_is_a_sample_node

phptemplate.engine

As of version 4.6 the phptemplate engine has been move to the drupal core. this is probably the single most important improvement to Drupal since it's invention. I personally do not like templating engines like Smarty that use PHP to create another language that has to be learned. The users of PHP content management systems should learn PHP and beableto get what they want from the framwork. Learning Smarty or the tens of other templating languages is only confusing and in the long run not profitable.

Multiple page templates

Here's how to get a different page template per url is important . This comes in use when you do not want to have the sidebars and other page eliments appear in admin sections or forums.

<?php

function _phptemplate_variables($hook, $vars = array()) {
  switch ($hook) {
    case 'page':
      if ($vars['is_front']) {
        $vars['template_file'] = 'page-index';
      }
      else {
        $uri_request_id = $_SERVER['REQUEST_URI'];
        $section = explode("/", $uri_request_id);
        switch ($section[1]) {
          case 'admin': $vars['template_file'] = 'page-admin'; break;
          case 'group': $vars['template_file'] = 'page-group'; break;
          case 'question': $vars['template_file'] = 'page-vocab'; break;
          case 'add': $vars['template_file'] = 'page-addnode'; break;
          default: $vars['template_file'] = 'page-default';
        }
      }
    break;
  }
  return $vars;
}
?>

or in your page.tpl.php you can use

<?php

if ($is_front) {
    include 'page-index.tpl.php';
    return;
}
$uri_request_id = $_SERVER['REQUEST_URI'];
$section = explode("/", $uri_request_id);
switch ($section[1]) {
    case 'admin': include 'page-admin.tpl.php'; break;
    case 'group': include 'page-group.tpl.php'; break;
    case 'question': include 'page-vocab.tpl.php'; break;
    case 'add': include 'page-addnode.tpl.php'; break;
    default: include 'page-default.tpl.php';
}

?>

page template by node type

make a copy of your page.tpl.php file and rename it to be page-default.tpl.php.
make further copies your page.tpl.php file it and rename them to be page-front.tpl.php, page-blog.tpl.php and page-book.tpl.php etcetera..
using a text editor like notepad.exe or equivalent, modify the layout of each tpl.php file to suit your desires
upload your new page-type.tpl.php layout files to your active theme folder
Using a text editor like notepad.exe or equivalent, replace the contents of your page.tpl.php file with the snippet below
Ensure that you have a page-default.tpl.php file as part of your collection of layouts.
Upload your new page.tpl.php file to your active theme folder and your new layouts will take effect automatically

<?php

/**
* This snippet loads up different page-type.tpl.php layout
* files automatically. For use in a page.tpl.php file.
*
* This works with Drupal 4.5, Drupal 4.6 and Drupal 4.7
*/
if ($is_front) {/* check if it's the front page */
    include 'page-front.tpl.php'; /*load a custom front-page.tpl.php */
    return; }
if ($node-&gt;type == 'book') {/* check if it's a book page */
    include 'page-book.tpl.php'; /*load a page-book.tpl.php */
    return; }
if ($node-&gt;type == 'blog') {/* check if it's a blog node */
    include 'page-blog.tpl.php'; /*load page-blog.tpl.php */
    return; }
if ($node-&gt;type == 'image') {/* check if it's an image node */
    include 'page-image.tpl.php'; /*load page-image.tpl.php */
    return; }
if ($node-&gt;type == 'forum') {/* check if it's a forum node */
    include 'page-forum.tpl.php'; /*load page-forum.tpl.php */
    return; }
include 'page-default.tpl.php'; /*if none of the above applies, load the page-default.tpl.php */
    return;
?>

ping.module

Drupal can pings sites automatically to notify them that your site has changed. It can ping the following sites:

Weblogs.com,
a web site that tracks and displays links to changed weblogs and
news-oriented web sites. To get your Drupal site listed, weblogs.com
must be informed about your site's updates. This is the job of the ping
module and when installed, the administrator doesn't have to do
anything to participate in the Weblogs.com system. The ping module automatically notifies weblogs.com when your site is updated. To do so, Drupal implements the XML-RPC interface of weblogs.com.

Weblogs.Com for RSS, a web site that tracks and displays links to recently changed RSS feeds in XML format. To get your Drupal site listed, Weblogs.Com for RSS
must be informed about updates to your RSS feed. This is the job of the
ping module and when installed, the administrator doesn't have to do
anything to participate in the the weblogs.com for RSS system. The ping module automatically notifies Weblogs.Com for RSS when your site is updated.

blo.gs, a directory of recently updated weblogs and tools for tracking interesting weblogs, in the spirit of services like Weblogs.com, blogtracker and blogrolling.com. To get your Drupal site listed, blo.gs

must be informed about your site's updates. This is the job of the ping
module and when installed, the administrator doesn't have to do
anything to participate in the blo.gs system. The ping module automatically notifies blo.gs when your site is updated. To do so, Drupal implements the XML-RPC interface of blo.gs.

The ping feature requires crontab.

poll.module

Users with the correct permissions can create and/or vote on polls.

To create a poll a user needs the "create polls" permission.
To vote on a poll question a user must have the "vote on polls" permission.
To view the results one needs the "access content" permission.
To administer polls you need the "administer nodes" permission.

Creating
a poll is much like creating any other node. Click "create poll" in
your user box. The title of the poll should be the question, then enter
the answers and the "base" vote counts. You can also choose the time
period over which the vote will run.

The Poll
item in the navigation links will take you to a page where you can see
all the current polls, vote on them (if you haven't already) and view
the results.

project.module

Requirements

The project.module requires that it have its own seperate vocabulary set up. The project.module should not share the vocabulary of any other module, for example the forum.module.

You should have the following on your web host and Drupal installation:

mysql database
php version 4.2>5
activated taxonomy.module
a filesystem upload module (filestore2, download,upload)

Installation

set module into module folder
run the database script
Create a starting taxonomy and make sure to check the "required" checkbox to make sure no projects can be created without using the proper taxonomy.


Projects
 -term 1 (new project)
 -term 2 (new project)

Configuration

Administration User Instructions:

When creating a new project it is important to do things in a certain order. Here we will show the steps necessary to create a new project starting from the creation of a proper vocabulary (category)

add project container vocabulary in administer categories interface
add project container terms in administer categories interface
add project to terms container in project interface
add project releases to a project in project interface. Project will not appear until a release has been made. If you want to have them appear without release then try the Plus Project module

Additional modules:

The project.module will controll the linking to the released software but need a companion module to handle the uploading and filesystem organization. It is recommended that the download.module be used since it does not have any limitations on file size as it uses FTP for upload. the filestore2.module or upload.module can be used but they do have limitations set by HTTP upload usage.

download.module
filestore2.module

Site User Instructions:

Site users may have any range of previleges when using the project module. Here we will give instructions on how to use the user interface that appears with the modules activation.

Issues:

Issues are the head subject of a thread concerning the software. When an issue is reported it can be commented on just like a forum topic. Issues may also have attachments like images and patch files.

Comments:

Comments are a threaded discusion that takes place after an issue has be reported. Comments can contain attachments.

Attachments:

The uploading of files when creating a comment or an issue is made possible through any number of upload modules that the sites administrator make available.

search.module

Search guidelines

The
search page allows you to search the web site's content. You can
specify multiple words, and they will all be searched for. You can also
use wildcards, so 'walk*' will match 'walk', 'walking', 'walker',
'walkable' and so on. Furthermore, searches are not case sensitive so
searching for 'walk', 'Walk' or 'WALK' will yield exactly the same
results.

Words excluded from the search

Words
that frequently occur, typically called 'noise words', are ignored.
Example words are 'a', 'at', 'and', 'are', 'as', 'how', 'where', etc.
Words shorter than 2 letters are also ignored.

statistics.module

Introduction

The
statistics module keeps track of numerous statistics for your site but
be warned, statistical collection does cause a little overhead, thus
everything comes disabled by default.

The
module counts how many times, and from where -- using HTTP referrer --
each of your posts is viewed. Once we have that count the module can do
the following with it:

The count can be displayed in the node's link section next to "# comments".
A
configurable block can be added which can display a configurable number
of the day's top stories, the all time top stories, and the last
stories read.
A configurable user page can be added,
which can display the day's top stories, the all time top stories, and
the last stories read. You can individually configure how many posts
are displayed in each section.

Notes on using the statistics:

If
you enable the view counters for content, this adds 1 database query
for each node that is viewed (2 queries if it's the first time the node
has ever been viewed).
If you enable the access log,
this adds 1 database query for each page that Drupal displays. Logged
information includes: HTTP referrer (if any), node being accessed (if
any), user ID (if any), the IP address of the user, and the time the
page was viewed.

As with any new module, the statistics module needs to be enabled before you can use it. Also refer to the permissions section, as this module supports four separate permissions.

referrers log

This admin page shows you site-wide referrer statistics. You can see 'all' statistics, 'external' statistics or 'internal' statistics. Default is 'all'.

access log

This
admin page gives you an at-a-glance look at your most popular content.
It is useful for understanding what content on your Drupal site is the
most popular. Also on this page are links to the referrer statistics
for each listed node.

Configuring the statistics module

There are some configuration options added to the main administer » settings » statistics section:

enable access log
-- allows you to turn the access log on and off. This log is used to
store data about every page accessed, such as the remote host's IP
address, where they came from (referrer), what node they've viewed, and
their user name. Enabling the log adds one database call per page
displayed by Drupal.
discard access logs older than
-- allows you to configure how long an access log entry is saved, after
which time it is deleted from the database table. To use this you need
to run "cron.php"
enable node view counter --
allows you to turn on and off the node-counting functionality of this
module. If it is turned on, an extra database query is added for each
node displayed, which increments a counter.
display node view counters
-- allows you to globally disable the displaying of node view counters.
Additionally, a user group must have 'access statistics' permissions to
view the counters.

Permissions

This module has four permissions that need to be configured in the permissions section.

access statistics - enable for user roles that get to see view counts for individual content. (This does not define access to the block)
administer statistics module - enable for user roles that get to configure the statistics module.
administer statistics - enable for user roles that get to view the referrer statistics.

If 'administer statistics' and 'access statistics' are both enabled, the user will see a link from each node to that node's referrer statistics (if enabled).

story.module

The story module lets your users
submit articles for consideration by the rest of the community, who can
vote on them if moderation is enabled. Stories usually follow a
publishing flow of submit -> moderate -> post to the main page -> comments. Administrators are able to shortcut this flow as desired.

administer » settings » story

you can set up an introductory text for story authors, and a floor on
the number of words which may be included in a story. This is designed
to help discourage the submission of trivially short stories.

User access permissions for stories

create stories:
Allows a role to create stories. They cannot edit or delete stories,
even if they are the authors. You must enable this permission to in
order for a role to create a story.

edit own stories:
Allows a role to add/edit stories if they own the story. Use this
permission if you want users to be able to edit and maintain their own
stories.

system.module

Drupal comes with system-wide
defaults but the setting-module provides control over many Drupal
preferences, behaviours including visual and operational settings.

Cron

Some
modules require regularly scheduled actions, such as cleaning up
logfiles. Cron, which stands for chronograph, is a periodic command
scheduler executing commands at intervals specified in seconds. It can
be used to control the execution of daily, weekly and monthly jobs (or
anything with a period measured in seconds). Automating tasks is one of
the best ways to keep a system running smoothly, and if most of your
administration does not require your direct involvement, cron is an
ideal solution.

Whenever http://www.hivemindz.com/hm/cron.php

is accessed, cron will run: it calls the _cron hook in each module
allowing the module to run tasks if they have not been executed in the
last n seconds, where n is the period of that task. When all the tasks are finished, cron is done.

The
recommended way to set up your cron system is to set up a Unix/Linux
crontab entry (see "man crontab") that frequently visits http://www.hivemindz.com/hm/cron.php.
Note that cron does not guarantee the commands will be executed at the
specified interval. However, Drupal will try its best to run the tasks
as close to the specified intervals as possible. The more you visit
cron.php, the more accurate cron will be.

If your hosting
company does not allow you to set up crontab entries, you can always
ask someone else to set up an entry for you. After all, virtually any
Unix/Linux machine with access to the internet can set up a crontab
entry to frequently visit http://www.hivemindz.com/hm/cron.php.

For the Unix/Linux crontab itself, use a browser like lynx or wget but make sure the process terminates: either use


/usr/bin/lynx -source http://www.hivemindz.com/hm/cron.php

/usr/bin/wget -o /dev/null -O /dev/null <a href="http://www.hivemindz.com/hm/cron.php">http://www.hivemindz.com/hm/cron.php</a>


scripts

     00 * * * * /home/www/drupal/scripts/cron-lynx.sh

Note that it is essential to access


cron.php


localhost


127.0.0.1

Cache

Drupal
has a caching mechanism which stores dynamically generated web pages in
a database. By caching a web page, Drupal does not have to create the
page each time someone wants to view it, instead it takes only one SQL
query to display it, reducing response time and the server's load. Only
pages requested by "anonymous" users are cached. In order to reduce
server load and save bandwidth, Drupal stores and sends cached pages
compressed.

taxonomy.module

Background

Taxonomy
is the study of classification. Drupal's taxonomy module allows you to
define vocabularies which are used to classify content. The module
supports hierarchical classification and association between terms,
allowing for truly flexible information retrieval and classification.
For more details about classification types and insight into the development of the taxonomy module, see this article.

An example taxonomy: food

Dairy
- Milk
Drink
- Alcohol
  - Beer
  - Wine
- Pop
- Milk
Meat
- Beef
- Chicken
- Lamb
Spices
- Sugar

Notes

The term Milk appears within both Dairy and Drink. This is an example of multiple parents for a term.
In Drupal the order of siblings (e.g. Beef, Chicken, Lamb) in a vocabulary may be controlled with the weight parameter.

Vocabularies

When
you create a controlled vocabulary you are creating a set of terms to
use for describing content (known as descriptors in indexing lingo).
Drupal allows you to describe each piece of content (blog, story, etc.)
using one or many of these terms. For simple implementations, you might
create a set of categories without subcategories, similar to Slashdot's sections. For more complex implementations, you might create a hierarchical list of categories such as Food taxonomy shown above.

Setting up a vocabulary

When setting up a controlled vocabulary, if you select the hierarchy option, you will be defining a tree structure of terms, as in a thesaurus. If you select the related terms option, you are allowing the definition of related terms (think see also), as in a thesaurus. Selecting multiple select

will allow you to describe a piece of content using more than one term.
That content will then appear on each term's page, increasing the
chance that a user will find it.

When setting up a controlled vocabulary you are asked for:

Vocabulary name: The name for this vocabulary. Example: Dairy.
Description: Description of the vocabulary. This can be used by modules and feeds.
Types:
The list of content types you want to associate this vocabulary with.
Some available types are blog, book, forum, page, and story.
Related terms: Allows relationships between terms within this vocabulary. Think of these as see also references.
Hierarchy: Allows a tree-like vocabulary, as in our Foods example above.
Multiple select: Allows pieces of content to be described using more than one term. Content may then appear on multiple taxonomy pages.
Required: If selected, each piece of content must have a term in this vocabulary associated with it.
Weight: The overall weight for this vocabulary in listings with multiple vocabularies.

Adding terms to a vocabulary

Once
done defining the vocabulary, you have to add terms to it to make it
useful. The options you see when adding a term to a vocabulary will
depend on what you selected for related terms, hierarchy and multiple select. These options are:

Term name: The name for this term. Example: Milk.
Description: Description of the term that may be used by modules and feeds. This is synonymous with a "scope note".
Parent:
Select the term under which this term is a subset -- the branch of the
hierarchy that this term belongs under. This is also known as the
"Broader term" indicator used in thesauri.
Synonyms:
Enter synonyms for this term, one synonym per line. Synonyms can be
used for variant spellings, acronyms, and other terms that have the
same meaning as the added term, but which are not explicitly listed in
this vocabulary (i.e. unauthorized terms).
Weight: The weight is used to sort the terms of this vocabulary.

Displaying content organized by terms

In
order to view the content associated with a term or a collection of
terms, you should browse to a properly formed Taxonomy URL. For
example, taxonomy/term/1+2. Taxonomy
URLs always contain one or more term IDs at the end of the URL. You may
learn the term ID for a given term by hovering over that term in the taxonomy overview
page and noting the number at the end or the URL. To build a Taxonomy
URL start with "taxonomy/term/". Then list the term IDs, separated by
"+" to choose content tagged with any of the given term IDs, or separated by "," to choose content tagged with