Hi!
MediaWiki-CodeSniffer 0.9.0 is now available for use in your MediaWiki
extensions and other projects. Here are the notable changes since the
last release:
* Add sniff to enforce "function (" for closures (Kunal Mehta)
* Add usage of && in generic_pass (addshore)
* Disallow `and` and `or` (Kunal Mehta)
* Don't require documentation for constructors without parameters (Kunal
Mehta)
* Don't require documentation for '__toString' (Kunal Mehta)
* Don't require return/throws/param for doc blocks with @inheritDoc
(Kunal Mehta)
* Expand list of standard methods that don't need documentation (Kunal
Mehta)
* Fix FunctionComment.Missing sniff code (Kunal Mehta)
* Fix indentation (Umherirrender)
* Fix WhiteSpace/SpaceAfterClosureSniff (Antoine Musso)
* Make sure all files end with a newline (Kunal Mehta)
* test: ensure consistent report width (Antoine Musso)
* Update for CodeSniffer 3.0 (Kunal Mehta)
* Update squizlabs/PHP_CodeSniffer to 3.0.1 (Reedy)
* Use upstream CharacterBeforePHPOpeningTag sniff (Kunal Mehta)
The 3.0 upstream release should bring in a lot of under-the-hood
improvements, including support for parallel processing!
Note that due to an upstream bug, PHPCS 3.x doesn't work with repos that
have "prepend-autoloader": false set.
I've begun to submit patches to upgrade to the latest version and
automatically fix some of the issues:
<https://gerrit.wikimedia.org/r/#/q/topic:bump-dev-deps+status:open>.
Thanks to everyone who contributed to this release, please file bugs or
feature requests in the MediaWiki-Codesniffer Phabricator project if you
find any.
-- Legoktm
Hi all,
I've been working on enhancing the Theme extension [1] to add a
preference option so that registered users can set their preferred
theme [2], just like how they can set a skin and other such options.
The theme selector is shown on Special:Preferences, below the list of
available skins, and since themes are nothing but a set of CSS
modifications on top of a skin's base CSS, previewing them in real
time is easy. Or so I thought, anyway.
Turns out that this is a bit more complicated than that. I'm loading
the theme-specific CSS module via mw.loader.load(), which seems to
append a <style> tag to the <head> of the page.
To prevent "stacking" of theme CSS and to ensure that themes will
display as intended, I'm using $( 'head style' ).last().remove(); to
remove the last added <style> tag from head. This has the unintended
side-effect that previewing a theme works only once, and after that
the theme CSS is no longer applied because ResourceLoader thinks it
has already been loaded.
What would be the proper way to signal to ResourceLoader, "actually I
need you to load this module again"?
To test out my patch [2], you'll need a skin which supports themes,
such as MonoBook or Vector. Then simply git clone the
mediawiki/extensions/Theme repository, apply the patch on top of that,
load the extension via wfLoadExtension( 'Theme' ); in
LocalSettings.php (you may also need to set $wgDefaultTheme =
'default'; in your LocalSettings.php) and then visit
Special:Preferences and you should see the new "Theme" drop-down menu
there.
[1] https://www.mediawiki.org/wiki/Extension:Theme
[2] https://gerrit.wikimedia.org/r/#/c/359643/
Thanks and regards,
--
Jack Phoenix
MediaWiki developer
Hi,
Ladsgroup filed a request[1] for +2 in mediawiki/* repos that I missed
until now, and hadn't been sent to this mailing list. Please comment if
you haven't already and I'll close it in a few days.
[1] https://phabricator.wikimedia.org/T165860
-- Legoktm
Due to vandalism/spam in Phabricator [1] I've temporarily enabled the
"Require administrators to approve newly registered accounts" setting.
I'll update when we have turned it back off.
andre
[1] https://phabricator.wikimedia.org/T168142
--
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/
Follow on to previous email chain improperly named "Setting up multiple
Parsoid servers behind load balancer".
I'm getting much slower response times in a setup with multiple app servers
behind an HAProxy load balancer, versus the same setup with just a single
app server behind the same load balancer. I've setup profiling per
recommendations from this mailing list. [1] is the call graph of a
particularly long request. [2] is a graph showing requests over many page
loads, with the better-performing yellow dots/line being the single app
server. The worst-performing color is with profiling turned on.
This gist [3] has my LocalSettings.php from both app servers and the
included Extensions.php.
Can anyone help me figure this out? Anything else I can provide or certain
things I should test?
Thanks,
James
[1]
https://gist.githubusercontent.com/jamesmontalvo3/5adf207623454c9eff98e9315…
[2]
https://gist.githubusercontent.com/jamesmontalvo3/5adf207623454c9eff98e9315…
[3] https://gist.github.com/jamesmontalvo3/5adf207623454c9eff98e93152b43108
Greetings!
I'm sure you'll like the stuff I've just found for you, here, take a look http://bit.do/dwAq9
Looking forward, Federico Urban
Sent from Mail for Windows 10
Hi everybody,
(With apologies for cross-posting...)
You may have seen the recent communication [1
<https://www.mediawiki.org/wiki/Wikimedia_Engineering/June_2017_changes>]
about the product and tech tune-up which went live the week of June 5th,
2017. In that communication, we promised an update on the future of
Discovery projects and we will talk about those in this email.
The Discovery team structure has now changed, but the new teams will still
work together to complete the goals as listed in the draft annual plan.[2]
A summary of their anticipated work, as we finalize these changes, is
below. We plan on doing a check-in at the end of the calendar year to see
how our goals are progressing with the new smaller and separated team
structure.
Here is a list of the various projects under the Discovery umbrella, along
with the goals that they will be working on:
Search Backend
Improve search capabilities:
-
Implement ‘learning to rank’ [3] and other advanced machine learning
methodologies
-
Improve support for languages using new analyzers
-
Maintain and expand power user search functionality
Search Frontend
Improve user interface of the search results page with new functionality:
-
Implement explore similar [4]
<https://www.mediawiki.org/wiki/Cross-wiki_Search_Result_Improvements/Testin…>
-
Update the completion suggester box [5]
<https://www.mediawiki.org/wiki/Extension:CirrusSearch/CompletionSuggester>
-
Investigate the usage of a Wiktionary widget for English Wikipedia [6]
Wikidata Query Service
Expand and scale:
-
Improve ability to support power features on-wiki for readers
-
Improve full text search functionality
-
Implement SPARQL federation support
Portal
Create and implement automated language statistics and translation updates
for Wikipedia.org
Analysis
Provide in-depth analytics support:
-
Perform experimental design, data collection, and data analysis
-
Perform ad-hoc analyses of Discovery-domain data
-
Maintain and augment the Discovery Dashboards,[7] which allow the teams
to track their KPIs and other metrics
Maps
Map support:
-
Implement new map style
-
Increase frequency of OSM data replication
-
As needed, assist with individual language Wikipedia’s implementation of
mapframe [8] <https://www.mediawiki.org/wiki/Maps/how_to:_embedded_maps>
Note: There is a possibility that we can do more with maps in the coming
year; we are currently evaluating strategic, partnership, and resourcing
options.
Structured Data on Commons
Extend structured data search on Commons, as part of the structured data
grant [9] via:
-
Research and implement advanced search capabilities
-
Implement new elements, filters, relationships
Graphs and Tabular Data on Commons
We will be re-evaluating this functionality against other Commons
initiatives such as the structured data grant. As with maps, we will
provide updates when we know more.
We are still working out all the details with the new team structure and
there might be some turbulence; let us know if there are any concerns and
we will do our best to answer them.
Best regards,
Deborah Tankersley, Product Manager, Discovery
Erika Bjune, Engineering Manager, Search Platform
Jon Katz, Reading Product Lead
Toby Negrin, Interim Vice President of Product
Victoria Coleman, Chief Technology Officer
[1] https://www.mediawiki.org/wiki/Wikimedia_Engineering/June_2017_changes
[2]
https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2017-2018/…
[3] https://en.wikipedia.org/wiki/Learning_to_rank
[4]
https://www.mediawiki.org/wiki/Cross-wiki_Search_Result_Improvements/Testin…
[5]
https://www.mediawiki.org/wiki/Extension:CirrusSearch/CompletionSuggester
[6]
https://www.mediawiki.org/wiki/Cross-wiki_Search_Result_Improvements/Testin…
[7] https://discovery.wmflabs.org/
[8] https://www.mediawiki.org/wiki/Maps/how_to:_embedded_maps
[9] https://commons.wikimedia.org/wiki/Commons:Structured_data
Hey,
We are currently having problem with ORES service which sends out time out
errors intermittently. More information can be found in
https://phabricator.wikimedia.org/T167819
We will let you know when the service is back to full capacity.
Best
--
Amir Sarabadani Tafreshi
Software Engineer (contractor)
-------------------------------------
Wikimedia Deutschland e.V. | Tempelhofer Ufer 23-24 | 10963 Berlin
http://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.
