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.ji@gmail.com

On Tue, Nov 3, 2015 at 2:10 AM, Florian Schmidt < florian.schmidt.welzow@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/Ex... [2] https://github.com/wikimedia/mediawiki/blob/master/docs/extension.schema.jso...

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

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.ji@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