I am using the Extension:Bootstrap for the Chameleon Skin and have noticed from the network waterfall in the browsers dev tools that a) that the bootstrap scripts are always loaded anew with every page, and b) that the time it takes for the bootstrap scripts to load (6-8 seconds) is the longest activity in the entire page load process.. My bootstrap installation is simple, just a composer load and the usual wfLoadExtension( 'Bootstrap' ); in LocalSettings.php.. Is this long load time behavior normal for bootstrap? Is there any way to speed it up? Thanks!
Extension talk:Bootstrap
Hallo,
is it possible to override Bootstrap's Mixins?
Kind regards,
DesignerThan
Hi everyone,
does someone know how to create those tabs?
The problem is, that the <a> - Tags are not displayed as Tabs but as HTML-Code, because this tag is not allowed by the MW-Software. On this wiki you can have a look at the issue!
Another Skin called Foreground was able to do that. Maybe someone has an idea.
Thanks, DesignerThan
If I change the <a>-Tags to <span>-Tags, the Tabs show correctly but the JS-Tabs don't work. That would be the other thing to solve. I hope someone knows how to solve that.
Have a look at the "HTML Tags" extension to get the <a> tags on board. However only feasible/advisable on closed wikis with trusted users.
I also use this extension on a wiki with Foreground to get accordions going. Currently the server hosting the demo wiki for Forground is down for maintenance so I cannot link right now.
Thanks for the fast answer. I don't know if that is a solution for us, we have a big community. The thing that throws me off is, that the Tabs from the FG-Skin also with <a>-Tags for the tab's actually work.
It appears that the "BootstrapComponens" extension does not provide tabs but all the rest.
I have browsed a bit. It seems that people are using "Header Tabs" extension to get tabs on Chameleon which is a bit derp.
Foreground is still using Foundation 5 for that reason. With Foundation 6 this will not longer work. So no upgrade to version 6.
I will have a look at BootstrapComponents as at HTML Tags. Then I will see what happens.
I had a look at the code of Foundation 5 and in the Skin Template file I found the issue why the tabs are working for them. One point is, that you need to activate the feature in the LocalSettings.php, and if that is done they don't use the content output method of MW, they just use echo to output it. That is, I guess, why the <a> tags work in the Foundation Skin.
Thanks for your help so far. We are using the Extension Header Tabs but I would like to get rid of it, don't like the style very much.
After I installed the "HTML Tags" and added the a-Tag with the following code to the allowed Tags and now the tabs work.
$wgHTMLTagsAttributes['a'] = [ 'href', 'class', 'id', 'data-toggle', 'role', 'aria-controls', 'aria-selected' ];
Do I create a threat for the wiki, if I allow the a-Tags with those attributes?
Well, you could add everything to a link by allowing the a tag. This is why it is not possible on MediaWiki. You need to trust your users or check everything they do here. If in doubt I would not do it.
MediaWiki 1.31.7 PHP 7.3.18 (apache2handler) MySQL 8.0.20 Chameleon 3.0.0
Why do I have click twice to get the drop down menu?
This was not the same as in Chameleon 1.7.1
also Chameleon 3.0.0 installs bootstrap 4.2.1 and 4.2.0 is required
This was reported with issue 166. Thanks for noting.
I installed bootstrap 4.2.0 with composer
Why do I have click twice to get the drop down menu?
This was not the same as in Chameleon 1.7.1
The second issue was reported with Chameleon issue 170.
Your requirements could not be resolved to an installable set of packages.
Problem 1 - The requested package mediawiki/bootstrap could not be found in any version, there may be a typo in the package name.
Could be that you need to allow composer to install dev packages. See https://www.mediawiki.org/wiki/Skin:Chameleon#Installation (item 3).
I believe this is how the "composer.json" file has to be set up:
{
"require": {
"php": ">=5.3.2",
"mediawiki/bootstrap": "1.*@dev"
},
"minimum-stability" : "dev",
"prefer-stable" : true
}
Hope that this is it. By the way, neither MediaWiki (alpha) nor Cameleon provide a "composer-example.json" file.
Not any more. Instead MW now has a composer.json, that you have to modify. And remember on every pull to stash and unstash. :(
Oh my gosh! Indeed, this is really going to be fun. :(
That fixed it I guess. Thanks a lot!
GoDaddy shared hosting has composer installed (version 1.7.2). My Mediawiki installation was done via cPanel installatron. The mediawiki installation folder is named "wiki". In the folder wiki/vendor resides the composer folder, the composer.json file, and the composer.lock file.
I created the composer.local.json file in the wiki folder as instructed. However whenever I run composer update --no-dev "mediawiki/bootstrap" in the wiki folder, I receive and error stating that "Composer could not find a composer.json file in path/wiki To initialize a project, please create a composer.json file as described in the --link to site-- "Getting Started" section"
I am not familiar with composer so any help would be greatly appreciated.
Why Vector skin change significantly when loading this extension?
Example screenshot
Off: https://i.imgur.com/GQYi5hz.png
On: https://i.imgur.com/M9Gr7wW.png
As you may notice everything is a lot more little after applying settings. Also margins and paddings are shorter between images and texts for example.
I'm not using any specific CSS code for format. What it's more strange it's why everything it's way more little
Code used:
$wgHooks['SetupAfterCache'][]=function(){
\Bootstrap\BootstrapManager::getInstance()->addAllBootstrapModules();
return true;
};
$wgHooks['ParserAfterParse'][]=function( Parser &$parser, &$text, StripState &$stripState ){
$parser->getOutput()->addModuleStyles( 'ext.bootstrap.styles' );
$parser->getOutput()->addModuleScripts( 'ext.bootstrap.scripts' );
return true;
};
Bootstrap (the package, not the extension) contains some styles that are invoked even if no specific classes are used on the html elements, e.g. for normalization. If you want to find out about the styles on a specific element, use your browsers developer tools.
Thanks for the answer. I was supposing so. But I thought that the extension was prepared to manage Vector skin at least (without modifications).
So it's essentially common, that Vector skin by default with bootstrap extension changes the appearance that significantly?
I would like to see if someone can make a "fix" in the future, to maintain Vector appearance, despite of Bootstrap extension introduction.
I am afraid so. This extension really only pulls the Bootstrap package in. It was originally developed as a basis for other skins and extensions (for the Chameleon skin, in particular), hence the rather complicated instructions to activate it stand-alone. However, if you want to use it with Vector it should be fairly easy to pull in additional Less files to get a similar look. You'd have to make sure of course, that any changes you introduce are still compatible with Bootstrap. E.g. I suspect that Vector might use a different box-sizing and you'd have to weigh the pros and cons of using either border-box or content-box. And you'd probably have to update that Less file whenever Vector is updated.
Another approach might be to not pull in all Bootstrap modules, but only the ones you need and hoping that Vector does not get too much out of shape. But I have to admit that I never got around to do this myself and so the methods are there, but I am not sure that they work as expected.
Finally there is also Extension:BootStrap (notice the different spelling), that claims to be "Designed and tested using the Vector Skin only", but I never tried it and I don't know if it is still maintained.
In any case, whatever solution you come up with in the end, it'd be great if you keep me updated.
Yes, I also checked that extension, but there is a problem. Download links are broken.
I installed mw1.26.4 and tried to install chameleon-skin which required the bootstrap-extension. So i downloaded mw-bootstrap-1.2.1.zip into /extensions and unzipped it and renamed it to bootstrap .
After this i edited composer.json in the root and added behind "zordius/lightncandy": "0.21",
the line "mediawiki/bootstrap:~1.0"
but i have no installation...
What is the specific reason for not following the installation instructions of Chameleon?
Only with require_once "$IP/skins/chameleon/Chameleon.php"; appears a line which request to install bootstrap : Error: The Chameleon skin depends on the Bootstrap extension. You need to install the Bootstrap extension first.
..... "zordius/lightncandy": "0.21",
"mediawiki/chameleon-skin": "~1.0",
"mediawiki/bootstrap:~1.0"
has no effect.
The problem is that i only have a provider and filezilla. I cannot execute composer.
Therefore i added the lines to composer.json but i have no installation.
If i add wfLoadExtension( 'Bootstrap' ); an error appears instead : Fatal error: Uncaught Exception: .....htdocs\mw1264/extensions/Bootstrap/extension.json does not exist! ...
(In the specific directory are composer.json and package.json) . To experimental rename composer.json to extension.json leads to Error: The Chameleon skin depends on the Bootstrap extension. You need to install the Bootstrap extension first.
Adding the lines to composer.json does not install anything. You need to execute composer. This will download the Chameleon skin and all its dependencies (including Bootstrap) and install them in the correct location.
If your provider does not provide you with shell access you can not directly install Chameleon (or any other skin or extension requiring composer). In this case you should create a local MediaWiki installation with all skins and extensions and then upload that in its entirety to the server.
- You dont see a possibility to add the wfLoadExtension-choice to the bootstrap-master ?
2. The problem will be the database. Many providers will not allow to access it from a pc. So one has to make an normal online installation and delete it with exception of localsettings.php)
(Another possibility would be to write a composer-modul-extension which can be put to 1 Minute and a very long cycle or even switched off completely)
It's not that easy. You would need to include all dependencies in a downloadable package. To maintain installability with composer you would then have to add a switch to discover and use either the composer-installed dependencies or the ones installed with the downloadable package. Next you would have to add the activation by wfLoadExtension. At that point you would have a Bootstrap extension installable on its own. Next you would have to do all of the above steps with the skin. A better solution might be to not provide a separate package for the Bootstrap extension at all, but to somehow bundle Chameleon and the Bootstrap extension and all dependencies into one package. You'd have to come up with some plan of how to install everything in the correct place. Whatever that place might be. E.g. it might be an idea for the bundle to not install the Bootstrap extension in the /extensions folder, but in some subfolder of the skin.
Regarding the database I do not see the problem. You should be able to 1. git pull MediaWiki locally, 2. add all your (non-composer) extensions and skins, 3. modify composer.local.json and 4. run composer update. Then you upload the whole thing and install as usual.
I liked to have an independent version of the skin which integrates bootstrap by #import because i can then exchange it with Yaml and import others.
Mediwiki should add a composer-tab after admin-login which presents a field with username and password (for ssh)
and a list of choosable composer - orders (inclusive update) and a run-button. But i dont know who is responsioble for that.
We get this error when we update to 1.29 from 1.27 with this extension enabled: "Fatal error: Call to a member function ucfirst() on a non-object in /srv/www/scoutwiki/htdocs-1.29/includes/user/User.php on line 1079"
Do you know why and how to fix that?
The error with ucfirst() is when loged in and the error is Fatal error: Call to a member function getCode() on a non-object in /srv/www/scoutwiki/htdocs-1.29/includes/user/User.php on line 1578 when loged out.
Could be connected with the extension using $wgUser at a time when it is not yet initialized. Could be something else completely.
If you could open an issue at https://github.com/cmln/mw-bootstrap/issues including a stack trace, that would be very much appreciated.
Opened issue.
I am getting this error. Anyone know how to fix?
More information is needed to fix this. See https://github.com/cmln/mw-bootstrap/issues/1
At first, I want to thank you for your extension! It really spares me a lot of time not having to figure out how to get Bootstrap running with MediaWiki. Unfortunately, it's not working out-of-the-box for me. I've followed the installation instructions and your extension shows up on the Special:Version page, but the Bootstrap CSS directives fail to spawn.
I'm writing an extension that uses its own content model. In fillParserOutput, where I add all my resource loader modules, I retrieve the singleton and add all Bootstrap modules via addAllBootstrapModules. However, the Bootstrap CSS directives do still not seem to apply. Is there anything I am missing or do I need to add the Bootstrap modules at another point in time?
It may be worth noting that I can not see any Bootstrap CSS/LESS files in the directory of your extension - in case they are downloaded to this one, at all.
This post was hidden by F.trott (history)
After addAllBootstrapModules you need to add the module 'ext.bootstrap' to the OutputPage.
(I've started this topic) Yeah, I'm doing exactly what the installation and the usage sections of the extension told me to. Today I've noticed that the extension actually is working if I'm in debug mode (appending 'debug=1' to the URL parameters). Is this a caching issue or what kind of sorcery is preventing the extension to work in normal mode?
It could indeed be a caching issue. If the page is retrieved from the cache, it may be that the hook you are using is never called. If that is the case it might be better to work with the ParserOutput object instead of the OutputPage.
Wouldn't this mean that everything should work fine on new pages that could impossibly be cached before? The extension doesn't show on new pages as well...until switching to debug mode!
Not necessarily. A page consists of several calls, each of which is cached separately. So if your new page uses the same styles as other pages these styles may come from the cache. Although I admit that it is sometimes not so easy to find out what is cached and what is not.
I've tried to add the Bootstrap module using the ParserOutput in the OutputPageParserOutput hook. Same results here.
Let's step back. What is the absolute minimum to get the extension running? (1) get BootstrapManager singleton and (2) add which modules are needed, e.g. all via addAllBootstrapModules. Then (3) add the Bootstrap modules, e.g. ext.bootstrap.style, via ParserOutput/OutputPage->addModuleStyles and (4) add the modules of my own extension in the same way. Are these all steps necessary and is the ordering correct?
I think that should be it.
Okay, now I'm pretty sure that is not an issue with your extension: If I register module styles within the OutputPageParserOutput hook, both your extension's and my own extension's styles are applied in debug mode only. I have no idea what's going on here... Do you know which cache could cause this issue and/or how to clear it or all caches involved?
Not sure. There is $wgParserCache, but I don't know if it is used by the Resource loader. It might also be worth seeing if the call to retrieve the styles is contained in the HTML of the page and if it returns valid styles.
The call to retrieve the styles is triggered in both normal and debug mode. However, in normal mode its response doesn't contain the Bootstrap style directives.
Ok, I tried it and it turns out that the instructions are somewhat inaccurate. In fact, they are totally borked. :)
Here is what you need to add to LocalSettings.php to enable Bootstrap styles on all pages:
$wgHooks['SetupAfterCache'][]=function(){
\Bootstrap\BootstrapManager::getInstance()->addAllBootstrapModules();
return true;
};
$wgHooks['ParserAfterParse'][]=function( Parser &$parser, &$text, StripState &$stripState ){
$parser->getOutput()->addModuleStyles( 'ext.bootstrap.styles' );
$parser->getOutput()->addModuleScripts( 'ext.bootstrap.scripts' );
return true;
};
Thanks for looking into this issue, I really appreciate it! However, this doesn't work for me neither :D Again, in debug mode it works. In production mode it doesn't.
I've looked into this issue in more detail and here's what happens: In production mode, all modules are loaded in one or two requests. The request asks for your extension's module but its response doesn't contain any Bootstrap directives.
In debug mode, all modules are loaded in single requests. The request retrieving my extension's module returns the most recent version of my files. The request retrieving your extension's module returns a stylesheet containing the Bootstrap directives AND an old version of my own extension's stylesheet.
I remember to use addExternalModule like in the Chameleon skin and I guess the resource loader at some point decided to cache the response - including my module. However, this is really frustrating because in the resulting sheet these old directives are below my most recent ones and thus override all of them that don't have a higher cascade weight.
In production mode the response might have also be cached at a point in time when I didn't get your extension to fully work yet. However, I have no idea how to cope with this issue. Restarting the vagrant VM doesn't change anything. I've disabled caching wherever I could and cleared the central cache folder without success. Database tables like *cache are empty. And so is my browser cache.
I have no idea where it's being cached. Maybe on HTTP server level.
Okay, I have to revise my statement: Adding the hooks to the LocalSettings.php actually DOES work for both modes! However, this is not what I need because I want to use Bootstrap within my extension, I don't want to force the whole installation to use it :/
Well then for ParserAfterParse you have to make sure it is only applied in case you need it. The SetupAfterCache hook does not hurt. It just registers the module without actually delivering it to the client.