Add special "tag" to define where the footnotes should be placed

Thanks acp, this was a great idea! Inadvertedly, you've also solved how to implement this other feature request too.

I've now tried to implemented your idea fully in the next version of Footnotes which I intend to commit today:
- supports both html and textile versions
- by default, add footnotes at the end (as before)
- if <footnotes> or <footnotes /> tag is present, the footer is put in its place instead of at the end
- same for Textile, use footnotes. tag.
- possible to use more than one <footnotes> tag. Not that I know why that would be useful, but it didn't seem necessary to limit it to 1 either.

Ahh, at least in the HTML version you cannot have more than one list of footnotes, because the footnotes have id-attributes which must be unique. So I put back the limit of only replacing one footnote tag.

Actually there's two ways I can see to fix the id problem.

One, just serialize them. e.g.

$counter = 0; // appears early
$output .= 'id="footnotes-' . $counter . '"'; // appears each time you want a serialized id
$output .= 'id="footnotes-' . $counter++ . '"'; // except for the last time you use the same serial, then it's this one

Assuming php uses the ++ operator in the same way as C, which I certainly hope it does, the above should work nicely. You could also separately do a $counter++ someplace and always use the first example, just to improve readability.

Alternatively, you could move from a tag to a more drupal-esque [footnotes] but you could also accept [footnotes=style] and that style could be added to the end of the id much the same way as the counter variable is in my example above. I mean sure you could do this without using a bracketed tag but I think that makes a lot more sense. (Arguably though this is a stylistic decision and you can and will do it however you like.)

Of course, you could also always just specify a class instead of an id, which probably makes more sense :)

Yeah, but the id's are used as targets for the links in the text and you can only link to one place anyway.

I guess the design for this feature should be ok. But this was quite a big change, so I'm interested to hear from anyone who has tested it before I put this issue as closed. The new version seems to be available for download now.

happy to see that it's going to be implemented,

As I said, this feature is available now.

I can now upgrade my module without having any modifications to make ;). Just one little thing though, this also solved another problem I had, the appearance of footers in my trimmed content (frontpage for instance). Since almost 99% of the time, the teaser didn't include my "footnotes. " I didn't get the footnotes which was what I wanted (and I think that's the way it should be, footnotes on frontpage shouldn't be showed imho).

Yes. I realised you had used your solution like this, but my implementation is different: footnotes will appear in the teaser too. But not all footnotes, only if there actually is a footnote in the text excerpted for the teaser part.

This is not only for backwards compatibility, it was a conscious decision that I think it should be like this.

You said that if there wasn't any "footnotes. " (or the html one anyway), you have a default fallback. While I understand the necessity of it, for all the people upgrading, I think it would be nice to be able to disable this behaviour, and maybe provide an upgrade script that just adds a "footnotes. " at the end of all articles/pages/etc.

Nonono... You should realise by just reading your own explanation, that your solution is not the "clean" one :-) The simple design is that people can use this without even knowing about the <footnotes /> and it should be like that.

But, have you heard about the Excerpt module: http://drupal.org/project/excerpt It is exactly for your needs.

And another feature that could be interesting would be the possibility to set configure the filter so as to add some code before/after the footnotes block. So for instance, before footnotes add "h2. Footnotes" or something like that...

But now you can do this. This was the major innovation of your suggestion:

h2. Footnotes:
footnotes.

or in html

<h2>Footnotes:</h2>
<footnotes />

Of course, the text is not generated automatically so you have to do it manually for every node, but it is possible. (The correct way to do it automatically would be with CSS, but as I understand it there does not exist a browser that supports that feature.)

Of course, one could have a generic module that substitutes any tag to any text. But that has nothing to do with Footnotes. I don't think such a module exists.

I realised you still had one unanswered question although this was already closed. I'll try to explain my ideas of this architecture...

What happens if there is no foonotes ? The "h2. Footnotes" will still be printed which is incorrect. The "feature" described above solves that.

Suppose we had another module, providing a filter that can substitute any text to some other text.

You could now run footnotes first, then this other filter. The filter could look for <div class="footnotes"> and replace that with a string like <h2>Notes:</h2><div class="footnotes">

This would now work so that "Notes:" heading is only inserted where there actually are some footnotes.

So argument 1 is that the principle of modularity says that Footnotes shouldn't provide this feature, because it is a generic feature.

**

From a usability standpoint I agree that Footnotes could provide it as a convenience, because obviously the above is a bit geeky (grepping html code and substituting with new html code). I am however somehow instinctively against generating any new text from Footnotes. One concrete thing I'm afraid of is all the multilingual issues we would run up against, this could easily become very complicated.

So argument 2 is just the KISS principle, trying to just do the simple things here.

**

I am open to discussion on some kind of "conditional operator tag", whose contents would only be shown when there are footnotes. So to do what you want to do you would:

<footnotes-exist attr="yes">
<h2>Notes:</h2>
</footnotes-exist>
<footnotes />

But I would still like to argue that this is becoming quite complicated, I would think about it for a long time before implementing it.

This discussion seems to have faded out and is quite old now, so I'm closing this.

In summary:

1) This issue resulted in implementation of the <footnotes /> tag.

2) Footnotes still appear in teasers. To avoid this, use Excerpt module.

3) Undecided how to perfectly implement the request to be able to have a header (say "Notes:") above the footnotes. I'm open for suggestions, start a new issue for that.