!?!?!?!??!?! so any fix this
Project:Support desk/Flow
Please ask Miraheze itself.
I'd like some custom JS code to be executed when the preview panel in the wiki editor is refreshed. (I am using a custom JS library for mathematical typesetting, and I want it to be run on the preview so that the mathematical content is typeset.) Is there any way to achieve this?
Even partial answers would be very welcome, since I even struggle at understanding how the editor's code is organised...
@Sparusaurata2 you are looking for the Javascript hook system. And the hook for when the wikicontent (be it in a preview or not) changes is 'wikipage.content'
Thanks a lot! Following this suggestion, I added the following code in Common.js
:
mw.hook( 'wikipage.content' ).add( function( $content ) { renderMathInElement($content, { delimiters: [ {left: '$DKATEX$', right: '$DKATEX$', display: true}, {left: '$TKATEX$', right: '$TKATEX$', display: false}, {left: '\\[', right: '\\]', display: true}, {left: '\\(', right: '\\)', display: false ], output: "mathml" }); } );
but when I try it out and reload the Preview in the Wiki editor, the expected result does not happen (the math is not rendered) and instead I obtain an error in the JS console: Uncaught TypeError: e.childNodes is undefined
. Any idea why this is happening?
Hi,
We are currently running the following versions:
MediaWiki 1.43.0
PHP 8.3.15 (fpm-fcgi)
ICU 74.2
MariaDB 10.11.10-MariaDB
When we update to PHP 8.3.16 and try to log in to our mediawiki site using AD credentials via LDAP we get the following error: "Could not fetch required user info to complete login"
If I put in the wrong password it will tell me that the user or password is incorrect.
I have tried verifying that LDAP is working using the ldapsearch command and that seems to work fine.
Anyone got any ideas what I can do to fix this?
Thanks
Hi,
I am upgrading mediawiki from 1.33.1 to 1.42.1. I used a 1.35 version to upgrade DB without error. But now I get an error logging in
[eb40b7f6f59133a091c0fa4a] /index.php/Speciale:Entra Wikimedia\Rdbms\DBQueryError: A database query error has occurred. Did you forget to run your application's database schema updater after upgrading or after adding a new extension?
Please see <nowiki>https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Upgrading</nowiki> and <nowiki>https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:How_to_debug</nowiki> for more information.
Error 1146: Table 'my_wiki.oathauth_devices' doesn't exist
Function: MediaWiki\Extension\OATHAuth\OATHUserRepository::loadKeysFromDatabase
Query: SELECT oad_id,oad_data,oat_name FROM `oathauth_devices` JOIN `oathauth_types` ON ((oat_id = oad_type)) WHERE oad_user = 1
So i tried the web-version of the upgrader. and I get this error.
Running /var/www/html/mediawiki/extensions/OATHAuth/maintenance/UpdateForMultipleDevicesSupport.php...
An error occurred:
Error 1049: Unknown database 'virtual'
Function: Wikimedia\Rdbms\DatabaseMySQL::doSelectDomain
Query: USE `virtual`
Any clue? I think that the upgrading script it's getting stucked in that part. Oauth is not something I need I think
Multiple people have reported this, however we are having trouble seeing the error ourselves and haven't been able to figure out the cause. If there is anything special about your install please let us know.
Yes, a work around is to disable the oathAuth extension if you dont need 2fa.
Thanks for reply We are testing if we can use it as a company repository for guides and internal know how. If you need some file to track the bug I can send it to you
If I'll need oauth maybe I'll export the few pages and put it into a new fresh install
Best
We believe this is a problem with the web upgrader that can be worked around by using the command line update.php script
I am experiencing the same problem after upgrading from v1.40 to 1.42.1.
Running php maintenance/run.php update does not solve the problem.
Only workaround for now was to disable the extension.
the same issue. going from the 1.35.4 to 1.42.1
wa used
I also ran into this issue yesterday. After further reviewing the sources for both the 1_41 and 1_42 branch's extensions (not MediaWiki itself) I discovered that the errors we're all reporting here were due to changes those extensions (AbuseFilter and OATHAuth) made in the database schema when upgrading from 1_41 to 1_42 that weren't accounted for by the extensions in 1_42 (they expected those changes to already be there).
I had to upgrade from 1_40 to 1_41 first and then dump my database and import it into 1_42, run the maintenance run update.php and now all seems to be correct and fully functional right off the bat.
If you try to upgrade from 1_40 to 1_42 without getting those extension's database changes that were included in 1_41 and you just disable them as a workaround, those core extensions could potentially never work again (unless the authors of the extensions include checks for the work they did in 1_41 in later versions).
I have the same problem. I updated from 1.36 to 1.42.3 directly.
Now I get this error:
[1d3af140767aa7e702b0db4b] /wiki/Special:SpecialPages Wikimedia\Rdbms\DBQueryError: A database query error has occurred. Did you forget to run your application's database schema updater after upgrading or after adding a new extension?
Please see https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Upgrading and https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:How_to_debug for more information.
Error 1146: Table 'my_wiki.oathauth_devices' doesn't exist
Function: MediaWiki\Extension\OATHAuth\OATHUserRepository::loadKeysFromDatabase
Query: SELECT oad_id,oad_data,oat_name FROM `oathauth_devices` JOIN `oathauth_types` ON ((oat_id = oad_type)) WHERE oad_user = 1
Backtrace:
from /var/lib/mediawiki-1.42/includes/libs/rdbms/database/Database.php(1203)
#0 /var/lib/mediawiki-1.42/includes/libs/rdbms/database/Database.php(1187): Wikimedia\Rdbms\Database->getQueryException()
#1 /var/lib/mediawiki-1.42/includes/libs/rdbms/database/Database.php(1161): Wikimedia\Rdbms\Database->getQueryExceptionAndLog()
#2 /var/lib/mediawiki-1.42/includes/libs/rdbms/database/Database.php(652): Wikimedia\Rdbms\Database->reportQueryError()
#3 /var/lib/mediawiki-1.42/includes/libs/rdbms/database/Database.php(1350): Wikimedia\Rdbms\Database->query()
#4 /var/lib/mediawiki-1.42/includes/libs/rdbms/database/DBConnRef.php(119): Wikimedia\Rdbms\Database->select()
#5 /var/lib/mediawiki-1.42/includes/libs/rdbms/database/DBConnRef.php(351): Wikimedia\Rdbms\DBConnRef->__call()
#6 /var/lib/mediawiki-1.42/includes/libs/rdbms/querybuilder/SelectQueryBuilder.php(729): Wikimedia\Rdbms\DBConnRef->select()
#7 /var/lib/mediawiki-1.42/extensions/OATHAuth/src/OATHUserRepository.php(342): Wikimedia\Rdbms\SelectQueryBuilder->fetchResultSet()
#8 /var/lib/mediawiki-1.42/extensions/OATHAuth/src/OATHUserRepository.php(79): MediaWiki\Extension\OATHAuth\OATHUserRepository->loadKeysFromDatabase()
#9 /var/lib/mediawiki-1.42/extensions/OATHAuth/src/Special/OATHManage.php(77): MediaWiki\Extension\OATHAuth\OATHUserRepository->findByUser()
#10 /var/lib/mediawiki-1.42/vendor/wikimedia/object-factory/src/ObjectFactory.php(240): MediaWiki\Extension\OATHAuth\Special\OATHManage->__construct()
#11 /var/lib/mediawiki-1.42/vendor/wikimedia/object-factory/src/ObjectFactory.php(149): Wikimedia\ObjectFactory\ObjectFactory::getObjectFromSpec()
#12 /var/lib/mediawiki-1.42/includes/specialpage/SpecialPageFactory.php(1501): Wikimedia\ObjectFactory\ObjectFactory->createObject()
#13 /var/lib/mediawiki-1.42/includes/specialpage/SpecialPageFactory.php(1539): MediaWiki\SpecialPage\SpecialPageFactory->getPage()
#14 /var/lib/mediawiki-1.42/includes/specials/SpecialSpecialPages.php(64): MediaWiki\SpecialPage\SpecialPageFactory->getUsablePages()
#15 /var/lib/mediawiki-1.42/includes/specials/SpecialSpecialPages.php(53): MediaWiki\Specials\SpecialSpecialPages->getPageGroups()
#16 /var/lib/mediawiki-1.42/includes/specialpage/SpecialPage.php(719): MediaWiki\Specials\SpecialSpecialPages->execute()
#17 /var/lib/mediawiki-1.42/includes/specialpage/SpecialPageFactory.php(1669): MediaWiki\SpecialPage\SpecialPage->run()
#18 /var/lib/mediawiki-1.42/includes/actions/ActionEntryPoint.php(504): MediaWiki\SpecialPage\SpecialPageFactory->executePath()
#19 /var/lib/mediawiki-1.42/includes/actions/ActionEntryPoint.php(145): MediaWiki\Actions\ActionEntryPoint->performRequest()
#20 /var/lib/mediawiki-1.42/includes/MediaWikiEntryPoint.php(199): MediaWiki\Actions\ActionEntryPoint->execute()
#21 /var/lib/mediawiki-1.42/index.php(58): MediaWiki\MediaWikiEntryPoint->run()
#22 {main}
And perhaps not too surprisingly, that table does not exist:
MariaDB [(none)]> show tables from my_wiki;
+------------------------+
| Tables_in_my_wiki |
+------------------------+
| actor |
| archive |
| block |
| block_target |
| bot_passwords |
| category |
| categorylinks |
| change_tag |
| change_tag_def |
| comment |
| content |
| content_models |
| externallinks |
| filearchive |
| image |
| imagelinks |
| interwiki |
| ip_changes |
| ipblocks |
| ipblocks_restrictions |
| iwlinks |
| job |
| l10n_cache |
| langlinks |
| linktarget |
| log_search |
| logging |
| module_deps |
| oathauth_users |
| objectcache |
| oldimage |
| page |
| page_props |
| page_restrictions |
| pagelinks |
| protected_titles |
| querycache |
| querycache_info |
| querycachetwo |
| recentchanges |
| redirect |
| revision |
| searchindex |
| site_identifiers |
| site_stats |
| sites |
| slot_roles |
| slots |
| templatelinks |
| text |
| updatelog |
| uploadstash |
| user |
| user_autocreate_serial |
| user_former_groups |
| user_groups |
| user_newtalk |
| user_properties |
| watchlist |
| watchlist_expiry |
+------------------------+
60 rows in set (0.001 sec)
This should hopefully make it *much* easier to fix (and reproduce). Combined with the infro from @DenverChess, it seems that the update.php script isn't correctly creating this table and creating or migrating the data (if appropriate).
As "Tockdom46" describes in the following thread: "https://phabricator.wikimedia.org/T371849":
"As Denver mentioned in https://www.mediawiki.org/wiki/Topic:Yakailc03f0u43c0 , upgrading a wiki from 1.39.10 to 1.43.0 requires that you add the OATHAuth from 1.41.X to the extension folder, update the database with
$ php maintenance/run.php update.php
Afterwards I ran it again with the OATHauth for 1.43.0 though it did not seem to be required."
Tried the above and can confirm this works.
Thank you to the above comment pointer. Installing the 1.41.x version of OATHAuth fixed an upgrade from 1.39.x to 1.43 that was using this extension.
Hello, I think that I've probably found solution about this. (maybe?) Before run update.php, run (wiki folder)/extensions/OATHAuth/sql/sqlite/tables-generated.sql
manually. I tested it when upgrading MediaWiki from 1.40.2 to 1.43.0 directly, not installing 1.41.x version of OATHAuth.
I'm upgrading from 1.39.11 to 1.43 and ran into a similar issue of the OATHAuth database tables not being up-to-date.
Running extensions/OATHAuth/sql/mysql/tables-generated.sql manually allowed me to upgrade to 1.43 directly with OATHAuth intact. Thank you @하늘토끼 for the tip
Hi,
how to add the extension to sidebar? I don't want the link to an extra side. Ideally the tree with all categories is shown on every site i visit on my wiki.
thank you
Does Extension:CategoryTree#Hacks help?
@AhmadF.Cheema I've added $wgCategoryTreeSidebarRoot = 'Category:article_name'; $wgCategoryTreeForceHeaders = true;
to the LocalSettings.php
for Modern, MonoBook and Vector skins but categories won't show up on the sidebar :(
As it says in the text for CategoryTree then it wont show up, however what I found you can do is add categorytree-portlet by editing your sidebar page. It still wont show because the parsing makes it vanish because the portlet becomes an empty list due to the point at which it parses but I have a work around;
- Edit the file skins/Timeless/includes/TimelessTemplate.php
- In function getMainNavigation just after "if ( $content === false ) {...}" add
if( empty($content) ) {
$content="SOME-RANDOM-NON-BLANK-TEXT";
<nowiki>}</nowiki>
See also: Topic:Xoq2d13kogk8dcbn
Filed a bug: https://phabricator.wikimedia.org/T384508
so when i view the source code of my /var/chwiki/chaz (my apache directory) it shows nothing
also in the apache2 error.log file it shows alot of error ah00035, and php errors
also i have given the mw-config directory +x permissions, and it still shows ah00035
do i need to reinstall (even though i havent)
i figured it out
Так что было? У меня такая же проблема
Hey Guys!
I have a question,i want deleted some spamers from my MediaWiki. I konw that i must go in the database and delete the user from there.
My question,where i must go exactly to delete the Users ? I see many tables,but not no who the rigt table.
Hope somebody can help me :-)
Sorry for my english,not my native language
Seriana
There used to be an Extension for this. It can be found Here, however it will damage your Database. I suggest that you use The User Merge and Delete Extension found Here.
Best Wishes, ~Comppro
I have the same problem like Seriana, How to merge 7900 Spam accounts? There must be a solution directly working on the database, it is unfeasable to do that over a WikiPage. Regards, Markus
If you want to do that in the database, the easy way is to go to the table "user" and to delete all the users, which you do no longer want. You can do that, but this is relational data. Meaning: MediaWiki does not only use it for the usernames, but also associates posts and other stuff with these table rows. If you just remove them without checking, if they are still used anywhere else, you will break your wiki.
A rather clean solution, which I found very usable, is Extension:User_Merge_and_Delete. It takes care for those references automatically. This drastically reduces the risk of screwing up your wiki.
I'm with the others on looking for a solution on how to delete several hundred spam accounts on my wiki. the User_Merge_and_Delete is simply not capable of tackling this in a method that is worthwhile or plausible. I would also greatly appreciate attempting to lock-out certain functions, or find a better User Registration to stop this spamming or at least diminish it.
-Keith (hoosierhackerhouse.com; a Shadowrun Gaming Wiki)
If these accounts are only there and never got used, you can use the maintenance script removeUnusedAccounts.php to remove these accounts. If you find better ways, let us know, however, others also were not successful as you can see from the missing feedback in this very thread. You can delete the user records from the DB directly; fast and simple. But don't complain when it breaks your wiki.
If you have a list of known good accounts, you can use Extension:BlockandNuke and Extension:UserMerge to merge spam accounts into the user Spammer. BlockandNuke will also ban the IP addresses from editing.
I've been using this on my personal spam-bait wiki and have blocked over 10,000 IP addresses in the last month.
BlockandNuke doesn't work and/or the documentation is out of date.
I installed mediawiki on one of my domains, to 'practice' the wikimarkup language and possibly use it for my 'linux howto's' sub-domain linux.landisreed. I didn't get to it right away and was unaware, due to the lack of detailed install and configure docs that are, like mozilla not up to date. Anyways, i noticed huge CPU usage and looked at phpMyAdmin, my db, search Users, using 10,000 records per page starting at zero and apparently have around 80,0000 user accounts as there are 8 pages (10,000 records per page, nope: 71,718 actually, minus me and my admin user from setup)... this is a lot to deal with. In Mediawiki > Special Pages > User List it seems that most 'people' have entered some sort of text (Spam they are advertising) so 'empty entries' script doesn't seem to be the answer... I think I'm going to attack this from the Backup db > Delete Users other than my Admin and my 'personal' accounts and see what that does form me.. I'll let you know what happens.
- note... funny, before looking at phpmyadmin, i started blocking users, one article at a time, but.... after 10 (Not knowing just how many there were), i thought I'd look into a 'better' or at least quicker way... doesn't appear to be one... I'd of thought, with how long mediawiki has been around and how many sites us it, there'd be a way... 'freeware', eh..
Landis.
Well, i used git in ssh to clone and 'install' on my server. added functions to LocalSettings.php, logged in a 'SysOp' (original user from setup), navigated to http://linux.landisreed.com/wiki/Special:UserMerge and got the following error: [4d78a706] 2014-01-30 10:25:16: Fatal exception of type MWException Thought that 'install' went too smoothly.. lol : ( NEXT... i'm looking at other options, instead of wasting time figuring this error out.
> i thought I'd look into a 'better' or at least quicker way... doesn't appear to be one...
That is wrong. There are faster ways. E.g. if you have a list of known good accounts, you can use Extension:BlockandNuke and Extension:UserMerge to merge spam accounts into the user Spammer. BlockandNuke will also ban the IP addresses from editing.
thank you, but... in the 2, almost 3 weeks my wiki sat idle before i got back to it after install (wish install config page warned to secure site), i was lucky enough to get almost 80,000 'spam' users, each with a page or two or 6... i didn't see any good way to deal with that..
So, I exported the known good page, created a new db and 'updated' my mediawiki install and imported or recreated from *.mediawiki (text files) the pages. This worked out ok, because i learned a bunch since the install 3 weeks ago.. like Namespace.. nice.
Anyways, thanks again, Landis.
Really it is an important, Mediawiki need some kind of system (like as temporary table to save IP trying - avoiding third dependencies) to block massive register.
see also here Extension:UserVerification (allows to delete users with some constraints)
On MW 1.39, when I go to Special:Version, I get numerous warnings like :
Warning: is_readable(): open_basedir restriction in effect. File(/gitinfo/info.json) is not within the allowed path(s): (/var/www/vhosts/[...]/:/tmp/) in [...]/includes/GitInfo.php on line 173
I don't have access to php.ini and setting $wgGitBin to false has no effect. Any idea how I could go about solving this?
Edit: I'm seeing this with ini_set( 'display_errors', 1 ) so maybe it's only natural that this warning is showing. Close this report if it is.
Something is wrong with a path configuration somewhere. It should not be trying to read that out of the root directory.
Any idea what configuration needs to be changed to fix this? I'm having the same problem in MW 1.41: Special:Version page has numerous warnings overwriting the top of the page.
Most look like:
Warning: is_readable(): open_basedir restriction in effect. File(/gitinfo/info.json) is not within the allowed path(s): (/var/services/web:/tmp:/var/services/tmp) in /volume1/web/mediawiki/includes/utils/GitInfo.php on line 177
Poem added this one:
Warning: is_readable(): open_basedir restriction in effect. File(/gitinfo/info-extensions-Poem.json) is not within the allowed path(s): (/var/services/web:/tmp:/var/services/tmp) in /volume1/web/mediawiki/includes/utils/GitInfo.php on line 177
Please post LocalSettings.php (minus any passwords)
Sorry for the delay, @Bawolff - here's my LocalSettings.php content:
<?php
# This file was automatically generated by the MediaWiki 1.35.5
# 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 = "thesitename";
$wgMetaNamespace = "thenamespace";
## 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 = "/mediawiki";
## The protocol and server name to use in fully-qualified URLs
$wgServer = "http://myserver";
## 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" ];
$wgLogos = [ '1x' => "$wgResourceBasePath/resources/assets/mediawiki.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 = "localhost:/run/mysqld/mysqld10.sock";
$wgDBname = "the_mediawiki_db";
$wgDBuser = "the_mediawiki_user";
$wgDBpassword = "thepassword";
# 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_ACCEL;
$wgMemCachedServers = [];
## To enable image uploads, make sure the 'images' directory
## is writable, then set this to true:
$wgEnableUploads = false;
# 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 = false;
## 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 = "en_US.utf8";
## 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 = "thesecretkey";
# 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 = "theupgradekey";
## 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 = "";
# The following permissions were set based on your choice in the installer
$wgGroupPermissions['*']['createaccount'] = false;
$wgGroupPermissions['*']['edit'] = false;
$wgGroupPermissions['*']['read'] = false;
## 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( 'MonoBook' );
wfLoadSkin( 'Timeless' );
wfLoadSkin( 'Vector' );
# End of automatically generated settings.
# Add more configuration options below.
# enable extensions (extension needs to be placed in 'extensions' dir,
# if not already there
wfLoadExtension( 'Poem' );
I have the same issue. Do you have a solution?
I've used Extension:JSBreadCrumb for several years with no problems, downloaded latest version for MW 1.42.3, and installed on 3 sites I upgraded. Breadcrumbs were working fine, but now no longer display.
Any idea how to troubleshoot this? JSBreadCrumb is the only extension I'm using, and vector-2022 the only skin.
See LocalSettings for REF site — http://dstall.com/LocalSettings.txt and Common.css https://dstall.com/REF/MediaWiki:Common.css
you should not post your un-redacted localsettings file -- make sure you hide the passwords.
I'm not familiar with jsbreadcrumbs but maybe @Cindy.cicalese could help you.
A workaround until the vector-2022 selector is added directly to the extension is at Topic:Ye4ac6qmgdeiqddr.
Hi!
I would like to know if it's possible to setup Mediawiki with an already defined LocalSettings.php
file, instead of following the manual steps to generate one (basic setup), or running install.php
to generate the file and prepare the database.
I tried running update.php
but it gave me an error (probably because the setup is required before the update can be done).
What I want is to do what the basic setup does, but using the parameters already defined in the LocalSettings.php
file (similar to what is done when running install.php
. but without defining the parameters in the command line and generating a new file, but using the parameters already defined in the file).
Thanks in advance!
i dont think that already exists, but you could probably write a really simple maintenance script wrapper around install.php to do so.
@Bawolff Thanks for the reply. I ended up creating 2 files to do that, maintenance/upgrade.php
and includes/installer/CustomCliInstaller.php
.
The upgrade.php
file is very similar to install.php
, except that it gets the parameters defined in the LocalSettings.php
file (instead of getting them from the command line arguments) and calls CustomCliInstaller.php
(while install.php
calls CliInstaller.php
).
The CustomCliInstaller.php
extends CliInstaller.php
and the main difference is that it overrides the execute method, because CliInstaller.php
gives an error at the execute
method if the file LocalSettings.php
already exists.
Bellow are the code of the 2 files (when I pasted the code, the indentation and empty lines were removed, I don't know if this is normal).
upgrade.php:
<?php
/**
* CLI-based MediaWiki installation and configuration.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License along
* with this program; if not, write to the Free Software Foundation, Inc.,
* 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
* http://www.gnu.org/copyleft/gpl.html
*
* @file
* @ingroup Maintenance
*/
require_once __DIR__ . '/Maintenance.php';
require_once __DIR__ . '/../includes/AutoLoader.php';
require_once __DIR__ . '/../includes/installer/CustomCliInstaller.php';
define( 'MW_CONFIG_CALLBACK', 'Installer::overrideConfig' );
define( 'MEDIAWIKI_INSTALL', true );
/**
* Maintenance script to upgrade MediaWiki
*
* Default values for the options are defined in DefaultSettings.php
* (see the mapping in CliInstaller.php)
*
* @ingroup Maintenance
*/
class CommandLineUpgrader extends Maintenance {
public function __construct() {
parent::__construct();
global $IP;
$this->addDescription( "CLI-based MediaWiki installation and configuration.\n" .
"Will install based on the settings at LocalSettings.php or update (if it's already installed)." );
}
public function execute() {
global $IP;
$vars = Installer::getExistingLocalSettings();
if ( !$vars ) {
$status = Status::newFatal( "config-download-localsettings" );
$this->showStatusMessage( $status );
return $status;
}
$sitename = $vars['wgSitename'];
$admin = $vars['wgDBuser'];
$options = [
'dbtype' => $vars['wgDBtype'],
'dbserver' => $vars['wgDBserver'],
'dbname' => $vars['wgDBname'],
'dbuser' => $vars['wgDBuser'],
'dbpass' => $vars['wgDBpassword'],
'dbprefix' => $vars['wgDBprefix'],
'dbtableoptions' => $vars['wgDBTableOptions'],
'dbport' => $vars['wgDBport'],
'dbschema' => $vars['wgDBmwschema'],
'dbpath' => $vars['wgSQLiteDataDir'],
'server' => $vars['wgServer'],
'scriptpath' => $vars['wgScriptPath'],
'lang' => $vars['wgLanguageCode'],
'pass' => $vars['wgDBpassword'],
];
try {
$installer = new CustomCliInstaller( $siteName, $admin, $options );
} catch ( \MediaWiki\Installer\InstallException $e ) {
$this->output( $e->getStatus()->getMessage( false, false, 'en' )->text() . "\n" );
return false;
}
$status = $installer->doEnvironmentChecks();
if ( $status->isGood() ) {
$installer->showMessage( 'config-env-good' );
} else {
$installer->showStatusMessage( $status );
return false;
}
$status = $installer->execute();
if ( !$status->isGood() ) {
$installer->showStatusMessage( $status );
return false;
}
$installer->showMessage(
'config-install-success',
$installer->getVar( 'wgServer' ),
$installer->getVar( 'wgScriptPath' )
);
return true;
}
}
$maintClass = CommandLineUpgrader::class;
require_once RUN_MAINTENANCE_IF_MAIN;
CustomCliInstaller.php:
<?php
/**
* Core installer command line interface.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License along
* with this program; if not, write to the Free Software Foundation, Inc.,
* 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
* http://www.gnu.org/copyleft/gpl.html
*
* @file
* @ingroup Installer
*/
/**
* Class for the custom installer command line interface.
*
* @ingroup Installer
* @since 1.17
*/
class CustomCliInstaller extends CliInstaller {
/**
* @param string $siteName
* @param string|null $admin
* @param array $options
* @throws InstallException
*/
public function __construct( $siteName, $admin = null, array $options = [] ) {
parent::__construct( $siteName, $admin, $options );
}
/**
* Main entry point.
* @return Status
*/
public function execute() {
// If APC is available, use that as the MainCacheType, instead of nothing.
// This is hacky and should be consolidated with WebInstallerOptions.
// This is here instead of in __construct(), because it should run run after
// doEnvironmentChecks(), which populates '_Caches'.
if ( count( $this->getVar( '_Caches' ) ) ) {
// We detected a CACHE_ACCEL implementation, use it.
$this->setVar( '_MainCacheType', 'accel' );
}
$result = $this->performInstallation(
[ $this, 'startStage' ],
[ $this, 'endStage' ]
);
// PerformInstallation bails on a fatal, so make sure the last item
// completed before giving 'next.' Likewise, only provide back on failure
$lastStepStatus = end( $result );
if ( $lastStepStatus->isOK() ) {
return Status::newGood();
} else {
return $lastStepStatus;
}
}
}
Any possibilities of this being added (or adapted) to the mediawiki code?
Took a bit of googling but this is exactly what I need! Thanks!
Something like this should absolutely be included!
I'm using Terraform to deploy my environment in AWS. Having to manually run the stock installer cli tool every time I teardown and deploy is quite the pain. It'd be extra nice if MysqlInstaller
respected the $wgDBssl
setting.
Is this still the only way to do this? I'm looking into automating a media-wiki "stack" but the LocalSettings.php/install process is being the most annoying thing to deal with on new setups.