-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hello,
In an HTMLForm I'm filling a select with options extracted from a JSON
call (using ResourceLoader addModules).
Everything OK, excepts when I try to submit the form. The form is not
properly validated before even when I put 'validation-callback' =>
true and required => false in the actual select I'm filling with
Javascript.
I presume this may be happening because I'm puting these options not
in the expected way.
How could this be solved? E. g., fully disabling validation of the form?
Involved code:
http://pastebin.com/Q5KA2e1U
Any idea? Thanks!
- --
Toni Hermoso Pulido
http://www.cau.cathttp://www.similis.cc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBCAAGBQJVSyAdAAoJELt+jnuNHMW+c7MP/3Wztb2T5n3fiVzVlsmD38c1
VSJc3/HLwRtQQVDBTk7U0wrqie3/s6wsBNZUds63HqiEi+YE/PaWu/oqmyziiqr5
JNeIiPdfsWYoZFJhb5Y6mTVYWrEpn2QgtGkjeItvBc5QGjCRdJEOtASoqvmbSieT
mdNY30IolO8p6P4ILwoRhK/520+EIVm7YY4L12SdcPXGSQ+g1tFcZVut6uMjbfeD
KPA2X0mSiusIqxLAlhpl5ZbfUCOSj202MU928rWMqQe9A73Lfi/LURXeebDyLKTm
29uoLZ/K4SQ+1FQ8blfZHyikjJi8geMZV9yqFV0K96ADQkC95WxbHHE4aNkl1lxa
k4OViYOeoPekriNA/1DGBOEV2oE7oW2i7jeJTDxmWbN5DmFH3zY5QOMEpUZkXXvW
FnQ6FU20AHEda2nnukamLIoc585aaUoX1hRP+ugQKpiVJIzQTOHONU0D/SW9whdO
IX+P1JBw8e38ngsj7TbEQrVfmAv+4p3OXdfUI/HdeBqs4Mv+f1SB8Gi8GxUrGsOd
ZsTL5NTCNmZo5d/tdAIOtSKZJAYfe75BceRNKNfcHKFLS2RB8BhFSA4s8Lfd85wE
D3KHurkatzT7maAkQ17ym+ryn1Vu8FSck5d/RtHCKVq1FKPw5p68ExqQEP9qbA+A
Ig/fLxolcoxV1ZzAi+Zt
=nneA
-----END PGP SIGNATURE-----
Hey,
Github has a huge community of developers that collaborating with them can
be beneficial for us and them but Wikimedia codes are in gerrit (and in
future in phabricator) and our bug tracker is in phabrictor. sometimes It
feels we are in another planet.
Wikimedia has a mirror in github but we close pull requests immediately and
we barely check issues raised there. Also there is a big notice in
github[1], "if you want to help, do it our way". Suddenly I got an idea
that if we can synchronize github activities with gerrit and phabricator,
it would help us by letting others help in their own way. It made me so
excited that I wrote a bot yesterday to automatically duplicates patches of
pull requests in gerrit and makes a comment in the pull request stating we
made a patch in gerrit. I did a test in pywikibot and it worked well [2][3].
Note that the bot doesn't create a pull request for every gerrit patch but
it creates a gerrit patch for every (open) pull requests.
But before I go on we need to discuss on several important aspects of this
idea:
1- Is it really necessary to do this? Do you agree we need something like
that?
2-I think a bot to duplicate pull requests is not the best idea since it
creates them under the bot account and not under original user account. We
can create a plugin for phabrictor to do that but issues like privacy would
bother us. (using OAuth wouldn't be a bad idea) What do you think? What do
you suggest?
3- Even if we create a plugin, still a bot to synchronize comments and code
reviews is needed. I wrote my original code in a way that I can expand this
to do this job too, but do you agree we need to do this?
4- We can also expand this bot to create a phabricator task for each issue
that has been created (except pull requests). Is it okay?
I published my code in [4].
[1]: https://github.com/wikimedia/pywikibot-core "Github mirror of
"pywikibot/core" - our actual code is hosted with Gerrit (please see
https://www.mediawiki.org/wiki/Developer_access for contributing"
[2]: https://github.com/wikimedia/pywikibot-core/pull/5
[3]: https://gerrit.wikimedia.org/r/208906
[4]: https://github.com/Ladsgroup/sync_github_bot
Best
Starting today, editors can use *<graph>* tag to include complex graphs and
maps inside articles.
*Demo:* https://www.mediawiki.org/wiki/Extension:Graph/Demo
*Vega's demo:* http://trifacta.github.io/vega/editor/?spec=scatter_matrix
*Extension info:* https://www.mediawiki.org/wiki/Extension:Graph
*Vega's docs:* https://github.com/trifacta/vega/wiki
*Bug reports:* https://phabricator.wikimedia.org/ - project tag #graph
Graph tag support template parameter expansion. There is also a Graphoid
service to convert graphs into images. Currently, Graphoid is used in case
the browser does not support modern JavaScript, but I plan to use it for
all anonymous users - downloading large JS code needed to render graphs is
significantly slower than showing an image.
Potential future growth (developers needed!):
* Documentation and better tutorials
* Visualize as you type - show changes in graph while editing its code
* Visual Editor's plugin
* Animation <https://github.com/trifacta/vega/wiki/Interaction-Scenarios>
Project history: Exactly one year ago, Dan Andreescu (milimetric) and Jon
Robson demoed Vega visualization grammar <https://trifacta.github.io/vega/>
usage in MediaWiki. The project stayed dormant for almost half a year,
until Zero team decided it was a good solution to do on-wiki graphs. The
project was rewritten, and gained many new features, such as template
parameters. Yet, doing graphs just for Zero portal seemed silly. Wider
audience meant that we now had to support older browsers, thus Graphoid
service was born.
This project could not have happened without the help from Dan Andreescu,
Brion Vibber, Timo Tijhof, Chris Steipp, Max Semenik, Marko Obrovac,
Alexandros Kosiaris, Jon Robson, Gabriel Wicke, and others who have helped
me develop, test, instrument, and deploy Graph extension and Graphoid
service. I also would like to thank the Vega team for making this amazing
library.
--Yurik
On 05/04/2015 08:07 AM, Guillaume Paumier wrote:
> * You can now chat with other users
> <https://www.mediawiki.org/wiki/Conpherence> in Phabricator. [1]
> <https://phabricator.wikimedia.org/T91392>
Uh, why? Where was this actually discussed with more than 4 people? We
already have IRC and mailing lists, so why do we need yet another
communication system? Are we going to be enabling Phriction next?
Please turn it off.
-- Legoktm
In the next RFC meeting, we will discuss the following RFCs:
* Request timeouts and retries
<https://phabricator.wikimedia.org/T97204>
* Re-evaluate varnish-level request-restart behavior on 5xx
<https://phabricator.wikimedia.org/T97206>
The meeting will be on the IRC channel #wikimedia-office on
chat.freenode.net at the following time:
* UTC: Wednesday 21:00
* US PDT: Wednesday 14:00
* Europe CEST: Wednesday 23:00
* Australia AEST: Thursday 07:00
-- Tim Starling
I've noticed that the image previews in Hovercards ('Popups' extension) do
not respect high-density displays and can end up a little blurry because of
this.
While patching the extension, someone recommended to me to bracket the
detected density to the values we use for default thumb generation on the
wiki (the 1, 1.5, and 2x densities we specify in 'srcset' attribute on
<img>s), so browsers that are zoomed slightly off from default or devices
that are not quite on the most common densities don't force extra thumbnail
renders.
Do folks have any preference for whether I should add that as a separate
function like $.bracketedDevicePixelRatio() or just directly bracket the
output of the $.devicePixelRatio wrapper function?
A quick look at code using $.devicePixelRatio() indicates most uses are
multiplying an image size to get a thumbnail, so that might be convenient
but I don't want to cause surprises. ;)
Task: https://phabricator.wikimedia.org/T97935
Core patch: https://gerrit.wikimedia.org/r/#/c/208820/
Hovercards patch: https://gerrit.wikimedia.org/r/#/c/208515/
Current version of the patch adds a separate $.bracketedDevicePixelRatio().
-- brion