On Tue, Aug 11, 2015 at 11:11 AM, Legoktm legoktm.wikipe...@gmail.com
wrote:
I assume these wiki pages would be some kind of structured
ContentHandler pages? We could restrict editing those fields to the
application owners then?
By wiki pages I meant wikitext pages. I think in terms of
To refocus the discussion on OAuth (no superprotect and copyright issues
here please :), the field with legal relevance is the privacy policy of the
application (and maybe its terms of service if we add such a thing in the
future). Any time you use, say, CropTool, the tool operator has access
to
OK, this sounds like a level of sensitivity greater than what I think is
appropriate for a standard wiki page, and possibly greater than for
standard admin full protection. If Special:* is the only or best way to
achieve that, so be it.
Pine
On Tue, Aug 11, 2015 at 2:11 PM, Gergo Tisza
Language choice. Tidy is written in C. Note that I included shelling
out to Node.js as an option in my original post. It's not really part
of Parsoid, it's a JavaScript library that Parsoid uses. We would use
the same JavaScript library with a few lines of wrapper code.
-- Tim Starling
On
We currently have editable pages on Wikimedia sites with important legal
strings, and AFAIK no one has caused a noteworthy incident by editing or
vandalizing them. (Cc'ing Maggie to ask for verification.) However, the
term attack vector gets my attention. Is there a way to keep the pages in
wiki
What is the recommended path for updating extensions if you are still
using the 1.23.x series? After the update announcement today, I tried
downloading the 1.23 version of each of the extensions that we use from
the Extension Distributor. Each of the downloads appears to be the same
as the old
2015-08-11 0:54 GMT+03:00 Chad innocentkil...@gmail.com:
I would like to announce the release of MediaWiki 1.25.2, 1.24.3, and
1.23.10.
Can merge patches to master be added to the release checklist so that
sites running form master, such as translatewiki.net, can update promptly,
please. This
Interesting article about how various sites/apps switched away from the
hamburger and to the more conventional tab bar, with tangible results:
http://deep.design/the-hamburger-menu/
--
EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle
IRC: bgerstle
On Tue, Aug 11, 2015 at 2:21 AM Niklas Laxström niklas.laxst...@gmail.com
wrote:
2015-08-11 0:54 GMT+03:00 Chad innocentkil...@gmail.com:
I would like to announce the release of MediaWiki 1.25.2, 1.24.3, and
1.23.10.
Can merge patches to master be added to the release checklist so that
On Mon, Aug 10, 2015 at 7:13 PM, Ricordisamoa ricordisa...@openmailbox.org
wrote:
Since the current REST API is available under v1, my take is the v0
API :-)
That name sucks because it implies that the REST API is supposed to replace
it.
--
Brad Jorsch (Anomie)
Senior Software Engineer
I support Bob or leaving it as it currently is, with time we will simply
start using mediawiki or core api more and more often.
Vito
2015-08-11 15:24 GMT+02:00 Brad Jorsch (Anomie) bjor...@wikimedia.org:
On Mon, Aug 10, 2015 at 7:13 PM, Ricordisamoa
ricordisa...@openmailbox.org
wrote:
No, no, old tech that needs to keep running is called classic! ;-)
On Tue, Aug 11, 2015 at 2:24 PM Brad Jorsch (Anomie) bjor...@wikimedia.org
wrote:
On Mon, Aug 10, 2015 at 7:13 PM, Ricordisamoa
ricordisa...@openmailbox.org
wrote:
Since the current REST API is available under v1, my take
Last night I tweaked the listing at https://en.wikipedia.org/api/ to read:
* Action API, providing rich queries, editing and content access.
* REST API v1, mainly focused on high-volume content access.
The PHP prefix seemed to confuse some, thinking that it was a
PHP-specific API.
Another
On Mon, Aug 10, 2015 at 11:43 PM, Pine W wiki.p...@gmail.com wrote:
We currently have editable pages on Wikimedia sites with important legal
strings, and AFAIK no one has caused a noteworthy incident by editing or
vandalizing them.
There are several cases that I'm aware of where
I am familiar with other incidents myself, and would not consider
moving away from the existing system premature optimization. I would
consider it sanity. We exist in a situation where wikis can
individually customise, say, the copyright release associated with
edits. Changing that is A Good
Would keeping sensitive pages in wikitext format under full protection
(meaning that only local administrators can edit) be sufficient?
Pine
On Aug 11, 2015 9:38 AM, Oliver Keyes oke...@wikimedia.org wrote:
I am familiar with other incidents myself, and would not consider
moving away from the
Hi,
On 08/10/2015 06:23 PM, Gergo Tisza wrote:
tl;dr should OAuth [1] (the system by which external tools can register to
be Wikimedia applications and users can grant them the right to act in
their name) rely on community-maintained description pages or profile forms
filled by application
On Wed, Aug 12, 2015 at 1:44 AM, Pine W wiki.p...@gmail.com wrote:
Would keeping sensitive pages in wikitext format under full protection
(meaning that only local administrators can edit) be sufficient?
This is asking for trouble. Even if all our admins acted sensibly all the
time - and if
Ok, it sounds like using a Special:* for OAuth info would be prudent.
That's unfortunate for usability reasons, but the security considerations
appear to be more important.
Pine
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
Jim Tittsler j...@onjapan.net writes:
What is the recommended path for updating extensions if you are still
using the 1.23.x series?
Generally, extensions don't update their release branches. Sometimes
you can use the latest from master's HEAD for an extension, but breaking
changes happen
Yeah, the same thought crossed my mind. Unfortunately, superprotect has
such a well-earned negative reputation in the community that I don't think
it will ever be welcomed even in situations like this where it might be
sensible. An alternative might be to devolve the superprotect right to
Il 11/08/2015 20:10, Risker ha scritto:
On 11 August 2015 at 13:07, Mr. Stradivarius misterst...@gmail.com wrote:
On Wed, Aug 12, 2015 at 1:44 AM, Pine W wiki.p...@gmail.com wrote:
Would keeping sensitive pages in wikitext format under full protection
(meaning that only local administrators
Well, therein lies the problem. If a community goes rogue, and wants to
selectively change the copyright terms for their project, stewards (under
the current standards of behaviour) would pretty much be obligated to do
that - even though it's contrary to a lot of other things. We can't put
Given that MediaWiki namespace pages are already admin-only, not really.
On 11 August 2015 at 12:44, Pine W wiki.p...@gmail.com wrote:
Would keeping sensitive pages in wikitext format under full protection
(meaning that only local administrators can edit) be sufficient?
Pine
On Aug 11, 2015
On 11 August 2015 at 13:07, Mr. Stradivarius misterst...@gmail.com wrote:
On Wed, Aug 12, 2015 at 1:44 AM, Pine W wiki.p...@gmail.com wrote:
Would keeping sensitive pages in wikitext format under full protection
(meaning that only local administrators can edit) be sufficient?
This is
FYI Ori also shared this link on the design list today, and there's been
some interesting discussion there:
https://lists.wikimedia.org/pipermail/design/2015-August/002366.html
J
On Tue, Aug 11, 2015 at 3:47 AM, Brian Gerstle bgers...@wikimedia.org
wrote:
Interesting article about how various
Il 03/08/2015 22:08, C. Scott Ananian ha scritto:
On Sat, Aug 1, 2015 at 2:23 AM, Ricordisamoaricordisa...@openmailbox.org
wrote:
Il 31/07/2015 21:08, C. Scott Ananian ha scritto:
I agree that we have not (to date) spent a lot of time on APIs supporting
direct editing of the Parsoid DOM. I
The patch implementing this functionality
https://gerrit.wikimedia.org/r/#/c/230646/ was just merged. We therefore
expect that this will therefore go out to production next week with the
normal MediaWiki deployment train.
Dan
On 10 August 2015 at 14:36, Dan Garry dga...@wikimedia.org wrote:
I'm not sure about that, but let's take the Superprotect discussion to a
different thread if we're going to continue on that subject. (:
Back to the subject of Oauth. Legoktm assuming that Superprotect isn't
applied, can you think of a way to protect the relevant pages in wiki page
format that
I'm elevating this task of mine to RFC status:
https://phabricator.wikimedia.org/T89331
Running the output of the MediaWiki parser through HTML Tidy always
seemed like a nasty hack. The effects on wikitext syntax are arbitrary
and change from version to version. When we upgrade our Linux
On Tue, Aug 11, 2015 at 5:16 PM, Trevor Parscal tpars...@wikimedia.org
wrote:
Is it possible use part of the Parsoid code to do this?
It is possible to do this in Parsoid (or any node service) with this line:
var sanerHTML = domino.createDocument(input).outerHTML;
However, performance is
Interesting. What is the cause of the slower speed?
- Trevor
On Tuesday, August 11, 2015, Gabriel Wicke gwi...@wikimedia.org wrote:
On Tue, Aug 11, 2015 at 5:16 PM, Trevor Parscal tpars...@wikimedia.org
javascript:;
wrote:
Is it possible use part of the Parsoid code to do this?
It is
Is it possible use part of the Parsoid code to do this?
- Trevor
On Tuesday, August 11, 2015, Tim Starling tstarl...@wikimedia.org wrote:
I'm elevating this task of mine to RFC status:
https://phabricator.wikimedia.org/T89331
Running the output of the MediaWiki parser through HTML Tidy
TL;DR: Join us to discuss Templates, Page Components editing on Thu, 13
August, 12:45 – 14:00 PDT [0].
Hello all,
Recent discussions, including the pre-Wikimania content brainstorming
[2][3], brought up several important questions about the next steps for
MediaWiki's and particularly
On Tue, Aug 11, 2015 at 5:24 PM, Trevor Parscal tpars...@wikimedia.org
wrote:
Interesting. What is the cause of the slower speed?
Mainly a pure-JS DOM implementation (domino) not being quite the same speed
as C or Rust with all optimizations turned on. The deltas are roughly in
line with
As many OAuth tools are semi-automated, they're prime candidates for being
interesting ways to help our most active users make contributions on mobile
devices while they're on the go. The OAuth workflow is pretty poorly
designed for this at the moment, but it has a lot of potential.
Generally,
36 matches
Mail list logo
