Change Details

The section indexes returned by the parse API when the section parameter is set, in both the `sections` array and the edit links, start at 1 instead of the section index, causing the edit links to open the wrong section. For example, the API call https://en.wikipedia.org/w/api.php?action=parse&format=json&page=Toronto&prop=text%7Csections&section=9 starts the edit links at 1 and the indexes in the `sections` array at 1 when they should start at 9. The issue has to do with the sectionindex stored in the Parser::mHeadings array. Also to note is that if a section that starts with `T-` is passed, the sections in `<noinclude>` tags before it need to be accounted for because simply returning `T-` prefixed section indexes won't work since the API still returns sections that are in `<noinclude>` tags.

The section indexes returned by the parse API when the section parameter is set, in both the `sections` array and the edit links, start at 1 instead of the section index, causing the edit links to open the wrong section. For example, the API call https://en.wikipedia.org/w/api.php?action=parse&page=Toronto&prop=text%7Csections&section=9 starts the edit links at 1 and the indexes in the `sections` array at 1 when they should start at 9. The issue has to do with the sectionindex stored in the Parser::mHeadings array. Also to note is that if a section that starts with `T-` is passed, the sections in `<noinclude>` tags before it need to be accounted for because simply returning `T-` prefixed section indexes won't work since the API still returns sections that are in `<noinclude>` tags.

The section indexes returned by the parse API when the section parameter is set, in both the `sections` array and the edit links, start at 1 instead of the section index, causing the edit links to open the wrong section. For example, the API call https://en.wikipedia.org/w/api.php?action=parse&format=json&page=Toronto&prop=text%7Csections&section=9 starts the edit links at 1 and the indexes in the `sections` array at 1 when they should start at 9. The issue has to do with the sectionindex stored in the Parser::mHeadings array. Also to note is that if a section that starts with `T-` is passed, the sections in `<noinclude>` tags before it need to be accounted for because simply returning `T-` prefixed section indexes won't work since the API still returns sections that are in `<noinclude>` tags.