Le 05/02/13 16:02, Mark A. Hershberger a écrit :
On 02/05/2013 09:06 AM, Antoine Musso wrote:
Long story short, we have MediaWiki core published at packagist.org now:
This is awesome!
How do we get extensions into packagist?
There is no real documentation yet but one could reuse an
Hi all,
I have been talking to many third-party yas part of my WMF internship in
the last few weeks and one the main concerns they express is the lack of
stability in the PHP classes MediaWiki exposes from version to version. The
frequent changes in what I would call the PHP-API makes extentions
I believe Mariya is talking about the internal APIs available to extensions,
(eg: User, Title, EditPage, so forth), not the public API.
Yay, acronyms!
-Chad
On Mon, Feb 11, 2013 at 8:14 AM, Yuri Astrakhan yuriastrak...@gmail.com wrote:
Mariya,
Could you be more specific? What types of
I don't think she means what we call the api - but more methods random
extensions are likely to use.
We could start documenting certain stable methods with a special code
comment ( say @stable) which would mean something like this method will not
be removed, and if the need arises we'll remove
I have a blasphemous proposal... extensions should only use the public API
via FauxRequest objects. The public API interface has been very stable, and
it gives MW core devs much more flexibility with changing the innards of
the system...
On Mon, Feb 11, 2013 at 8:36 AM, bawolff
I disagree with only. Extensions dont just query the db and sometimes
extensions need to do things we cant put in a web api. But it would be *c*ool
if using the api internally was encouraged.
(Keep in mind action=parse and action=edit of the api is unsafe to call
internally at some points in the
Yes, precisely. Is there an accepted way to call it, so I don't confuse
people every time I talk about it ?
Yuri, I am working on getting some concrete examples.
Mariya
On Mon, Feb 11, 2013 at 3:24 PM, Chad innocentkil...@gmail.com wrote:
I believe Mariya is talking about the internal APIs
Maria: see http://www.mediawiki.org/wiki/API:Calling_internally for info
on calling the api internally.
However thinking about it the interface is not really well designed for
calling internally. One would expect a high level internal api would be
returning title objects. One would not expect
https://meta.wikimedia.org/wiki/Wikisource_roadmap
https://www.mediawiki.org/wiki/Extension:Proofread_Page/Roadmap
Some key items:
* making VisualEditor work with ProofreadPage
* documenting ProofreadPage better (maybe a sprint sometime soon using
Etherpads?)
* developing Wikisource ideas to go
On 02/08/2013 02:31 PM, Matthew Flaschen wrote:
I've started an RFC about making password requirements stronger, in a
workable way that is configurable by group.
See
https://www.mediawiki.org/wiki/Requests_for_comment/Password_requirements .
Matt Flaschen
Hi all,
For what I've undrstood from conversations so far the Web or HTML API is
not enough for extension developement and the variability of exposed
internal classes is often responsible for the incompatibility of extensions
with certain MediaWiki versions. Correct me if I am wrong.
We could
On 11.02.2013 20:19, Mariya Nedelcheva Miteva wrote:
Hi all,
For what I've undrstood from conversations so far the Web or HTML API is
not enough for extension developement and the variability of exposed
internal classes is often responsible for the incompatibility of extensions
with certain
Le 11/02/13 14:53, Lydia Pintscher a écrit :
* You can see an example of how wikidata works at
http://it.wikipedia.org/wiki/Marie_Curie
For those not familiar with WikiData, scroll down to the very bottom and
look at the bottom left. There is a link Modifica Link which points to
the Wikidata
1) removal of global $action
2) removal of Xml::hidden()
3) broken Output::add() (had to migrate to resource loader)
4) various parser tag bugs
5) removal of MessageCache::addMessage()
6) removal of ts_makeSortable() (javascript)
7) brokage of WikiEditor adaptation
8) MediaWiki:common.js no more
1) removal of global $action
2) removal of Xml::hidden()
3) broken Output::add() (had to migrate to resource loader)
4) various parser tag bugs
5) removal of MessageCache::addMessage()
6) removal of ts_makeSortable() (javascript)
7) brokage of WikiEditor adaptation
8) MediaWiki:common.js
vita...@yourcmc.ru writes:
I think it would be good if you provide some examples - what changes were a
problem for someone?
See extensive examples in my post about 1.18 update difficulties:
http://lists.wikimedia.org/pipermail/wikitech-l/2012-January/057486.html
DanB
Links and details, along with updates as they happen, are available on the
testing page at
http://www.mediawiki.org/wiki/Article_feedback/Version_5/Testing_Feb_2013
...
The WMF Editor Engagement team has been updating the Article Feedback tool,
improving both the back end architecture and
Google's announced that they will run Google Summer of Code again this
year, and we plan to apply. I've updated
https://www.mediawiki.org/wiki/Summer_of_Code_2013 and I'd love for
potential mentors to add their ideas to
https://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects .
Note
On 11.02.2013, 22:11 Asher wrote:
And then I'd wonder about the server side implementation. How will frontend
cache invalidation work? Are we going to need to purge every individual
article section relative to /w/api.php on edit?
Since the API doesn't require pretty URLs, we could simply
Max - good answers re: caching concerns. That leaves studying if the bytes
transferred on average mobile article view increases or decreases with lazy
section loading. If it increases, I'd say this isn't a positive direction
to go in and stop there. If it decreases, then we should look at the
On Mon, Feb 11, 2013 at 10:49 AM, Antoine Musso hashar+...@free.fr wrote:
http://www.wikidata.org/wiki/Q7186
From there our awesome community can fill information about Marie
Curie such as the interwiki links but also her place of birth, spouse
or image ...
I assume the [ add source ] is
Heya :)
We tried to deploy phase 1 on enwp today but ran into issues. We'll
have to reschedule. Currently it looks like we'll do this on
Wednesday.
Sorry folks.
Cheers
Lydia
--
Lydia Pintscher - http://about.me/lydia.pintscher
Community Communications for Wikidata
Wikimedia Deutschland e.V.
Srsly. Cool. Really.
___
Philippe Beaudette
Director, Community Advocacy
Wikimedia Foundation, Inc.
415-839-6885, x 6643
phili...@wikimedia.org
On Mon, Feb 11, 2013 at 2:52 PM, Jon Robson jdlrob...@gmail.com wrote:
-- Forwarded message --
From: Jon Robson
On Fri, Feb 8, 2013 at 8:52 AM, Chad innocentkil...@gmail.com wrote:
Rest assured--we will still be getting the latest and greatest. And we're
still
on target for late Monday/early Tuesday.
Friendly reminder that Gerrit will be coming down in about an hour
for the upgrade. During the
I'm a bit worried that now we are asking why pages are lazy loaded
rather than focusing on the fact that they currently __are doing
this___ and how we can log these (if we want to discuss this further
let's start another thread as I'm getting extremely confused doing so
on this one).
Lazy loading
Everyone,
I'm delighted to announce that Ed Sanders has joined the VisualEditor[0] team
as a software engineer from today. He will be focussed on the data structures
and APIs inside the VisualEditor, and in particular its data model component.
Ed will be working remotely from the UK.
Ed has
On 02/11/2013 09:50 AM, Brian Wolff wrote:
Maria: see http://www.mediawiki.org/wiki/API:Calling_internally for info
on calling the api internally.
I think you're misunderstanding what she's saying. She's talk about
ordinary PHP classes, methods and hooks, basically the way an extension
On Mon, Feb 11, 2013 at 6:49 PM, Chad innocentkil...@gmail.com wrote:
On Fri, Feb 8, 2013 at 8:52 AM, Chad innocentkil...@gmail.com wrote:
Rest assured--we will still be getting the latest and greatest. And we're
still
on target for late Monday/early Tuesday.
Friendly reminder that Gerrit
Thanks, Jon. To try and clarify a bit more about the API requests... they
are not made on a per-section basis. As I mentioned earlier, there are two
cases in which article content gets loaded by the API:
1) Going directly to a page (eg clicking a link from a Google search) will
result in the
Thanks for the clarification Arthur, that clears up some misconceptions I
had. I saw a demo around the allstaff where individual sections were lazy
loaded, so I think I had that in my head.
It does still seem to me that the data to determine secondary api requests
should already be present in
On Monday, February 11, 2013 at 6:33 PM, Chad wrote:
Took a few minutes longer than expected, but we're back up and
everything's live. We had to deploy a newer version to grab one
last fix we spotted during the upgrade. Our deployed version is
now 2.5.1-1266-gcc231e1.
There might be a
On Thu, Feb 7, 2013 at 1:31 PM, Daniel Barrett d...@vistaprint.com wrote:
...
1. A desire for a department to have their own space on the wiki.
I assume you looked at enabling subpages in the main namespace?[1]
That way Human Resources/Payroll/Show_me_the_money gets a nice
breadcrumb up to
On 02/11/2013 09:33 PM, Chad wrote:
There might be a few problems left over with the IRC notifications,
I'll tackle those tomorrow (making sure replication is working properly
now). If you spot any other problems, please let me know.
I'm getting Internal Server Error intermittently in the add
On Mon, Feb 11, 2013 at 11:57 PM, Matthew Flaschen
mflasc...@wikimedia.org wrote:
On 02/11/2013 09:33 PM, Chad wrote:
There might be a few problems left over with the IRC notifications,
I'll tackle those tomorrow (making sure replication is working properly
now). If you spot any other
On 2013-02-12 12:55 AM, S Page sp...@wikimedia.org wrote:
On Thu, Feb 7, 2013 at 1:31 PM, Daniel Barrett d...@vistaprint.com
wrote:
...
1. A desire for a department to have their own space on the wiki.
I assume you looked at enabling subpages in the main namespace?[1]
That way Human
On 02/11/2013 10:27 AM, Sumana Harihareswara wrote:
On 02/08/2013 02:31 PM, Matthew Flaschen wrote:
I've started an RFC about making password requirements stronger, in a
workable way that is configurable by group.
See
https://www.mediawiki.org/wiki/Requests_for_comment/Password_requirements
I really don't see the drawbacks to making the settings more configurable
as long as it defaults to currently configured settings for a wiki. As long
as what would trigger a forced password change can be controlled by the end
user of the software, I can't think anything that should stop
37 matches
Mail list logo
