Re: [Wikitech-l] MW 1.25 extension registration - PHP constants redux

[Florian Schmidt]

Hi again :)

> new extension registration doesn't support PHP constants
That's not entirely correct ;) Extension Registration supports constants[1], 
even if it's not documented[2]. But you should really try to avoid such hacks. 
For your case: Why do you don't use a configuration variable, if you want, that 
a user has the ability to configure something in/for your extension? So instead 
of the constant NS_COMMENTSTREAMS you could add a configuration variable 
$wgCommenStreamsNS which defaults to 1000.

[1] 
https://github.com/wikimedia/mediawiki/blob/REL1_25/includes/registration/ExtensionRegistry.php#L235-L237
[2] 
https://github.com/wikimedia/mediawiki/blob/master/docs/extension.schema.json

Best
Florian

-Original-Nachricht-
Betreff: [Wikitech-l] MW 1.25 extension registration - PHP constants redux
Datum: Mon, 02 Nov 2015 23:41:01 +0100
Von: Jason Ji 
An: Wikimedia developers 

Hi all,

Sorry to be spamming this list due to my own incompetence. I'm basically
doing an upgrade-a-thon of our various extensions to the new extension
format, and therefore running into issues as I go.

In a previous email I discussed a problem I was having with the fact that
the new extension registration doesn't support PHP constants, which I was
using for explicit dependencies. Now I'm working on upgrading another
extension where I use PHP constants to allow users to configure options for
my extension.

My extension is called CommentStreams. In the old registration approach,
inside of CommentStreams.php, I had three constants defined:

define('NS_COMMENTSTREAMS', 1000);
define('CS_COMMENTS_EXPANDED', 0);
define('CS_COMMENTS_COLLAPSED', 1);

NS_COMMENTSTREAMS is a custom namespace I define using the
CanonicalNamespaces hook, but I wanted to expose this variable through a
PHP constant so users could configure the extension in LocalSettings.php,
for example for use with $wgNamespacesToBeSearchedDefault:

$wgNamespacesToBeSearchedDefault[NS_COMENTSTREAMS] = true;

(Of course I could just require the user of my extension to define
NS_COMMENTSTREAMS in their own LocalSettings.php, but I wanted to
encapsulate it in the extension so they wouldn't have to worry about it.)

The story with CS_COMMENTS_EXPANDED and CS_COMMENTS_COLLAPSED is similar -
internally defined constants that I wanted to expose for users to be able
to use to configure things in LocalSettings.php.

With the new extension registration, I tried to put these constant
definitions inside of the custom registration
/www.mediawiki.org/wiki/Manual:Extension_registration#Customizing_registration>
callback function, hoping that this callback would be called before the
rest of LocalSettings.php is parsed, so the usage could remain something
like this:

wfLoadExtension('CommentStreams');
$wgNamespacesToBeSearchedDefault[NS_COMMENTSTREAMS] = true;
// other configuration with CS_COMMENTS_EXPANDED or CS_COMMENTS_COLLAPSED

However, that doesn't seem to be the case - I get warnings of defined
constants all over the place, breaking my functionality.

Is there a way around this? Alternatively, if this is bad coding practice
(I do not profess to be well versed in good PHP convention, and I'm still
learning good MediaWiki convention), is there a better way to handle this?

Thanks for the assistance!

--
Jason Ji
jason.y...@gmail.com
___
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] MW 1.25 extension registration - PHP constants redux

[Jason Ji]

Hi all,

Sorry to be spamming this list due to my own incompetence. I'm basically
doing an upgrade-a-thon of our various extensions to the new extension
format, and therefore running into issues as I go.

In a previous email I discussed a problem I was having with the fact that
the new extension registration doesn't support PHP constants, which I was
using for explicit dependencies. Now I'm working on upgrading another
extension where I use PHP constants to allow users to configure options for
my extension.

My extension is called CommentStreams. In the old registration approach,
inside of CommentStreams.php, I had three constants defined:

define('NS_COMMENTSTREAMS', 1000);
define('CS_COMMENTS_EXPANDED', 0);
define('CS_COMMENTS_COLLAPSED', 1);

NS_COMMENTSTREAMS is a custom namespace I define using the
CanonicalNamespaces hook, but I wanted to expose this variable through a
PHP constant so users could configure the extension in LocalSettings.php,
for example for use with $wgNamespacesToBeSearchedDefault:

$wgNamespacesToBeSearchedDefault[NS_COMENTSTREAMS] = true;

(Of course I could just require the user of my extension to define
NS_COMMENTSTREAMS in their own LocalSettings.php, but I wanted to
encapsulate it in the extension so they wouldn't have to worry about it.)

The story with CS_COMMENTS_EXPANDED and CS_COMMENTS_COLLAPSED is similar -
internally defined constants that I wanted to expose for users to be able
to use to configure things in LocalSettings.php.

With the new extension registration, I tried to put these constant
definitions inside of the custom registration

callback function, hoping that this callback would be called before the
rest of LocalSettings.php is parsed, so the usage could remain something
like this:

wfLoadExtension('CommentStreams');
$wgNamespacesToBeSearchedDefault[NS_COMMENTSTREAMS] = true;
// other configuration with CS_COMMENTS_EXPANDED or CS_COMMENTS_COLLAPSED

However, that doesn't seem to be the case - I get warnings of defined
constants all over the place, breaking my functionality.

Is there a way around this? Alternatively, if this is bad coding practice
(I do not profess to be well versed in good PHP convention, and I'm still
learning good MediaWiki convention), is there a better way to handle this?

Thanks for the assistance!

--
Jason Ji
jason.y...@gmail.com
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Discovery & Reading Showcase 20151028

[Adam Baso]

Hi all -

The Discovery and Reading product/engineering verticals did a merged
showcase last week for people to demonstrate new work and experiments.

https://www.youtube.com/watch?v=LNAQD4RCeWM

Enjoy!

The first 7 minutes or so the opening slide deck isn't showing (the people
in the room are showing instead). See
https://upload.wikimedia.org/wikipedia/commons/b/be/IOS_Wikipedia_App_5.0_Update.pdf
for the corresponding, actually expanded, slide deck. Starting at 7:43 the
hands on demos begin.

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

Re: [Wikitech-l] MW 1.25 new extension registration - PHP constants

[S Page]

On Oct 30, 2015 11:06, "Florian Schmidt" 
wrote:

[Thanks for helping the developer community!]

> I'm wondering, if dependencies like yours are widely used and if
extending the requires section support to extensions would help to solve
your problem (with that you could specify a specific version, a range of
version or any version above a specific one, or all versions, too, so your
VIKIJS_VERSION wouldn't be needed anymore, too).

That sounds like
https://m.mediawiki.org/wiki/Requests_for_comment/Improving_extension_management
, also at  https://phabricator.wikimedia.org/T88596 from the task:

"on dependencies between extensions -- I don't think there is consensus on
whether to specify those dependencies in extension.json or composer.json
(TimStarling, 21:36:55)"

> Would you like to open a task in phabricator to discuss this?

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

Re: [Wikitech-l] Tech Talk: Nothing Left but Always Right: The Twisted Road to RTL Support: November 2

[Rachel Farrand]

Reminder: This talk is starting in 35 min

On Wed, Oct 28, 2015 at 1:53 PM, Rachel Farrand 
wrote:

> Please join for the following tech talk:
>
> *Tech Talk**:* Nothing Left but Always Right: The Twisted Road to RTL
> Support
> *Presenter:* Moriel Schottlender
> *Date:* November 02, 2015
> *Time: *20:00 UTC
> 
>
> Link to live YouTube stream 
> *IRC channel for questions/discussion:* #wikimedia-office
> Google+ page
> ,
>  another
> place for questions
>
> *Summary: *There are roughly 500 million speakers of Right-to-Left
> languages all over the world, and 16 RTL Wikipedias, but support of
> right-to-left languages on the Web in general is so abysmal that it is hard
> to find a single piece of software that properly supports all the necessary
> behaviors. And yet, that's exactly what we're committed on doing for
> Wikipedia's right-to-left users.
> This talk will demonstrate the challenges that the web poses for Right to
> Left languages, some of the solutions that are available, and some of the
> work we've been doing to make RTL users' experience better.
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] MW 1.25 new extension registration - PHP constants

[Jason Ji]

Thank you Florian! I moved the dependency check to a function in
$wgExtensionFunctions and that did the trick.

Jason

--
Jason Ji
jason.y...@gmail.com

On Mon, Nov 2, 2015 at 11:48 AM, Florian Schmidt <
florian.schmidt.wel...@t-online.de> wrote:

> Hi Jason,
>
> you're right, the call to the callback is before[1] the loaded extensions
> are added to the array[2] which is the backend for isLoaded(). You need to
> put the dependency check after the extensions are loaded, e.g. into the
> wgExtensionFunctions array[3], which is currently loaded after the load and
> execution of LocalSettings.php (including wfLoadExtensions()s execution).
>
> [1]
> https://github.com/wikimedia/mediawiki/blob/e87668e86ce9ad20df05c1baa8e7cf3f58900524/includes/registration/ExtensionRegistry.php#L279
> [2]
> https://github.com/wikimedia/mediawiki/blob/e87668e86ce9ad20df05c1baa8e7cf3f58900524/includes/registration/ExtensionRegistry.php#L282
> [3] https://www.mediawiki.org/wiki/Manual:$wgExtensionFunctions
>
> -Ursprüngliche Nachricht-
> Von: Wikitech-l [mailto:wikitech-l-boun...@lists.wikimedia.org] Im
> Auftrag von Jason Ji
> Gesendet: Montag, 2. November 2015 17:15
> An: Wikimedia developers 
> Betreff: Re: [Wikitech-l] MW 1.25 new extension registration - PHP
> constants
>
> Hi Florian (or others),
>
> This morning I tried to implement Florian's suggestion of using
> ExtensionRegistry::getInstance()->isLoaded( 'ExtensionName' ) to check
> dependencies, but ran into a roadblock. Hoping someone can help me out, and
> I'll try to summarize what the problem is.
>
> I've converted *VIKI *and *VikiTitleIcon *to the new extension
> registration format. VikiTitleIcon depends on VIKI and prior to the new
> extension registration format, it used to check for the *VIKIJS_VERSION*
> PHP constant, else die(), as I described in my previous email. I wasn't
> sure exactly where to use the new isLoaded() call in VikiTitleIcon, so I
> took a best guess and used custom registration <
> https://www.mediawiki.org/wiki/Manual:Extension_registration#Customizing_registration
> >
> to specify a 'callback' function, wherein I check for isLoaded('VIKI') or
> die() otherwise. I've confirmed that my callback is being called, but
> unfortunately, this always causes the system to think that VIKI is not
> loaded and dies, regardless of whether I've included
> wfLoadExtension('VIKI') in LocalSettings.php.
>
> I'm guessing that this has something to do with the order of execution for
> registering extensions, and perhaps VIKI is only queued up for registration
> with the ExtensionRegistry but hasn't finished registration before the
> VikiTitleIcon registration callback gets called, so isLoaded('VIKI') is
> returning false. But I'm not sure, because I don't know anything about the
> internal workings of ExtensionRegistry. If the callback of VikiTitleIcon is
> not the correct place to check for the loading of VIKI, is there a better
> place?
>
> Thanks,
>
> --
> Jason Ji
> jason.y...@gmail.com
>
> On Fri, Oct 30, 2015 at 3:36 PM, Jason Ji  wrote:
>
> > And thanks to you for suggesting the idea and getting on it so quickly!
> >
> > --
> > Jason Ji
> > jason.y...@gmail.com
> >
> > On Fri, Oct 30, 2015 at 3:35 PM, Florian Schmidt <
> > florian.schmidt.wel...@t-online.de> wrote:
> >
> >> Hi,
> >>
> >> thanks for opening the task! :) I was free and started to work on
> >> this some minutes ago, because I really like the idea, so I already
> >> added a change to gerrit, before anyone has the chance to discuss
> >> this :( But I hope, that we get such a function into
> >> ExtensionRegistration! Big thanks again for bringing this up.
> >>
> >> Best,
> >> Florian
> >>
> >> -Ursprüngliche Nachricht-
> >> Von: Wikitech-l [mailto:wikitech-l-boun...@lists.wikimedia.org] Im
> >> Auftrag von Jason Ji
> >> Gesendet: Freitag, 30. Oktober 2015 20:25
> >> An: Wikimedia developers 
> >> Betreff: Re: [Wikitech-l] MW 1.25 new extension registration - PHP
> >> constants
> >>
> >> Hi Florian,
> >>
> >> Thanks! For my immediate purposes, I think just doing the isLoaded()
> >> check will probably suffice, as I don't actually have any need to
> >> check versions at the moment. But I agree with your suggestion,
> >> extending the 'requires'
> >> section of extension.json does seem like it would be very helpful and
> >> extension developer-friendly, and that's a great idea.
> >>
> >> I've opened a Phabricator task here
> >> , but feel free to tweak
> >> it if I've described something poorly or didn't tag it correctly -
> >> I've never actually created a task in Phabricator before.
> >>
> >> Thanks!
> >>
> >> --
> >> Jason Ji
> >> jason.y...@gmail.com
> >>
> >> On Fri, Oct 30, 2015 at 2:06 PM, Florian Schmidt <
> >> florian.schmidt.wel...@t-online.de> wrote:
> >>
> >> > You can, in your php extension code, so not inside the
> >> > extension.json, check, if another extension is installed or not:
> >> >
> >> > ExtensionRegistry::getInsta

[Wikitech-l] Chrome Devtools Tips & Tricks

[Stephen Niedzielski]

Hello web devs! There was a pretty neat article trending on Hacker News
recently that gave some pointers on Chrome Devtools. Check it out!

https://news.ycombinator.com/item?id=10416062

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

Re: [Wikitech-l] Reserving data-mw- attribute prefix in the sanitizer as non-user specifiable

[Subramanya Sastry]

On 11/02/2015 05:11 AM, Brian Wolff wrote:

We already reserve data-ooui (by reserve, I mean blacklist in the
sanitizer). But it feels wrong to use that for parts of mw that are
not ooui. I would like to propose that we reserve data-mw- prefix as
well for general usage by mediawiki/extensions (By which I mean that
any attribute starting with data-mw-, would be blocked by the
sanitizer. Thus if a user writes on a wikipage , the data-mw-foo attribute would be
stripped). Thus if javascript sees such an attribute, it can know for
sure that the value is not direct untrusted user-input.


Parsoid currently generates data-parsoid and data-mw attributes. data-mw 
attribute is used to convey semantic information in the HTML (images, 
templates, extensions) as per 
https://www.mediawiki.org/wiki/Parsoid/MediaWiki_DOM_spec


So, "data-mw" itself as an attribute should not be used by extensions, 
but, "data-mw-" as a prefix should be fine.


If it encounters data-mw or data-parsoid in wikitext HTML tags, it 
renames them with a data-x- prefix (as below).


[subbu@earth tests] echo "data-parsoid='bar'>x" | node parse --normalize

x

That is another possibility for dealing with conflicting attributes, but 
not sure what purpose that might serve. For Parsoid, we have to do this 
so that we preserve the original wikitext unchanged. So, blacklisting 
seems fine in this case. Whenever that is done, we should consider 
adding data-parsoid and data-mw to that list of blacklisted attributes 
so we can get rid of the attribute-renaming code in Parsoid.


Subbu.



Anyone have any objections to doing this?

Bikeshed now about the choice of name for the prefix, or forever hold
your peace ;)

--
-bawolff

___
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

Re: [Wikitech-l] MW 1.25 new extension registration - PHP constants

[Florian Schmidt]

Hi Jason,

you're right, the call to the callback is before[1] the loaded extensions are 
added to the array[2] which is the backend for isLoaded(). You need to put the 
dependency check after the extensions are loaded, e.g. into the 
wgExtensionFunctions array[3], which is currently loaded after the load and 
execution of LocalSettings.php (including wfLoadExtensions()s execution).

[1] 
https://github.com/wikimedia/mediawiki/blob/e87668e86ce9ad20df05c1baa8e7cf3f58900524/includes/registration/ExtensionRegistry.php#L279
[2] 
https://github.com/wikimedia/mediawiki/blob/e87668e86ce9ad20df05c1baa8e7cf3f58900524/includes/registration/ExtensionRegistry.php#L282
[3] https://www.mediawiki.org/wiki/Manual:$wgExtensionFunctions

-Ursprüngliche Nachricht-
Von: Wikitech-l [mailto:wikitech-l-boun...@lists.wikimedia.org] Im Auftrag von 
Jason Ji
Gesendet: Montag, 2. November 2015 17:15
An: Wikimedia developers 
Betreff: Re: [Wikitech-l] MW 1.25 new extension registration - PHP constants

Hi Florian (or others),

This morning I tried to implement Florian's suggestion of using 
ExtensionRegistry::getInstance()->isLoaded( 'ExtensionName' ) to check 
dependencies, but ran into a roadblock. Hoping someone can help me out, and 
I'll try to summarize what the problem is.

I've converted *VIKI *and *VikiTitleIcon *to the new extension registration 
format. VikiTitleIcon depends on VIKI and prior to the new extension 
registration format, it used to check for the *VIKIJS_VERSION* PHP constant, 
else die(), as I described in my previous email. I wasn't sure exactly where to 
use the new isLoaded() call in VikiTitleIcon, so I took a best guess and used 
custom registration 

to specify a 'callback' function, wherein I check for isLoaded('VIKI') or
die() otherwise. I've confirmed that my callback is being called, but 
unfortunately, this always causes the system to think that VIKI is not loaded 
and dies, regardless of whether I've included
wfLoadExtension('VIKI') in LocalSettings.php.

I'm guessing that this has something to do with the order of execution for 
registering extensions, and perhaps VIKI is only queued up for registration 
with the ExtensionRegistry but hasn't finished registration before the 
VikiTitleIcon registration callback gets called, so isLoaded('VIKI') is 
returning false. But I'm not sure, because I don't know anything about the 
internal workings of ExtensionRegistry. If the callback of VikiTitleIcon is not 
the correct place to check for the loading of VIKI, is there a better place?

Thanks,

--
Jason Ji
jason.y...@gmail.com

On Fri, Oct 30, 2015 at 3:36 PM, Jason Ji  wrote:

> And thanks to you for suggesting the idea and getting on it so quickly!
>
> --
> Jason Ji
> jason.y...@gmail.com
>
> On Fri, Oct 30, 2015 at 3:35 PM, Florian Schmidt < 
> florian.schmidt.wel...@t-online.de> wrote:
>
>> Hi,
>>
>> thanks for opening the task! :) I was free and started to work on 
>> this some minutes ago, because I really like the idea, so I already 
>> added a change to gerrit, before anyone has the chance to discuss 
>> this :( But I hope, that we get such a function into 
>> ExtensionRegistration! Big thanks again for bringing this up.
>>
>> Best,
>> Florian
>>
>> -Ursprüngliche Nachricht-
>> Von: Wikitech-l [mailto:wikitech-l-boun...@lists.wikimedia.org] Im 
>> Auftrag von Jason Ji
>> Gesendet: Freitag, 30. Oktober 2015 20:25
>> An: Wikimedia developers 
>> Betreff: Re: [Wikitech-l] MW 1.25 new extension registration - PHP 
>> constants
>>
>> Hi Florian,
>>
>> Thanks! For my immediate purposes, I think just doing the isLoaded() 
>> check will probably suffice, as I don't actually have any need to 
>> check versions at the moment. But I agree with your suggestion, 
>> extending the 'requires'
>> section of extension.json does seem like it would be very helpful and 
>> extension developer-friendly, and that's a great idea.
>>
>> I've opened a Phabricator task here
>> , but feel free to tweak 
>> it if I've described something poorly or didn't tag it correctly - 
>> I've never actually created a task in Phabricator before.
>>
>> Thanks!
>>
>> --
>> Jason Ji
>> jason.y...@gmail.com
>>
>> On Fri, Oct 30, 2015 at 2:06 PM, Florian Schmidt < 
>> florian.schmidt.wel...@t-online.de> wrote:
>>
>> > You can, in your php extension code, so not inside the 
>> > extension.json, check, if another extension is installed or not:
>> >
>> > ExtensionRegistry::getInstance()->isLoaded( 'ExtensionName' );
>> >
>> > There's also a "requires" section, which is parsed in 
>> > extension.json, but it currently only supports MediaWiki core 
>> > versions (it behaves like composer's requires section). I'm 
>> > wondering, if dependencies like yours are widely used and if 
>> > extending the requires section support to extensions would help to 
>> > solve your problem (with that you could specify a 

[Wikitech-l] OOjs UI 0.13.0 Release (breaking change)

[James Forrester]

Hey all,

OOjs UI 0.13.0 was released last week. It will be in MW from 1.27.0-wmf.5+,
which will be deployed to production in the regular train starting
tomorrow. As there are a couple of nominal breaking changes and a
deprecation, please look carefully over them to determine if they affect
your code.


*Breaking changes since last release:*

   - [BREAKING CHANGE] Remove aliases for OO.ui.mixins (C. Scott Ananian)

   We deprecated the old names of the mixins system in v0.11.4 in June,
   when we adopted the new naming system. We believe we have remedied all
   known users of the deprecated code (VisualEditor, Echo, Flow,
   MobileFrontend, Graph and Citoid all have had changes made to compensate).

   - [BREAKING CHANGE] Turn Element#gatherPreInfuseState into a static
   method (Bartosz Dziewoński)

   This is a nominal breaking change; there are no known users of this
   feature, which we are improving for performance, cleanliness and usability;
   expect more soon.


*Deprecating change since last release:*

   - [DEPRECATING CHANGE] SelectFileWidget: Rename dragDropUI option to
   showDropTarget (Ed Sanders)

   We renamed the option `dragDropUI`, a boolean which controlled whether
   the SelectFileWidget would display a drag-and-drop target UI element,
   has been renamed to `showDropTarget`. The old option name still works
   for now, but will be removed in v0.15.0.

   - [DEPRECATING CHANGE] TextInputWidget: Add getValidity function,
   deprecate isValid (Prateek Saxena)

   Despite the naming of this function, it returned a Promise, not a
   boolean. The new getValidity function works better and is named sanely.
   The isValid() function still works for now, but will be removed in v0.15.0.


Additional details are in the full change log

. This is the first breaking change since v0.12.0 was released in July;
since then there have been 252 code changes to the library by 22
developers; my thanks to all of them. If you have any further questions or
need help dealing with deprecations, please let me know. As always, general
library documentation is available at  mediawiki.org
 and generated code-level documentation
and interactive demos at doc.mediawiki.org
.

Yours,
-- 
James D. Forrester
Lead Product Manager, Editing
Wikimedia Foundation, Inc.

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

Re: [Wikitech-l] MW 1.25 new extension registration - PHP constants

[Jason Ji]

Hi Florian (or others),

This morning I tried to implement Florian's suggestion of using
ExtensionRegistry::getInstance()->isLoaded( 'ExtensionName' ) to check
dependencies, but ran into a roadblock. Hoping someone can help me out, and
I'll try to summarize what the problem is.

I've converted *VIKI *and *VikiTitleIcon *to the new extension registration
format. VikiTitleIcon depends on VIKI and prior to the new extension
registration format, it used to check for the *VIKIJS_VERSION* PHP
constant, else die(), as I described in my previous email. I wasn't sure
exactly where to use the new isLoaded() call in VikiTitleIcon, so I took a
best guess and used custom registration

to specify a 'callback' function, wherein I check for isLoaded('VIKI') or
die() otherwise. I've confirmed that my callback is being called, but
unfortunately, this always causes the system to think that VIKI is not
loaded and dies, regardless of whether I've included
wfLoadExtension('VIKI') in LocalSettings.php.

I'm guessing that this has something to do with the order of execution for
registering extensions, and perhaps VIKI is only queued up for registration
with the ExtensionRegistry but hasn't finished registration before the
VikiTitleIcon registration callback gets called, so isLoaded('VIKI') is
returning false. But I'm not sure, because I don't know anything about the
internal workings of ExtensionRegistry. If the callback of VikiTitleIcon is
not the correct place to check for the loading of VIKI, is there a better
place?

Thanks,

--
Jason Ji
jason.y...@gmail.com

On Fri, Oct 30, 2015 at 3:36 PM, Jason Ji  wrote:

> And thanks to you for suggesting the idea and getting on it so quickly!
>
> --
> Jason Ji
> jason.y...@gmail.com
>
> On Fri, Oct 30, 2015 at 3:35 PM, Florian Schmidt <
> florian.schmidt.wel...@t-online.de> wrote:
>
>> Hi,
>>
>> thanks for opening the task! :) I was free and started to work on this
>> some minutes ago, because I really like the idea, so I already added a
>> change to gerrit, before anyone has the chance to discuss this :( But I
>> hope, that we get such a function into ExtensionRegistration! Big thanks
>> again for bringing this up.
>>
>> Best,
>> Florian
>>
>> -Ursprüngliche Nachricht-
>> Von: Wikitech-l [mailto:wikitech-l-boun...@lists.wikimedia.org] Im
>> Auftrag von Jason Ji
>> Gesendet: Freitag, 30. Oktober 2015 20:25
>> An: Wikimedia developers 
>> Betreff: Re: [Wikitech-l] MW 1.25 new extension registration - PHP
>> constants
>>
>> Hi Florian,
>>
>> Thanks! For my immediate purposes, I think just doing the isLoaded()
>> check will probably suffice, as I don't actually have any need to check
>> versions at the moment. But I agree with your suggestion, extending the
>> 'requires'
>> section of extension.json does seem like it would be very helpful and
>> extension developer-friendly, and that's a great idea.
>>
>> I've opened a Phabricator task here
>> , but feel free to tweak it
>> if I've described something poorly or didn't tag it correctly - I've never
>> actually created a task in Phabricator before.
>>
>> Thanks!
>>
>> --
>> Jason Ji
>> jason.y...@gmail.com
>>
>> On Fri, Oct 30, 2015 at 2:06 PM, Florian Schmidt <
>> florian.schmidt.wel...@t-online.de> wrote:
>>
>> > You can, in your php extension code, so not inside the extension.json,
>> > check, if another extension is installed or not:
>> >
>> > ExtensionRegistry::getInstance()->isLoaded( 'ExtensionName' );
>> >
>> > There's also a "requires" section, which is parsed in extension.json,
>> > but it currently only supports MediaWiki core versions (it behaves
>> > like composer's requires section). I'm wondering, if dependencies like
>> > yours are widely used and if extending the requires section support to
>> > extensions would help to solve your problem (with that you could
>> > specify a specific version, a range of version or any version above a
>> > specific one, or all versions, too, so your VIKIJS_VERSION wouldn't be
>> needed anymore, too).
>> > Would you like to open a task in phabricator to discuss this?
>> >
>> > Best,
>> > Florian
>> >
>> > -Ursprüngliche Nachricht-
>> > Von: Wikitech-l [mailto:wikitech-l-boun...@lists.wikimedia.org] Im
>> > Auftrag von Jason Ji
>> > Gesendet: Freitag, 30. Oktober 2015 17:00
>> > An: wikitech-l@lists.wikimedia.org
>> > Betreff: [Wikitech-l] MW 1.25 new extension registration - PHP
>> > constants
>> >
>> > Hi there,
>> >
>> > I'm the primary developer of the VIKI
>> >  extension and its two
>> > companion extensions, VikiSemanticTitle <
>> > https://www.mediawiki.org/wiki/Extension:VikiSemanticTitle> and
>> > VikiTitleIcon .
>> >
>> > I thought I'd take a look at converting these three extensions to the
>> > new extension registration <
>> > https://www

[Wikitech-l] Reserving data-mw- attribute prefix in the sanitizer as non-user specifiable

[Brian Wolff]

Occasionally its useful to pass trusted data to javascript using data
attributes on elements that you know is not from the user. In the
past, there has been security issues from using the data attribute for
information that is assumed to be trusted, but in reality could be
messed with by the user. (T58699, T105413)

We already reserve data-ooui (by reserve, I mean blacklist in the
sanitizer). But it feels wrong to use that for parts of mw that are
not ooui. I would like to propose that we reserve data-mw- prefix as
well for general usage by mediawiki/extensions (By which I mean that
any attribute starting with data-mw-, would be blocked by the
sanitizer. Thus if a user writes on a wikipage , the data-mw-foo attribute would be
stripped). Thus if javascript sees such an attribute, it can know for
sure that the value is not direct untrusted user-input.

Anyone have any objections to doing this?

Bikeshed now about the choice of name for the prefix, or forever hold
your peace ;)

--
-bawolff

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