Last modified: 2014-03-09 12:18:13 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T33919, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 31919 - Allow posting new sections to top of page on a per-page basis
Allow posting new sections to top of page on a per-page basis
Status: NEW
Product: MediaWiki
Classification: Unclassified
Page editing (Other open bugs)
unspecified
All All
: Normal enhancement with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
http://en.wikipedia.org/w/index.php?t...
: easy
: 15494 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-10-24 13:37 UTC by mabdul
Modified: 2014-03-09 12:18 UTC (History)
10 users (show)

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


Attachments

Description mabdul 2011-10-24 13:37:28 UTC
As you can see in this URL, I want to add a parameter(the actual  in that preloadedtext/template. The problem is that there is no magic word that recognize the actual full URL of that page, nor is there a way to give the preloadtext any parameter. A "quick 'n dirty" possibility for adding the desired parameter would be allowing me that I can use the appendtext of the API like in the following URL:
http://en.wikipedia.org/w/index.php?title=User_talk:Mabdul&action=edit&editintro=Template:AFC_submission/user_talk_editintro&preload=Template:AFC_submission/user_talk_preload/sandbox&preloadtitle=Your+submission+at+%5B%5BWP%3AAFC%7CArticles+for+creation%5D%5D&section=new&appendtext=GPL}}

With this change, I would be able to change the actual system (by moving the actual pagename to the end) of our preloaded template and thus being able that the "accepting" reviewer don't have to type the accepted page manually. (this template is existing of course also for declining)
Comment 1 Ryan Kaldari 2012-05-15 18:11:59 UTC
I'm having a bit of trouble understanding your request. Are you saying you want to preload a template into the editing interface and also pass parameters to that template via the URL? If so, there is no practical way to implement that as the edit page has no awareness of templates and their parameters, i.e. it wouldn't know where to plug in the parameter text. Could you explain more specifically what you are wanting to accomplish. Perhaps there is a better way to achieve it.
Comment 2 mabdul 2012-05-16 09:57:45 UTC
I believe that you misunderstood me and rereading my own bug report I understand why.

The API allows to add sections/text at the top of the page through the api call 'appendtext' this would be very helpful for some tasks at enwp if we can use that also by using the normal GUI.

This is in contrast similar to the &section=new only at the top of the page, because &section=-1 doesn't work (the first section is filled in the text field) nor is &section=0 always usable since preloaded text doesn't work in both cases

What we need (the TeaHouse and the AFC team) is that we can add sections at the top and or above all content. (best would be both)

Hope that clarifies the situation.
Comment 3 Ryan Kaldari 2012-05-16 14:07:42 UTC
Ah, so you want to be able to post new sections to the top of the page. Why didn't you just say so :)
Comment 4 MZMcBride 2012-10-19 17:56:32 UTC
This bug is related to bug 15494 ("Add new sections to the top of a page on a site-wide basis").

I'm going to mark this as easy. Bug 15494 is about the ability to change the &section=new behavior on a site-wide basis (via a configuration variable). This bug is about the ability to change the &section=new behavior on a per-page basis.

I think a magic word is the most logical implementation for this. Something like __REVERSEPOSTORDER__ or something, maybe? That way it would just do whatever the non-default behavior is. Or you could take a more explicit approach and have __ALWAYSTOPPOST__ and __ALWAYSBOTTOMPOST__ and the implicit value would be whatever the site-wide default is.
Comment 5 Jack D. Pond 2014-02-19 12:55:12 UTC
*** Bug 15494 has been marked as a duplicate of this bug. ***

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


Navigation
Links