Last modified: 2012-07-26 19:48:25 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 8207 - </sort> seems to collect footnote at the wrong place.
</sort> seems to collect footnote at the wrong place.
Status: RESOLVED WORKSFORME
Product: MediaWiki extensions
Classification: Unclassified
Sort (Other open bugs)
unspecified
PC Linux
: Low normal with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
http://test-wiki-02.blissenbach.eu/wi...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-12-10 12:11 UTC by Purodha Blissenbach
Modified: 2012-07-26 19:48 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Purodha Blissenbach 2006-12-10 12:11:56 UTC
This may be a bug against the Sort extension or the 
FootNote (neither available in MediaZilla).

See http://test-wiki-02.blissenbach.eu/wiki/
index.php?title=Footnote-sort -- Footnotes appear in the 
page after the sort-Block, but should be at it's end.

The installation is 1.9-svn - not updated since Novembre 
18, 2006. It is likely to remain at that revision for about 
the rest of the year.
Comment 1 Rob Church 2006-12-10 12:30:11 UTC
Where did the <footnote> parser hook come from?
Comment 2 Purodha Blissenbach 2006-12-10 15:15:51 UTC
Here is a 'tail' of LocalSettings.php :

$wgRightsIcon = "http://creativecommons.org/images/
public/somerights20.png";
# $wgRightsCode = "by-nc-sa"; # Not yet used

$wgDiff3 = "/usr/bin/diff3";

# When you make changes to this configuration file, 
this will make
# sure that cached pages are cleared.
$configdate = gmdate( 'YmdHis', 
@filemtime( __FILE__ ) );
$wgCacheEpoch = max( $wgCacheEpoch, $configdate );
error_reporting(E_ALL);
require_once 'extensions/ExtensionLoader.php';
wfExtensionLoader(
    'ExtensionFunctions.php',
    'FootNote/Footnote.php',    # Ok.
    'ParserFunctions/ParserFunctions.php',      # Ok.
    'ShowProcesslist/ShowProcesslist.php',      # ?
    'Sort/Sort.php',    # Ok.
    'inputbox/inputbox.php',    # OK.
    'Patroller/Patroller.php'   # needs install
 ) or die( "Failed to load" );
?>

All .php files and directories under extensions are 
symlinks to a separate checkout directory, where all 
extensions are, i.e.
.../wiki/extensions/xyz.php
to
.../extions/xyz.php
and
.../wiki/extensions/xyz
to
.../extions/xyz/

There are 2 or 3 more language/MessagesXxx.php files 
than usual.
Nothing else has been tweaked.

The remark "OK." above says basic functionality has 
been tested and is working.

ExtensionFunctions.php was included "just in case",
Special:ShowProcesslist curently says "no Right"
Patroller: additinoal tables have not yet been created.

Does that answer your question?
Comment 3 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-12-10 20:31:37 UTC
Please verify that this bug is in either MediaWiki or one of the extensions in
SVN before reopening.  If the bug is in another extension, as seems likely, the
appropriate course of action is to contact that extension's author(s), who more
than likely don't read this bug tracker.
Comment 4 Purodha Blissenbach 2006-12-10 23:47:32 UTC
No chance. This is only an unimportant temporary test 
installation meant for something else. I simply don't 
have the time to delve more deeply into this bug.
I stumbled accidentally over it, and thought it to be 
better than not, to pass it on.
Comment 5 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-12-10 23:50:17 UTC
Then thank you, but it's probably not anything we can debug or fix.
Comment 6 Rob Church 2006-12-11 00:16:00 UTC
Where did FootNote come from?

Simetrical; for bugs in extensions used on Wikimedia sites, and for those in
Subversion, bug reports here do no harm. If FootNote is in SVN, then we may want
to fix it up to work with other, dare I say more "official" extensions (such as
Sort). Then again, we may just want to bitch at the creator. :D
Comment 7 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-12-11 00:18:00 UTC
I thought FootNote and Sort weren't in SVN (got confused by "neither available
in MediaZilla", Mediazilla vs. SVN, d'oh).  My mistake, both are in SVN, so this
belongs here.
Comment 8 Purodha Blissenbach 2006-12-11 00:25:10 UTC
Oops. 2 Collisions.
I've e-mailed this URL to the authors mentioned in the 
extensions.
Comment 9 Purodha Blissenbach 2006-12-11 00:29:34 UTC
For the installation, I used two svn co commands, 
trunk of mediawiki to .../wiki and trunk of extions to
 .../extensions - both into the web space.

When I wanted to bug report @extensions, I found 
neither Sort nor FootNote there.
Comment 10 Rob Church 2006-12-11 01:03:32 UTC
Right, the cause for this is quite straightforward; Footnote makes use of the
ParserBeforeTidy hook, which is called on parse operations. The problem is that
Sort (and quite a few other extensions) call a parse run within their hook
functions, which causes this hook to be called; hence the stuff is injected into
the parsed output that Sort returns.

Footnote has a check to make sure that it isn't injecting two sets of endnotes,
so of course, once the first lot comes out, no more will be printed, which has
the effect that the only endnotes on the page appear under a sorted list.
Comment 11 Purodha Blissenbach 2006-12-11 01:19:34 UTC
That sounds as if the two cannot share the same hook, 
or some sort of hook funtion stacking is needed, that 
effectively would make the hook function calls within 
a <sort> private to that <sort> separating all parsed 
data processed within from the data processed outside.
Comment 12 Rob Church 2006-12-11 01:25:17 UTC
They aren't sharing a hook at all; Sort does not use the ParserBeforeTidy hook.
Sort *does* call an internal parse operation, which will cause that hook to be
called, and then Footnote comes along. It's not the *fault* of their extension,
nor is it the fault of Wegge or myself (the authors).

It's probably better, now that we have it, to use the Cite extension, with <ref>
and <references> for exact positioning of the references block wherever you want
it. It's probably not realistic for extensions to expect that Parser::parse()
will only ever run once for a given piece of text where parser hooks are involved.
Comment 13 Purodha Blissenbach 2006-12-11 01:44:42 UTC
True.
(I think,I understood it right, that the call to the 
ParserBeforeTidy hook was an indirect one. Thus, my 
writing they 'share' it was a bit sloppy indeed. 
Still, stacking would be a possible solution to such 
problems, but from my experience with similar 
solutions, I'd rather avoid it if possible, since it 
may quickly become very complicated and confusing to 
use. Truly reentrant code would be preferrable)

Thank you for your diagnosis!
Comment 14 Siebrand Mazeland 2008-08-11 16:41:07 UTC
Should this issue be closed? And if so, is FootNote obsolete in favour of Cite? The last change to Footnote was pre r10812 (August 2005). Rob Church has done some refactoring on Sort in July 2007, which sortof makes it maintained (ill, though).
Comment 15 matanya 2012-07-26 19:48:25 UTC
FootNote was replaced by Cite.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links