Page MenuHomePhabricator

Only on meta, "action=edit&prefix=foo" redirects to [[meta:Main_Page]] (as the site's main page is a special page)
Open, HighPublic


The Project Grants space on Meta is experiencing a significantly impactful issue with the tabs structure, which is how grantees create reports and complete other important grant process tasks. Grantees are currently not able to generate pages normally because the buttons aren't working. Instead of creating a page at the designated place, the buttons are directing editors to edit the Main Page on Meta-wiki. The Main Page can only be edited by administrators on Meta, and so a message pops up accordingly, and this is creating confusion for grantees. At present, Chris Schilling is manually creating the pages and putting them where they are supposed to go. None of us on the Community Resources Team is able to fix this problem, and we're hoping that someone with more technical expertise than we have might be able to help us fix the buttons.

Chris Schilling (who has been trying unsuccessfully to fix the buttons) says his best guess is that there is an issue with the template pages for the buttons that generate the pages:

He has looked through these and compared them to other buttons we used in Rapid Grants (that are working as expected) to see if there is any obvious difference, but he wasn't able to identify any issues.

Chris thinks another possibility is that there is something wrong with the complicated wiki markup on the Project Grant Tabs template.

We are hoping that someone with more technical training than we have could help us try to fix this problem.

Background that may or may not be helpful: The Project Grants space on Meta uses a complex system of tabs, templates, etc that were originally designed by Jonathan Morgan, Heather Walls, and Siko Bouterse for the Individual Engagement Grants program many years ago. Though nobody on the Community Resources team now fully understands the system, Chris Schilling has gotten the farthest in trying to make sense of the system and has the best understanding of the documentation that exists, as well as the current bug.

Event Timeline

Hi, could you please include a full list of steps that someone would have to perform to reproduce this situation (including links that other people could use), what is expected to happen (including the full URL that you'd expect to end up on), and what happens instead (see )? Thanks! :)

Ah, I think I understand the problem. This seems to be meta specific (cannot reproduce on with the same account permissions).

  1. Go to
  2. Paste the following input:
  1. Press Show Preview
  2. Click Whatever button
  3. Get redirected to main page (unexpected)
  4. Go to
  5. Repeat steps 2-4
  6. End up instead on (expected)
Aklapper renamed this task from Project Grants tabs on Meta are malfunctioning, interrupting grantee reporting efforts and other important grants processes to Using <inputbox> on meta to create a new subpage redirects to main page (works as expected on 25 2020, 1:21 AM
Aklapper renamed this task from Using <inputbox> on meta to create a new subpage redirects to main page (works as expected on to "action=edit&prefix=foo" on meta redirects to [[meta:Main_Page]] (works as expected on where it allows creating a new page).Nov 25 2020, 1:29 PM

@Aklapper Thank you so much for your help with this, including guidance about what information to include. It seems like you were able to determine and describe the problem and how to replicate it. Is there still information you need from me about that at this point? @I_JethroBT has a better understanding of the issue than I do, so I'm including him in case he wants to add anything.

I'd recommend to go on IRC and ask in #wikimedia-tech and/or #mediawiki-dev if someone has an idea and could take a look at this issue.
Maybe someone will also stumble upon this ticket itself, but WMF-General-or-Unknown is a quite broad project tag.

I myself don't need more info and I'm afraid I cannot help further. :-/

@Aklapper I think I understand now that you are just here to generously help me out with making this ticket functional. Thank you! I appreciate it. I just sent a message to #wikimedia-dev using Element. Thanks for that tip. Helpful.

Adding the inputbox extension tag here, as I suspect it is centrally involved with the unexpected behavior described.

Also see T269230: Inputbox with option type=comment produces pages in main namespace which is about a very different parameter but has a similar outcome (ending up in the top-level mainspace).

KEchavarriqueen added a subscriber: KEchavarriqueen.

Hello All - I am hoping that I can flag this as a high priority issue for the team. It was flagged three weeks ago. We will soon be starting a round and this impacts the communities ability and experience while they are applying for grants. It would be great to get an update on this ticket and if there is an estimated resolution date.
Thank you! Kassia

@KEchavarriqueen: You can do so (and it's likely correct), but note that changing the Priority field will not automagically change anything (fields summarize and reflect reality and do not cause it). See T268696#6649137 how I'd recommend to get attention of some developers if you want to see this closer to getting fixed.

Or to be more explicit: Creating a ticket here (if that is meant by "flagging"?) does not necessarily mean that some developer will decide to take a look and investigate. As far as I know nobody is looking into this, hence no updates or dates. (Please see also Development prioritization for general info - thanks.)

Furthermore, the InputBox extension (if that's the culprit) currently has no code stewards/maintainers.

Daimona added a subscriber: Daimona.

I was also annoyed by this issue so I went ahead and investigated. For starters, I cannot reproduce it locally, where I get the same result as on

Second, handling the "prefix" parameter happens inside InputBox, specifically within the onMediaWikiPerformAction handler, which looks fairly simple. There are three things that could cause the hook to fail:

  1. If the current action is not "edit". Although we're correctly passing action=edit, MediaWiki::getAction() has some additional logic, so it's still remotely possible that something's broken there, but for now I'm going to assume that this is not the cause.
  2. If the "prefix" parameter is not passed. This is certainly not the case.
  3. If the OutputPage::redirect() call doesn't work for some reason. This would require some investigation.

I should also note that no redirect happens at all, apparently. The code is supposed to return a 301 status code, but:

$  curl -Is '' -w "%{http_code}" -o /dev/null

Also, since it happens for meta but not other wikis, it might have to do with site config, or custom hook handlers. In general, this isn't easy to investigate given the local non-reproducibility.

I've also tried the corresponding URL on various WMF projects (a few wikis, + commons, +species, +wikiquote), and for all of them, it works. For instance:

$  curl -Is '' -w "%{http_code}" -o /dev/null

There's something special for meta going on, but I don't know what exactly. We might need to check custom hook handlers, and possibly live-hack a prod server (or at least run a REPL there), because I really have no idea as to what makes meta special.

This is a very interesting bug. I was playing with var_dump at mwdebug1001. This is my new version of the hook in inputbox i used for testing:

public static function onMediaWikiPerformAction(
) {
        if ( $wiki->getAction() !== 'edit' && $request->getText( 'veaction' ) !== 'edit' ) {
                // not our problem
                return true;
        $mainReq = RequestContext::getMain()->getRequest();
                'mainReqFoo' => $mainReq->getText( 'foo', 'bar' ),
                'passedReqFoo' => $request->getText( 'foo', 'bar' ),
                'prefixMain' => $mainReq->getText( 'prefix', 'bar' ),
                'passedReqPrefix' => $request->getText( 'prefix', 'bar' ),
                'valuesPassedReq' => $request->getValues(),
                'valuesMainReq' => $mainReq->getValues(),
        if ( $request->getText( 'prefix', '' ) === '' ) {
                // Fine
                return true;

        $title = $request->getText( 'prefix', '' ) . $request->getText( 'title', '' );
        $params = $request->getValues();
        unset( $params['prefix'] );
        $params['title'] = $title;

        global $wgScript;
        $output->redirect( wfAppendQuery( $wgScript, $params ), '301' );
        return false;

And this is what I got with curl:

urbanecm@notebook  ~
$ curl --silent -H 'X-Wikimedia-Debug: backend=mwdebug1001.eqiad.wmnet' '' | head -n 20
array(6) {
  string(3) "bar"
  string(3) "bar"
  string(3) "bar"
  string(3) "bar"
  array(1) {
    string(4) "edit"
  array(1) {
    string(4) "edit"
urbanecm@notebook  ~

Something has eaten the GET parameters, causing the hook to think it was not set at all. Why?

According to my further tests, $_GET is in correct state. Something in our request classes ignores parameters.

With the help of eval.php on metawiki, I finally understood what's going on and why it's basically only reproducible on metawiki.

The code in the main MediaWiki class will determine the title of the current request before running the PerformAction hook, which makes sense. At a quick glance, it seems to me that the relevant logic is duplicated in several places, but that's unrelated. Since our request has no known title-related parameter (e.g. "title", "oldid", "diff" etc.), it will fallback to the main page. This also makes sense.

Now, let's put the above statements aside for a minute, and let's go inside performRequest(). This method also does some title normalization, but it doesn't affect our case, and $title is still the main page. Then it has a block for handling redirects, title-less URLs etc., introduced by

elseif ( !$this->tryNormaliseRedirect( $title ) ) {

which is always entered in our example, for all wikis (because action=edit will make tryNormaliseRedirect return false). It then checks whether the title is a redirecting special page, and if it is, it will override the main Request object with a DerivativeRequest. While I didn't realize it the other day, it's now clear that DerivativeRequest can discard GET and POST data (see class doc); I was confused by the WebRequest parameter, which is however partially ignored. Since this DerivativeRequest is created with ad-hoc query data (in particular, the data provided by the aforementioned special page), it does indeed lose the GET params. This gets passed to the hook, which doesn't find the "prefix" parameter, and everything fails.

A similar scenario was already on my mind, and perhaps yours, since I started investigating this bug. However, if you followed me above, you might be thinking (at least I was): "but that can only happen if the title is a special page, and we said the code was using the main page". But as you might have guessed by now, especially with you're familiar with meta, here is the crux, and the reason why this issue is only reproducible on meta: the main page there is Special:MyLanguage/Main Page! :)

I'm currently working on a solution.

Change 668697 had a related patch set uploaded (by Daimona Eaytoy; owner: Daimona Eaytoy):
[mediawiki/extensions/InputBox@master] Process the "prefix" query param in onBeforeInitialize

Aklapper renamed this task from "action=edit&prefix=foo" on meta redirects to [[meta:Main_Page]] (works as expected on where it allows creating a new page) to Only on meta, "action=edit&prefix=foo" redirects to [[meta:Main_Page]] (as the site's main page is a special page).Mar 5 2021, 3:15 PM
Aklapper awarded a token.

Change 668697 abandoned by Daimona Eaytoy:

[mediawiki/extensions/InputBox@master] Process the \"prefix\" query param in onBeforeInitialize


Doesn't seem to work.