Closed (fixed)
Project:
Footnotes
Version:
5.x-1.3
Component:
Footnotes.module
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
30 Apr 2008 at 23:33 UTC
Updated:
27 Jul 2008 at 18:32 UTC
If the footnote is linked to text that appears before the teaser cutoff, the article teaser will display the footnote where the number should appear in the article teaser. It still displays as it should in the article itself, though. I will look into the problem myself to see if I can find a fix for it. I apologize if this issue was resolved in 6.x--I'm waiting for a few more modules to be updated before I upgrade. For an example of the bug, go to http://napoletano.net/front/ and scroll down to the teaser with the title, "What is free software?". The sentence beginning "While I..." to the end of the teaser is all part of the footnote. Beyond that, the module works great, and I love it.
Comments
Comment #1
hingo commentedHi Napzilla
Thanks for this bug report. I have never seen this behaviour before. But I can tell what is happening. Also, I can reproduce this on my own Drupal5 installation.
What is happening:
You have the following text at the beginning of your article:
1) In general, having a footnote as part of the teaser works just fine. The result should be that there is a footnote as part of the teaser, properly formatted with a nr 1 and put at the end of the teaser text.
2) Drupal typically tries to cut the teaser at a full paragraph break. However, it also honours what has been set in Administer - Content Management - Post settings. Default seems to be to cut at 600 characters max.
3) In your case, Drupal has decided to cut at 655 characters. I have no idea why and I'm not familiar with the exact algorithm Drupal uses here. If I had to guess, I would say it is cutting after the first full stop that appears after the 600 mark.
4) The end result is unfortunately that the teaser contains part of the footnote, but not all, and especially it is missing the closing
</fn>tag. Here's your teaser text:5) This text is given to the footnotes filter. At this point Footnotes fails to find a footnote, because it is looking for a pattern including the end tag:
<fn>...</fn>6) End result is that (partial) footnote text appears inline in the teaser.
Whose fault is it? (Drupal core)
We could fix Footnotes to also process this kind of broken footnote. What is more important is to realise that the Drupal code that creates teasers is broken and affects other use cases too, not just Footnotes. For instance, try replacing
<fn>...</fn>with<em>...</em>instead. Drupal will again break the teaser inside the<em>...</em>tags. In this case you will end up having all of your front page in italics, because there is an open<em>tag there.What should be done?
We (go ahead, if you have the time and energy) should open a new bug against Drupal core. Use your text as an example triggering the error, but instead of
<fn>tags use the more general<em>. Needed fix is for Drupal to avoid cutting the teaser text within an open html tag. (The same problem will probably affect non-html markup like bbcode too by the way.)I will leave this bug open until a new bug has been created against Drupal core HEAD. When the new bug is opened I will close this one.
While we could also add workaround code into the Footnotes module, I don't intend to do so for now. Let's instead focus on fixing the real problem in Drupal code. Meanwhile, also see another workaround below.
Workaround
You can use
<!--break-->to manually tell Drupal the spot were you want the teaser to end. This will fix your problem as the whole footnote will be part of the teaser and everything will work as it should.Comment #2
hingo commentedDrupal 7 doesn't really fix this proper, but since D7 comes with the HTML Corrector, so any HTML tags that would be broken by this actually get fixed whenever HTML corrector is used. (In practice, always.) Unfortunately however, this doesn't solve the problem for fn tags.
Since Drupal 7 doesn't suffer from this anymore, I'll look into fixing this withing footnotes. (While waiting for that, workaround given above still applies.)
Comment #3
hingo commentedThis is now fixed and committed to CVS HEAD, so it will appear overnight in the 6.x-2.x-dev snapshot download.
The fix simply checks whether there is one closing tag missing and if there is, appends it to the end. (Yes, there are multiple scenarios this could be wrong, but not with sane input.)
Comment #4
hingo commented