daniel added a comment.
In T240083#5732326 <https://phabricator.wikimedia.org/T240083#5732326>, @Anomie wrote: >> `User::saveSettings` is calling `Title::purgeSquid`. It is undocumented why changing preferences requires purging the user page, unconditionally, synchronously. > > It was added in r42179 <http://mediawiki.org/wiki/Special:Code/MediaWiki/42179> with reference to T3306: Suppress the "email this user" link in the toolbox if said user has opted not to/can't receive emails <https://phabricator.wikimedia.org/T3306>. It seems the purge is intended to update the state of the "Email user" link when the associated preference is changed. "Email user" isn't shown for anonymous visitors, right? So it's not in the web cache, so purgeSquid() isn't needed. Never was, as far as I understand... > But the speculation about purging for gender changes might now be another use case requiring such a purge. That may indeed be needed, but shouldn't have anything to do with purging web caches. > In T240083#5731759 <https://phabricator.wikimedia.org/T240083#5731759>, @daniel wrote: > >> There are several places where this chain could potentially be cut, but I didn't find a trivial once at a first glance. > > `ContentHandler::getPageLanguage()` probably shouldn't depend on the request in the first place. If the content is really in multiple languages somehow such that it can be displayed in the user's UI language, that should probably be indicated directly for the caller to deal with (if it cares) instead of returning the current user's UI language. As it is, this particular use case (`getCdnUrls`) is broken because it won't be returning every possible URL, only those corresponding to the current user's UI language. But changing all that would probably be a large project. Yes, the concept of page languages as currently implemented is broken. When I created ContentHandler, I tried to keep the existing behavior, baking the existing confusion into the interface of ContentHandler. Would have been better to fix it. > It's already deferring the actual update, you'd just have to somehow move the call to $this->getCdnUrls() to when the update runs instead of when it's constructed. Or make the list of URLs not depend on the user. As you point out, that doesn't make any sense, that list of URLs should depend solely on the title. >> Also, why is autoCreateUser() triggered before setup is complete? > > Part of setup is determining the User making the request. If that User doesn't exist locally yet, it has to be auto-created to have it available to finish the setup. Could that be deferred until the point where the User object would usually be initialized from the session? TASK DETAIL https://phabricator.wikimedia.org/T240083 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: Anomie, daniel, Ladsgroup, Addshore, Nikerabbit, Krinkle, Aklapper, Iflorez, darthmon_wmde, WDoranWMF, alaa_wmde, holger.knust, EvanProdromou, DannyS712, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Agabi10, Taiwania_Justo, Scott_WUaS, Pchelolo, Jonas, Wikidata-bugs, aude, Amire80, Lydia_Pintscher, Arrbee, santhosh, KartikMistry, Jdforrester-WMF, Mbch331, Rxy, Jay8g, Krenair
_______________________________________________ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
