I have a wiki with a high volume of edits that need to be made (via API),
about 2-3 per second. The wiki can't keep up with them; there ends up being
a backlog of edits that need to be made as, e.g., attempts are being made
by 10 different bots to make 10 edits simultaneously (all to different
pages) and it takes a long time for them to save so that the bots can move
on to their next edits.
What's the best way to boost performance in the ways needed to reduce the
time needed to save edits, or to be able to save more edits per second by
concurrently running bots? Thanks, -- Starstruck
I’m sorry, but it appears that your issue is not directly related to MediaWiki. At the MediaWiki mailing list, we can only help you with issues related to MediaWiki. You’d probably be better off reaching out to someone else.
On Sunday, December 30, 2018, 12:45 PM, Jess Urbe <urbejessie(a)gmail.com> wrote:
I got a block bits came from wikkimedia but when we deploy in my wallet its bump error so I got to foxed it.that is a donation for the poor people
On Mon, Dec 31, 2018, 1:40 AM Amanda Quad <amandaquad(a)yahoo.com wrote:
I’m sorry, but we can’t help you fix your problem if you don’t tell us what your problem is! This message was blank except for the subject, so unfortunately we cannot help you further unless you provide us with more information.
On Saturday, December 29, 2018, 7:06 AM, Jess Urbe <urbejessie(a)gmail.com> wrote:
I'm using MW version 1.29.2 on a shared hosting server (PHP 7.2.13 and MySQL 5.5.60). I've inadvertently exceeded the ISP's 1GB size limit of the database, with the result that I can't make any further changes. The wiki is still up and running, but I can't edit or delete content, no users can log in, and none of the PHP scripts will run from the maintenance shell extension. Because it's a shared hosting server, I don't have direct shell access to run PHP scripts.
My ISP has suggested that I reduce the size of the database using MySQL, so I can get it back under the threshold limit, and 'unfreeze' everything. In theory I should be able to delete unwanted old versions of pages in the usual way to free up space.
Using MySQL I've emptied the archive table (only 256 kb), but I need to be able to clear another 10 Mb or so without corrupting the database. What else can I delete safely to avoid crashing the wiki?
Thanks for any suggestions,
A while back we applied hardening per
. Our php.ini includes the following:
;; #15 Limit PHP Access To File System
;; Allows recursive descent
When (1) the cache is stale, and (2) we run Special:Version, then part
of our security configuration is provided:
Is there any way to close that hole?
I'm OK with allowing Git to run, but I don't know how to do it short
of opening up /usr/bin to the web server.
Thanks in advance.
I'm trying to perform another 1.30 -> 1.31 upgrade. MariaDB version 5.5.60.
I've tried to run upgrade.php with our standard user (mwuser) and db
administrator (root). upgrade.php has always worked in the past using
our standard user (mwuser).
I've run "mysql_upgrade --user=root ..." again just in case because of
the hint below. Everything is OK.
What is the error and how do I fix it?
# php maintenance/update.php
MediaWiki 1.31.1 Updater
Your composer.lock file is up to date with current dependencies!
Going to run database updates for my_wiki-wikicryptopp_
Depending on the size of your database this may take a while!
Abort with control-c in the next five seconds (skip this countdown with --quick)
Turning off Content Handler DB fields for this part of upgrade.
Adding ipb_id field to table ipblocks ...[33b892a93ece4b42600cbd2b] [no req] W
ikimedia\Rdbms\DBQueryError from line 1457 of /var/www/html/w/includes/libs/rdbm
s/database/Database.php: A database query error has occurred. Did you forget to
run your application's database schema updater after upgrading?
Query: ALTER TABLE `mediawiki`.`wikicryptopp_ipblocks`
ADD ipb_auto tinyint NOT NULL default '0',
ADD ipb_id int NOT NULL auto_increment,
ADD PRIMARY KEY (ipb_id)
Function: Wikimedia\Rdbms\Database::sourceFile( /var/www/html/w/maintenance/arch
Error: 1142 ALTER command denied to user 'mwuser'@'localhost' for table 'wikicry
#0 /var/www/html/w/includes/libs/rdbms/database/Database.php(1427): Wikimedia\Rd
bms\Database->makeQueryException(string, integer, string, string)
#1 /var/www/html/w/includes/libs/rdbms/database/Database.php(1200): Wikimedia\Rd
bms\Database->reportQueryError(string, integer, string, string, boolean)
#2 /var/www/html/w/includes/libs/rdbms/database/Database.php(4194): Wikimedia\Rd
#3 /var/www/html/w/includes/libs/rdbms/database/Database.php(4129): Wikimedia\Rd
bms\Database->sourceStream(unknown type, NULL, NULL, string, NULL)
#4 /var/www/html/w/includes/installer/DatabaseUpdater.php(683): Wikimedia\Rdbms\
#5 /var/www/html/w/includes/installer/DatabaseUpdater.php(751): DatabaseUpdater-
>applyPatch(string, boolean, string)
#6 /var/www/html/w/includes/installer/DatabaseUpdater.php(482): DatabaseUpdater-
>addField(string, string, string)
#7 /var/www/html/w/includes/installer/DatabaseUpdater.php(446): DatabaseUpdater-
#8 /var/www/html/w/maintenance/update.php(200): DatabaseUpdater->doUpdates(array
#9 /var/www/html/w/maintenance/doMaintenance.php(94): UpdateMediaWiki->execute()
#10 /var/www/html/w/maintenance/update.php(245): require_once(string)
We use CentOS 7. Red Hat supplies antique software. It offers Media
wiki 1.21, if I recall correctly. It is what it is. We had to take on
maintenance of Mediawiki because we wanted to offer newer features
users. Skins and extensions sometimes need something newer than what
the platform provides.
We've managed to update Apache, Python and PHP using SCL
However, we cannot get the MySQL update to work. We are stuck at MySQL
5.5.60. MySQL 5.5.60 was released April 2018.
We can't upgrade to to MW 1.31 due to CentOS's MySQL. We tried to
install MW 1.31 but maintenance/update.sh died when trying to update
the database. We had to go to backup and restore the installation.
It is not just CentOS. Other OSes, like Ubuntu 14 LTS, are boxing
users. For example Ubuntu 14 provides MySQL 5.5.62
5.5.62 was released October 2018.
Earlier I said "We've managed to update Apache, Python and PHP...".
SCL does not offer Composer. Composer is an entirely new set of
hardships. SCL probably does not offer Composer because dev tools have
no business being on a production server. While you may think
'composer update' is easy, it took us a day and a half to work around
all the problems and exceptions.
Please consider lowering the MySQL requirements. Most helpful would be
to lower and freeze all requirements for the next 3 or 5 years. A
requirements freeze would allow us (and other users) to upgrade
Mediawiki without the hassles and aggravations.
Thanks in advance.
I'm in a very unusual state. I had to perform a restore of our html/
directory because I accidentally blew away /var/www/html . We also
lacked a current backup, and our backup was exactly 1 year old. So the
upgrade.php file below is from MW 1.28, IIRC.
I had a current backup of LocalSettings.php from MW 1.30, so I used it
when the restored LocalSettings.php 1.28 caused problems. However, the
1.30 LocalSettings had all the wfLoadExtension and wfLoadSkin
commented because they are not present (yet).
So I have 1.28 Mediawiki, 1.30 LocalSettings, and a missing APC.
Caching and APC is discussed here, but I did not see what needs to be
installed: https://www.mediawiki.org/wiki/Manual:Performance_tuning .
What is APC, and how do I install it?
# yum install apc
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
* base: centos.mirror.netelligent.ca
* epel: ewr.edge.kernel.org
* extras: centos.mirror.netelligent.ca
* updates: centos.mirror.netelligent.ca
No package apc available.
Error: Nothing to do
# php maintenance/update.php
[f6724eba] [no req] MWException from line 150 of /var/www/html/w/includes/obje
ctcache/ObjectCache.php: CACHE_ACCEL requested but no suitable object cache is p
resent. You may want to install APC.
#0 /var/www/html/w/includes/objectcache/ObjectCache.php(94): ObjectCache::newAcc
#1 /var/www/html/w/includes/objectcache/ObjectCache.php(74): ObjectCache::newFro
#2 /var/www/html/w/includes/objectcache/ObjectCache.php(46): ObjectCache::newFro
#3 /var/www/html/w/includes/GlobalFunctions.php(3935): ObjectCache::getInstance(
#4 /var/www/html/w/includes/Setup.php(581): wfGetMainCache()
#5 /var/www/html/w/maintenance/doMaintenance.php(97): require_once(string)
#6 /var/www/html/w/maintenance/update.php(216): require_once(string)