Last modified: 2011-10-27 23:56:56 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.
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.
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 ^^
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§ion=0 but this way the top "{{/header}}" part gets accidentially deleted from time to time.
*** Bug 21141 has been marked as a duplicate of this bug. ***
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.
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.
(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
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.
Created attachment 9288 [details] hooks.txt documentation for the PlaceNewSection hook
(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.
r101096
