Is there any documentation for the new API defined in file.inc? I'm trying to rewrite the filestore module to store uploads as files instead of using the database. Or is someone already working on that?

Is the taxonomy_access patch intended to work with 4.3.2 or CVS? The patch won't apply cleanly to 4.3.2, and I'm not sure I understand it well enough to hack it into submission.

Since many users still eschew registration requirements, I hacked the forum.module a bit to allow anyone (anonymous or registered) to use a "display name". This avoids having a lot of posts from "anonymous".

Hi all,
for my Portal I absolutely need a way to filter data on terms and node types.
I have several node types (7, at the moment, which are extensions of the standard story module), and some of them share the same vocabulary.
As an example, I created a 'Geography' vocabulary, which represents a tree with all the Italian regions and Italian major cities.
In my portal, which will deal with choral music, this vocabulary is linked to events, choirs and resources.
Another vocabulary (genre) is linked to choirs, events, weblinks.

This takes me to the point where I need to extend taxonomy in order to be able to do this:

?q=taxonomy/page/or/143,145/choir,events

to filter out or to feed only choirs and events dealing with terms 143 and 145 (which are 'pop' and 'jazz' music type)

For this reason I hacked taxonomy module and taxonomy_html module in order to add this functionality.

After the list of terms, you can specify a list of comma separated node types, and it works fine. It works also with feed.

Before going on with the tests, I would like to know if someone else is working on the same functionality, in order to avoid duplicate work.

Furthermore, I would like to use a 'standard' Drupal, so I would not like to have an 'hacked' functionality on a 'core' module like this.

Since I think this feature could extend tremendously Drupal possibilities (I'm really in love with Drupal...), I would like your opinion on this matter.

THE TERM METATAG

Let's stop using the term metatag. I think that there are several directions that we can go to make Drupal's node attributes make more sense. But first, we need to really understand what we're talking about when we say metatag.

A metatag is ONE single descriptive point in a document's larger description within a metadata framework like the Dublin Core (see link below). Metadata as it is commonly used today (e.g. in the Dublin Core Metadata Element Set) separates information about data into: 1) document descriptions (empirical data such as author, title, publisher, date of publication) and 2) knowledge descriptions (usually subject content and description/abstract). What Drupal attributes do is allow for the latter -- classification of nodes by subject. With this concept in mind there are a few directions we might go.

For more info on metadata elements see the Dublic Core Metadata Element Set

SUBJECT CLASSIFICATION

You can think in terms of what Libraries have historically done to get a sense of what is possible. A library catalog is a database holding bibliographic data (metadata) to help you find items in a large collection of data. You can do known item searching by looking for an author name, title, etc -- the document description stuff. But a lot of people want to find similar items, so maybe they find out what an item is about (subject) and browse for other books with the same subject. This is how most people want to use Drupal's attributes, I assume, and they may also want some sense of relationship (perhaps hierarchical, perhaps not) between each subject.