Dear Team,
Came across a situation similar to [1] where I had to call submit()
function of a FormSpecialPage during a unit test. We have something going
on in the background, and $this->getUser() needs to return a valid user.
Is there a way to mimic this context inside the unit test, so that I can
manually set a $user in the unit test, and this would be used while
performing inner operations ?
[1]
https://gerrit.wikimedia.org/r/#/c/399995/4/tests/specials/SpecialNewslette…
--
Tony Thomas
https://mediawiki.org/wiki/User:01tonythomas
--
This afternoon, while procrastinating by cleaning up my clone of
gerrit's mediawiki extensions repository, I decided to make a meta
repository for some non-WMF-hosted extensions. (Hopefully this will
mean less need to clean up the clone in the future.)
I got some low-hanging fruit to start it off, but I'm hoping I can get
some pull requests to add more repositories.
Check it out: https://github.com/MWStake/nonwmf-extensions
Thanks,
Mark.
Hi all,
We are delighted to announce that our IEG renewal application for the Commons
app <https://play.google.com/store/apps/details?id=fr.free.nrw.commons>[1] has
been approved! Thank you so much to everyone who supported us – reading
all of the wonderful comments on our proposal has been extremely meaningful
and encouraging for us.
We have been hard at work getting version 2.6 of the app out; there was a
bit of a rocky start with the first few beta iterations, but we finally
have v2.6.5 in production. \o/
Several UI improvements have been made in the current version:
- New login screen
- New design for the list of nearby places that need pictures
- New navigation drawer design with username displayed
- The upload screen has been remodeled to include tooltips for title and
description fields, as well as an explicit copyright declaration and a link
to Commons policies
- Improved media details view with links to the selected license,
categories and image coordinates
Other improvements include:
- Category search - fixed major bugs, improved ordering and filter for
categories
- The "nearby places that need pictures" feature has improved GPS and
refresh handling
- Several privacy improvements - new privacy policy, switched to using
Wikimedia maps server instead of Mapbox, and removed event logging
- Reduced memory leaks and battery usage; fixed multiple other crashes and
bugs
- Various improvements to navigation flow and backstack
- Added option for users to send logs to developers (has to be manually
activated by user)
For more information on the new version, recent screenshots, and
upload/deletion statistics for 2017, please see this blog post
<https://cookiesandcodeblog.wordpress.com/2017/12/24/commons-app-update-vers…>[2].
Feedback, bug reports, and suggestions are always welcome on our GitHub page
<https://github.com/commons-app/apps-android-commons>[3].
Cheers, and happy holidays. :)
Best regards,
Josephine (@misaochan)
[1] https://play.google.com/store/apps/details?id=fr.free.nrw.commons
[2]
https://cookiesandcodeblog.wordpress.com/2017/12/24/commons-app-update-vers…
[3] https://github.com/commons-app/apps-android-commons
This afternoon, while procrastinating by cleaning up my clone of
gerrit's mediawiki extensions repository, I decided to make a meta
repository for some non-WMF-hosted extensions. (Hopefully this will
mean less need to clean up the clone in the future.)
I got some low-hanging fruit to start it off, but I'm hoping I can get
some pull requests to add more repositories.
Check it out: https://github.com/MWStake/nonwmf-extensions
Thanks,
Mark.
This year's edition of Google-Code is already half over:
https://www.mediawiki.org/wiki/Google_Code-in/2017
*** YOUR HELP IS NEEDED: GCI is still running for another 3½ weeks.
We do need more of your tasks, especially in the next days when many
students will have more time. If you have a task in mind to mentor, add
it. You can still become a mentor at any time - see the link above! ***
Thanks to many students and the help of Wikimedia's 46 mentors we have
seen more than 200 tasks resolved already!
Curious? Here is a subjective list of some of the achievements:
* Several students took incremental tasks to learn Lua and templates
* New help pages explain how to use VisualEditor to create complex
links and how to use the Thanks extension
* Several students learned how to create simple on-wiki user scripts
* The Commons Android app got screenshots in several languages and
their Play Store texts added to TranslateWiki
* The Kiwix mobile app on Android has an improved language selection
and warns users when opening external content
* In the Wikipedia Android app, a long press on find in page up / down
arrows now advances to the first / last match
* Several Wiki Education Dashboard components received tests
* Huggle got new languages incorporated and docs are now on one page
* Added tabindex to MediaWiki's Special:Upload page
* MediaWiki API offers a parameter to filter revisions based on a tag
* phpcs code sniffs got re-enabled in several MediaWiki extensions
* MinusX support was added to numerous skins and extensions
* MediaWiki's "includes/Feed.php" file now uses a Mustache template
* Pywikibot received numerous code improvements and can now detect
when it is run in the Wikimedia Toolforge environment
* Labels + numbers in the ContentTranslation trend graph are localized
* The EasyQuery JS gadget on wikidata.org got a query error fixed
* Scraping of PRISM tags was added to the html-metadata node library
* The wikilabels AI service got pytests for the flask application
introduced and created
* Potential logos for the PAWS and Citoid projects were proposed
* Several extensions do not use deprecated jQuery.fn.hover() anymore
* Many deprecated wfWaitForSlaves usages in MW+extensions got replaced
* MediaWiki's comment based strip markers now include quotes to avoid
being included in attributes
* Some MW maintenance scripts got code improvements to not trigger
false positives in the phan-taint-check-plugin script
* The Timeless skin received several updated screenshots on Commons
* In Echo, the Help tooltip is now accessible and the difference
between "un/read" background colors in the flyout has been increased
* Strategies to improve event participation were researched
* The wm-bot IRC bot received a @restrict command
* The git-repo client tool received Gerrit support
...and many more.
Congratulations & thanks to all our students and mentors!
andre
--
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/
Hello all!
Here are the minutes from this week's meeting:
* New RFC about tagging imported revisions:
<https://phabricator.wikimedia.org/T183061>. This is currently considered a
“draft” as the proposal needs work, but the motivation seems to have merit and
there is already some relevant discussion on the ticket.
* RFC process update accepted after Last Call: the new process can be found at
<https://www.mediawiki.org/wiki/Requests_for_comment/Process/Draft>. Krinkle
will replace the old documentation with the new version and explain all the
differences in a separate email.
* Last week’s RFC discussion was about refactoring the Preferences class.
<https://phabricator.wikimedia.org/T178449>
* Ops is moving a first set of services to Kubernetes. We will probably have an
RFC on how Kubernetes is going to affect deployment and configuration changes
before wider use.
* Ops is planning to start using etcd for configuration management.
* Tgr found an interesting option that may address part of or needs wrt
JavaScript package management, see his comment on
<https://phabricator.wikimedia.org/T107561>
* Active discussion about where to best put platform-specific default settings
<https://phabricator.wikimedia.org/T182020>
You can also find our meeting minutes at
<https://www.mediawiki.org/wiki/Wikimedia_Technical_Committee/Minutes>
See also the TechCom RFC board
<https://phabricator.wikimedia.org/tag/mediawiki-rfcs/>.
--
Daniel Kinzler
Principal Platform Engineer
Wikimedia Deutschland
Gesellschaft zur Förderung Freien Wissens e.V.
https://www.mediawiki.org/wiki/Scrum_of_scrums/2017-12-20
*= 2017-12-**20** =*
Grace has a conflict today and cannot facilitate today. Please
self-organize. I will publish notes later.
== Callouts ==
* Reminder: Failover for wikidata (new s8 shard) arranged for 9th Jan -
T181645
* Would like somebody from performance/MediaWiki team to look at:
https://phabricator.wikimedia.org/T183101 we’ve got some fails on
LinksUpdate which blocked search index update which makes Wikidata items
invisible in search (~50 items)
== Audiences ==
=== Readers ===
==== iOS native app ====
* Blocked by: none
* Blocking: none
* Updates:
**5.7.3 with faster article loading, pure black mode for OLED releasing
this week
==== Android native app ====
* Blocked by:
* Blocking:
* Updates:
==== Reading Web ====
* Blocked by:
* Blocking:
* Updates:
==== Reading Infrastructure ====
* Blocked by: Ops on puppet code review:
* https://gerrit.wikimedia.org/r/#/c/397623/
* https://gerrit.wikimedia.org/r/#/c/395694/
* Blocking:
* Updates:
==== Multimedia ====
* Blocked by:
* Blocking:
* Updates: 3D deployment pushed to January, MediaInfo work is unblocked and
progressing, and very little else is happening
===== Maps =====
* Blocked by: service-runner build failures
* Blocking: N/A
* Updates:
=== Contributors ===
==== Editing ====
* Blocked by:
* Blocking:
* Updates:
==== Parsing ====
* Blocked by:
* Blocking:
* Updates:
==== Global Collaboration ====
* Blocked by:
* Blocking: Flow dump performance improvement is blocking ops and in
progress. I'm resuming this now.
* Updates:
** RCFilters
*** Bug fixes, especially regarding RecentChangesLinked page; also,
LiveUpdate
** Ruby browser tests
*** We're removing most of our Ruby browser tests, since we decided the
value doesn't justify the time investment of converting them to node.js,
and Ruby support is being removed completely.
* Ongoing work on Flow frontend experimentation; mostly consolidated on a
plan for this.
==== UI Standardization ====
** Special OOUI v0.24.4 release coming today with some backports to address
issues uncovered in v0.24.3
*** 2 deprecating changes, icons 'bellOn' of 'alerts' pack, 'quotesAdd' &
'redirect' of 'editing-advanced' have been identified to be unused nor
won't be used in future.
- Will be removed in v0.26.0
*** Add 'lightbulb' icon to 'interactions' pack
*** Also introduce OO.ui.getDefaultOverlay function that provides a more
solid default OOUI overlay handling within other core theme elements
(Bartosz Dziewoński)
* Ongoing:
** OOUI & based products:
*** icons: Finalizing work on icon set to be more harmonious and align to
WikimediaUI Style Guide https://phabricator.wikimedia.org/T177432 –
currently addressing remaining RTL issues
** Unify SVG markup across Foundation products
https://phabricator.wikimedia.org/T178867
*** All products aligned
*** Introducing per-project proof SVGO optimization for future SVG
additions, see also
https://www.mediawiki.org/wiki/Manual:Coding_conventions/SVG
=== Community Tech ===
Finally received green light with our core refactoring for
GlobalPreferences. Otherwise, wrapping up this year's stuff. New wishes in
the new year, whee!
== Technology ==
=== Analytics ===
* Blocked by:
* Blocking:
* Updates:
- * Announced alpha release of wikistats: https://stats.wikimedia.org/v2/
(Working on UI bugs filed by users, we love our users for caring and filing
them)
- * Blogposts on the way for wikistats, on both the back-end and
front-end work
- * Working on new public apis to power map data, pageviews-per-country
- * Some performance issues with druid private cluster, resolved (some
tricky interaction with OS Page Cache)
- * New kafka jumbo cluster work progressing, at the request of Brandon
we are going to take a second look at supported ciphers for TLS
- * Updated dashiki dashboards with a CC0 license link, see, for
example: https://edit-analysis.wmflabs.org/multimedia-health/
=== Cloud Services ===
* Blocked by:
* Blocking:
* Updates:
** All puppetmasters now running 4.x puppet
*** Agent upgrade pending Trusty agent packages
** All Wiki Replica usage now on the "new" cluster. <
https://wikitech.wikimedia.org/wiki/Wiki_Replica_c1_and_c3_shutdown>
*** labsdb1001 & labsdb1003 can be decommissioned on or after 2018-01-03
** Some things a bit blocked by the broken puppet compiler (at least as of
Friday)
=== Fundraising Tech ===
* Blocked by: nothing
* Blocking: nothing
* Updates:
** Fundraiser still going really smoothly, showing very few banners
** Investigating some low-level errors
** Getting some civi stuff merged upstream
** fixes & enhancements to internal dashboard and grafana stats
=== MediaWiki Platform ===
* Blocked by: N/A
* Blocking: N/A
* Updates:
** Q3/Dev Summit/Audiences Technology Working Group planning
** Multi-content revisions
*** Actor table patch being rebased after merge of some Revision table
patches
*** Code review
*** Reviewing development needs
** Comment table schema change continuing to be applied
** cleanupUsersWithNoId script has been run on most wikis
** Helping GCI students with their tasks
** Prepping the next MediaWiki-CodeSniffer release
** Socializing and publishing
https://www.mediawiki.org/wiki/Best_practices_for_extensions page since
people are starting to comment on it
=== Performance ===
* Blocked by: N/A
* Blocking: N/A
* Updates:
** Q3 goals posted
** Intro to Performance measurement posted:
https://wikitech.wikimedia.org/wiki/Measure_Performance -- training based
on this to come in Q3
** WebPageRelay variability reduced to ~2%, well positioned for Q3
** Improved Varnish slow log landed on Vagrant, will be hitting prod
right after the holidays
** mcrouter configuration will be hitting prod right after the
holidays, for testing
=== Release Engineering ===
* Blocked by:
* Blocking:
* Updates:
=== Research ===
* Blocked by:
* Blocking:
* Updates:
=== Scoring Platform ===
* Blocked by:
* Blocking:
* Updates:
=== Search Platform ===
* Blocked by:
* Blocking:
* Updates:
* Would like somebody from performance team to look at:
https://phabricator.wikimedia.org/T183101 we’ve got some fails on
LinksUpdate which blocked search index update which makes Wikidata items
invisible in search (~50 items)
* Working on fixes for completion suggester & redirects namespaces
* Working on Wikidata search fixes for delay & space handling
* Working on refactoring search profiles to make them more config-like
https://phabricator.wikimedia.org/T183279
* Wikidata fulltext search prototype published and collecting feedback:
https://www.wikidata.org/wiki/Wikidata:Project_chat#Wikidata_fulltext_searc…
=== Security ===
* Blocked by:
* Blocking:
* Updates:
** Reviews:
*** Google MT reviewed, with more notes coming
*** mo
*** mediawiki-services-chromium-render
*** stacktraces on wikis
*** git mirroring to diffusion
=== Services ===
* Blocked by:
* Blocking:
* Updates:
=== Technical Operations ===
* Blocked by:
** Usual issue about Flow dumps, global collaboration, Ops welcomes Matt
back :-)
* Blocking:
** None
* Updates:
** Reminder: Failover for wikidata (new s8 shard) arranged for 9th Jan -
T181645
** Ganglia is finally dead!
** Mysterious crashes of HHVM on api still ongoing, with low frequency.
Investigating in the background.
** Goals posted
== Wikidata ==
* With many people on vacation, we started a small "cleanup/pet project"
sprint over the holidays.
* Re-introducing PSR-4 in all Wikibase code bases.
* Good progress on statement editing on sub-entities, namely Form entities
in the Lexeme extension.
== German Technical Wishlist ==
* Blocked by:
* Blocking:
* Updates:
== SoS Meeting Bookkeeping ==
* Updates:
Dear Wikimedians,
as you likely know, upcoming Wikimedia Hackathon will take place in
Barcelona from 18 to 20 May 2018*.
https://www.mediawiki.org/wiki/Wikimedia_Hackathon_2018
Before that event, some previous activities are being organized, among
them a one-weekend Prehackathon in Olot (Catalonia) from 2 to 4 February
2018 focused on multilingualism and language technical aspects.
More details at:
https://www.mediawiki.org/wiki/Wikimedia_Hackathon_2018/Prehackathon_Olot
Best,
Toni Hermoso
--
* Registration and scholarship details of May Hackathon will be public
in a few weeks.
Hi!
I've noticed a certain problem in our workflow that I'd like to discuss.
>From time to time, we deprecate certain APIs in core or extensions. The
idea of deprecation is that we have gradual transition - existing code
keeps working, and we gradually switch to the new API over time, instead
of removing old API at one sweep and breaking all the existing code.
This is the theory, and it is solid.
Also, we have phan checks on the CI builds, which prevent us from using
deprecated APIs. Right now if phan detects deprecated API, it fails the
build.
Now, combining this produces a problem - if somebody deprecates an API
that I use anywhere in my extension (and some extensions can be rather
big and use a lot of different APIs), all patches to that extension
immediately have their builds broken - including all those patches that
have nothing to do with the changed API. Of course, the easy way is just
to add @suppress and phan shuts up - but that means, the deprecated
function is completely off the radar, and nobody probably would remember
to look at it again ever.
I see several issues here with this workflow:
1. Deprecation breaks unrelated patches, so I have no choice but to shut
it up if I want to continue my work.
2. It trains me that the reaction to phan issues should be to add
@suppress - which is the opposite of what we want to happen.
3. The process kind of violates the spirit of what deprecation is about
- existing code doesn't keep working without change, at least as far as
the build is concerned, and constantly @suppress-ing phan diminishes the
value of having those checks in the first place.
I am not sure what would be the best way to solve this, so I'd like to
hear some thoughts on this from people. Do you also think it is a
problem or it's just me? What would be the best way to improve it?
Thanks,
--
Stas Malyshev
smalyshev(a)wikimedia.org
Hello fellow MW developers,
in a private Wiki I have strange issues with refreshLinksDynamic Jobs, that pop up apparently without reason. In particular I even have a loop between 2 pages. After page 1 is refreshed MW thinks it needs to refresh page 2. And after MW refreshed it, I get page 1 in the queue again [WTF].
MW's behaviour is even more strange:
I run my MW jobs via CRON and have
$wgJobRunRate = 0;
$wgRunJobsAsync = false;
in LocalSettings.
When running one job at a time the job queue never depletes. When running 100 jobs at once, via
php runJobs.php --maxjobs=100
the queue eventually gets processed completely.
I saw Daniel's page about JobQueue issues [1] but apparently no solution exists yet. Is this still the current state of understanding?
BTW. I am running the latest MW 1.27 and I must stay on the LTS track of MW. With 1.23 I did not have issues like that at all.
Any feedback will be appreciated.
thx,
michael
[1] https://www.mediawiki.org/wiki/User:Daniel_Kinzler_(WMDE)/Job_Queue