Site users

How to begin editing a feed

On the feeds page, you can edit a feed:

1. After clicking "New configuration" and entering a name and description of a new feed
2. for a default enabled feed, clicking the "Override" link
3. that you have created, by clicking the "Edit link".

Feed edit page overview

The Feed edit page offers four configuration options:

1. Basic settings (name, where to attach feed, refresh time)
2. Fetcher (whether to retrieve feed from a file, or web address)
3. Parser (specify the feed format, eg. XML, CSV, OPML)
4. Processor (whether to process the data as nodes, taxonomy terms, etc)
   • Processor settings and mapping

These options are described more fully, below.

Feed edit page details

Basic settings

• Name: The name of default feed, or the feed you created
• Description: What the feed does
• Attach to content type:
  • Use standalone form
  • Feed item
  • An existing node content type
• Minimum refresh period:
• Import on create

Fetcher

The Fetcher is where your feed is fetched from.

Block Content Per Role (sometimes referred to as Block CPR) provides configurable blocks, each with content to display for enabled & weighted roles.

Out of the box, Drupal allows blocks to be restricted to be visibible only to users with specific roles. There are some cases where a user may have more than 1 role (in fact, any user logged into a site already has 1 role, authenticated). If you were to add a set of blocks to a region and set each block to display for specific roles (for example, Anonymous, Authenticated & Subscriber) you would quickly run into problems as somebody logged in as a subscriber will also have an authenticated role.

Block CPR gets around this problem by letting the administrator "weight" the role's content. The first matching role from the visiting user will have it's content shown.

Next to security, Performance is arguably the least understood characteristic of web applications. One old colleague put it best when he talked about there being really only two states: satisfactory and not-satisfactory ... there is really no middle ground there, things are either fast enough or they are not. Unfortunately, it is also nearly impossible to know ahead of time exactly what "fast enough" is ... with "Google-speed" setting the bar for public web sites and CMS systems using authenticated almost exclusively, there is a serious performance problem waiting in the wings at all time. This was true for Livelink and no less true for Drupal.

In case the terminology is not clear, chatrooms are intended to be containers for chats.

If you know that you will have a series of related chats, then create a chatroom for them, and create the chats from the chatroom interface.

If a chat is one off or adhoc, then you can simply create a chat node without needing to relate it to any chatroom.

For developers, chatrooms and chats are distinct node types, and should be treated as such.

The "Manage this chat" fieldset contains an "Invite a user to this chat" widget. Use this to invite users to a chat.

An invited user will see a message on the next page they view, letting them know which chat they have been invited to by whom.

Modules can act on invites, so invites could lead to anything that can be coded in a Drupal module.

Chats can be made private, such that only users explicitly invited to a chat will be able to participate.

When a chat is created, check the "make chat private" checkbox.

Once the chat is loaded, use the "Add a user to this chat:" widget in the "Manage this chat" field set to add users.

You can also make the chat public from the "Manage this chat" area.

If the chat is not already public, there is a "Make chat public" button in the "Manage this chat" area.