Hi,
On Tue, Mar 1, 2016 at 3:36 PM, David Strine <dstrine(a)wikimedia.org> wrote:
> We will be holding this brownbag in 25 minutes. The Bluejeans link has
> changed:
>
> https://bluejeans.com/396234560
I'm not familiar with bluejeans and maybe have missed a transition
because I wasn't paying enough attention. is this some kind of
experiment? have all meetings transitioned to this service?
anyway, my immediate question at the moment is how do you join without
sharing your microphone and camera?
am I correct thinking that this is an entirely proprietary stack
that's neither gratis nor libre and has no on-premise (not cloud)
hosting option? are we paying for this?
-Jeremy
The Tech Department at Wikimedia Foundation [1] invites you to a* special
event on February 09, 2023, at 1600 UTC* [2].
*Richard Evans, Electronics & Data Systems Engineer At NASA Glenn Research
Center *[3], will be presenting on *how MediaWiki is being used within NASA*
to help manage the testing of very large spacecraft to prove they can
survive the harsh conditions of launch, orbit, and re-entry. The management
platform is built from MediaWiki and several key extensions that provide
workflow support. This evolving platform plans to incorporate the
extensions that form the MediaWiki-powered Open CSP platform [4]. This talk
will explain the architecture and benefits of the NASA platform and
motivate the need for Open CSP. We’ll also be recording the event to share
with those who can’t make it. You can join the event through Google Meet
[5].
Looking forward to seeing you there,
*--on behalf of the Tech Department, Wikimedia Foundation.*
*(For follow-ups, please reach out to *lnguyen(a)wikimedia.org.)
[1] https://www.mediawiki.org/wiki/Wikimedia_Technology
[2] https://zonestamp.toolforge.org/1675958415
[3] https://www.wikidata.org/wiki/Q618728#sitelinks-wikipedia
[4] https://www.open-csp.org/Main_Page
[5]
https://stream.meet.google.com/stream/ce81307c-cdb7-4a5e-9697-65c423f27614
--
________________________________
Erica Litrenta (she/her)
Senior Manager, Community Relations Specialists (Product)
Wikimedia Foundation
TLDR: Any ResourceLoader module will now run on mobile or desktop site by
default. Previously they would only load on the desktop site.
Hopefully this goes without disruption, but to be safe, if you maintain
code used in Wikimedia production, please:
1) check your experiences over the course of this week in mobile/desktop
site for JS errors/obvious UI errors (the former will be detected and
monitored via logstash)
2) check that your repository doesn't fail the core
testUnsatisfiableDependencies PHPUnit test. 3) Please check out the
following Phabricator tickets to see if you are impacted on the long term
[4][5].
# Background
Back in the early days of MobileFrontend, most of the JavaScript we had was
not mobile friendly. To avoid this we created an allow-list system, where
JavaScript was disabled by default and extensions/skins had to explicitly
enable it by adding a "targets" property to their ResourceLoaderModule
definition.
This was meant as a short term solution, but as with many things, attention
got pulled elsewhere, and almost ten years later it was still there.
There have been many complaints about this over those years. Mainly:
1) It means we have split the ResourceLoader cache further
2) It's not intuitive - new code was getting shipped to desktop only
experiences by default.
It also featured on the Developer Wishlist of 2017 at #34 [1].
3) Many older features don't work for community members for no credible
reason.
# Recent developments
As one of the few remaining people responsible for doing this in the first
time, I felt obliged to spend some time over December trying to pay off
this technical debt. I audited code that was being removed by the targets
system [2] and made the target explicit. Where modules were problematic on
mobile, we marked them in such a way that it was clear that they should
only run in a certain mode. This was only possible thanks to attention from
Amir, Santosh, Thiemo, Lucas W, Tpt, Sohom D, Bartosz - thank you all.
Today, Roan merged a change that makes ResourceLoader modules default to
the desktop AND mobile sites. This should be a harmless change, but may be
unintentionally triggering failures in testUnsatisfiableDependencies tests
as it seems some extension/skins are not included in the MediaWiki core
PHPUnit test run. If you encounter this issue, the fix is relatively simple
- you must define targets explicitly (see this example [6] and apologies in
advance for any annoyance this may cause)
# For action
Please take extra care with your code that you test on both mobile/desktop
sites and at mobile/desktop breakpoints. It's still possible to ship code
to mobile/desktop and see these guidelines [3] if you need to do that or
reply to this email with any questions you have.
# Next steps
This change will help with limiting the targets system to existing known
cases. This has been a long term request of the performance team. Please
see the follow up tickets to see if there is any action from you at your
leisure [4][5].
[1] https://www.mediawiki.org/wiki/Developer_Wishlist/2017/results
[2] in https://phabricator.wikimedia.org/T324723
[3]
https://www.mediawiki.org/wiki/ResourceLoader/Migration_guide_for_extension…
[4] https://phabricator.wikimedia.org/T328497
[5] https://phabricator.wikimedia.org/T328498
[6]
https://gerrit.wikimedia.org/r/c/mediawiki/extensions/PropertySuggester/+/8…
Hello all!
The Search Platform Team usually holds an open meeting on the first
Wednesday of each month. Come talk to us about anything related to
Wikimedia search, Wikidata Query Service (WDQS), Wikimedia Commons Query
Service (WCQS), etc.!
Feel free to add your items to the Etherpad Agenda for the next meeting.
Details for our next meeting:
Date: Wednesday, February 1st, 2023
Time: 16:00-17:00 UTC / 08:00 PDT / 11:00 EDT / 17:00 CET
Etherpad: https://etherpad.wikimedia.org/p/Search_Platform_Office_Hours
Google Meet link: https://meet.google.com/vgj-bbeb-uyi
Join by phone: https://tel.meet/vgj-bbeb-uyi?pin=8118110806927
Have fun and see you soon!
Guillaume
--
*Guillaume Lederrey* (he/him)
Engineering Manager
Wikimedia Foundation <https://wikimediafoundation.org/>
The hardware that hosts osmdb.eqiad.wmnet is long past its end of life
and will be shut down on February 12th. WMF staff do not plan to support
that database after that date, and the domain will be shut down.
I am pretty sure that we have already made arrangements with all current
users of the service, but I'm sending this email out of an abundance of
caution. If you think you are using it, please chime in on the
associated phabricator ticket[0] so that we know you exist! There is a
volunteer-maintained replacement that you should be able to switch to
with a minimum of effort.
Thanks for reading!
-Andrew + the WMCS team
[0] https://phabricator.wikimedia.org/T323159
Hi, I need the list of uploaders in the category Category:Uploaded via
Campaign:Wikivacaciones 2022, I did https://quarry.wmcloud.org/query/70909
based in another request but it doesn't work, anyone can fix it? Regards!!
Hi,
Hope this is the right channel for solving the issue. Varnish has been
implemented a year ago, excellent response, working fine. But after
installation of Mobilefrontend several months later the issues were
detected. (mediawiki 1.38.2, varnish 7.1)
Purges after the page updates run and purge desktop entries automatically
as well, but when the same page is accessed from the mobile device, the old
page version before the update is shown, the mobile entry has not been
purged. Mobilefrontend is installed and configured as advised in
mw:Extension:MobileFrontend/Configuring_browser_auto-detection option 2,
same domain.
The only difference between requests for desktop/mobile version is in the
header x-subdomain: no for mobile version (shows during the debug in
varnishlog). But even curl sending this header for purge request did not
work.
Configuration:
Mediawiki:
wfLoadExtension( 'MobileFrontend' );
$wgMFAutodetectMobileView = true;
$wgMinervaEnableSiteNotice = true;
$wgMFDefaultSkinClass = 'SkinMinerva';
...
$wgInternalServer = "http://127.0.0.1:8080";
$wgUseCdn = true;
$wgCdnServers = array();
$wgCdnServers[] = "127.0.0.1:8080";
Varnish:
According https://www.mediawiki.org/wiki/Manual:Varnish_caching, it had to
be customized, the page is little out-of-date and according to:
https://www.mediawiki.org/wiki/Extension:MobileFrontend/Configuration a
https://www.mediawiki.org/wiki/Extension:MobileFrontend/Configuring_browser…
.
In sub vcl_recv {
....
if (req.method == "PURGE") {
if ((req.http.X-Forwarded-For == "ip address") ||
(req.http.X-Forwarded-For == "ip address") ||
(req.http.X-Forwarded-For == "ip address")) {
set req.http.host = "host";
return (hash);
} else {
return (synth(405, "Not allowed"));
}
}
...
unset req.http.x-subdomain; # Requester shouldn't be allowed to
supply arbitrary X-Subdomain header
if (req.http.User-Agent ~
"(?i)^(lg-|sie-|nec-|lge-|sgh-|pg-)|(mobi|240x240|240x320|320x320|alcatel|android|audio
vox|bada|benq|blackberry|cdm-|compal-|docomo|ericsson|hiptop|htc[-_]|huawei|ipod|kddi-|kindle|meego|midp|mitsu|mmp\/|mot-
|motor|ngm_|nintendo|opera.m|palm|panasonic|philips|phone|playstation|portalmmm|sagem-|samsung|sanyo|sec-|sendo|sharp|sof
tbank|symbian|teleca|up.browser|webos)") {
set req.http.x-subdomain = "no";
}
...
return (hash);
...
sub vcl_hash {
# Cache the mobile version of pages separately.
#
# NOTE: x-subdomain header should only have one value (if it
exists),
# therefore vcl_recv() should remove user-supplied X-Subdomain
header.
hash_data(req.http.x-subdomain);
}
...
import purge;
sub my_purge {
set req.http.purged = purge.soft(0s,30s);
if (req.http.purged == "0") {
return (synth(404));
}
else {
return (synth(200));
}
}
After the purge if someone does not request the page and it would not be
loaded into cache, after 30 seconds the page should be loaded automatically.
The consequence of the issue is that mobile users do not see up-to-date
versions of the pages, the only workaround is restart varnish.
Thanks for advice pointing to the solution.
Pavel Spacek