Last modified: 2012-10-16 01:06:28 UTC
I've run into this issue with $this->data['content_navigation']; see bug 40857. These functions should fill up all indices they might ever provide with nulls instead of leaving them undefined. Rationale: a) undefined values force the caller to check everything with isset(), which is butt-ugly. b) these values are not undefined; they are defined perfectly well, to be non-existent (or empty, or in other words null) for given page-view-user combination.
a) Skins should be using wfSuppressWarnings(); and wfRestoreWarnings(); to not have to worry about index warnings. b) No, they are undefined and there are multiple reasons these should not be null: - You will always have to consider the possibility that a key is undefined. Keys may be provided by an extension and the extension may not be defined. Or we may decide - For the most part keys in content_navigation, personal_urls, etc... are NOT supposed to be addressed explicitly. You are supposed to foreach over them. There can be any number of keys that you don't know about. New ones we introduced and ones added by extensions. The only time you should be directly addressing keys inside of these arrays is if you are outputting a single one somewhere else, unsetting it, and then foreaching over the rest. - Setting values to null as you suggest will actively break existing skins. The desired standard is to foreach over these arrays. And setting things to null will causing skins to start outputting dead list items and cause some of them to completely break as they receive null where they were supposed to be given link data. Since changing this will actually break things, I'm marking this WONTFIX.
