Page MenuHomePhabricator

pageAssessments property of Lua mw.title objects should index assessments by project
Closed, ResolvedPublic

Description

After T380122, mw.title objects now have the pageAssessments property. These come as a Lua table indexed by number; however, this is an unexpected behavior different from the MediaWiki web service API, which indexes assessments by project name.

What happens?:
Run the following in the Wikipedia Lua debug console:

mw.logObject(mw.title.new("Apple").pageAssessments)

Returns:

table#1 {
    table#2 {
        ["class"] = "GA",
        ["importance"] = "High",
        ["name"] = "Agriculture",
    },
    table#3 {
        ["class"] = "GA",
        ["importance"] = "Top",
        ["name"] = "Food and drink",
    },
    table#4 {
        ["class"] = "GA",
        ["importance"] = "High",
        ["name"] = "Plants",
    },
    table#5 {
        ["class"] = "GA",
        ["importance"] = "",
        ["name"] = "Project-independent assessment",
    },
}

How the MediaWiki web service API handles this:
The following API query:

action=query&format=json&prop=pageassessments&titles=Apple&formatversion=2&pasubprojects=1

Returns:

"title": "Apple",
"pageassessments": {
    "Plants": {
        "class": "GA",
        "importance": "High"
    },
    "Food and drink": {
        "class": "GA",
        "importance": "Top"
    },
    "Agriculture": {
        "class": "GA",
        "importance": "High"
    },
    "Project-independent assessment": {
        "class": "GA",
        "importance": ""
    }
}

What should have happened instead?:
To allow Lua modules to programmatically retrieve specific assessments and meet feature parity with the web service API, the pageAssessments table should index by assessment, where:

mw.logObject(mw.title.new("Apple").pageAssessments)

Should return something like:

table#1 {
    ["Agriculture"] = {
        ["class"] = "GA",
        ["importance"] = "High",
    },
    ["Food and drink"] = {
        ["class"] = "GA",
        ["importance"] = "Top",
    },
    ["Plants"] = {
        ["class"] = "GA",
        ["importance"] = "High",
    },
    ["Project-independent assessment"] = {
        ["class"] = "GA",
        ["importance"] = "",
    },
}

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript
SD0001 changed the subtype of this task from "Bug Report" to "Task".EditedJun 8 2025, 6:47 AM
SD0001 subscribed.

Why would you expect the API and Lua interface to use an identical format? Not keying by project name and using a sorted array was chosen for Lua to provide a greater stability in the parser output, which is not much a consideration for the API.

Why would you expect the API and Lua interface to use an identical format?

Given that both the HTTP API and Lua API access the same backend data structure, I'd expect them to present said data in the same way. Regardless, indexing by name allows for constructs like

mw.title.new(pageName).pageAssessments[projectName]["class"]

which is much simpler and less computationally intensive than iterating over the contents of every table to find a given project's assessment.

Plus, anecdotally it is much more common to just want the project-independent assessment. One example is the proposal to display FA or GA status in the article tagline.

Should I just go ahead and do this? It requires changing the output format of PageAssessmentsStore::getAllAssessments(), which I also want to do for T374761: PageAssessments should specify WikiProjects as config variable.

There are but a few uses of this in the wild https://global-search.toolforge.org/?q=%22pageAssessments%22&namespaces=828&title=

I'm going to move forward with this, and we can fix the existing callers manually.

MusikAnimal changed the task status from Open to In Progress.May 5 2026, 1:28 PM
MusikAnimal claimed this task.
MusikAnimal renamed this task from pageAssessments property of mw.title objects should index elements by assessment to pageAssessments property of Lua mw.title objects should index assessments by project.May 5 2026, 2:45 PM

Change #1283019 had a related patch set uploaded (by MusikAnimal; author: MusikAnimal):

[mediawiki/extensions/PageAssessments@master] PageAssessmentsStore: make ::getAllAssessments() keyed by project

https://gerrit.wikimedia.org/r/1283019

Change #1283031 had a related patch set uploaded (by MusikAnimal; author: MusikAnimal):

[integration/config@master] Zuul: add Scribunto as a dependency of PageAssessments

https://gerrit.wikimedia.org/r/1283031

Change #1283031 merged by jenkins-bot:

[integration/config@master] Zuul: [mediawiki/extensions/PageAssessments] Add Scribunto dependency

https://gerrit.wikimedia.org/r/1283031

Mentioned in SAL (#wikimedia-releng) [2026-05-05T19:01:29Z] <James_F> Zuul: [mediawiki/extensions/PageAssessments] Add Scribunto dependency, for T396135

Change #1283019 merged by jenkins-bot:

[mediawiki/extensions/PageAssessments@master] PageAssessmentsStore: make ::getAllAssessments() keyed by project

https://gerrit.wikimedia.org/r/1283019

Thanks for the review!

I may need help fixing the existing callers. I will attempt to fix testwiki:Module:Page assessment raw when wmf.6 lands tomorrow.

The testwiki module was pretty simple to fix. It looks like the only other callers are on group2, so I will update them Thursday.

This may have caused T428962: TypeError: MediaWiki\Extension\PageAssessments\PageAssessmentsStore::cleanProjectTitle(): Argument #1 ($project) must be of type string, int given

That it did, and since has been resolved (with some follow-up work to come after). I'll resolve this task and the follow-up can be part of T428962.