User Details
- User Since
- Jan 7 2020, 11:30 AM (123 w, 4 d)
- Availability
- Available
- LDAP User
- Unknown
- MediaWiki User
- DAlangi (WMF) [ Global Accounts ]
Thu, May 19
Wed, May 18
Mon, May 16
@daniel, can this be resolved or is there something more to do here?
Wed, May 11
With the sticky header in Vector2022 and sticky header in a sortable wikitable and a new patch applied, we now get.
With @daniel's patch applied to Vector2010, here's a sample output
Fri, May 6
Thu, Apr 28
I think the tombstone mechanism is feasibly correct to solve this problem but the only query I have in mind with this mechanism is the complexity it introduces and amount of extra overheads involved. I don't want to worry much about the extra memory we'll use the store the tomestone session data (maybe we want to invalidate it after a period of time?).
Wed, Apr 27
Mon, Apr 25
@Krinkle, this is still happening, I've made a patch to emit warnings & log in production. Let me know if that is enough to investigate the issue.
Now making > 3 months. Also, coming from @Nikerabbit which the issue seemed to have happened on TW, it can be resolved. Please reopen if I'm wrong.
Per CS (https://codesearch.wmcloud.org/search/?q=Http%3A%3A&i=nope&files=&excludeFiles=&repos=), we've got some WMF deployed extensions before this class goes away
Sun, Apr 24
Dec 20 2021
Role user account created on Meta-Wiki: https://meta.wikimedia.org/wiki/User:Chapthorgs
After filling the form and submitting (locally to test how it works), below is what I get
This is what I currently have locally
Dec 9 2021
Dec 8 2021
Dec 6 2021
Dec 2 2021
Was done in this patch @Jdforrester-WMF - https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Collection/+/730621. So this can be resolved.
Yes @Ladsgroup, please it needs some public notice. Thank you for the final removal patch. I'll leave you to resolve this once the notice goes out. :)
Done!
Dec 1 2021
In addition, it looks like finalize() will just be similar to what ExtensionRegistry::finish() does? I just want to know if we'll be doing ->finalize() instead of unset() @Pchelolo?
I see that in Setup.php, once all settings have been loaded, the $wgSettings container is destroyed completely. Do we still need the finalize() method or will that method be replacing what unset() is doing?
Nov 30 2021
Nov 25 2021
Nov 17 2021
The rework of the landing page covers this. See: https://meta.wikimedia.org/wiki/Wikimedia_Affiliates_Data_Portal.
The rework of the landing page covers this. See: https://meta.wikimedia.org/wiki/Wikimedia_Affiliates_Data_Portal.
Nov 3 2021
Oct 29 2021
Code now removed! Thanks!
Oct 27 2021
Let's see if we'll see any more traces of this before resolving!
We're now in 1.38 of MediaWiki, should we begin to investigate and remove this or should we still wait?
Oct 6 2021
Sep 30 2021
@Pchelolo dropped a comment in the patch about the scope of this and there is some work happening in ContentHandler which will touch this so let's wait a little.
Sep 29 2021
@daniel, I'm thinking we should call the service AccessPageContent instead so it reads well on the first go. But we can also leave it as is but I just wanted to understand your inspiration behind the service name.