Manuel Vacelet (vaceletm)2024-01-16 11:53Status changed from New to ClosedClose date set to 2024-01-16
Thomas Gerbet (tgerbet)2023-06-15 14:46 I'll submit a patch to change this to the newer $wgParserCacheType. Thanks for the hint, I will do it. It is easy enough ;)
Robert Vogel (rvogel)2023-06-15 14:41 Further things to test: Append ?action=raw to the URL to see the wikitext of the page, rather than the parsed HTML Clear browser cache, especially LocalStorage, to see if maybe the "autosave" feature of VisualEditor is the cause
Robert Vogel (rvogel)2023-06-15 14:37 last edited by: Robert Vogel (rvogel) 2023-06-15 14:37 So it looks like we have already disabled the ParserCache in plugins/mediawiki/www/LocalSettings.php:175, but it is done by using $wgEnableParserCache which has been removed in 1.35. I'll submit a patch to change this to the newer $wgParserCacheType. The default parser cache backend (when MainCacheType is left to CACHE_NONE) is effectively CACHE_DB (SqlBagOStuff). -- https://www.mediawiki.org/wiki/Manual:$wgParserCacheType
Manuel Vacelet (vaceletm)2023-06-14 17:10 I don't know how to reproduce the issue, it happened several time and seems like a cache issue like the content of editor and/or page not being properly refreshed either at load or save.
Miriam Schlindwein (mschlindwein)2023-06-14 16:01 I tested the described behaviour: I had 2 users editing and saving the same page in multiple combinations also without reloading the page when entering edit mode and could not recreate this. Sometimes I got a popup window which asked if the user 1 wanted to resume his edit or start a new one. If I selected "resume" - then changes from user 2 where missing -> but this is expected behaviour. If user 1 started a new edit then everything was there.