[Wikitech-l] m1 database master (etherpad, bacula, rt, librenms) restart - Thursday 20th 09:00 AM UTC

[Manuel Arostegui]

Hello,

*Thursday 20th at 09:00AM UTC* we'll be restarting and upgrading db1135
(m2 misc primary database master) as part of
https://phabricator.wikimedia.org/T239791
The specific task for the upgrade is
https://phabricator.wikimedia.org/T244238

Impact: The following services will be on read-only for around 1 minute:

librenms
etherpad
bacula
racktables
rt

Sorry for the inconvenience
Manuel.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] How to invalidate a ResourceLoader URL that depends on user-generated content?

[Máté Szabó]

Hi all,

I am working on a custom ResourceLoader module whose style contents are 
compiled from Sass stylesheets. These Sass stylesheets take as input 
user-defined theme variables that affect the output.
I am looking for a way to invalidate ResourceLoader URLs that include such 
style modules, when these variables change as a result of an user 
action—primarily so that the user can see their own changes.

ResourceLoader will cache such style URLs for 5 minutes on the CDN and in the 
user’s browser cache, so by default the user would have to wait until their 
cached copy of styles expire before they would receive the updated version. 
Accordingly, I have tried to explore if following the document steps to empty 
one’s browser cache[1] after making changes would cause the browser to fetch 
the updated resource from the backend. Unfortunately, both Chrome and Firefox 
appear to send a “Cache-Control: no-cache” request header for the style URL if 
the page is hard refreshed, which seems to cause most CDNs (including WMF’s) to 
act as the source of truth and serve the asset from cache if it is already 
there, without triggering a backend fetch or conditional revalidation. In the 
case of a simple refresh, Chromium and derivatives will not trigger a 
conditional revalidation of resources including on a page since 2017,[2] so 
they just continue to use the asset that was already in the browser’s cache. 
Thus, the standard instructions for emptying one’s cache do not seem to be 
sufficient to allow the user to see the effect of their styling changes.

Given the above, the only option I see that would allow the user to see the 
updated styles after modifying input variables would be to append a version 
hash to the style URL included in the page HTML—something which ResourceLoader 
does not
currently do.

Do you know of a better approach to this problem? Are there any examples in 
MediaWiki core or extensions that accomplish something similar? I have 
consulted the code for ResourceLoaderSiteStylesModule, but it does not seem to 
have any specific invalidation behaviour, nor does it use a version hash in 
style URLs in the page HTML, so it seems that any updates to it take 5 minutes 
to propagate.

Thanks in advance!

—
[1] https://en.wikipedia.org/wiki/Wikipedia:Bypass_your_cache
[2] https://bugs.chromium.org/p/chromium/issues/detail?id=505048

Cheers,

Máté Szabó 
SOFTWARE ENGINEER
+36 30 947 5903

Fandom Poland sp. z o.o. z siedzibą w Poznaniu, ul. Abp. A. Baraniaka 6
Sąd Rejonowy Poznań – Nowe Miasto i Wilda w Poznaniu, VIII Wydział Gospodarczy 
Krajowego Rejestru Sądowego, KRS 254365
NIP: 5252358778
Kapitał zakładowy: 50.000,00 złotych


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Phabricator database master restart - Thursday 13th 06:00AM UTC

[Manuel Arostegui]

Hello,

Thursday 13th at 06:00 AM UTC we'll be restarting phabricator database
master for https://phabricator.wikimedia.org/T239791 and to get it upgraded
as well (https://phabricator.wikimedia.org/T244566)

Phabricator will be on read-only mode for around 1 minute.

Sorry for the inconvenience,
Manuel.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Thank you... twuensday ?

[Derk-Jan Hartman]

Well it's not Tuesday, but better late than never.

I'd like to think volutneer DannyS712 [1] who has frankly done a humongous
amount of work over the last couple of weeks. DannyS712 has been going
through many technical-debt and code cleanup tasks, splitting them and
tackling them each one extension at a time, all while working at the same
time on their Global watchlist userscript [2] and many other technical
tasks on en.wp at the same time. Absolutely impressive.

I also want to join [3] VolkerE in thanking MattFitzpatrick,
 PerfektesChaos and heydonworks for highlighting and persisting on
indicating a simple accessibility improvement [4] of the Table of Contents
for screenreader users, that will soon be deployed.

[1] https://phabricator.wikimedia.org/p/DannyS712
[2] https://meta.wikimedia.org/wiki/User:DannyS712/Global_watchlist.js
[3] https://twitter.com/Volker_E/status/1227261008059592704
[4] T139221: Make generated table of contents a navigation region

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] How to invalidate a ResourceLoader URL that depends on user-generated content?

[Roan Kattouw]

Yes, it takes 5 minutes for just about everything to update in
ResourceLoader. This is also true for ResourceLoaderSiteStylesModule: when
you save an edit to e.g. MediaWiki:Common.css, you don't immediately see
the styles change. However, previewing edits to MediaWiki:Common.css does
work, because of some special handling.

When previewing, EditPage sets a content override (using
OutputPage::addContentOverride()) for the page being previewed, with the
text that's in the edit box. This content override is then propagated to
the ResourceLoaderContext object by OutputPage::getRlClientContext().
ResourceLoaderWikiModule checks these content overrides before accessing
wiki pages (which is how it gets the content from the edit box instead of
the content that's on the wiki page), and it also causes
shouldEmbedModule() to return true if there's a content override that
applies to it (which is how it avoids requesting the module from load.php
and instead embeds it as an inline 

[Wikitech-l] TechCom Radar 2020-02-12

[Alexandra Paskulin]

Hi all,

Here are the minutes from this week's TechCom meeting:

* Discussed: RFC Re-evaluate librsvg as SVG renderer on Wikimedia wikis


* Discussed: Config on the RequestContext may not be the same as the main
config 

* Opened: Improve file attribution for “Called deprecation function” logs


* RFC review meeting scheduled for next week: Adopt a modern JavaScript
framework for use with MediaWiki 
2020-02-19 22:00 UTC (14:00 PT, 23:00 CET) on Freenode in #wikimedia-office

You can also find our meeting minutes at


See also the TechCom RFC board


If you prefer you can subscribe to our newsletter here


Best,
- Alex

-- 
Alex Paskulin
Technical Writer
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Phabricator database master restart - Thursday 13th 06:00AM UTC

[Manuel Arostegui]

Hello,

This will start in 15 minutes.

On Wed, Feb 12, 2020 at 7:41 PM Manuel Arostegui 
wrote:

> Hello,
>
> Thursday 13th at 06:00 AM UTC we'll be restarting phabricator database
> master for https://phabricator.wikimedia.org/T239791 and to get it
> upgraded as well (https://phabricator.wikimedia.org/T244566)
>
> Phabricator will be on read-only mode for around 1 minute.
>
> Sorry for the inconvenience,
> Manuel.
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Phabricator database master restart - Thursday 13th 06:00AM UTC

[Manuel Arostegui]

This was done successfully. Downtime was 56 seconds.
Thanks Mukunda for being around and helping out during the maintenance.

On Thu, Feb 13, 2020 at 6:44 AM Manuel Arostegui 
wrote:

> Hello,
>
> This will start in 15 minutes.
>
> On Wed, Feb 12, 2020 at 7:41 PM Manuel Arostegui 
> wrote:
>
>> Hello,
>>
>> Thursday 13th at 06:00 AM UTC we'll be restarting phabricator database
>> master for https://phabricator.wikimedia.org/T239791 and to get it
>> upgraded as well (https://phabricator.wikimedia.org/T244566)
>>
>> Phabricator will be on read-only mode for around 1 minute.
>>
>> Sorry for the inconvenience,
>> Manuel.
>>
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l