Last modified: 2011-10-27 23:56:56 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 6793 - New Variable __NEWSECTIONS__ like __TOC__
New Variable __NEWSECTIONS__ like __TOC__
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Page editing (Other open bugs)
unspecified
All All
: Low enhancement with 4 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
: patch, patch-need-review
: 21141 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-07-23 14:00 UTC by Julian Fleischer
Modified: 2011-10-27 23:56 UTC (History)
4 users (show)

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


Attachments
Add PlaceNewSection hook to allow extensions to override placement of new sections (771 bytes, patch)
2011-10-24 06:29 UTC, Nikola Kovacs
Details
hooks.txt documentation for the PlaceNewSection hook (803 bytes, patch)
2011-10-26 20:23 UTC, Nikola Kovacs
Details

Description Julian Fleischer 2006-07-23 14:00:49 UTC
This is about the feature to add new comments to a page. By default they are added to the end of the 
discussion-article (or article, however). But what, for example, if you want to install a little message at the end of 
your discussion page? if than a section is added that little message wont be still at the end of the page. So it would 
be great to have a Variable like __TOC__ that can be used to determine WHERE new sections will be added. If that 
variable is ommited the default behaviour will of course be executed.
Comment 1 Charlie Huggard 2006-07-25 02:58:33 UTC
This would be pretty neat... I could fosee 2 magic words __NEWSECTIONABOVE__ and
__NEWSECTIONBELOW__ which would of course put the new section above or below the
marker (first marker taking precidence). With NEWSECTIONBELOW, it would enable
discussions to flow the opposite way (with the newest sections floating to the
top and older discussions sinking to the bottom of the page. 
Comment 2 Julian Fleischer 2006-07-25 09:45:19 UTC
Just to understand you right: Are you speaking of something like that:

<page>Hello, this is my discussion page, you can [[%editlink%|leave me a message]].
(generated toc or with __TOC__ placed)
__NEWSECTIONBELOW__
(new sections will go here)
==discussion==
blablabla
==discussion==
blablabla</page>

<page>Still my discussionpage
(__TOC__)
==discussion==
blabla
:answer
==discussion==
blabla
(new sections will go here)
__NEWSECTIONSABOVE__</page>

The second example is the default behaviour, except there would be standing something after __NEWSECTIONSABOVE__

i guess i more needed to make that clear to myself with an example ;) good idea either ^^
Comment 3 AlexSm 2007-07-02 16:43:19 UTC
Any chance __NEWSECTIONBELOW__ could be implemented? It will be really useful for some forums that flow bottom-to-top. 

Right now "Add new subject" link is implemented with &action=edit&section=0 but this way the top "{{/header}}" part gets  accidentially deleted from time to time. 
Comment 4 Alexandre Emsenhuber [IAlex] 2009-10-14 20:37:34 UTC
*** Bug 21141 has been marked as a duplicate of this bug. ***
Comment 5 Nikola Kovacs 2011-10-24 06:29:56 UTC
Created attachment 9275 [details]
Add PlaceNewSection hook to allow extensions to override placement of new sections

[[mediawikiwiki:Extension:PlaceNewSection]] can do this, but requires a patch to WikiPage.php (Article.php in MW1.17 and older); I had to introduce a new hook because none of the existing ones were suitable.
Comment 6 Nikola Kovacs 2011-10-24 06:31:25 UTC
Oops, that interwiki link didn't work, here's the full url:
http://www.mediawiki.org/wiki/Extension:PlaceNewSection

(In reply to comment #5)
> Created attachment 9275 [details]
> Add PlaceNewSection hook to allow extensions to override placement of new
> sections
> 
> [[mediawikiwiki:Extension:PlaceNewSection]] can do this, but requires a patch
> to WikiPage.php (Article.php in MW1.17 and older); I had to introduce a new
> hook because none of the existing ones were suitable.
Comment 7 Mark A. Hershberger 2011-10-26 19:28:31 UTC
(In reply to comment #6)
> Oops, that interwiki link didn't work,

Clicking it WORKSFORME.

Could you also provide a patch for hooks.txt? http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/docs/hooks.txt?view=markup
Comment 8 Nikola Kovacs 2011-10-26 20:21:06 UTC
I swear it didn't work... someone must've turned on forwarding.

Anyway, do you think it would be a good idea to change the parameters, or is it okay like this? Right now it's a bit illogical IMHO, $oldtext is the text of the page before the edit, $text is the text of the new section (i.e. the contents of the edit box), and the hook expects you to put the new, merged text into $text, since that's how the core code works; but it would make more sense to have a &$text that contains the old text, a $subject and a $sectiontext, and then you'd have to replace $text with the merged version. That would make more sense since you're changing the page text, not the text of the new section, but would require some additional code to put everything where it's supposed to go before and after calling the hook.
Comment 9 Nikola Kovacs 2011-10-26 20:23:39 UTC
Created attachment 9288 [details]
hooks.txt documentation for the PlaceNewSection hook
Comment 10 Mark A. Hershberger 2011-10-27 23:43:47 UTC
(In reply to comment #8)
> Anyway, do you think it would be a good idea to change the parameters, or is it
> okay like this?
> [...] the hook expects you to put the new, merged text
> into $text, since that's how the core code works;

Making your hook work like the core is better, imo.
Comment 11 Mark A. Hershberger 2011-10-27 23:56:25 UTC
r101096

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


Navigation
Links