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
Hello all,
On Wednesday September 23rd 2026, the SRE team will run a planned
datacenter switchover, moving all wikis from eqiad to codfw. This is an
important periodic test of our tools and procedures, to ensure the wikis
will continue to be available even in the event of major technical issues
in our primary home. It also gives all our SRE and ops teams a chance to do
maintenance and upgrades on systems in eqiad that normally run 24 hours a
day.
The switchover process requires a brief read-only period for all
Foundation-hosted wikis, which will start on Wednesday September 23rd 2026
@ 14:00 UTC, and will last for just a few minutes while we execute the
migration as efficiently as possible. All our public and private wikis will
be continuously available for reading, as usual, but editing will be
unavailable during the process. Users will see a notification of the
upcoming maintenance, and anyone still editing will be asked to try again
in a few minutes.
MoveComms will soon begin notifying communities of the read-only window.
If you like, you can follow along on the day in the public
#wikimedia-operations channel on IRC. To report any issues, you can reach
us in #wikimedia-sre on IRC, or file a Phabricator ticket with the
#datacenter-switchover tag (
https://phabricator.wikimedia.org/maniphest/task/edit/form/1/?projects=Data…;
we'll be monitoring closely for reports of trouble during and after the
switchover. The switchover and its preparation will be tracked under
https://phabricator.wikimedia.org/T433363.
On behalf of the SRE team, please excuse the disruption, and we would like
to thank everyone in various departments who are involved in planning this
work. If you have any questions, please reply directly to this email.
Kind Regards,
--
Simon Lyngshede
Site Reliability Engineer / Traffic
Wikimedia Foundation
Dear Wikimedians,
Following the Wikimedia Foundation's decision[1] not to voluntarily
recognize Wiki Workers United (WWU), a new community petition has been
launched calling on the Board of Trustees to intervene.
The petition asks the Board to instruct the CEO to voluntarily recognize
the union and begin collective bargaining without further delay.
During the Q&A at Wikimania,[2] CEO Bernadette Meehan was asked whether
the Foundation would voluntarily recognize the union, noting that more
than 70% of eligible US staff had signed authorization cards and that
over a thousand Wikimedians had signed a petition supporting
recognition. She responded that the Foundation had received the request
and would review it after Wikimania before making a decision. Two days
later, on 27 July, the Foundation announced that it would not
voluntarily recognize the union. The Foundation's statement says that,
while it respects employees' right to unionize, it believes the
appropriate path is a secret-ballot election conducted by the US
National Labor Relations Board (NLRB) before recognition is considered.
Wiki Workers United has announced that it already has the support of a
supermajority of eligible US-based employees through signed
authorization cards. We believe voluntary recognition would have
respected that democratic choice without requiring a lengthy election
process. Instead, the Foundation's decision to require an NLRB election
has raised concerns that the process will be unnecessarily prolonged,
consume additional staff time and donor resources, and further damage
trust between the Foundation, its employees, and the Wikimedia
community. We also believe that Foundation's public messaging is
inconsistent with its stated support for workers' right to organize.
The Board of Trustees now has an opportunity to prevent this dispute
from escalating further. Voluntarily recognizing Wiki Workers United
would help rebuild trust between the Foundation, its staff, and the
Wikimedia community, while avoiding a prolonged dispute that risks
causing lasting damage to the Foundation's reputation and its
relationship with volunteers and donors.
If you believe the Wikimedia Foundation should voluntarily recognize
Wiki Workers United, please consider signing the petition:
* https://meta.wikimedia.org/wiki/2026_recognize_Wiki_Workers_United_petition
You can help by sharing it with your local Wikimedia communities,
affiliates, and fellow contributors. The more people who are aware of
this issue, the stronger the message that respecting workers' right to
organize and maintaining trust within the Wikimedia movement matter to
all of us.
In solidarity!
- Nemoralis.
[1]:
https://wikimediafoundation.org/news/2026/07/27/statement-cwa-recognition-r…
[2]:
https://commons.wikimedia.org/wiki/File:Questions_for_Bernadette_Meehan_reg…
[3]:
https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(WMF)#Recent_questions…
Hello everyone,
I’m happy to invite you to the next Global GLAM Call, happening on Tuesday,
28 July!
If you haven't joined one before, it's a monthly community meetup where
Wikimedians from across the movement come together to share updates and
discuss all things GLAM (Galleries, Libraries, Archives, Museums), Culture,
and Heritage.
📅 Register here on the event page: Global GLAM Call 2026-07-28
<https://meta.wikimedia.org/wiki/Event:Global_GLAM_call_2026-07-28>
This month's agenda includes the following:
- An update from the Wiki+GLAM+Gender initiative
- Metabase and MEOW
- The UN resolution on Reparative Justice
- GLAM Tool Hospital
- GLAM User Group updates
And if there's time at the end, we'll open the floor for anyone who'd like
to raise additional topics.
This month the call will be hosted by Alice Kibombo.
Want to contribute? You're welcome to submit agenda proposals via the GLAM
page on Meta at any time. You can also request simultaneous interpretation
or ask to host a session in the future— just get in touch through the same
page.
Hope to see you online.
All the best,
Connor
(sorry for cross posting this invitation)
Hi folks,
[If you aren't deploying to production, you can disregard this message.]
As part of upgrading deployment hosts to Debian Bookworm, we will
temporarily switch the active deployment server to
deploy2003.codfw.wmnet tomorrow, Wednesday, July 8 at 17:00–18:00 UTC. We
plan to switch it back after approximately 1 week.
If you use the alias deployment.eqiad.wmnet, please note that the host key
will change. You may want to run wmf-update-known-hosts-production if you
get errors/warnings.
Please reach out if you encounter any issue, either by responding to this
email or commenting on https://phabricator.wikimedia.org/T423714 .
Thank you!
Raine + ServiceOps
--
Raine Souček (they/them)
Senior Site Reliability Engineer, Service Operations
Wikimedia Foundation
Hi all,
Heads up: as part of putting GitLab behind a CDN (T425441
<https://phabricator.wikimedia.org/T425441>), SSH access for git commands
is moving to a dedicated hostname: gitlab-ssh.wikimedia.org. This only
affects SSH git access. HTTPS clones are unaffected.
- The new hostname is available now.
- Starting tomorrow (June 23rd) morning, GitLab will advertise it
<https://gerrit.wikimedia.org/r/c/operations/puppet/+/1300763> on new
git clone commands, so new clones will use it automatically.
- gitlab.wikimedia.org will stay reachable over SSH for git commands
until GitLab moves behind the CDN. We'll announce the change before it
happens. After that, gitlab.wikimedia.org will no longer be reachable
via SSH.
The quickest way to switch remotes all at once would be:
git config --global url."git(a)gitlab-ssh.wikimedia.org:".insteadOf "
git(a)gitlab.wikimedia.org:"
Per-repo rewrites, CI jobs and ~/.ssh/config are covered in the migration
guide <https://wikitech.wikimedia.org/wiki/GitLab/Migration>. wmf-laptop
<https://wikitech.wikimedia.org/wiki/Wmf-laptop> has been updated, so
wmf-update-known-hosts-production and wmf-update-ssh-config will reflect
the change.
Questions and feedback welcome on the task
<https://phabricator.wikimedia.org/T425441>.
Thanks!
--
*Arnaud Bran* (he/him)
Senior Site Reliability Engineer
Wikimedia Foundation <https://wikimediafoundation.org/>
