Hi all,
As the last part of putting Gitlab behind a CDN (T425441
<https://phabricator.wikimedia.org/T425441>), Gitlab will be served through
our CDN, joining its replicas which have been in that position since last
week.
The change will happen on Wednesday August 19 at 08:00 UTC.
No action needed: URLs stay the same and git over SSH is unaffected (
gitlab-ssh.wikimedia.org connects directly). Should anything misbehave, the
change can be reverted quickly.
As usual, questions and feedback are welcome on the task
<https://phabricator.wikimedia.org/T425441>.
Thanks!
--
*Arnaud Bran* (he/him)
Senior Site Reliability Engineer
Wikimedia Foundation <https://wikimediafoundation.org/>
This week's 1.47.0-wmf.17[0] version of MediaWiki is blocked at testwikis.
We can't proceed until the following issue is resolved:
* T426102: Rename current 'Worklist' texts in invitation lists"
- https://phabricator.wikimedia.org/T426102
Assistance appreciated!
-- Your cognitively overburdened train crew
[0]. https://phabricator.wikimedia.org/T430834
I'm reading Dumps/Airflow on wikitech. It talks about DAGs. What is a DAG? The usual meaning (Directed Acyclic Graph) doesn't make any sense in this context.
Dear all,
We are preparing an academic research project involving the large-scale
analysis of art-historical material from Wikimedia Commons, conducted
jointly by the University of Marburg and the Getty Research Institute.
For this project, we anticipate requiring access to at least five million
Commons images. High-resolution originals are not necessary; thumbnails
would suffice.
Before we initiate any large-scale retrieval, we would be grateful if you
could advise us on the preferred way to access this material. In
particular, we would be grateful for advice on whether an existing bulk
dataset provides Commons thumbnails on this scale, or whether a project of
this size should make use of, or request, any special API arrangements. As
we can identify and filter the relevant image URLs from the metadata in
advance, the main question concerns the recommended method for retrieving
the images themselves.
If you have any more questions about the project, please do not hesitate to
get in touch.
Thank you, and all the best,
Stefanie
__________________________
Dr. Stefanie Schneider
Wissenschaftliche Mitarbeiterin
Philipps-Universität Marburg
Kunstgeschichtliches Institut
Biegenstraße 11
35037 Marburg
Raum: 00003
Telefon: +49 6421 28-22174
E-Mail: stefanie.schneider(a)uni-marburg.de
https://www.uni-marburg.de/de/fb09/khi/dr-stefanie-schneider
Audience:
* Folks who patrol and use testwiki regularly
TL;DR:
* WMF would like to add some content to testwiki to support testing
MediaWiki deployments.
* That content may be seen as conflicting with
[[testwiki:Wikipedia:What Test Wiki is not]]'s "content or anything
meaningful" clause.
* What reasonable compromise to allow this class of testing content
can we establish?
I have just opened a "Adding some local content pages for Pretrain
project testing" [0] topic on testwiki's Village pump. The TL;DR above
is the gist of the post. We are working on a project called Pretrain
[1] that is creating a new automated MediaWiki deployment process.
This project needs some test content on testwiki to help validate the
deployments there using a new "automated supervision" [2] process we
are developing. The imagined test content may conflict with
interpretations of testwiki's "What Test Wiki is not" [3] guidance.
I would like to find compromises / compensating controls that make it
possible to add the desired testing pages to testwiki without causing
problems for the folks who patrol that wiki or polluting the internet
with stale copies of content articles that might confuse readers. If
you are a person who regularly patrols testwiki edits, periodically
cleans up testing garbage that accumulates there, or has another
reason to care how testwiki content is managed I would appreciate your
feedback on the Village pump proposal [0]. I am hoping to reach an
initial agreement rather quickly, but certainly do not want to rush
reasonable debate about our options.
[0]: https://test.wikipedia.org/wiki/Wikipedia:Village_pump#Adding_some_local_co…
[1]: https://www.mediawiki.org/wiki/Wikimedia_Release_Engineering_Team/Pretrain
[2]: https://phabricator.wikimedia.org/T428972
[3]: https://test.wikipedia.org/wiki/Wikipedia:What_Test_Wiki_is_not
Bryan
--
Bryan Davis Wikimedia Foundation
Principal Software Engineer Boise, ID USA
[[m:User:BDavis (WMF)]] irc: bd808
Hi everyone,
I've always been curious about how many people actually visit my Toolforge
tools - and I suspect I'm not alone. So I built Toolcounter (
https://toolcounter.toolforge.org/), a lightweight, privacy-friendly hit
counter designed specifically for Toolforge-hosted tools.
*What it tracks*
📄 Page views - counted on every page load (including refreshes). Good for
total traffic.
👤 Sessions (unique visit approximation) — uses sessionStorage in the
visitor's browser. First open in a tab = 1 session. Refresh = not counted
again. New tab = counted again. No cookies, no IP, no personal data stored.
Both counts appear separately on the dashboard with a per-day bar chart.
*Quick integration (replace YOUR_TOOL and PAGE)*
Option 1 - SVG badge (no JS, image only, shows page views):
<img src="
https://toolcounter.toolforge.org/badge.php?tool=YOUR_TOOL&page=PAGE"
alt="Page views">
Option 2 - JS embed (shows both views + unique sessions):
👁 Views: <span id="tc-views"></span>
👤 Unique: <span id="tc-sessions"></span>
<script src="
https://toolcounter.toolforge.org/embed.js.php?tool=YOUR_TOOL&page=PAGE
"></script>
An embed code generator is available on the homepage.
*Privacy*
The database stores zero personal data, only anonymous counters per (tool,
page) pair. No cookies are set. No IP addresses, User-Agent strings, or
usernames are ever written to the database. Full privacy policy:
https://toolcounter.toolforge.org/privacy.php
Source code is publicly available and open for audit.
Feedback and contributions are very welcome. Happy to answer questions here
or on my talk page: https://meta.wikimedia.org/wiki/User_talk:Suyash.dwivedi
Cheers,
Suyash Dwivedi
https://toolcounter.toolforge.org/https://meta.wikimedia.org/wiki/Wikis_Lazy_Coders
As per the MediaWiki version lifecycle[1], I would like to announce the
formal end of life (EOL) of MediaWiki 1.44 as of July 31, 2026.
1.44.6 is the last release for this branch.
This means that MediaWiki 1.44 will no longer receive maintenance or
security backports. It is therefore strongly discouraged that you continue
to use it.
Please upgrade to MediaWiki 1.45, which will be supported until the end of
December 2026. Or to MediaWiki 1.46, which will be supported until the end
of July 2027.
Thanks!
[1] https://www.mediawiki.org/wiki/Version_lifecycle