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

[Marcin Cieslak]

On 2015-11-02, Jason Ji  wrote:
> 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);

You might want to see how ProofreadPage solved related problems:

https://phabricator.wikimedia.org/T39483

and the fix in 98bb44055a9a44429ab40d9ff71375eb79379d24
by your truly (although at the time it didn't use NS_xxx anymore).

~saper


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

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

[Jason Ji]

Hi Florian,

There are times when I want to use constants for readability without using
raw strings. The namespace example could be arguable - perhaps it's better
to let an experienced MediaWiki administrator choose a different namespace
to avoid collisions if necessary, although on the flip side we may not want
an inexperienced admin accidentally setting NS_COMMENTSTREAMS to 0. But for
another example, CS_COMMENTS_EXPANDED or CS_COMMENTS_COLLAPSED are two
options that the user chooses from. I'd rather have the user set a variable
in LocalSettings.php like:

$wgFakeChoice = CS_COMMENTS_EXPANDED;

Rather than something like either of these:

$wgFakeChoice = 0;
$wgFakeChoice = "expanded";

Does that make sense?

Thanks for pointing out that extension.json actually does (silently)
support constants. Is there a reason it's not documented?

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

On Tue, Nov 3, 2015 at 2:10 AM, Florian Schmidt <
florian.schmidt.wel...@t-online.de> wrote:

> 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 jason.y...@gmail.com
> An: Wikimedia developers wikitech-l@lists.wikimedia.org
>
> 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 mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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 jason.y...@gmail.com
An: Wikimedia developers wikitech-l@lists.wikimedia.org

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