Output footnotes at the end of the node, not the end of the field they are for

This is by design.
There is little we can do without writing another module altogether: we depend on Drupal's core API and it only allows us to modify the text within one field.
CCK is accepting different input formats for each field. Some might have the footnote filter, some other not.
There is no way for us to know where to put the footnote.

If you can offer an elegant solution, and a patch, I'll review it.

You mean that if you put the footnote tag in one field, you get the actual footnote at the bottom of another field?
Can you precise?

Either I don't understand what you mean,
or I understood properly in the first place, in which case it is as I said: by design.

To be honest, I don't have much time this week. I'll do my best to investigate after next week, but I think I perfectly understood what you meant, and I have already replied a few times.

The footnote can only be placed within the same textarea as the one containing the footnote tag. We cannot place the footnote at the end of another CCK field. I keep trying to explain that you cannot place the <footnote /> tag in another field than the one containing the actual footnotes. The <footnote /> tag will only work within the same CCK field or textarea. The <footnote /> tag in textarea#3 will only take into account the footnotes present in your third CCK textarea field. This is by design and we are limited by how the core Drupal API work. CCK is not part of core. Maybe you should ask the CCK developers to provide an API that we could use, that would do what you request.

If you provide a patch, I will consider it. See my comment #8 here: http://drupal.org/node/101126#comment-185909 .

Hi rbl and others

I'd like to point out that when Beginner says "this is by design" it's more like this is a consequence of Drupal's and CCK's design, not that anyone did this on purpose when developing Footnotes :-)

So, as Beginner is trying to explain, Footnotes is a filter module, and when you use CCK, filters are run independently on each field (part) of your CCK page. Footnotes has no way of knowing that what text it is seeing is actually a small part of some bigger context. So the footnote is put at the end of the portion of text (one cck field) that was fed to the Footnote filter.

I have not used CCK myself together with Footnotes, so never ran into this problem. But since most filters seem to just substitute some string/code to some other string - a very local operation - Footnotes may well be the first to have this kind of problem: We would need to somehow know all of the page, where it starts and ends and which fields belong to it.

I do agree with rbl that this is a problem, for instance one could easily create a CCK page with a lot of footnotes all numbered "1". But as it is now, it is not trivial to fix from within Footnotes only.

So I will put the status of this bug back to active, but please everyone understand that neither me nor Beginner nor anyone else have currently committed to fix these kinds of issues.

As part of my annual bug squashing efforts, I think I may have found the solution to this. (After all these years :-)

Revisit the problem: The problem here is that footnotes is implemented as a filter (and I think this is still the right way to do it). A Drupal filter just operates on a piece of text, there is no concept of node, in fact you cannot know which node (if any, could be a comment, etc...) you are working on. A CCK node is a collection of many text fields, each filtered separately, but presented to the user as one page.

The solution: I'm proposing (for myself to implement) a new concept of a footnote collection[footnote collection="unique_id" /]. This new tag would have 2 attributes:

collection = is a unique identifier across the drupal site for this collection of footnotes. The node number of your CCK node is a good example. (Ie. this lets the user manually enter the node number visible in the URL, since we don't get it form the filter API.)

mode = "store" or "flush". A footnote tag with mode=store, would not output the list of footnotes, rather store them in the database (TODO: in "variable" table, no doubt). The processing of footnotes would then continue and append to the same list of footnotes across all text fragments that have the same unique cid. The mode="flush" would finally output the full list of footnotes and empty the variable from the database. (Default needs to be "flush". This is inconvenient for those that actually use this feature, but necessary when considering how [footnotes /] without attributes will work.)

Example:

TEXTAREA#1
Quick brown fox[fn]A fox is a mammal[/fn] jumps over lazy dogs.
[footnotes collection="12345" mode="store" /]

TEXTAREA#2 
Quick brown fox jumps over lazy dogs[fn]A dog is a mammal too[/fn].
[footnotes collection="12345" mode="store" /]

TEXTAREA#3
Quick brown fox jumps over lazy dogs[fn]This is just another footnote[/fn].
[footnotes collection="12345" mode="flush" /]

Notes:
To be researched: How to ensure that the "flush" tag is processed last? I have no control of that.

This could be useful also in other contexts, like pages of a book with the footnotes collected on the last page. But then all the pages would have to be submitted together (on each edit) in a specific order... not realistic.

Further idea / opposite approach: Investigate how CCK works and whether it would make sense to apply a run of some filter over the complete set of CCK fields. That would actually be targeting the root problem (yay, for root problem) and could be useful enhancement to CCK if it doesn't exist already.

Renaming

As alluded to in #1219598: Control output of Footnote links (i.e. location where footnotes is printed), we just need to add the footnotes to the $node->content array with a large weight. We can do this in hook_node_view() and hook_nodeapi() in drupal 6.

Then by default it will print at the end of your node content or you can theme it in your node.tpl.php to be wherever you like.

There will also have to be an option where you select whether it displays after the field (default so as not to break existing sites) or at the end of the $node->content array.

I'm going to assume hingo is no longer working on this.

I'm not :-)

However, this feature always puzzled me. I know this can be done with views and nodeapi. However the approach of the original footnotes when done as a filter is that footnotes essentially defines an extension to HTML, where fn is like a tag. You could for instance run some text content that includes footnotes also via an XSLT processor. Also in Drupal you could use a filter for some text that is not a node.

It would "feel nice" if those properties can be preserved. Otoh, with increased usage of CCK fields, that is probably important use case to solve whether or not it completely preserves the original idea.

I probably should have read your previous posts in full but it's past bed time and I'm just noting things down so I don't forget :)

Yeah, being a filter complicates things, and with fieldable entities things are further complicated in terms of getting a solution that fits everything.

Maybe as a start we could provide some helper functions or theme functions for devs & themers to use to easily get the footnotes for a specific field, or maybe even for a specific entity, by iterating over formatted fields as mentioned in #12.

So themers could just call a function from their preprocess function and then print out in their tpl.

That would be a start anyway.

I would like to know if this is still impossible? I want to output the footnotes in another block and I can't seem to find a way to do this. After reading all this, I guess it is not possible. Just checking if I misunderstood the discussion and there was some hope. Thanks!

I found a dirty work around to achieve the goal to show footnotes of various fields in a field collections as endnotes in an extra block. It isn't what you would call a clean and beautiful solution, but at least it works:

The problem I had, is, that I have a multiple field collection with fields like this:

$item->field_section;
$item->field_subsection;
$item->field_textblock;

I am using this to force the editors of the site to structure there academic texts with sections and subsections. The Problem that resulted from this, was that in the node view the footnotes were shown after each 'textblock' field. But I wanted them to be shown in a marginalia column as an extra block all together. So, what I actually did, is to

• hide all the fields form the node view
• added an extra field
• used hook_node_insert and hook_node_update to copy the values of the field collection to the extra field
• created a custom block with the following code to show the footnotes in:

      
/* TODO: This is a very dirty hack: To show the footnotes in an extra block,
  we copy them from the rendered field */
function custom_api_footnotes() {
  if (is_numeric(arg(1))) {
    $node = node_load(arg(1));
    if (isset($node->body['und'][0])) {
      $output = "";
      $output = field_view_field('node', $node, 'body');
      preg_match('#<ul.*?footnotes.*?\>.*<\/ul>#s', $output['#object']->body['und'][0]['safe_value'], $result);
      $footnotes = isset($result[0]) ? $result[0]: "";
      return print_r($footnotes, true);
    }
  }
}

This is it. No elegant, not beautiful, but working.

I think, a real solution for this problem could be, to add to the footnote module an footnote field, where the footnotes of specific fields are shown.