Hello, and a thousand apologies if I'm in the wrong place to ask about this.
I'm making a web-based tool that makes a web request to a CSV file at
https://wikistats.wmflabs.org — however, because that webserver hasn't
enabled CORS (cross-origin resource sharing), most browsers can't
fetch the file.
To see this, open your browser to any non-WMFlabs.org URL (like
github.com), then open the JavaScript Console, and type in the
following:
fetch('https://wikistats.wmflabs.org/api.php?action=dump&table=wikipedias&format=c…').then(res
=> res.json()).then(x=>console.log(x))
Firefox for example will tell you, "Cross-Origin Request Blocked: The
Same Origin Policy disallows reading the remote resource at
https://wikistats.wmflabs.org/api.php?action=dump&table=wikipedias&format=c….
(Reason: CORS header ‘Access-Control-Allow-Origin’ missing).
TypeError: NetworkError when attempting to fetch resource."
Assuming Wikistats, the Cloud team, and the Wikimedia Foundation *do*
indeed want this data to be loadable by JavaScript running on any
domain, the standard way to fix this is to add the
"Access-Control-Allow-Origin: *" header to all responses sent by the
webserver. More detail is available at https://enable-cors.org/
I dug around for a while looking for a way to reach someone who might
be in charge of the https://wikistats.wmflabs.org webserver, and if
I'm in the wrong place, please accept my apologies.
Many thanks for your hard work,
Ahmed
Sorry for cross-posting!
Reminder: Technical Advice IRC meeting again **tomorrow, Wednesday 4-5 pm
UTC** on #wikimedia-tech.
The Technical Advice IRC meeting is open for all volunteer developers,
topics and questions. This can be anything from "how to get started" over
"who would be the best contact for X" to specific questions on your project.
If you know already what you would like to discuss or ask, please add your
topic to the next meeting: https://www.mediawiki.org/wiki/Technical_
Advice_IRC_Meeting
Hope to see you there!
Michi (for WMDE’s tech team)
--
Michael F. Schönitzer
Wikimedia Deutschland e.V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Tel. (030) 219 158 26-0
http://wikimedia.de
Stellen Sie sich eine Welt vor, in der jeder Mensch an der Menge allen
Wissens frei teilhaben kann. Helfen Sie uns dabei!
http://spenden.wikimedia.de/
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/681/51985.
Sorry for cross-posting!
Reminder: Technical Advice IRC meeting again **tomorrow, Wednesday 4-5 pm
UTC** on #wikimedia-tech.
The Technical Advice IRC meeting is open for all volunteer developers,
topics and questions. This can be anything from "how to get started" over
"who would be the best contact for X" to specific questions on your project.
If you know already what you would like to discuss or ask, please add your
topic to the next meeting:
https://www.mediawiki.org/wiki/Technical_Advice_IRC_Meeting
Hope to see you there!
Michi (for WMDE’s tech team)
--
Michael F. Schönitzer
Wikimedia Deutschland e.V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Tel. (030) 219 158 26-0
http://wikimedia.de
Stellen Sie sich eine Welt vor, in der jeder Mensch an der Menge allen
Wissens frei teilhaben kann. Helfen Sie uns dabei!
http://spenden.wikimedia.de/
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/681/51985.
hi,
I have some cron submissions to the grid from the account wikisource-bot
where the notifications of cron submission are sent to all users of the
account.
what are the means to manage those notifications.
* to have them sent to one specified user alone, rather than all users of
the account?
* to have them culled or written to a file?
Thx. Billinghurst
We lost a KVM host at around 7:20 UTC. Because we use local storage for
instances there are a number of them that are down. Toolforge suffered a
few losses but it seems to have been few enough that GridEngine and
Kubernetes users are unaffected at this time . The initial task is T187292
(with a list of instances), and an incident report will follow. We hope to
recover all of the instances that are down but it will take time to sort
through.
--
Chase Pettet
chasemp on phabricator <https://phabricator.wikimedia.org/p/chasemp/> and
IRC
_______________________________________________
Wikimedia Cloud Services announce mailing list
Cloud-announce(a)lists.wikimedia.org (formerly labs-announce(a)lists.wikimedia.org)
https://lists.wikimedia.org/mailman/listinfo/cloud-announce
Sorry for cross-posting!
Reminder: Technical Advice IRC meeting again **tomorrow, Wednesday 4-5 pm
UTC** on #wikimedia-tech.
The Technical Advice IRC meeting is open for all volunteer developers,
topics and questions. This can be anything from "how to get started" over
"who would be the best contact for X" to specific questions on your project.
If you know already what you would like to discuss or ask, please add your
topic to the next meeting: https://www.mediawiki.org/
wiki/Technical_Advice_IRC_Meeting
Hope to see you there!
Michi (for WMDE’s tech team)
--
Michael F. Schönitzer
Wikimedia Deutschland e.V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Tel. (030) 219 158 26-0
http://wikimedia.de
Stellen Sie sich eine Welt vor, in der jeder Mensch an der Menge allen
Wissens frei teilhaben kann. Helfen Sie uns dabei!
http://spenden.wikimedia.de/
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/681/51985.
Hello,
upon request at Czech Wikipedia's helpdesk I created a tool that sends
notifications about new weekly articles by e-mail together with its first
paragraph and link to it. To accomplish such a thing I need user's email,
so I firstly decided to store it in a database. To prevent this tool from
spamming I of course require its confirmation by accessing an URL with a
random string (MD5 hash of user's email *and* random number from 1 to 100;
I mean, those two things are in one hash). You can have a look at this tool
at tools.wmflabs.org/wiki2email/.
My question is: Is this okay? Should I add some kind of formal information
to the tool? If so, is there some help page? Should I stop with collecting
mails at all and use some WMF-maintained service for mass-emailing (mailman
at lists.wikimedia.org maybe?) and make the tool to just send an email to
the list itself?
This question came to my mind before creating, so I do appologize for
asking after programming.
Best regards,
Martin Urbanec
--
Můj kalendář najdete na https://martin.urbanec.cz/calendar.html
I want to write a tool which checks that you are consistent about ordering of <ref> tags. For example, if I did:
> The sky is blue.<ref name=“x”/><ref name=“y”/>
> The grass is green.<ref name=“y”/><ref name=“x”/>
This would get rendered as:
> The sky is blue.[1][2] The grass is green.[2][1]
When what you want is:
> The sky is blue.[1][2] The grass is green.[1][2]
Checking for out-of-order citations seems pretty straight-forward. In python, I’m using mwclient to get the wikitext, and wikitextparser to extract the tags from that. It should be trivial to check that they always show up in the same order.
The problem is, when I do:
> parsed = wtp.parse(wikitext)
> tags = parsed.tags()
I get a list of tags with no information about which ones are adjacent to each other. So, while the above example is an error, doing:
> The sky is blue.<ref name=“x”/><ref name=“y”/>
> The grass is green.<ref name=“y”/>.
> The dirt is brown.<ref name=“x”/>
Will render as:
> The sky is blue.[1][2] The grass is green.[2] The dirt is brown.[1]
which is perfectly fine. But, wikitextparser’s tags() doesn’t differentiate between those.
Krinkle has filed a feature request in Phabricator about adding
information for the centralauth database to the meta_p.wiki table
<https://phabricator.wikimedia.org/T186675>.
There are pros and cons to doing this, so I thought it would be good
to reach out to y'all to see if the pro of making it easier to figure
out which database section (e.g. s7) the database lives in outweigh
the con of introducing a "family" that identifies non-wiki databases
in the "wiki" table.
Please do read and comment on the Phabricator task if you have
opinions and would be impacted by the change.
Bryan
--
Bryan Davis Wikimedia Foundation <bd808(a)wikimedia.org>
[[m:User:BDavis_(WMF)]] Manager, Cloud Services Boise, ID USA
irc: bd808 v:415.839.6885 x6855