Page MenuHomePhabricator

add redirect target value on page info (ApiQueryInfo)
Open, LowPublicFeature

Description

It would be nice to get the redirect target as info from api when querying a redirect page.

At the current wmf live version you have to parse the page content for getting the correct redirect target. That should be unnecessary in future because of T30952.
But you still have to make two api requests (without and with redirect-Parameter) if you are also interested in informations about the redirect page. (E.g. if it's a staticredirect using page=pageprops).

It would be much easier if the redirect target information is also included in the page information when querying a page that is a redirect.

My suggestion would be that prop=info should contain this information in its redirect value. At the moment redirect="" is returned. This could be changed to redirect="iw:targetpage#anker", a combination of interwiki, fulltitle and fragment (splitting is not needed).

This shouldn't break existing tools because at the moment only the existence of this redirect attribute is tested and the value is ignored.


Version: unspecified
Severity: enhancement

Details

Reference
bz29115

Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 11:28 PM
bzimport set Reference to bz29115.
bzimport added a subscriber: Unknown Object (MLST).

Because of the extra query (and possibly parsing the redirect if there is no entry in the table) required, this should be an optional inprop that's disabled by default.

Extra option is ok, but this extra query must only be executed if $this->pageIsRedir is true.

No idea, why this change causes OOM

Have you more information?
Which query was used

  • the new prop=info&inprop=redirecttargets
  • or existing &redirects of action=query

because both sharing code here.

(In reply to comment #6)

No idea, why this change causes OOM

Have you more information?
Which query was used

  • the new prop=info&inprop=redirecttargets
  • or existing &redirects of action=query

because both sharing code here.

We don't have a url...

<binasher> Dec 12 21:44:38 10.0.2.218 apache2[9189]: PHP Stack trace:
<binasher> Dec 12 21:44:38 10.0.2.218 apache2[9189]: PHP 1. {main}() /usr/local/apache/common-local/live-1.5/api.php:0
<binasher> Dec 12 21:44:38 10.0.2.218 apache2[9189]: PHP 2. require() /usr/local/apache/common-local/live-1.5/api.php:3
<binasher> Dec 12 21:44:38 10.0.2.218 apache2[9189]: PHP 3. ApiMain->execute() /usr/local/apache/common-local/php-1.21wmf6/api.php:77
<binasher> Dec 12 21:44:38 10.0.2.218 apache2[9189]: PHP 4. ApiMain->executeActionWithErrorHandling() /usr/local/apache/common-local/php-1.21wmf6/includes/api/ApiMain.php:349
<binasher> Dec 12 21:44:38 10.0.2.218 apache2[9189]: PHP 5. ApiMain->executeAction() /usr/local/apache/common-local/php-1.21wmf6/includes/api/ApiMain.php:372
<binasher> Dec 12 21:44:38 10.0.2.218 apache2[9189]: PHP 6. ApiQuery->execute() /usr/local/apache/common-local/php-1.21wmf6/includes/api/ApiMain.php:825
<binasher> Dec 12 21:44:38 10.0.2.218 apache2[9189]: PHP 7. ApiPageSet->execute() /usr/local/apache/common-local/php-1.21wmf6/includes/api/ApiQuery.php:312
<binasher> Dec 12 21:44:38 10.0.2.218 apache2[9189]: PHP 8. ApiPageSet->initFromTitles($titles = array (0 => 'File:Canadian Land Forces Command Badge.svg')) /usr/local/apache/common-local/php-1.21wmf6/includes/api/ApiPageSet.php:303
<binasher> Dec 12 21:44:38 10.0.2.218 apache2[9189]: PHP 9. ApiPageSet->resolvePendingRedirects() /usr/local/apache/common-local/php-1.21wmf6/includes/api/ApiPageSet.php:432
<binasher> Dec 12 21:44:38 10.0.2.218 apache2[9189]: PHP 10. ApiPageSet->getRedirectTargets() /usr/local/apache/common-local/php-1.21wmf6/includes/api/ApiPageSet.php:597
<binasher> Dec 12 21:44:38 10.0.2.218 apache2[9189]: PHP 11. ApiPageSet->resolveIdsToRedirectTargets($redirectIDs = array (0 => 16128102), $profileDB = 'profileDB') /usr/local/apache/common-local/php-1.21wmf6/includes/api/ApiPageSet.php:627
<binasher> Dec 12 21:44:38 10.0.2.218 apache2[9189]: PHP 12. Title::makeTitle($ns = '6', $title = 'Canadian_Army_Badge.svg', $fragment = '', $interwiki = '') /usr/local/apache/common-local/php-1.21wmf6/includes/api/ApiPageSet.php:682

In most cases, it was OOMing in the Title::makeTitle() call

  • Bug 50981 has been marked as a duplicate of this bug. ***

Would be great to be somehow able to reproduce the bug and get more details. Do we have a test/dev instance working against the commons DB?

Now a prop=redirects module exists (goes live with 1.23wmf16), which maybe can help here, because it shows all redirects to a page:

https://www.mediawiki.org/w/api.php?action=query&titles=MediaWiki&prop=redirects&rdlimit=100

You can also use it as a generator to get information about the redirects:

https://www.mediawiki.org/w/api.php?action=query&titles=MediaWiki&generator=redirects&grdlimit=100&prop=pageprops

It is also possible to use it with &redirects=

https://www.mediawiki.org/w/api.php?action=query&titles=Main%20Page&prop=redirects&rdlimit=100&redirects=

Using it with generator and redirects= looks not very helpful:

https://www.mediawiki.org/w/api.php?action=query&titles=Main%20Page&generator=redirects&grdlimit=100&redirects=&prop=pageprops

because the redirects also resolved for the titles of the generator and not only of the query action. Not sure, if that is a feature or not.

jayvdb set Security to None.

Reading through the history here, I'm a little confused why this task is still unresolved... we should either implement this feature again (this task can probably be marked good first task and picked up fairly quickly) or we should close this task.

Given Umherirrender's comment, it's not immediately clear to me whether this feature is still needed. However, once that decision has been made (@Anomie, @Catrope, or @Reedy, thoughts?), resolving this task one way or another should be pretty quick and painless, I think.

The feature would probably still be useful. You can get the target by
passing the titles to action=query&redirects=1 (no prop modules needed),
but it's a bit awkward if you're also wanting other info about the redirect
itself.

prop=redirects is "what redirects here", not "where does this redirect to".

The feature would probably still be useful. You can get the target by
passing the titles to action=query&redirects=1 (no prop modules needed),
but it's a bit awkward if you're also wanting other info about the redirect
itself.

Cool, thanks for the quick feedback.

As far as I know, a modernized version of the approach taken in https://gerrit.wikimedia.org/r/34977 would be fine here. I guess we just need to make sure there's decent test coverage surrounding files/SVGs or something (given the previous out-of-memory errors)?

I find this info useful as I do not need to parse the wikitext to see where an item redirects to (see T143200).

I think this functionality fits in the "info" [1] API. Something like a "redirecttitle" maybe?

https://en.wikipedia.org/w/api.php?action=help&modules=query%2Binfo

I think this functionality fits in the "info" [1] API. Something like a "redirecttitle" maybe?

https://en.wikipedia.org/w/api.php?action=query&titles=Main%20page&prop=info&redirects provides both info and the redirect target.
Am I misunderstanding something?

I think this functionality fits in the "info" [1] API. Something like a "redirecttitle" maybe?

https://en.wikipedia.org/w/api.php?action=query&titles=Main%20page&prop=info&redirects provides both info and the redirect target.
Am I misunderstanding something?

It provides info for the target of the redirect rather than the redirect itself.

For a slightly clearer example, https://en.wikipedia.org/w/api.php?action=query&titles=Foo&prop=info&redirects provides info about the target page (Foobar) rather than info about the redirect Foo.

Aklapper changed the subtype of this task from "Task" to "Feature Request".Feb 4 2022, 11:00 AM