Disable footnotes outside of the normal view

I noticed that. To clarify what you are talking about, footnotes itself works just as it should, but that module will additionally print out a list of links in the article.

1) The solution is that the print module should imho ignore links that point to anchors inside the article itself and only list links to other pages.

2) If the print developers disagree with the above, they could still do such a solution specifically to ignore footnotes related links, which you can easily identify by looking at the span and ol html elements that are identified by footnotes specific class attributes.

3) If the print developers still disagree, then I could think of a solution where footnotes creates the footnotes as text only, so that they are not links. The print module would then still have to support that functionality, so this leads us back to 2) as a cleaner solution.

I opened an issue in the print module's queue: #735260: Interaction with footnotes module (exclude anchors)

Actually, the solution should indeed be 3), as your module is really the one that is inserting the links and can remove them in a much cleaner way.

Consider that the there are 6 build modes defined by Drupal core (http://api.drupal.org/api/drupal/modules--node--node.module/6) and that you probably only want the footnote links to appear in one of them (the NODE_BUILD_NORMAL) while excluding them from some of the others (at least NODE_BUILD_PRINT and NODE_BUILD_RSS) the footnote module should adjust it's output depending on the current build mode.

As you can see 3) is actually the cleaner solution.

Hi jcnventura

Thanks for the pointer. I wasn't aware that these constants are available.

The problem remains though: In the filter api, $node isn't available to me at all. I'm just given a variable with text and process it, there is no information that would tell for what purpose.

I agree that if I had access to $node->build_mode this would be the perfect solution.

Any other ideas?

Oh, going back to the approach that Print module has to handle this issue, I could easily insert some class attribute that would make it easy for you identify links that you should "ignore" / not print out. It could be a generic identifier like <a href="#..." class="link-internal">...</a>

I've attached a patch to the other issue, which solves the problem by making anchor links in the list optional:

http://drupal.org/node/735260#comment-2692318

Part of the problem is that the footnotes module uses <ol>. That means losing the CSS generates a huge problem (i.e. 1. 1., 2. 2., etc.) At least, using UL helps since that way you get a dot + 1., dot + 2. instead of the doubling numbering.

There is a simple sample:

With <ol>

1. 1. Note 1
2. 2. Note 2

With <ul>

• 1. Note 1
• 2. Note 2

And my problem appeared in my RSS feed which I find more dramatic than the Print module which much less people use on my sites. Several entries with notes appear in the feed (at least at time of writing):

http://www.turnwatcher.com/rss.xml

I'm attaching a patch. Please, check it out and mark this issue as "reviewed & tested by the community" so we have a chance to get this in the next version of footnotes.

Thank you.
Alexis

Wanted to change the status too 8-P

Hi Alexis

You bring up an excellent point about OL vs UL. I have never realized it doesn't work with RSS feeds. (With Print feeds it's just a matter of using CSS again to get the right results.)

I consider this a separate bug in its own right, so I have created a new bug for it: #761664: Footnotes are double numbered when CSS is not used, such as in RSS feeds. (Due to using OL list)

Changing status back to active to reflect the main topic of this thread.

print module maintainer here: I have just committed a patch that disabled the named anchors in the printed URL list by default, so the original request is no longer applicable.

I still think that if it was possible, the footnotes should be disabled for build modes other than the normal view, so I am keeping this active, but I do understand that may not be possible in an input filter..

Unless there is a change in Filter API, it is not possible to address this problem within Footnotes. (But I can see how a BUILD MODE could be useful for many filters.)