drupal 7 version.

There definitively are plans for a Drupal 7 version, but I have not committed to supporting Drupal 7 from day one.

In fact, the current plan is to spend some days during the Summer to apply the patches and fix the bugs that you can see open in the Footnotes issue tracker. That would then be 6.x-2.4 I guess. It would make sense to branch a D7 version out of that I guess.

On the other hand, if you want to go ahead and work on a D7 version right away, I of course cannot stop you :-)

Has anyone started working on a drupal 7 version yet? I believe it would be a good time to start thinking about it.

+1

There is no work on a D7 version yet, however the 6.x-2.4 release seems to be working well, so it is now a good base to build such a release from.

To be honest, I'm not sure when I will have time to do it, the Autumn has again been busy on the MySQL diaspora front. But once me or someone decides to do it, there isn't much to do.

What needs to be done is basically to link the existing functions into the new footnotes_filter_info() function:

http://api.drupal.org/api/drupal/modules--filter--filter.api.php/functio...

New in this function is also the very welcome opportunity to provide default settings, such as the filter weight.

After that the only other task should be to update version number and footnotes.info file, plus see if WYSIWYG module brings any changes on those sub modules.

+1

+1

I made very hasty port to Drupal 7 which seems to work as supposed. Here is the new code if someone is interested of such a quick solution.

function footnotes_filter_info() {
  $filters['filter_footnotes'] = array(
    'title' => t('Convert footnotes'), 
    'description' => t('Converts footnotes.'), 
    'process callback' => 'footnotes_filter', 
    'tips callback' => 'footnotes_filter_tips',
  );
  return $filters;
}

filter_tips does not have same parameters so easier way over that was to just return single tip.

function footnotes_filter_tips() {
  return t('Use [fn]...[/fn] (or <fn>...</fn>) to insert automatically numbered footnotes.');
}

And finally footnotes_filter has new parameters too. In addition to parameter change everything else apart from "case process" can be removed from that function (lines 107-146).

footnotes_filter($text, $filter, $format)

Subscribing

Building on #7, heres a patch for a first attempt at a D7 port. Also including full module.

I removed the Textile suport and better URL filter, as neither seemed to be maintained any more

There are a few big issues still to resolve:

• I added support for the setting, but switching it on spectacularly breaks the page. Keep it off for now
• For some reason my links only started at number 2. I worked around it by setting $n = -1, and by only outputting to theme if $value > 0, but that doesn't solve the greater issue
• Im getting a lot of Notice: Undefined index: ref_id in theme_footnote_list() for all the $fn variables there. Not sure whats going on there, it seems to be outputting to theme ok
• Havent included wysiwyg support yet

But for now, its functional :)

Good work nirb.

To get rid of the Undefined index errors I simply checked to make sure the values even existed:

 function theme_footnote_list($footnotes) {
  $str = '<ul class="footnotes">';
  // loop through the footnotes
  foreach ($footnotes as $fn) {
    if (isset($fn['ref_id']) && !is_array( $fn['ref_id'])) {
      // Output normal footnote if values exist
      if(isset($fn['fn_id']) && isset($fn['value']) && isset($fn['text'])) {
        $str .= '<li class="footnote" id="' . $fn['fn_id'] .'"><a class="footnote-label" href="#' . $fn['ref_id'] . '">' . $fn['value'] . '.</a> ';
        $str .= $fn['text'] . "</li>\n";
      }
    }
    else {
      // Output footnote that has more than one reference to it in the body.
      // The only difference is to insert backlinks to all references.
      // Helper: we need to enumerate a, b, c...
      $abc = str_split("abcdefghijklmnopqrstuvwxyz"); $i = 0;
       if(isset($fn['fn_id']) && isset($fn['value'])) {
          $str .= '<li class="footnote" id="' . $fn['fn_id'] .'"><span class="footnote-label">' . $fn['value'] . '.</span> ';
       }
     if (isset($fn['ref_id'])) {
        foreach ($fn['ref_id'] as $ref) {
          $str .= '<a class="footnote-multi" href="#' . $ref . '">' . $abc[$i] . '.</a> ';
          $i++;
        }
     }
      if(isset($fn['text'])) {
        $str .= $fn['text'] . "</li>\n";
      }
    }
  }
  $str .= "</ul>\n";
  return $str;
}

I've never actually used this module before until now, but it looks extremely awesome. As I become a bit more familiar with it I'll try to help with the other stuff.

Hi all

I feel that a short ping from the Footnotes maintainer is probably overdue: I've been working a bit on Footnotes recently. Some bugs and one feature patch were filed against 6.x-2.4 so I have now fixed those and pending one review I will release 6.x-2.5 and then branch a D7 version from there.

I haven't looked at the patch posted here yet, but judging from the comments you might be on the right track. My laziness towards a D7 port is partially intentional, I was kind of hoping to see some community action on this item, and appreciate it very much - I love to see the open source magic happening :-)

So please continue, I will look at it and commit soonish.

subscribe

subscribing

Thanks for this and also mikegfx in #10. Is it just me or does the footnotes list at the bottom of the body text consits of a list of numbers, in order, but with the Citation Key in each case as text rather than the formatted reference itself. Also, the anchor title in each case is the Citation Key rather than the formatted reference. I have biblio/footnotes working nicely in D6 on a couple of sites and feel I am missing something obvious.

@ch1mjw it seems like you have a biblio problem, not footnotes problem. (And even if you insist on it being a footnotes problem, please open a separate issue and don't divert this thread.)

I've created a version of this module for drupal 7 that treats the footnotes as a formatter instead of a filter. My version works fine now, but is still somewhat rough. The reason I did this was so that an entire node could contain footnotes, and then you could have footnotes for all fields present in a single sources section instead of beneath each field independently. The main problem with this is that I think it has ventured too far away from the way this module currently handles footnotes to easily integrate it. If there is enough interest in my changes I would consider looking into integrating it into this existing module, or creating another module all together. It's also up to hingo as I would likely need his help to implement it.

@mikegfx: If I understood you correctly, you have developed something that fixes #113944: Output footnotes at the end of the node, not the end of the field they are for. I would be interested to see the code, can you please post a separate issue.

I've kept thinking about that nasty issue for all these years, but never really had time to dive into it. (Even now, I'm still stuck solving major MySQL problems and only giving minimal time to Drupal and footnotes, unfortunately.) I never really mixed CCK fields and footnotes myself so there was never a situation where I'd have a personal motivation to attack this.

I look forward to seeing how you intend to solve this. If you're doing something completely different (not a filter) then a Drupal 7 version could be a nice opportunity to introduce it.

subscribing

I think footnotes should stay as filters for the first version migrated to Drupal 7 (7.x-1.x-dev). For those users looking to put footnotes in various fields, in addition to the body, I would suggest doing a 7.x-2.x-dev version.

So the 1.x-dev version would be enough for 90% of the users of this module, while 2.x-dev would migrate to formatters.

Could this suggestion help out in having a Drupal 7 version of Footnotes sooner? How about the version in #9? Can this be committed as the first version for Drupal 7?

Mike,

1. Does this version work with already existing footnotes in a field?
2. Can you make this available for testing?

I don't have any problem with all footnotes in a single sources section. However, I do think that there needs to be a setting that allows you to choose where the sources section is displayed (I may not understand formatters, perhaps this is a default).

Hey guys, sorry I completely spaced this thread.

Maria,
It's not completely compatible in it's current state, though it might not require too heavy of changes to make it so. I think a better solution will need to come of already existing formatters(which will need to strip out the footnotes completely. The difficult part about displaying a footnote for the entirety of a node display is knowing which fields need to be included in the display. Because of this, since I built it before most contrib modules were even ready, my current solution is very specific to my own projects needs.

I think that if we do go the route of doing footnotes based on entire displays, it needs to be a system that is flexible enough to work with modules like Display Suite, Node Blocks, Views(node display) and so forth. This could be done by instead, making footnotes an 'option' on the manage field display screen(See mockup attached below).

I think maybe we make the initial port to 7 a straight a port, then if their is enough interest we make a second branch that rethinks the approach to work with drupal 7's greater accessibility to data.

I stripped some of the project specific stuff out of mine and attached it below. I in no way think it's the route we should go, but it's a general proof of concept. Please test in a sandbox, as I have not tested this stripped out version. It may need a few minor repairs/tweaks.

One additional thing I changed was how the multiple references should work. Basically whenever an FN tag has a value, it will automatically display independently of any of the ones that are autonumbered. If two FN tags reference the same value, they are then grouped together and numbered in the order they display relative to something else.

So say you have 5 tags
a. fn
b. fn = 1
c. fn
d. fn = 1
e. fn

Before:
a, b, d = 1 (a being autonumbered to 1)
c = 2
e = 3

Now:
a = 1
b, d = 2
c = 3
e = 4

This was done so that you wouldn't have to do a massive reordering of the footnotes should you want to insert one above some existing association. The groups no longer care about the auto numbered footnotes, they only care about ones that are identical, and then will renumber relative to the other footnotes.

I apologize for not making this as accessible as I had originally had hoped.

I think maybe we make the initial port to 7 a straight a port, then if their is enough interest we make a second branch that rethinks the approach to work with drupal 7's greater accessibility to data.

@mikegfx: This is what I suggested in #20. So do a straight Drupal 7 port before doing a 2.x branch. This way straight upgrades from Drupal 6 to 7 will work. And users interested in the new architecture for this module, would then be able to comment about the 2.x branch.

So I would suggest to keep this issue open for the straight Drupal 7 port and create a new issue for the 2.x branch.

FYI everyone. I believe I have now completed a port to Drupal 7, based on the patch in #9 but fixing the Undefined index errors and another bug too.

In general it was good work. I will now sleep on it, review, then learn how to push a new branch over the weekend.

The addon modules (Views and Wysiwyg) are still to do, I don't know if there will be any issues with them.

I will be happy to test this. I only have a few footnotes, which may provide a safer testing ground. If I need to install some special model to give better error feedback, please let me know what modules. I may not be able to do it quickly, I will try to get to it as soon as I am able.

So the "beta1" release is visible now: http://drupal.org/project/footnotes

Turns out the Views module itself doesn't really support D7 yet, so porting Footnotes Views is impossible. Now I'll work on the Wysiwyg modules.

http://drupal.org/node/1091238

update went perfectly. thanks for all your work!