CanastaWiki / Canasta

MediaWiki Docker image for Canasta, an all-in-one MediaWiki stack for easy deployment and management of enterprise-ready MediaWiki on production environments.
https://www.canasta.wiki
MIT License
36 stars 27 forks source link

Load Bootstrap extension if Chameleon loaded during manual (non-CLI) install #148

Closed lotusccong closed 1 year ago

lotusccong commented 1 year ago

I followed the steps to manually install and create a new wiki site. After Mediawiki finished the installation and created the LocalSetting.php . I did copy the LocalSetting.php into config/ Run docker-compose down, then docker-compose up -d . When I access to https://localhost . It showed this error message localhost is currently unable to handle this request. HTTP ERROR 500

The LocalSetting.php as below

<?php

This file was automatically generated by the MediaWiki 1.35.8

installer. If you make manual changes, please keep track in case you

need to recreate them later.

#

See includes/DefaultSettings.php for all configurable settings

and their default values, but don't forget to make changes in this

file, not there.

#

Further documentation for configuration settings may be found at:

https://www.mediawiki.org/wiki/Manual:Configuration_settings

Protect against web entry

if ( !defined( 'MEDIAWIKI' ) ) { exit; }

Uncomment this to disable output compression

$wgDisableOutputCompression = true;

$wgSitename = "True Buddha Canasta"; $wgMetaNamespace = "True_Buddha_Canasta";

The URL base path to the directory containing the wiki;

defaults for all runtime URL paths are based off of this.

For more information on customizing the URLs

(like /w/index.php/Page_title to /wiki/Page_title) please see:

https://www.mediawiki.org/wiki/Manual:Short_URL

$wgScriptPath = "/w";

The protocol and server name to use in fully-qualified URLs

$wgServer = "https://localhost";

The URL path to static resources (images, scripts, etc.)

$wgResourceBasePath = $wgScriptPath;

The URL paths to the logo. Make sure you change this from the default,

or else you'll overwrite your logo when you upgrade!

$wgLogos = [ '1x' => "$wgResourceBasePath/resources/assets/wiki.png" ];

UPO means: this is also a user preference option

$wgEnableEmail = true; $wgEnableUserEmail = true; # UPO

$wgEmergencyContact = "apache@🌻.invalid"; $wgPasswordSender = "apache@🌻.invalid";

$wgEnotifUserTalk = false; # UPO $wgEnotifWatchlist = false; # UPO $wgEmailAuthentication = true;

Database settings

$wgDBtype = "mysql"; $wgDBserver = "db"; $wgDBname = "my_wiki"; $wgDBuser = "root"; $wgDBpassword = "mediawiki";

MySQL specific settings

$wgDBprefix = "";

MySQL table options to use during installation or update

$wgDBTableOptions = "ENGINE=InnoDB, DEFAULT CHARSET=binary";

Shared database table

This has no effect unless $wgSharedDB is also set.

$wgSharedTables[] = "actor";

Shared memory settings

$wgMainCacheType = CACHE_NONE; $wgMemCachedServers = [];

To enable image uploads, make sure the 'images' directory

is writable, then set this to true:

$wgEnableUploads = false; $wgUseImageMagick = true; $wgImageMagickConvertCommand = "/usr/bin/convert";

InstantCommons allows wiki to use images from https://commons.wikimedia.org

$wgUseInstantCommons = false;

Periodically send a pingback to https://www.mediawiki.org/ with basic data

about this MediaWiki instance. The Wikimedia Foundation shares this data

with MediaWiki developers to help guide future development efforts.

$wgPingback = true;

If you use ImageMagick (or any other shell command) on a

Linux server, this will need to be set to the name of an

available UTF-8 locale. This should ideally be set to an English

language locale so that the behaviour of C library functions will

be consistent with typical installations. Use $wgLanguageCode to

localise the wiki.

$wgShellLocale = "C.UTF-8";

Set $wgCacheDirectory to a writable directory on the web server

to make your wiki go slightly faster. The directory should not

be publicly accessible from the web.

$wgCacheDirectory = "$IP/cache";

Site language code, should be one of the list in ./languages/data/Names.php

$wgLanguageCode = "en";

$wgSecretKey = "5f8726ae5dfa4d24b4cef4d86f33f9f6bb02867d1887cab172999c2ab649e18a";

Changing this will log out all existing sessions.

$wgAuthenticationTokenVersion = "1";

Site upgrade key. Must be set to a string (default provided) to turn on the

web installer while LocalSettings.php is in place

$wgUpgradeKey = "7eb104780b2e864a";

For attaching licensing metadata to pages, and displaying an

appropriate copyright notice / icon. GNU Free Documentation

License and Creative Commons licenses are supported so far.

$wgRightsPage = ""; # Set to the title of a wiki page that describes your license/copyright $wgRightsUrl = ""; $wgRightsText = ""; $wgRightsIcon = "";

Path to the GNU diff3 utility. Used for conflict resolution.

$wgDiff3 = "/usr/bin/diff3";

Default skin: you can change the default skin. Use the internal symbolic

names, ie 'vector', 'monobook':

$wgDefaultSkin = "vector";

Enabled skins.

The following skins were automatically enabled:

wfLoadSkin( 'chameleon' ); wfLoadSkin( 'CologneBlue' ); wfLoadSkin( 'MinervaNeue' ); wfLoadSkin( 'Modern' ); wfLoadSkin( 'MonoBook' ); wfLoadSkin( 'pivot' ); wfLoadSkin( 'Refreshed' ); wfLoadSkin( 'Timeless' ); wfLoadSkin( 'Vector' );

End of automatically generated settings.

Add more configuration options below.

jeffw16 commented 1 year ago

Immediately after the next time you visit https://localhost, please run:

sudo docker compose logs web

And see what the bottom of the output shows. If nothing abnormal appears, then try to run

sudo docker compose exec web tail /var/log/apache2/error.log

lotusccong commented 1 year ago

Got this error message debian@debian11:~$ sudo docker compose logs web no configuration file provided: not found debian@debian11:~$ sudo docker compose exec web tail /var/log/apache2/error.log no configuration file provided: not found

amalpaul54111 commented 1 year ago

I followed the steps to manually install and create a new wiki site. After Mediawiki finished the installation and created the LocalSetting.php . I did copy the LocalSetting.php into config/ Run docker-compose down, then docker-compose up -d . When I access to https://localhost . It showed this error message localhost is currently unable to handle this request. HTTP ERROR 500

I, too, had the same issue when I tried it. This could be due to this particular line, wfLoadSkin( 'chameleon' ); in LocalSettings.php. As the web container's log does show.

PHP Fatal error:  Uncaught ExtensionDependencyError: chameleon requires Bootstrap to be installed.
lotusccong commented 1 year ago

Hi Amal, Yes, you are right. After removed wfLoadSkin( 'chameleon' );. It works. :-).

yaronkoren commented 1 year ago

Sorry that I'm responding so late. Does anyone know how all those skins are getting automatically enabled in Canasta? I thought only Vector was automatically enable.

jeffw16 commented 1 year ago

I think this started happening with Canasta 1.2.0, when the symlinking resulted in all skins being loaded in the skins directory automatically. I am guessing MediaWiki automatically loaded these skins into LocalSettings.php during the setup process. We should find a way to stop this from happening, since we already preload Vector.

yaronkoren commented 1 year ago

Okay, that's obviously really bad, if so. I just changed the title again to make this clearer - sorry for overwriting your change.

jeffw16 commented 1 year ago

I like your new title better Yaron, thanks!

yaronkoren commented 1 year ago

Sorry, I changed the title yet again, now that I think I better understand this issue. The problem, I think, comes when using the standard MediaWiki installer GUI - which includes checkboxes (checked by default) for enabling all the existing skins. We could try to change the GUI - but maybe the better solution is to make sure that the Bootstrap extension gets loaded if the Chameleon skin does.

yaronkoren commented 1 year ago

Okay, having looked more into this (and talked it over with @gitmapd), I think the problem is in this file, in core MediaWiki:

https://phabricator.wikimedia.org/source/mediawiki/browse/master/includes/installer/LocalSettingsGenerator.php

It takes all the extensions and skins that the user selected in the GUI, and adds a wfLoad...() call for each one of them to LocalSettings.php. Unfortunately, it ignores any requirements that any of those extensions and skins have. Also unfortunately, it doesn't contain any hooks or some such to let us add to the set of extensions or skins.

I suppose the ideal fix would be to get a patch in to this file to have it read every extension.json and skin.json file of the selected extensions and skins, find all the requirements, and then include those also. I don't know how easy that would be to get into core MediaWiki, though. For now, I think we should just locally patch this file, to have it include some code like "if the set of skins includes Chameleon, and the set of extensions does not include Bootstrap, add Bootstrap to the set of extensions". Ideally within the __construct() function.

There are other required extensions and so forth - all the SMW-based extensions obviously require SMW - but this Chameleon one is the most notable, I think, because the GUI installer checks all the skin checkboxes by default (and none of the extension checkboxes). Clearly, based on the bug reports, Chameleon/Bootstrap is the big one. But in theory the code could handle other requirements also.

This would be, I think, our first-ever patch to core MediaWiki - which is kind of annoying, but I don't see another real solution here.

jeffw16 commented 1 year ago

I support the patch for now. Thank you @gitmapd for helping to investigating! Many kudos go to you.

yaronkoren commented 1 year ago

Cool. I just want to correct my earlier statement: Canasta does indeed already have two patches to core MediaWiki - I didn't realize that before. But they're both going away, I think, with MW 1.39, so this new patch will then be the only core patch. (And one of very few patches in general.)