@daniel, can this be resolved or is there something more to do here?

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

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?).

@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

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

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!

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?

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.

Code now removed! Thanks!

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?

@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.

@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.