Re-adding sample calls to cfLoadExtension(), cfLoadSkin()

32 views
Skip to first unread message

Yaron Koren

unread,
Jun 1, 2022, 2:05:16 PM6/1/22
to Canasta
Hi everyone,

The original spec for Canasta involved populating LocalSettings.php with commented-out calls to cfLoadExtension() and cfLoadSkin() for every extension and skin included in Canasta - to make it easier for admins to install any of them. However, in March, these calls were removed:


I think that's because there's now an alternate way to install extensions and skins, which is by adding one or more custom files to the settings/ directory, so they shouldn't necessarily go into LocalSettings.php - although I'm not sure that's the reason.

The code that creates the commented-out calls still exists - it places all these calls into two files, installedExtensions.txt and installedSkins.txt, but then nothing is done with these files:


It does seem nice to be able to see sample calls for all the bundled extensions and skins - maybe especially for Semantic MediaWiki, which still requires that extra enableSemantics() call for some reason, but really for all of them. But maybe it's not really necessary.

I can see five real options here:

1) Remove this code from the Dockerfile - there's no need to have these sample calls.
2) Keep the code, and document the presence of installedExtensions.txt and installedSkins.txt, so that admins can know where to find the sample calls.
3) Populate some file with these sample calls - maybe not LocalSettings.php, but maybe a file called LocalSettings.php.sample or something like that.
4) Go back to just pre-populating LocalSettings.php.
5) Remove the code, but add all these sample calls to some page on the Canasta website, as part of the documentation; so admins can copy and paste as needed.

Any thoughts?

-Yaron

Jeffrey Wang

unread,
Jun 14, 2022, 2:47:43 AM6/14/22
to Canasta
Yaron and I discussed this and we think #5 is the best choice.

#1 is a good alternative to #5 if we are lazy ;)
#2 is a decent idea, but I don't see why we need to add extra cruft to the codebase when we could just move it to the documentation.
#3 would go against our principle of being neutral and unopinionated.
#4 is a really bad idea because it would be very opinionated and do stuff to LocalSettings.php that I assume would annoy most people instead of being helpful.

Yaron Koren

unread,
Jun 14, 2022, 9:05:06 AM6/14/22
to Jeffrey Wang, Canasta
Hi,

To be clear, Jeffrey and I did discuss this, but I don't remember expressing a strong opinion. Jeffrey - it's good to know that you support #5, i.e. just removing the sample calls.

I also want to clarify that being neutral and unopinionated is not actually a Canasta principle. :) It's neutral on some things - like which of its extensions should be enabled - but obviously not neutral on things like which extensions and skins get bundled in. Jeffrey - by "opinionated" for #3 and #4, did you mean that they express an opinion on whether settings should be contained in LocalSettings.php or in other files within the settings/ directory? If so, for #3 that could be resolved by just changing the file name to something else, like WikiSettings.php.sample.

--
You received this message because you are subscribed to the Google Groups "Canasta" group.
To unsubscribe from this group and stop receiving emails from it, send an email to canasta-wiki...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/canasta-wiki/d80d7f3e-8128-457e-bbf6-161ad8a2d6e1n%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


--
WikiWorks · MediaWiki Consulting · http://wikiworks.com

Ike Hecht

unread,
Jun 23, 2022, 9:27:47 AM6/23/22
to Canasta
#3 sort of. I think it would be good to keep the calls in a PHP file and that way if someone wants to enable all the extensions they can just do a require(). And I don't like the idea of keeping it on the Canasta web site. Anything like this and even documentation should be kept as much as feasible with the code since Canasta features could change with each version.

Yaron Koren

unread,
Jun 23, 2022, 10:07:22 AM6/23/22
to Ike Hecht, Canasta
Hi,

This makes sense, and I think I agree with #3 - just have a file with all the calls (commented out, presumably), with a neutral name like WikiSettings.php.sample or CanastaSampleSettings.php or some such. It would only require adding a few more lines to the Dockerfile. Having the calls on the website would indeed lead to a mismatch for people using an older version of Canasta, with a different set of extensions and skins. 

On Thu, Jun 23, 2022 at 9:27 AM Ike Hecht <i...@wikiteq.com> wrote:
#3 sort of. I think it would be good to keep the calls in a PHP file and that way if someone wants to enable all the extensions they can just do a require(). And I don't like the idea of keeping it on the Canasta web site. Anything like this and even documentation should be kept as much as feasible with the code since Canasta features could change with each version.


Ike Hecht

unread,
Jun 23, 2022, 2:15:04 PM6/23/22
to Yaron Koren, Canasta
I was thinking we could have them not commented out. It would allow people to just include everything because why not? Users could also copy and paste from there if they want to choose specific extensions.
--

Ike Hecht

Chief Technology Officer

WikiTeq




(561) 888-0837
i...@wikiteq.com
wikiteq.com


Yaron Koren

unread,
Jun 23, 2022, 3:08:08 PM6/23/22
to Ike Hecht, Canasta
Having them uncommented actually does make more sense, yes.

Any thoughts on the name of the file - and most specifically, whether it should end in ".php" (and thus be includable) or something like ".php.sample"?

Ike Hecht

unread,
Jun 23, 2022, 3:12:52 PM6/23/22
to Yaron Koren, Canasta
I like a .php that doesn't get included by default.

Yaron Koren

unread,
Jun 23, 2022, 6:44:57 PM6/23/22
to Ike Hecht, Canasta
That also seems fine. How about "CanastaSampleSettings.php"?

Jeffrey Wang

unread,
Jun 24, 2022, 1:27:22 PM6/24/22
to Yaron Koren, Ike Hecht, Canasta
I don't like the idea of including these calls in a sample file in the code because I think it's unnecessary cruft that power users don't want and we will have the ability to centralize this info on the docs rather than hide them in the orchestrator package code where they would be ignored. I'd rather see it in a wiki or a MintyDocs-like per-version documentation site. Personally, I dislike extensions like CirrusSearch, which tell people to go to their README to parse through the (unreadable) setup instructions and which can't be edited without making a pull request. CanastaSampleSettings.php would need to include everything, right? And leaving them uncommented will lead to people copying the entire code and wondering why they have some extensions installed that change MediaWiki in a way they don't want.

--
You received this message because you are subscribed to the Google Groups "Canasta" group.
To unsubscribe from this group and stop receiving emails from it, send an email to canasta-wiki...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.


--

Jeffrey Wang

MyWikis

U.S. Central Daylight Time (UTC-05:00)

 jw...@mywikis.com

 mywikis.com


Yaron Koren

unread,
Jun 26, 2022, 9:07:50 PM6/26/22
to Jeffrey Wang, Ike Hecht, Canasta
Well, I still don't like the idea of putting these sample calls on the website and/or the documentation. But maybe the real best answer is #1 - i.e., don't bother with sample calls at all? After all, for almost all of these extensions and skins, the way to install them is super-simple - add a cfLoadExtension() or cfLoadSkin() call around the extension or skin name (or more accurately, the name of their folder). We hardly need 150 examples of this to drive the point home.

I think there are only two exceptions to this rule: Semantic MediaWiki (which inexplicably still requires an enableSemantics() call) and SocialProfile (which still lacks an extension.json file - I think it should be removed from Canasta for that reason, but that's a separate discussion). It would certainly be possible to add to the documentation (and maybe to LocalSettings.php as well) some basic instructions like "Use cfLoadExtension() or cfLoadSkin() for all extensions and skins except these two, which require special handling."

Basically, perhaps we've been overthinking this whole thing.

Ike Hecht

unread,
Jun 28, 2022, 6:05:34 PM6/28/22
to Yaron Koren, Jeffrey Wang, Canasta
Including something I wrote previously, but not on this group:

I think it would be cool to have a global called something like $wgCanastaDefaults = true;, which overrides the base MediaWiki settings with recommended settings for enterprise use cases. We should keep the MediaWiki defaults (by, uh, default) but allow a simple way for enterprise users to switch their defaults to more sane ones for an enterprise environment for both extensions and core.

I think it's good to give users a simple way to load all extensions, but if it sounds better, maybe we can do that via global instead of a require().

Yaron Koren

unread,
Jun 28, 2022, 7:55:22 PM6/28/22
to Ike Hecht, Jeffrey Wang, Canasta
Well, it's nice to be able to load all extensions (and skins) in theory, but in practice, how important is that ability? How many admins really would want to just load everything?

Also, a "$wgCanastaDefaults" or some such would be great (or maybe a function would be better, like cfSetDefaultSettings() ), but how does that relate to this discussion? Is the idea that the sample file with all the cfLoad... calls would also include a bunch of settings?

Ike Hecht

unread,
Jun 29, 2022, 6:27:30 PM6/29/22
to Yaron Koren, Jeffrey Wang, Canasta
We could in theory have a global or something like cfLoadExtensions( CF_ALL_EXTENSIONS ) or for that matter cfLoadExtensions( CF_MAIN_EXTENSIONS ). If everything has been tested and works, why not load everything? Most admins would want it, I think.

Yaron Koren

unread,
Jun 30, 2022, 9:54:47 AM6/30/22
to Ike Hecht, Jeffrey Wang, Canasta
I doubt that *most* admins would want to load every extension (or every skin), but it's certainly possible that some would. So it could be nice to have a "load all extensions" function. I don't think the "load main extensions" idea makes sense, though - it's hard enough to decide which extensions and skins get included in Canasta, without now having to also decide which are the "important" ones. I suppose it could potentially be useful to have other pre-defined extension sets, like a Cargo-based one, an SMW-based one, a Wikipedia-style one, etc. - although there, again, there would have to be a lot of rather arbitrary decision-making about what gets included and what doesn't. (Maybe not for a Wikipedia one, but then again we can't fully duplicate the Wikipedia experience at this point.) But "load all extensions" would be good.
Reply all
Reply to author
Forward
0 new messages