Posted by rbl on January 29, 2007 at 7:38pm
Jump to:
| Project: | Footnotes |
| Version: | 7.x-2.x-dev |
| Component: | Footnotes |
| Category: | feature request |
| Priority: | minor |
| Assigned: | hingo |
| Status: | active |
Issue Summary
The problem is that the footnote is being added after the CCK field where the footnote is and not in the end of the entire content, making the footnote appear in the middle of the text.
Take a look at the screenshot.
| Attachment | Size |
|---|---|
| Picture8.png | 34.21 KB |
Comments
#1
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.
#2
I would be satisfied if we could ensure the footnotes tag was respected =)
Moving the tag all over the page doesn't make any difference...
#3
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?
#4
No, sorry! I meant that the tag is not doing a thing! I can place it anywhere and the footnote content will always be outputted after the field containing the x code.
#5
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.
#6
Let me try to explain it again because my tags were removed =)
Let's say I have a CCK content type with 3 textarea fields. They all have Filtered HTML as input format where the module was configured and is working fine.
Adding a footnote (fn) to TEXTAREA#2 makes the footnote block (div or ol) appear bellow it, between TEXTAREA#2 and TEXTAREA#3, ignoring completly the "place footnotes here" tag (footnote)
TEXTAREA#1
TEXTAREA#2 has <fn>x</fn>
<ol><li>1. x</li></ol>
TEXTAREA#3
<footnote />
Hope that's better =)
#7
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 .
#8
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.
#9
#10
#11
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.
#12
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.
#13
#14