Manual talk:Parameters to index.php

redirected to a 404 page
Seriously, where is index.php - what domain? I keep getting redirected to a 404 page. This should be really obvious and it's not.
 * it is hidden with http://www.mediawiki.org/wiki/Manual:Very_short_URL Ikip 07:58, 26 September 2009 (UTC)

To do
Edit:
 * wpScrolltop: what is this used for?
 * why wpLivePreview? is this used to allow two buttons "preview" and "live preview" to be present on the form at the same time?
 * metadata

Article.php


 * token (edit token used in deletetrackback)
 * tbid

ImagePage.php


 * image: 1. the alternate text of the image thumbnail in the image description page, and 2. the title of the image when deleting all its revisions (appears to be no longer used; deleting the image description page now effectively deletes all revisions of the image)

Feed.php


 * ctype

OutputPage.php:


 * returnto

Pager.php


 * asc

redirect.php
Argument wpDropdown (the page to go)

Cascading protection
Cascading protection does not "change" the protection level of the transcluded pages; these have their own protection level, but are protected indirectly by the cascading protection of the transcluding pages. Tizio 15:43, 17 January 2007 (UTC)

Obsolete parameters
"editredlink" has been replaced by "action=edit&redlink=1", so it's likely to be removed from Wiki.php at some point. When this is done, move to a separate "Obsolete parameter" section. Tizio 14:26, 26 February 2008 (UTC)

I could swear action=raw worked...
But now all I get is a forbidden message saying "Raw pages must be accessed through the primary script entry point." I'm fairly certain this worked before... 75.17.213.235 09:07, 8 March 2008 (UTC)

To clarify, I'm sending request like http://www.mediawiki.org/wiki/Manual:Parameters_to_index.php?action=raw this used to work (iirc)...I think...?


 * Do what the error messages tells you: use the primary script access point. http://www.mediawiki.org/w/index.php?title=Manual:Parameters_to_index.php&action=raw works. -- Duesentrieb ⇌ 12:14, 8 March 2008 (UTC)


 * 29939. Splarka 07:08, 10 May 2008 (UTC)

AJAX
What should we do for using ajax in the search box? the description is not clear for me:

if enabled, calls a php function registered via $wgAjaxExportList; see Manual:Ajax. * requires $wgUseAjax to be true; the only callable functions are those in the array $wgAjaxExportList (implicite if $wgAjaxSearch or $wgAjaxWatch is set) * additional parameters: rs is the function name (e.g., rs=wfSajaxSearch); the rsargs[] array is the list of arguments of this function (e.g., rsargs[]=abcd passes the abcd string to the function). * the JavaScript function sajax_do_call for calling Ajax functions is defined in ajax.js

What schould a do in the LocalSettings.php

$wgUseAjax = true;

$wgAjaxSearch = true;

$wgAjaxWatch = true;

how schould $wgAjaxExportList[] with rs=wfSajaxSearch or array( 'wfSajaxSearch' ) works

Thx.

wp*Time...
I'm writing a bot for an internal corporate MediaWiki installation, and I'm running into the most peculiar situation. To a page that either does not exist or was created by my bot, I am able to update the page via the bot. On the other hand, if the page has been human-edited (no matter how far in the past), I receive a conflict resolution page. I have an edit token when doing this, and things appear to be okay there, but my values for the wpStarttime and wpEdittime are both blank. They are blank for two reasons really; almost every example I've seen has them both blank, and also I don't know what format a date would need to be in (or for that matter, a time pulled from where). Should they be blank? If not, what format should the stamp be in, and where should that date come from? This bot is for an automatic push of all schema changes to a database, so I really do not care about conflicts. Whatever my bot says should go. Is there anyone out there who can help me through this last leg of it? Thanks much in advance. -- Lance May 15:37, 18 July 2008 (UTC)


 * The reason it works for you if the page does not exist, or if the last editor was you, is conflict resolution is automatic in the latter, and unnecessary in the former. wpEdittime is the timestamp of the last revision. This is used to insure that when you save, if you have the timestamp of the last revision, no edit was made between you starting to edit, and you submitting the edit. If this is the case, no edit conflict checking is required. If this is omitted or doesn't match the last edit, and you aren't the last editor, then you of course get an edit conflict.


 * The format for edittime is, (for example my edit right now, the timestamp of your last edit): 20080718153710 YYYYMMDDHHMMSS. You can get this via the API. For example, this returned 2008-07-18T15:37:10Z, all you have to do is strip out everything that isn't a number, and send it back. Splarka 07:30, 19 July 2008 (UTC)

Accessing Request Parameters
If I'm creating an extension that uses it's own set of request parameters, is there recommended way to access request parameters? —Sledged (talk) 22:10, 6 August 2008 (UTC)

Small error
"the non-ascii characters in the initial content of the textarea are converted into the form &#xxxx"

This is not correct (doing that conversion alone would not be reversable), what actaully happens is the following

All occourances of &#x are replaced by &#x0, then all non ascii characters are replaced by an entity of the form &#x; (note: the x is NOT a placeholder, it is literally part of the entity).

-- plugwash

Get Version at 'date'
I am trying to figure out a way to return a version of a page as of a certain date. It can be accomplished by going to the history, finding the date of interest, and then selecting the last version before that date occurred, then noting the oldid of that version. Instead, I am trying to figure out if there is any other index.php parameter that is like "&asOf=02142003" to return the version as of Feb 14 2003 (or an error if there isn't one, much like how if you use an oldid that doesn't exist). Does anyone know if this is in the extended parameter list, an extension, an API call, or whether I should write a hack of some sort?

Thanks, Jshorb 19:41, 11 March 2009 (UTC)


 * That isn't really possible with the UI. It is pretty easy with the API though. For example: action=query&prop=revisions&rvlimit=1&rvstart=20081201000000 for this page (rvstart takes the format YYYYMMDDHHMMSS). Gives you the top revision of the date specified. You can even get the revision with &rvprop=content. I used this feature to make w:en:User:Splarka/timetravel.js. Splarka 07:15, 12 March 2009 (UTC)


 * Thanks! That looks like an excellent tool which you wrote, and thanks for the helpful advice! Jshorb 21:17, 19 March 2009 (UTC)

action=credits: missing documentation
I am missing a documentation about this feature. I have found it on translatewiki.net, but I do not know, how I can activate it on a wiki. Anybody know anything about this? Thanks. Der Umherirrende 17:37, 29 May 2009 (UTC) See $wgActions = array(	'credits' => true,	'deletetrackback' => true,	'info' => true,	'markpatrolled' => true,	'purge' => true,	'revert' => true,	'revisiondelete' => true,	'rollback' => true,	'unwatch' => true,	'watch' => true, ); - by default this is true, on WMF mostly false. G.Hagedorn 14:51, 26 August 2011 (UTC)


 * Yes, by default its turned on, but WMF has the config line:  in CommonSettings.php which turns it off. Bawolff 13:49, 7 September 2011 (UTC)

Oddity with explicit action=view in provided examples
The wikipedia elephant example does not display its first image when there is an explicit action=view in the URL (e.g. from following the link on this page); but it does appear with action=render or when following the view link and then removing the action parameter.

Is there somewhere better I should mention this? It's not really a support question... --WeaverThree 17:36, 21 March 2010 (UTC)

&handheld=yes
Should the  option be mentioned in this article? Tisane 19:19, 11 April 2010 (UTC)

revisiondelete=
revisiondelete is a parameter too, right? E.g., http://libertapedia.org/w/index.php?title=User%3ATisane%2FTest55&action=historysubmit&revisiondelete=1&diff=24999&oldid=24998&ids[24998]=1 Tisane 04:35, 14 July 2010 (UTC)

On Url
How change URL ? 201.43.188.70 16:49, 5 September 2010 (UTC)

action=ajax deprecated
As far as I understand action=ajax deprecated is no longer recommended, and extension authors are encouraged to use api.php instead? Maybe the should be a note on that and a link to some other page, though I don't know which... rotsee 22:31, 22 January 2012 (UTC)

Preload if redlink
Is it possible to define (preferably on a link-by-link basis) that if a given link is a redlink, clicking it should do a defined preload? How can I accomplish this? 10:55, 14 February 2012 (EST)
 * I'm not sure whether preload actually preloads anything on an existing page, anyway see Help:Extension:ParserFunctions. Nemo 16:06, 14 February 2012 (UTC)
 * I don't think it will either, but if the page isn't a redlink I don't want to go straight to the edit link. Basically: * If page exists, go to * Else open edit screen with preload.  Thanks!
 * Just posted a workaround to this on the Preloading talk page: https://www.mediawiki.org/wiki/Manual_talk:Creating_pages_with_preloaded_text#FYI:_Use_redlink.3D1_with_preload_to_change_action_modes_if_the_page_exists
 * In brief, the query params need to be &action=edit&redlink=1&preload= . I don't know why it works, but it seems to. Don't use the section=new param, obviously--that's useful for a completely different scenario.
 * --SellaR 54.240.196.185 01:36, 5 December 2013 (UTC)

forcelinkupdate
seems to be an undocumented valueless parameter to accompany. See Manual talk:Purge. — Richardguk (talk) 04:39, 7 December 2012 (UTC)


 * Done. I've also documented the debug parameter. — Richardguk (talk) 02:27, 4 January 2013 (UTC)

action=raw
This section says For security reasons, in some versions of MediaWiki this is only allowed when using the "primary script access point". Where/how is this configured?

On a MediaWiki installation we have running (1.19.2), ?action=raw does not work for simple URLs and &action=raw does not work for index.php?title requests. More precisely, ?action=raw works from the browser but not from curl. Is there some variable to enable this or detect the caller? --DavidBiesack (talk) 16:16, 10 January 2013 (UTC)

spambots circumvent captcha?
Could spambots somehow create an account with Manual:Parameters_to_index.php, circumventing the captcha? Igottheconch (talk) 03:47, 31 May 2013 (UTC)

Any way to use parameters with wiki internal links (aka double-bracket links?)
I want to get the same behavior as this: Okra is good!

but be able to pass in query params like this: [https:// /index.php?action=edit&redlink=1&preload=Template:mytemplate/preload]

Yes the full URL works fine, but there are 2 downsides: --SellaR 54.240.196.185 01:51, 5 December 2013 (UTC)
 * the page displays the little padlock icon for every single link
 * full urls don't handle spaces like wiki links do, which is a problem when you want to use them in a variety of situations and autogeneration schemes. Thanks.


 * Creating a clean URL from an arbitrary page name can be done with the Magic Word  . Additonal unsafe parts of the query string (e.g. a page name for the parameter "preload=") can be encoded with.
 * To remove the little padlock without obtaining the matching tiny key, wrap the link in a span tag  with the CSS class "plainlinks".
 * All of the above and then some extra is rolled together in Template:AddNewSection.   -- Cat&#39;s paw (talk) 13:21, 24 July 2014 (UTC)

New section at top of page
Is it possible to create a new section (with section=new) that is at the top of the page? I'm trying to create a link that preloads a template at the top of the page. I have to have it create a new section or else the preload doesn't work. Thanks, Negative24 (talk) 20:35, 18 May 2014 (UTC)

Get article content with format
Hi!

I am trying to embed a wiki article without the navigation, sidebar, etc. on a different page. I am using HTML iframe to embed it and passing parameter.

The embeding works fine, but the result is not formated, since the original CSS is lost.

Is there any way to get the formated article content?

I have tried simply copping and pasting the sytlesheet links to my HTML from my blog (see below), but it didn't work.

  

Any thoughts?

Thanks in advance.

Need clarification if &amp;forcelinkupdate parameter under a purge action is valid under index.php or not
Background: Based upon the information given within the documentation for API:Purge's Parameters, there are two additional parameters that can be used in conjunction with &action=purge. They are reproduced here in... ... and it is understood the above applies only in the cases where  is the URL being used. It is also a given that a simple refresh of a file cache is primarily done by something akin to executing the following... Note the URL used is comprised of. The API.php "equivalent" (w/output) to the INDEX.php variant is... Note the plurality difference of the titles= parameter in the API.php example compared to INDEX.php example.
 * : If set, updates the link tables
 * : Like, but also do   on any page that transcludes the current page. This is akin to making an edit to a template. Note that the job queue is used for this operation, so there may be a slight delay when doing this for pages used a large number of times.
 * https://commons.wikimedia.org/w/index.php?action=purge&title=File:Example.jpg
 * https://commons.wikimedia.org/w/api.php?action=purge&titles=File:Example.jpg

Issue: I've come across a contradiction in the current relevant documentation so there seems to be some question when it comes to the actual valid application of the additional force... parameters associate with the purge action. Specifically between the following two Manual: excerpts...
 * Manual:Purge states:
 * An alternative way to update the links table is to use the API's purge module with the forcelinkupdate option. Note: This option only applies to the API. Adding forcelinkupdate to a .../w/index.php URL has no effect.


 * Manual:Parameters_to_index.php indicates:
 * that applying the forcelinkupdate parameter along with the "standard" &action=purge under a .../w/index.php? URL is valid and provides an example of that usage to prove it.

Question: What are the valid uses of the additional force... parameters in a purge action for API.php and INDEX.php? Please elaborate. Thanks in advance. -- George Orwell III (talk) 02:31, 5 December 2015 (UTC)


 * I've traced through the code to be certain, and contrary to what the page said,  does not support  . The only way to trigger a link update via index.php is a null edit. Someone was obviously confusing the two and apparently nobody noticed until now. Was there anything else you needed clarification on? – Robin Hood   (talk)  06:19, 5 December 2015 (UTC)


 * Thank you; I guessed that would be the answer but I had to double check anyway. Any idea if the either the 'null-edit' or the 'forcerecursivelinkupdate' bits in this gadget are viable companions to the "simple" purging of a file's cache? -- George Orwell III (talk) 10:06, 5 December 2015 (UTC)


 * I'm not entirely sure I understood your question, but a null edit would purge a file's cache, and either of the force... options in the API operate in addition to the normal purge procedure, so the normal purge of a file cache would take place no matter what, if a purge was run on a File-space page. – Robin Hood  (talk)  23:43, 5 December 2015 (UTC)

I don't know how familiar you are with Wikisource so let me back up and cover some basics first. In a nutshell, Wikisource takes a multipage source file hosted on Commons, standardizes the pagination & particulars of that source file in an Index: (ns-106 s:Index:Occupy Nashville v. Haslam.djvu) on Wikisource, invites interested folks to "work the index" by transcribing and proofreading the individual pages of said source file (ns-104 s:Page:Occupy_Nashville_v._Haslam.djvu/2 until all transcribing is validated which then allows all the individual pages to be transcluded to the main space as a single "finished" work Occupy Nashville v. Haslam (bad example; incomplete). If you ticked through all that and bothered to open an edit session here or there, you can see there is a lot of inter & intra linking and/or thumbnail [re]generation going on at given point in the process; all of it ultimately derived from that source file hosted on Commons to some degree or another. As you can imagine, things tend to go bad fairly quick if one thing or another isn't accurately queried or behaving as it should any given moment. For example: one reoccurring problem that Wikisource folks have is if the thumbnails being generated in the Page namespace on Wikisource are somehow out of synch with the actual source file on Commons; executing the "typical" purge action in the Page: namespace really isn't optimal since more often than not, the issue lies with the source on Commons and not on Wikisource. What causes things like that are ongoing mysteries for the most part - all we know is getting things right again is what matters to contributors. Generally, things get fixed by pulling off one of three possible "actions" under one or the other, if not both, projects (Wikisource &/or Commons). These are
 * 1) a simple purge of the File: cache.
 * 2) using the API to do a forcerecursivelinkupdate since that does the forcelinkupdate as well.
 * 3) performing a "null edit".

If I can manage to get those three actions to work with some per namespace specific detections added in as an easy to use gadgetized enhancement (s:MediaWiki:Gadget-PurgeTab.js), folks can go about troubleshooting issues themselves way before brining them to our Village Pump every few days or so. Their problems start with not knowing about this convoluted proofreading scheme and tend to give up after the all-too-familiar Wikipedia simple purge (#1). If they had an easy way to "remotely" execute #2 &/or #3 without having to "visit" Commons like you or I would, life would be sooo much easier on them. My problem is all this resource loader, module dependency, edit token, jQuery ajax, MediaWiki API, execute callback, error console stuff is kind of beyond my current skill set -- so here I am looking for guidance on how to reach that goal and learn something [hopefully] in the process. Better? -- George Orwell III (talk) 04:45, 6 December 2015 (UTC)


 * Well, I now understand the issues you're having, but unfortunately, you're asking questions that are beyond my skill set as well. – Robin Hood  (talk)  09:51, 6 December 2015 (UTC)


 * Thanks for your time & help anyway. It will all work itself out in a decade or two :) -- George Orwell III (talk) 10:43, 6 December 2015 (UTC)

Suggested edit: dir=prev
Example: https://en.wikipedia.org/w/index.php?title=Special:Contributions&dir=prev&offset=20100304022135&limit=13&contribs=user&target=Atlgirl052005 Monmouth Bison (talk) 21:22, 1 May 2017 (UTC)

default action when not set is view ??
On 1.27 I get a default action of "read"?? — Preceding unsigned comment added by Sen-Sai (talk • contribs) 09:00, 9 October 2017 (UTC)
 * Can you be a bit more specific? On which wiki? How do you get the action? (It’s in the HTML code somewhere? You use JavaScript? Or some PHP function? Where/what exactly?) --Tacsipacsi (talk) 14:15, 9 October 2017 (UTC)

How to delete history
I look for a possibility to delete all history entries except the last 5 changes for all pages. Who knows the paramters ? --Manbu (talk) 18:49, 16 November 2019 (UTC)
 * There are no such parameters. MediaWiki aims for openness, so altering page history is not officially supported. It can be worked around by deleting the page and restoring specific revisions, but this can lead to unexpected results like the size differences shown on history page being different from the real size differences, or irrelevant edit summaries. —Tacsipacsi (talk) 09:34, 17 November 2019 (UTC)

Listing UrlShortener parameter
Why is listing UrlShortener so important? There are 342 special page extensions, all of which have one or more special pages, usually with parameters. Even though this page is admittedly incomplete, it doesn’t mean that such sub-topics should be started here that are even more incomplete and almost inpossible to complete. If all extension special page parameters would be documented here, the page would become incredibly long, and full of details irrelevant for most people (extensions are only installed on some wikis, so users of other wikis will find them useless). If you really want to create documentation, it probably has better place on the extension’s own page; maybe FlaggedRevs should be removed from here as well. —Tacsipacsi (talk) 23:57, 9 July 2020 (UTC)
 * Hi, In retrospect, I agree with you that the info does not really belong here. But with that same reason you gave, I believe FlaggedRevs should also not stay here?. It's not better than any extension and every extension is different in its own way. Sorry, I should have started this discussion, but I am fine for you or anyone to remove it now. I will add the doc in the extension's page where it fits better. Ammarpad (talk) 11:47, 10 July 2020 (UTC)