- Blog: https://timotijhof.net
- Mastodon: @krinkle
(Photo by Niek Hidding.)
(Photo by Niek Hidding.)
Can you be more specific about what you'd like to be able to capture?
In T366517#9997164, @Jdlrobson wrote:[…] we've been telling editors that this should only be a problem for 24hrs.
Oops, I did indeed intend for that, and did indeed forget to add that.
This issue may serve as data point to reconsider T190083. If I understand correctly, the reason plwiki is moving in this direction is because there is no mechanism other than a hidden/default/styles-only gadget to reliably and performantly add a (small, reasonable) CSS on a wiki site-wide. Keeping in mind that it is explicitly less performant to use TemplateStyles for things that a majority of pages need, since that would need to be redownloaded with every article instead of leveraging browser cache.
I suggest @Hokwelum and I pair on this as part of https://www.mediawiki.org/wiki/User:Krinkle/MediaWiki_Introduction_2023#Part_3 to familiarize with how extensions create schemas via the schema hook. This will also serve as good practice and preparation for the hooks classification work.
Since it looks like a generic enough library that could be used by other extensions too it might be useful to have it packaged as an external library.
See also:
I'll try to do this next week.
For future reference, the Monobook use case was addressed with a document class.
2013: Upstream jQuery 2.0, changes $.globalEval from eval.call(window) to domEval (i.e. inline script) for strict mode, and indirect = eval; indirect() for non-strict mode. Note that MediaWiki never deployed jQuery 2.
@Ebrahim James helps with many libs, but I suggest we handle this within our team instead (mw:Maintainers). We've had a bit of a reorg and this will be our first time doing it, so I'd rather we practice it and make sure we're familiar with the various bits and pieces.
Keeping any MediaWiki-adjacent work in our team on Gerrit for now.
In T368921#9967445, @Jdlrobson wrote:@Krinkle is there a timeline you are working towards here that I can communicate to our PM?
In T116561#5701530, @thiemowmde wrote:https://www.mediawiki.org/wiki/Manual:Coding_conventions#Line_continuation currently reflects this by saying "The operator separating the two lines should be placed consistently (always at the end or always at the start of the line)."
How can MW developers access the output of currently-runinng (or recently-completed) scheduled maintenance scripts that execute in Kubernetes?
@Ebrahim That is a very large patch indeed. Fortunately, that is a link to a mostly unrelated (and not merged) pull request to solve a different issue.
In T353817#9959609, @Joe wrote:Personal opinion, we should never ever turn off DirectorySlash. It's a perfect landmine waiting to be stepped onto, apart from the other risks.
Questions to think about:
The bootstrap-3.0.3 test case is enabled in CI and thus passing in the context PHPUnit and compare.php as a fixture:
In T368921#9946169, @Jdforrester-WMF wrote:Can you write a stylelint-config-wikimedia rule to detect (and ideally auto-fix) this?
We discussed this in the MwEng-SvcOps meeting (13 June 2024). Extstore was enabled on a few hosts in the DC. Some stats differered, but we weren't able to come up with a testing strategy to prove or disprove an observable benefit from the MW application in this state since keys are sharded across all hosts, and traffic generally involves many different keys.
Marking this as resolved since the review was completed above. Feel free to ping me in Phab or Gerrit with questions on follow-up work, or ask in our team channel on IRC.
Re-tagging for triage. Up to team to triage accordingly. (I'm cleaning up an old note pad, this isn't time-sensitive or related to me.)
/docroot/wikimediafoundation.org/.well-known contains a matrix/server file.
This redirect is coming from Apache and known as DirectorySlash. It's a way to make sure that directory index responsees have a reliable and consistent way that relative images, hyperlinks, etc are resolved.