Mariya Nedelcheva
Miteva
Sent: Tuesday, February 12, 2013 9:23 AM
To: Daniel Barrett; Wikimedia developers
Subject: Re: [Wikitech-l] Stable PHP API for MediaWiki ?
By the way, Daniel, have you had similar problems with your next upgrades?
Maybe things have indeed improved since your post about
I understand from your comments that keeping things stable and
preserving
compatibiliy HAS been a priority for core developers at least since
Daniel's email. Is this really the case? If this is the case, it
makes me
wonder why I hear some complaints about it.
Mariya, but did you hear that man
By the way, Daniel, have you had similar problems with your next upgrades?
Maybe things have indeed improved since your post about 1.18
Mariya
On Tue, Feb 12, 2013 at 3:14 PM, Maria Miteva wrote:
> Hi everyone,
>
> I guess it is a little difficult for me to describe what I mean since I am
> jus
Hi everyone,
I guess it is a little difficult for me to describe what I mean since I am
just rephrasing what I've heard from others. I am still waiting for some
more specific examples. However, I think most people are facing the kind of
problems which Daniel has so well described in his post to t
Le 11/02/13 19:58, vita...@yourcmc.ru a écrit :
>> 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)
>>
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
norma
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
>
> 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:co
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 l
Le 11/02/13 13:58, Mariya Nedelcheva Miteva a écrit :
> 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.
That has been kind
Hello Mariya,
I'm not a WMF developer, but in my opinion, MediaWiki is already a
fairly stable product. I personally had no problems with any PHP API
changes :-) and I think it would be good if you provide some examples -
what changes were a problem for someone?
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 Medi
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 coul
I don't see how something like parser functions, wiki syntax extensions,
skins, and many other extensions could feasibly be done using the Web-API.
2013/2/11 Yuri Astrakhan
> I have a blasphemous proposal... extensions should only use the public API
> via FauxRequest objects. The public API int
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 suc
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 wrote:
> I believe Mariya is talking about the internal APIs available to
> extensions,
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 c
Hi Yuri,
As I haven't created an extension myself( which I realize is a huge problem
when talking about this kind of a problem ), is this feasable for more
complex extensiosns? If yes, why are people not doing it? Is is just
because of lack of information?
Mariya
On Mon, Feb 11, 2013 at 3:47 PM
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 wrote:
> I don't
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 the
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 wrote:
> Mariya,
>
> Could you be more specific? What types of changes caused extensions t
Mariya,
Could you be more specific? What types of changes caused extensions to
break? I might be mistaken but the vast majority of the API framework
classes have been established over 5 years ago, with very few breaking
changes since. Most changes were related to adding new functionality (new
acti
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
d
23 matches
Mail list logo
