Last modified: 2014-05-21 13:53:39 UTC
Do we need to trigger a re-render of the catlinks div? Can we?
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.
*** Bug 50072 has been marked as a duplicate of this bug. ***
*** Bug 50737 has been marked as a duplicate of this bug. ***
*** Bug 56683 has been marked as a duplicate of this bug. ***
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.
*** Bug 57924 has been marked as a duplicate of this bug. ***
Change 107036 had a related patch set uploaded by Esanders: Update categories HTML on page save https://gerrit.wikimedia.org/r/107036
Change 107036 merged by jenkins-bot: Update categories HTML on page save https://gerrit.wikimedia.org/r/107036
Verified the fix on test 2
