Do we need to trigger a re-render of the catlinks div? Can we?
Version: unspecified
Severity: normal
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52403
Do we need to trigger a re-render of the catlinks div? Can we?
Version: unspecified
Severity: normal
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52403
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Invalid | Jdforrester-WMF | T50426 VisualEditor: Pre-beta needs (tracker) | |||
Resolved | Esanders | T50560 VisualEditor: Category changing in page doesn't cause footer to be updated on save |
It depends on what we get back from the server.
If we get back something that is compatible with what api.php?action=parse gives (prop.categorieshtml, from Skin::getCategories), which is what live preview in core uses as well, then we can just update it by replacing the old with the new html.
If we can't get that, we'll have to re-implement Skin::getCategories in javascript. However I'd like to avoid that since it is skin-specific (skins can do all kinds of weird stuff to it, hard to predict. Ideally this would fall under the parts of the page output (like mw-content-text, htmlhead and script loader) that has a fixed html layout that skins can't alter the html itself of (it has enough css hooks to style anyway they like, they shouldn't need to modify the html). But that's not the reality.
Oh wait, this isn't from the server (not MediaWiki, not Parsoid). I mean, it shouldn't. This is reflected live when editing the document. We'll have to do it in javascript somehow I'm afraid.
Note that the categories on the page are not refreshed even after multiple VE sessions. i.e. VE add category -> save -> VE add category -> save : results in a page that _displays_ only the categories at the beginning of the process.
Categories added via templates are also not displayed.
Change 107036 had a related patch set uploaded by Esanders:
Update categories HTML on page save