(In reply to comment #0)

(Note the way we enable Flow on a page is likely to change; editing PHP
config
files doesn't scale.)

Is there a bug / discussion somewhere discussing this? The pageprops module that LQT uses just pulls from the page_props table, which is what I think Flow should use as well. If we decide to go down that route, a custom API module won't be needed, it'll just work™.

(In reply to comment #1)

(In reply to comment #0)

(Note the way we enable Flow on a page is likely to change; editing PHP
config
files doesn't scale.)

Is there a bug / discussion somewhere discussing this?

Not to my knowledge; it's one of those things where it's dependent on how we want to go about deploying it more widely (not: how we do that technically, but how we do that from a community perspective), and so it's on the back-burner until Flow itself just works™. I invite you to start up a thread on the E2 list, though, because it's a conversation we keep having in fits and starts and never quite finishing.

While page_props would be workable, I would lean towards having a "prop=flow" query module that would also allow for returning other flow data related to the page. Unless there is no flow data you can usefully fetch by passing a page title?

e.g. api.php?format=jsonfm&action=query&titles=Foo|Talk:Foo&prop=flow might return something like this:

{

"query": {
    "pages": {
        "12345": {
            "pageid": 12345,
            "ns": 0,
            "title": "Foo"
        },
        "12346": {
            "pageid": 12346,
            "ns": 1,
            "title": "Talk:Foo",
            "flow": {
                   "enabled": true
            }
        }
    }
}

}

Change 111255 had a related patch set uploaded by Legoktm:
API: Add prop=flow to detect if Flow is enabled on a page

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

Change 111255 merged by jenkins-bot:
API: Add prop=flowinfo to detect if Flow is enabled on a page

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