VotingAPI: A framework for voting and rating modules

VotingAPI is a flexible, easy-to-use framework for rating, voting, moderation, and consensus-gathering modules in Drupal. It allows module developers to focus on their ideas (say, providing a 'rate this thread' widget at the bottom of each forum post) without worrying about the grunt work of storing votes, preventing ballot-stuffing, calculating the results, and so on.

VotingAPI does four key jobs for module developers:

  1. CRUD: Create/Retrieve/Update/Delete operations for voting data. The simplest modules only need to call two functions -- votingapi_set_votes() and votingapi_select_results() -- to use the API. Others can use finer-grain functions for complete control.
  2. Calculation: Every time a user casts a vote, VotingAPI calculates the results and caches them for you. You can use the default calculations (like average, total, etc) or implement your own custom tallying functions.
  3. Workflow: By integrating with Actions.module, VotingAPI can trigger workflow steps (like promoting a node to the front page, hiding a comment that's been flagged as spam, or emailing an administrator) when votes are cast and results are tallied. Modules can expose their own 'default' action sets and filter criteria to provide moderation and promotion systems.

Remove unwanted tabs from pages

Both Drupal core as well as various modules add tabs to pages that are not needed for general users, or not needed at all. You may wish to link to the page in a different way, as some users don't understand that they can click on the tab above a node.

Method for Drupal 4.7.x and Drupal 5

In versions of Drupal prior to 6, there was not a way to alter the hook_menu() generated tabs from code, so the function illustrated on this page will find and strip out a tab based on its name. As of Drupal 6, there is now the hook_menu_alter() function, which allows you to alter various properties of menu items that are set by core or other modules. If you are using Drupal 6, you should consider using hook_menu_alter instead, which is more exact, and is simpler/more efficient. One thing that hook_menu_alter cannot do that this page's method can is remove the "View" tab (if you have reason to remove the View tab, you can do so with this technique, and use hook_menu_alter for the rest of your tab removals).

Step 1 of 2

Locate your theme's template.php file. If one doesn't exist, create an empty one. This is where you can place customization PHP code.

Step 2 of 2

Showing the child items of primary links / Turning primary links into "primary menu"

Edit your page.tpl.php

Edit the section where the primary_links are printed to show the whole primary links menu instead of only showing the first level links of your primary links menu.

Migrating from Xoops

Here are some queries that I used in a recent migration from Xoops 2.0.13 to Drupal 4.7.0. This was my first real life experience using SQL so be warned. You might consider adapting the Xoops Migration Module for use with 4.7 instead.

Make database backups at every stage using mysqldump or phpmyadmin.

mysqlump --opt -u user -p database > backup.sql

You will need to have your xoops and Drupal tables in the same database for these to work. The whole transfer took me about 10 hours but I was learning as I went. This is not a complete migration solution but hopefully these will save you some time.

In each case change the drupal_users and xoops_users to reflect your table prefixes.

Users

Change the '-28800' to reflect the timezone of your users.

INSERT INTO drupal_users (uid, name, pass, mail, signature, 
  status, init, created, timezone, access, timezone_name, language) 
SELECT uid, uname, pass, email, user_sig,
  '1', email,  user_regdate, '-28800', last_login, 'America/Argentina/Buenos_Aires', 'en'
FROM xoops_users WHERE uid > 1;

If you want to transfer Occupation and User From then you'll need to setup fields in the profile.module and transfer these separately. Drupal supports user avatars but I didn't transfer these.

Stories from News 1.4

Working with content types and fields (Drupal 6 and earlier)

The Content Construction Kit allows you to add custom fields to custom content types using a web interface. In Drupal 5.x, custom content types can be created in Drupal core, and the Content Construction Kit allows you to add custom fields to any content type. In Drupal 7 and later, most of the functionality of CCK has been absorbed into Drupal core. For more information on fields in core, see Working with Fields (Drupal 7 and later)

LDAP: Integration with enterprise authentication systems

This LDAP integration module allows users to authenticate against a configurable Lightweight Directory Access Protocol directory. This is useful for organizations which have an existing organizational directory with usernames and passwords, and want Drupal to be able to authenticate against it.

Users can read and modify their LDAP entries, and the administrator is able to limit configuration.

LDAP Integration Module (starting with 6.x-1.0-beta3) in reality, is a set of five modules:

Authentication (ldapauth.module)
Required module. It implements basic LDAP integration and sets up the environment for the other optional modules.
Groups (ldapgroups.module)
Optional. Extends the basic functionality and integrates LDAP Groups into Drupal Roles.
Data (ldapdata.module)
Optional. Extends the basic functionality and allows for the management of LDAP Attributes from within Drupal.
Requires the profile or content profile modules to be installed.
Sync (ldapsync.module)

Pages

Subscribe with RSS Subscribe to RSS - Drupal 6.x