I'm not sure which end to approach this from, but will start here.

The Footnotes are great, but when combined with www.drupal.org/project/pagination (which splits a node automatically or manually into multiple pages) the footnotes all go to the last page and the links don't work. The only way to get them to work is by using the "view full page" option.

I'm dealing with lengthy and heavily structured content, so would like to use both modules if possible. Is there any way to control where footnotes are listed? Ideally I guess I'd like something like [showfootnotes] which would show all the footnotes in the current page - or maybe the ability to put them in a block. The Textile style footnotes section seems to refer to the ability to place the footnotes but I'm not using Textile.


hingo’s picture

Project: Footnotes » Pagination (Node)
Version: 6.x-2.1 » 6.x-1.x-dev
Component: Footnotes.module » Code

Hi adam

Thanks for the feedback, glad to meet another happy footnotes user.

I looked into this a bit, and I guess I have to send you to pagination.module for this feature request (which I happily support btw). The thing is, footnotes is just a filter, so it is limited in what it can do by the Drupal filter api. (And this is ok, simplicity is good, and saves me extra work, like now :-)

I looked into the pagination.module code and here's the thing: When you create paginated Drupal nodes, they are stored as one node but for each view, pagination.module will break the node into its part and present you with whatever page needs to be shown. The problem here is that the order of execution is such, that filters have already been applied before pagination does this. This is why all the footnotes are already on what will become the last page.

What we want is to have pagination to break the node into pieces first, then apply the filters. (Note that in this case each page will restart footnote numbers from 1, unless you use the value="5" label explicitly.)

It seems this is doable, and the answer is found in node_build_content() in node.module. (I'm just writing this here so you can point the pagination.module author to this issue...)

This is the interesting part:

  // The 'view' hook can be implemented to overwrite the default function
  // to display nodes.
  if (node_hook($node, 'view')) {
    $node = node_invoke($node, 'view', $teaser, $page);
  else {
    $node = node_prepare($node, $teaser);

  // Allow modules to make their own additions to the node.
  node_invoke_nodeapi($node, 'view', $teaser, $page);

Filters are applied in the node_prepare() function, whereas pagination.module does its thing in the node_invoke_nodeapi(). However, pagination.module should contain a function pagination_view() instead, that way it could do the pagination before filters are executed.

I haven't done this myself, but here's where to start:

PS: It seems I can redirect this issue directly to the Pagination module, so will do so now.

adam_b’s picture

Thanks for the comments, hingo. This is beyond my level of expertise, so I'll wait for the Pagination gods to comment.

mundanity’s picture

Hi Adam,

I'll try get to this by the weekend, thanks for bringing it to my attention.

mundanity’s picture

Hi Adam,

I'll try take a closer look this weekend, this week looks pretty busy unfortunately. The issue with just calling hook_view() instead is that pagination doesn't implement that hook (it's for modules which create custom nodes). There's a way to fool Drupal in calling hook_view but I want to double check to make sure that doesn't cause problems with other modules (ie, paginating too early, etc...)

scottrigby’s picture

Hi Owen,
I tried to get an understanding of this issue today, and came to basically the same conclusion (until I found this issue) - but I didn't think about using hook_view().
have you had any other thoughts about possible problems with using hook_view to deal with this issue? I'd be happy to help

mundanity’s picture

Hi Scott,

Unfortunately I haven't had enough time to sit down and take a more in depth look. This is definitely the next thing on my radar though. If you do have any thoughts / suggestions I'd be glad to hear them. I just want to make sure I'm not introducing other issues by breaking up the body of a node before filters are being run.

Currently however, it is a bit random as to when the pagination actually happens (depending on the modules you install, and the order assigned to pagination, determines when pagination's hook_nodeapi is actually fired).

mundanity’s picture

Status: Active » Closed (works as designed)

As a generic update, the issue is two fold:

1. Early pagination (before filters are applied) is a bit problematic, in that it's probably cleanest to apply this as a filter. This adds a lot of configuration to Pagination that I'm not a big fan of. In addition, it basically means that filters can't be cached, which could be an issue for a lot of sites. This also means that other elements added (ie cck fields, etc...) do not get paginated as well.

2. Late pagination obviously has issues with filter modules that wish to operate on content, but I *think* matches the typical use case more closely.

As for what the solution is, I'm not sure, I was toying around with the idea of supporting both methods, but that seems like a lot of bloat. I'm unfortunately going to mark this as "by design" until a better solution arises.

entrigan’s picture

I was dealing with a similar issue with a custom filter module having issues with pagination. I do not think there is a clean solution, so instead i converted my filter to a hook_nodeapi "filter".

reference: http://drupal.org/node/106249

EDIT: by using hook_nodeapi you can store info such as footnotes in a separate field.

siefca’s picture

You need a DOM parser to fix that, since the nature of footnotes is that they are assigned to a single page.
To resolve it in a clean way the single footnotes section should be splitted into many sections – one per subpage.

I'm using Markdown parser and Markdown-style footnotes. Here is my filtering module for Drupal 7 that fixes footnotes:


It shouldn't be a problem to adapt it to support other footnote types.
Sorry for bugs, if any, I'm using Drupal since 3 weeks after 4 years of absence and never coded any modules.