Re: [Wikitech-l] What is "revision slot" and why is it necessary to specify it now?

[Daniel Kinzler]

Am 05.04.20 um 23:18 schrieb Petr Bena:
> But still, I am curious what is the recommended approach for someone
> who wants to develop their application "properly" in a way that it's
> backward compatible? First query the MediaWiki version via API, and
> based on that decide how to call APIs? I can't think of any other way.

Yes, that's indeed the only way if the client is to be entirely generic. Though
deprecated API behavior tends to stay supported for quite a while,  much longer
than deprecated PHP methods. So checking the MediaWiki version first would only
be needed if you wanted your code to work with a wide range of MediaWiki 
versions.

Also, most clients are not totally agnostic to the wiki they run against. E.g.
pywikibot has per-wiki configuration, which could easily include the wiki
version. So no query would be necessary. Similarly, JS code running on the site
has access to the version from JS variables.

-- 
Daniel Kinzler
Principal Software Engineer, Core Platform
Wikimedia Foundation

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] What is "revision slot" and why is it necessary to specify it now?

[Petr Bena]

Aha thanks for the update. To give you some context, I would like to
fix https://phabricator.wikimedia.org/T249460 the main problem as I
see now, is that this looks like a seriously breaking change to me
(but maybe I am overlooking something). If I change the API call to
work with rvslots, I doubt it's going to work at all with MediaWiki <
1.32, on other hand, future versions of MW may stop working with older
parameters.

I don't see an easy way out here for applications that want to work
flawlessly with as many MW versions as possible. In case of Huggle,
it's not really so big deal, it's mostly used with Wikimedia wikis and
I believe we are consistently on newest version on all production
wikis. Huggle can be used on 3rd party MediaWiki installations too,
where this could be a serious issue, but I doubt there are too many
users who actually use it outside of Wikimedia world (and if there
are, they can just stick with older Huggle if they don't want to
upgrade their wiki installation).

But still, I am curious what is the recommended approach for someone
who wants to develop their application "properly" in a way that it's
backward compatible? First query the MediaWiki version via API, and
based on that decide how to call APIs? I can't think of any other way.

On Sun, Apr 5, 2020 at 11:10 PM Daniel Kinzler  wrote:
>
> Thanks for bringing this up.
>
> I have made some updates to the documentation in mediawiki.org to make clear
> that MCR is not work in progress. While support is not complete in all parts 
> of
> MediaWiki, the storage layer has been implemented and the database has been
> migrated to the new system.
>
> Am 05.04.20 um 22:17 schrieb Petr Bena:
> > Hello,
> >
> > https://www.mediawiki.org/wiki/API:Revisions mentions "revision slots"
> > multiple times, but fails to explain what it is?
> >
> > I noticed that some queries that were running fine in the past now
> > have warning: "Because "rvslots" was not specified, a legacy format
> > has been used for the output. This format is deprecated, and in the
> > future the new format will always be used."
> >
> > Which is interesting, but not very descriptive. What are revision
> > slots? Why are they needed? What is difference between "legacy format"
> > and "new format"? If rvslots are so important, why they aren't part of
> > some of the examples?
> >
> > So far I googled this: https://www.mediawiki.org/wiki/Manual:Slot it
> > seems like some new "work-in-progress" feature, that isn't very useful
> > yet, as there is only 1 slot in existence.
> >
> > Is it necessary to pay attention to this? Can I simply silence this
> > warning by providing parameter rvslots=*? Or should I pay it some
> > deeper attention?
> >
> > Thanks
> >
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
>
> --
> Daniel Kinzler
> Principal Software Engineer, Core Platform
> Wikimedia Foundation

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] What is "revision slot" and why is it necessary to specify it now?

[Daniel Kinzler]

Thanks for bringing this up.

I have made some updates to the documentation in mediawiki.org to make clear
that MCR is not work in progress. While support is not complete in all parts of
MediaWiki, the storage layer has been implemented and the database has been
migrated to the new system.

Am 05.04.20 um 22:17 schrieb Petr Bena:
> Hello,
> 
> https://www.mediawiki.org/wiki/API:Revisions mentions "revision slots"
> multiple times, but fails to explain what it is?
> 
> I noticed that some queries that were running fine in the past now
> have warning: "Because "rvslots" was not specified, a legacy format
> has been used for the output. This format is deprecated, and in the
> future the new format will always be used."
> 
> Which is interesting, but not very descriptive. What are revision
> slots? Why are they needed? What is difference between "legacy format"
> and "new format"? If rvslots are so important, why they aren't part of
> some of the examples?
> 
> So far I googled this: https://www.mediawiki.org/wiki/Manual:Slot it
> seems like some new "work-in-progress" feature, that isn't very useful
> yet, as there is only 1 slot in existence.
> 
> Is it necessary to pay attention to this? Can I simply silence this
> warning by providing parameter rvslots=*? Or should I pay it some
> deeper attention?
> 
> Thanks
> 
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> 

-- 
Daniel Kinzler
Principal Software Engineer, Core Platform
Wikimedia Foundation

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] What is "revision slot" and why is it necessary to specify it now?

[Brian Wolff]

It is where a page can have multiple content handlers associated with it.

The most common example is commons file pages. They have normal wikitext
page, but they also have a slot containing wikidata-style data structured
data.

Whether or not you have to worry about this depends on what you're doing.
For most things probably no, but more things might have multiple slots in
the future.

--
Bawolff

On Sunday, April 5, 2020, Petr Bena  wrote:

> Hello,
>
> https://www.mediawiki.org/wiki/API:Revisions mentions "revision slots"
> multiple times, but fails to explain what it is?
>
> I noticed that some queries that were running fine in the past now
> have warning: "Because "rvslots" was not specified, a legacy format
> has been used for the output. This format is deprecated, and in the
> future the new format will always be used."
>
> Which is interesting, but not very descriptive. What are revision
> slots? Why are they needed? What is difference between "legacy format"
> and "new format"? If rvslots are so important, why they aren't part of
> some of the examples?
>
> So far I googled this: https://www.mediawiki.org/wiki/Manual:Slot it
> seems like some new "work-in-progress" feature, that isn't very useful
> yet, as there is only 1 slot in existence.
>
> Is it necessary to pay attention to this? Can I simply silence this
> warning by providing parameter rvslots=*? Or should I pay it some
> deeper attention?
>
> Thanks
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] What is "revision slot" and why is it necessary to specify it now?

[Petr Bena]

Hello,

https://www.mediawiki.org/wiki/API:Revisions mentions "revision slots"
multiple times, but fails to explain what it is?

I noticed that some queries that were running fine in the past now
have warning: "Because "rvslots" was not specified, a legacy format
has been used for the output. This format is deprecated, and in the
future the new format will always be used."

Which is interesting, but not very descriptive. What are revision
slots? Why are they needed? What is difference between "legacy format"
and "new format"? If rvslots are so important, why they aren't part of
some of the examples?

So far I googled this: https://www.mediawiki.org/wiki/Manual:Slot it
seems like some new "work-in-progress" feature, that isn't very useful
yet, as there is only 1 slot in existence.

Is it necessary to pay attention to this? Can I simply silence this
warning by providing parameter rvslots=*? Or should I pay it some
deeper attention?

Thanks

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Running JS for parser function preview in Visual Editor

[Jeroen De Dauw]

Hey Szabó,

Thanks for the pointers - much appreciated.

My impression is that the approach you are talking about is great for
creating a high level of integration with Visual Editor. I've looked at
Kartographer which is doing something similar. However at this point I just
want the map JS to be executed appropriately. Writing 2000+ lines of JS for
this is not reasonable. Probably I don't need quite that much, but it is
hard to tell. It certainly seems like I'd end up with way more code and
coupling to VE than I have now, making my current hack preferable. Or is
registering minimal DM/CE stuff really short and decoupled?

Cheers

--
Jeroen De Dauw | www.EntropyWins.wtf 
Professional wiki hosting and services: www.Professional.Wiki

Entrepreneur | Software Crafter | Open Source | Wikimedia | Speaker
~=[,,_,,]:3
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Running JS for parser function preview in Visual Editor

[Máté Szabó]

Hi Jeroen,

I think you need to register a custom DM (DataModel)[1] and CE 
(ContentEditable)[2] node implementation for this extension tag inside 
VisualEditor to control their rendering and how the user can interact with 
them. Unfortunately, I am not sure if there is documentation (apart from the 
generated JSDoc) for these APIs, so I tend to refer to usage patterns in 
existing extensions when working with them. The Graph extension is an example 
of an extension that leverages these APIs to customise the behaviour of an 
extension tag that relies on JS libraries inside the VE.[3]

Hope this helps!

—
[1] https://doc.wikimedia.org/VisualEditor/master/#!/api/ve.dm.MWExtensionNode
[2] https://doc.wikimedia.org/VisualEditor/master/#!/api/ve.ce.MWExtensionNode
[3] 
https://github.com/wikimedia/mediawiki-extensions-Graph/tree/master/modules/ve-graph

Cheers,
Máté Szabó 
SOFTWARE ENGINEER

Fandom Poland sp. z o.o. z siedzibą w Poznaniu, ul. Abp. A. Baraniaka 6
Sąd Rejonowy Poznań – Nowe Miasto i Wilda w Poznaniu, VIII Wydział Gospodarczy 
Krajowego Rejestru Sądowego, KRS 254365
NIP: 5252358778
Kapitał zakładowy: 50.000,00 złotych

> On 4 Apr 2020, at 23:46, Jeroen De Dauw  wrote:
> 
> Hey,
> 
> I am maintainer of the Maps extension for MediaWiki.
> https://github.com/JeroenDeDauw/Maps#maps
> 
> Recently I worked on improving integration with Visual Editor. Maps used to
> not show up as a grey box [0] since their initialization JavaScript was not
> being run. I got things working but am not happy with the solution and hope
> there is a better approach.
> 
> After some searching I found that if I ran the initialization code in a
> handler to the ve.activationComplete hook, the maps would get initialized
> as desired [1]. That is not a complete solution though, since you can edit
> the maps with Visual Editor [2]. This causes an API request that parses the
> new wikitext to HTML, which then replaces the old HTML of the initialized
> map. So initialization needs to happen again.
> 
> An hour or two searching through the docs and Visual Editor code did not
> yield any usable hook/event. (This was quite surprising to me. Has no one
> ever done something similar to what I am doing here?) So I settled on just
> running initialization once every second with setInterval(). I found the
> ve.deactivationComplete hook which I then used to stop the code running
> every second on saving and existing the visual editor. Turns out that when
> opening the visual editor after that does not result in a new
> ve.activationComplete event, hence I had to remove termination of the
> repeating initialization.
> 
> Surely there is a better way to run my code once per second (ad infinitum)
> starting with Visual Editor activation? The perfect event for my usecase
> would be "visual editor rendered a parser function". A broader event (ie
> "something got rendered") would still be better than nothing.
> 
> You can see my current code here [3], including a few commented out bits
> which I left in so you can see some of what did not work.
> 
> [0]
> https://user-images.githubusercontent.com/146040/78461765-18d15780-76cc-11ea-82cd-eb69d0179fd7.png
> [1]
> https://user-images.githubusercontent.com/146040/78461769-21299280-76cc-11ea-9461-a2c343062482.png
> [2]
> https://user-images.githubusercontent.com/146040/78461779-369ebc80-76cc-11ea-9495-4a91a24a.png
> [3]
> https://github.com/JeroenDeDauw/Maps/blob/7.17.1/resources/leaflet/LeafletLoader.js#L24-L45
> 
> Cheers
> 
> --
> Jeroen De Dauw | www.EntropyWins.wtf 
> Professional wiki hosting and services: www.Professional.Wiki
> 
> Entrepreneur | Software Crafter | Open Source | Wikimedia | Speaker
> ~=[,,_,,]:3
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l