Hi and welcome,
Here are some easy tasks:
https://phabricator.wikimedia.org/project/view/169/
Baha
On Tue, 23 Feb 2016 11:04:28 -0500, Mehul Sawarkar
<mehulsawarkar(a)gmail.com> wrote:
> Hello,
>
> I am Mehul Sawarkar, a Computer Science student from India . I want to be
> part of wikimedia in GSoC 2016.Pplease help me getting started .Is there
> any small bug that I can fix?
>
> Thanks,
> Mehul Sawarkar.
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
--
Baha
Hey all,
I released OOjs UI 0.16.0 today. It will be in MediaWiki core from
1.27.0-wmf.15
which will be deployed to Wikimedia production in the regular train,
starting on
Tuesday 1 March. As there are four breaking changes (albeit some nominal)
please
look carefully over them to determine if they affect your code.
Breaking and deprecating changes since last release:
- DraggableGroupElement: Add default implementation of re-order (Ed
Sanders)
This mixin previously wouldn't re-oder its own contents, which instead
needed
to be implemented (and duplicated) by each downstream. We now provide a
basic
reorder() method, so that this is no longer needed. Widgets with more
complex
requirements can over-ride the method. The events which we previously
emitted
for downstream widgets to implement this themselves are still emitted
but are
deprecated and will be removed. The only known users of this are in
Editing's
own VisualEditor-MediaWiki and TemplateData, both of which we shall fix.
- SelectFileWidget: Remove deprecated config 'dragDropUI' (Prateek
Saxena)
This option had been deprecated some time ago, in v0.12.7, but we (I)
clearly
forgot to remove it. :-) Prateek noticed this whilst doing wider
clean-up for
this widget, and so we're now (finally) removing it. This option has not
been
used by anyone since August last year, as far as we know.
- MenuOptionsWidgets: Drop jQuery autoEllipsis support (Bartosz
Dziewoński)
This feature was very expensive in terms of both execution performance
and in
resource terms, and was only used as far as we know inside VisualEditor.
Thus
we have killed this feature, which only provided the option to add '…'
inside
labels rather than at their end when they didn't fit inside the menu.
Thus we
no longer support the 'autoFitLabel' configuration option, and the
getLabel()
call is now deprecated.
- Element#scrollIntoView: Replace callback with promise (Ed Sanders)
Having a callback for scrollIntoView was out of keeping with the
architecture
of the rest of the library, so we deprecated it with a returned promise
which
does the same.
- Remove 'noimages' distribution (Bartosz Dziewoński)
As part of our on-going work to slim down the library for wider usage,
during
the 0.15.x series of release we (mostly MatmaRex) split out the core
parts in
to a 'core' distribution, with the rest of the library's components
available
in other distributions. These changes removed the justification for
retaining
our 'noimages' distribution of the library without the images, as it was
only
of use to MediaWiki, which no longer needs it. This, this is only
nominally a
breaking change in the names of files to be loaded by downstream
environments
which should not have any effect on developers or end-users.
- Require PHP 5.5.9+; drop old array syntax (James D. Forrester)
We have simplified our server-side code, as we now require PHP version
5.5.9,
or higher, for the execution environment. This change was done following
that
by MediaWiki, dropping of support for PHP 5.3.x, as the only significant
user
of the library. This is thus a nominal breaking change in the
environments we
support, which should not have any effect on developers or end-users.
Additional details are in the full changelog[0]. If you have any further
queries
or need help dealing with deprecations, please let me know. As always, a
general
set of library documentation is available on mediawiki.org[1], and there is
some
comprehensive generated code-level documentation and interactive demos
hosted on
doc.wikimedia.org[2].
[0] -
https://phabricator.wikimedia.org/diffusion/GOJU/browse/master/History.md
[1] - https://www.mediawiki.org/wiki/OOjs_UI
[2] - https://doc.wikimedia.org/oojs-ui/master/
J.
--
James D. Forrester
Lead Product Manager, Editing
Wikimedia Foundation, Inc.
jforrester(a)wikimedia.org | @jdforrester
The mw:Parsoid/Troubleshooting page (
https://www.mediawiki.org/wiki/Parsoid/Troubleshooting) says the following:
> If your MediaWiki runs via SSL, make sure that your Parsoid server can
access your MediaWiki without certificate errors. In other words; make sure
that the certificate is valid and added to the certificate storage on your
Parsoid-running system. Alternatively and similarly, you can set up your
webserver to listen on another port, that is not open on your firewall,
thus it can be standard http without SSL, therefore be accessed by Parsoid.
I chose option two, using a separate port. My relevant Apache config is
below:
# standard https entry
Listen 443
<VirtualHost *:443>
SSLEngine on
SSLCertificateFile /path/to/cert.crt
SSLCertificateKeyFile /path/to/key.key
<Directory /opt/meza/htdocs>
AllowOverride All
Options Indexes FollowSymLinks
Require all granted
Options All -Indexes
</Directory>
DocumentRoot /opt/meza/htdocs
ServerName Meza
</VirtualHost>
# parsoid entry (port 9000 not open in firewall)
Listen 9000
<VirtualHost *:9000>
<Directory /opt/meza/htdocs>
AllowOverride All
Options Indexes FollowSymLinks
Require all granted
Options All -Indexes
</Directory>
DocumentRoot /opt/meza/htdocs
ServerName MezaParsoidEntryPoint
</VirtualHost>
Parsoid and VisualEditor are working great with this setup for everything
except images. When I first add an image (VE --> Insert --> Media) it works
as expected. The image displays and is configurable. When I save the page
everything functions properly. However, when I click edit again the image
does not show. Shortly thereafter the request for the image times out and I
get the following error in the browser console:
GET http://<my-domain>:9000/bme/img_auth.php/thumb/6/66/BME_sign.jpg/400px-BME_sign.jpg
net::ERR_CONNECTION_TIMED_OUT
Note that it's attempting to load the image over port 9000, not 443.
Is there a way to tell images to load over the standard entry point?
Thanks,
James
Hi,
for technical reasons (Semantic), I need to set a wiki's (1.25.x)
$wgLanguageCode to English but want to have the user's default language
set to German.
$wgLanguageCode = 'en';
$wgDefaultUserOptions['language'] = 'de';
The $wgDefaultUserOptions['language'] = 'de'; seems to be ignored. New
users still get default 'en'.
Did I miss something?
Many thanks,
Hello,
I set up XHGui on the Wikimedia Foundation's production cluster:
https://performance.wikimedia.org/xhgui/
XHGui is a web application for browsing and analyzing PHP profiling data
collected via the XHProf hierarchical profiler. It's now available on the
Wikimedia Foundation's production cluster:
https://performance.wikimedia.org/xhgui/
You can see an example of a profiled request here:
https://performance.wikimedia.org/xhgui/run/view?id=56ca93be7ed6ccf971b5b693
I set things up so all requests which bear the X-Wikimedia-Debug header
(see <https://wikitech.wikimedia.org/wiki/X-Wikimedia-Debug>) are profiled
and entered into XHGui's database.
Anyone can use this setup to profile requests and view profiling data, but
for the moment POSTing to XHGui (to add function watches, create custom
views, etc.) requires WMF staff or NDA LDAP credentials.
Note that cookie, client IP, form data, and all query parameters except
'action', are stripped from requests. Also note that the app server that
handles X-Wikimedia-Debug requests is configured to process messages in all
log channels, which grossly inflates the runtime of log-processing
functions.
Some of it, I suspect, is inevitable. I studied this a while back and
a lot of prominent countries were very close to the 50% switchover,
including (interestingly) Italy.
On 19 February 2016 at 06:51, Antoine Musso <hashar+wmf(a)free.fr> wrote:
> Le 18/02/2016 23:37, Tilman Bayer a écrit :
>> Context (last three months):
>>
>> Like for the Android app, there was a notable bump around Christmas, but
>> also an even larger spike on January 14 - the reason is not clear to us.
>
> Hello,
>
> I would suspect it is related to Wikipedia turning 15 years old. The
> birthday has been well covered by news at least in France. A few
> acquaintance learned about the Wikipedia mobile apps by reading the news
> and started using it.
>
> Quoting someone I met:
>
> "I never heard you have a Wikipedia app. It is nice and usefull, much
> better than the web view".
>
>
> Hearsay, I have no fact ...
>
> --
> Antoine "hashar" Musso
>
>
> _______________________________________________
> Mobile-l mailing list
> Mobile-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
--
Oliver Keyes
Count Logula
Wikimedia Foundation
Hi,
In the last Wikimedia Developer Summit there were again conversations about
a MediaWiki-centric organization focusing on 3rd party (non-Wikimedia) use
cases. If the people interested in this initiative want to influence the
next Wikimedia Foundation Annual Plan, the time is now, and the place is
https://phabricator.wikimedia.org/T127312
--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
Dear all,
I’m writing to give a heads-up that I expect to be taking medical leave
from today through March 9, due in part to stress caused by the recent
uncertainty and organizational departures. In my absence, my work will be
in the capable hands of Ryan Kaldari and the rest of the Community Tech
team. Any questions you would have directed to me, direct to Ryan.
I hope to return as promptly as circumstance allows.
All the best,
Frances