Manual talk:Maintenance scripts

Executing the maintenance scripts

What is meant by "filling in the required connection instructions"? Do I have to write these instructions into the "AdminSettings.php"? Sorry for asking such stupid questions. My best, --84.75.55.96 22:30, 6 November 2007 (UTC)

In the AdminSettings.sample, the connection information is generic. You will notice that :

$wgDBadminuser = 'wikiadmin';

$wgDBadminpassword = 'adminpass';

You should simply replace the values of 'wikiadmin' and 'adminpass' with your own database username and password in your AdminSettings.php file.

Stéphane Thibault 05:20, 27 December 2007 (UTC)

Ok, thanks! I did that. But how do I establish a commandline connection with the database server? I am working on a Mac and our wiki is installed on server of a hosting provider. But I think I have Shell access; at least it says shell access via "/bin/false". But I really have no clue how to connect. Do I need a particular program for that? My best, --Gollum 19:54, 26 February 2008 (UTC)

If the shell of a user is set to "/bin/false" it is usually the technical way of saying "no shell access". A shell is a program that reads your commands and executes them, while /bin/false only does one thing: exits immediately. --Myhr 13:14, 27 February 2008 (UTC)

Oh, that does not sound too good. What can I do then? Is there another way to execute the maintenance scripts then? Is it normal to ask the provider to do so? Any other ideas? My best, --Gollum 21:35, 27 February 2008 (UTC)

I have the same problem. I do not have access to SSH. I set up a cron job like this one:

*/45 * * * * /usr/local/bin/php /home/httpd/public_html/wiki/maintenance/generateSitemap.php wiki.mydomain.com --fspath /home/httpd/public_html/wiki/

Is that ok? (sorry for my poor english). --89.217.47.34 02:23, 1 April 2008 (UTC)

How to run maintenance scripts from a Web client?

Some users I'm helping are on hosted sites and aren't able to ssh in to run command-line scripts. It would be nice if there was some guideline and/or an alternative commandLine_ALLOW_FROM_WEB.inc that permits these users to run maintenance scripts from a Web page.

Renaming .htaccess to .htaccess_DISABLED lets one view the directory, but I think the next step is disabling the Web server check in commandLine.inc and replacing its command-line parsing with query string parsing. -- Skierpage 01:34, 24 October 2007 (UTC)

Well i think generally the idea of a maintenance script is that it's doing something too long-running and expensive to be triggered from the web, so I suspect if the developers were to answer this question, they'd say it's deliberately not possible.

However I have a situation where I would also like to do this. I'd say quite a few people are on web hosts without SSH access, so some of these functions could do with being web-callable somehow. Trouble is, for long-running batch operation would need to be broken up. E.g. avoid processing every page in the database, just do 500 per call.

-- Harry Wood (talk) 16:25, 29 September 2012 (UTC)

Having said that Extension:Maintenance and Extension:MaintenanceShell seem to be offering this -- Harry Wood (talk) 00:35, 8 October 2012 (UTC)

How do I purge the cache for all my hundreds of image pages?

I need to purge the cache for all my "image:" pages. (all at once) Is there a maintenance script to do this? purgeList.php? How does it work? or some other script? puzzled and in need --Maxelrod 22:16, 20 March 2008 (UTC)

importTextFile.php

I can't figure out how to get this file to work! I have tried through many ways including the sourceforge project wiki_import. When I use the importTextFile.php directly I get this error:

  Warning:  fwrite(): supplied argument is not a valid stream resource in /opt/lampp/htdocs/test/en/includes/Exception.php on line 128

I'm calling importTextFile.php using this code:

  php-cgi /path/to/importTextFile.php --title="filename.txt" --user=auto_import "/path/to/file.txt" --fspath "/path/to/wiki/"

I'm calling the wiki_import.sh using this code:

  echo "/path/to/file.txt" | wiki_import.sh -s 'Title'

and I get this error:

  DB connection error: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) (localhost)

--Greg 22:01, 12 April 2008 (UTC)

Extension:Maintenance

For those without command line access, I wrote an extension that runs a few of the scripts from a special page, but I'm not really all that sure how I should add a mention of it on the manual page. At first I was thinking about a simple see also link, but it should probably be outlined somewhere that there is an alternative (albeit not a very good one in terms of number of scripts it supports) for those without command line access. So... I don't know where to put a message like that :P --Skizzerz 23:19, 23 May 2008 (UTC)

Extension:MaintenanceShell

I expanded on Skizzerz ideas and made an extension which supports all maintenance scripts :) --Frantik 02:05, 31 May 2009 (UTC)

many scripts still not described

Is there anyone able to add some documentation about the scripts listed here with no corresponding page ? --New Morning 09:41, 2 July 2008 (UTC)

1&1

Hi,

When I try to run these scripts with putty, it answers : this version of Mediawiki requires php5 ; you are running 4.4.9. But I have already configured my htaccess with AddType x-mapp-php5 .php that is required on 1&1. I don't understand.

.htaccess only affects scripts run from the web server. When you use putty you're using the command line so htaccess isn't being used. I'm not quite sure how to run php5 via the command line in 1&1.. maybe try "php5" instead of "php"? --Frantik 02:14, 31 May 2009 (UTC)

In order to run php 5.2 on 1and1 you need to use php5 as your command. In order to run php 5.4 you need to use php6 on the command line. The 1and1 help page describes why they're using a 6 for the 5.4 command line.

AdminSettings.php

Which scripts require this? I haven't renamed it and most of them seem to work.. or do i get improved security if I do set it up correctly? --Frantik 02:11, 31 May 2009 (UTC)

Godaddy php5 not installed

Took me a while to get this, so I'm gonna share it with all those running Mediawiki in Godaddy.

When using Putty to run maintenance scripts, you'll get a message about not having php5 installed even though you have PHP5 installed. This is because Godaddy defaults to PHP4. To run maintenance scripts, instead of writing, let's say:

php cleanupTitles.php

write...

web/cgi-bin/php5 "cleanupTitles.php"

This way you load php5 instead of the default php4. --Mark 08:23, 8 December 2009 (UTC)

404 error

I am following the instructions (and added screenshots) and logged into putty:

http://www.mediawiki.org/w/index.php?title=Manual:Maintenance_scripts&oldid=365943#Running_the_scripts

When I type:

php rebuildall.php

I get the error:

php rebuildall.php 
Status: 404 
Content-type: text/html

Mediawiki states that:

1. I need to make sure the path is correct, for example:

php /home/httpd/host/XXXXXXX.com/httpdocs/wikidirectory/maintenance/refreshLinks.php

or

2. "you have to run it from the server, not through a browser. Either through SSH..." [1] I have ssh access

Adamtheclown 18:36, 25 November 2010 (UTC)

404 error solution

With the help of emufarmers I figured it out:

[Bobtheperv@p9nlh999 ~]$ ls
backup  cgi  crontab  data  dea1031109999999.sql  html  mydatabase.sql
[Bobtheperv@p9nlh999 ~]$ cd html
[Bobtheperv@p9nlh999 html]$ ls

Root folder directory listing

_db_backups AdminSettings.php AdminSettings.sample api.php api.php5 bin cgi config COPYING CREDITS dead deadrising.swf docs dr dumps extensions FAQ favicon.ico gdform.php HISTORY images img_auth.php img_auth.php5 includes index.php index.php5 INSTALL install-utils.inc languages lf.jpg LocalSettings.php maintenance Makefile math missing.html opensearch_desc.php opensearch_desc.php5 Other pages_current.xml php.ini php_uploads php5.ini php5.php5 phpsql_genkml.php profileinfo.php README redirect.php redirect.php5 redirect.phtml RELEASE-NOTES robots.txt serialized skins StartProfiler.php stats t tests thumb.php thumb.php5 trackback.php trackback.php5 UPGRADE walkingdead.php webformmailer.php welcome.html wiki.phtml

[Bobtheperv@p9nlh999 html]$
[Bobtheperv@p9nlh999 html]$ cd dr
[Bobtheperv@p9nlh999 dr]$ cd maintenance
[Bobtheperv@p9nlh999 maintenance]$ php rebuildall.php
Content-type: text/html

Sorry! This version of MediaWiki requires PHP 5; you are running 4.4.9.

If you are sure you already have PHP 5 installed, it may be installed
in a different path from PHP 4. Check with your system administrator.
[Bobtheperv@p9nlh999 maintenance]$

Adamtheclown 01:42, 26 November 2010 (UTC)

namespaceDupes.php conflicts

i'm trying to do some reorganization of our namespaces, [including removing some] and unfortunately i've got a handful of pages that exist outside one the namespaces that were apparently put in before we created it.

i'm trying to run namespaceDupes.php to push pages formerly under a namespace into the main namespace, but it results in the following error:

Checking namespace 104: "Namespace"
... 2 conflicts detected:
... 2758 (0,"Namespace:FAQ") -> (104,"FAQ") Namespace:FAQ
...  *** cannot resolve automatically; page exists with ID 2769 ***
... 2567 (0,"Namespace:Replication") -> (104,"Replication") Namespace:Replication
...  *** cannot resolve automatically; page exists with ID 2759 ***

i found a number of pages via google that had this error but with no information as to how to go about resolving these conflicts.

Zeefreak 15:42, 10 October 2011 (UTC)

MW_INSTALL_PATH note is inaccurate?

The current version says "If your script fails to run, and spews out a lot of error messages, the first thing to try is to set the MW_INSTALL_PATH environment variable to point to the root of your MediaWiki installation. This will help scripts to find the necessary files, ..." But doing this actually caused the spewing of some error messages in my case, possibly because it was not finding necessary files. In particular, it somehow made the edit.php script look for a ../maintenance/include/Init.php; in fact, my maintenance directory contained no include directory, much less an include/Init.php. Odd. Perhaps there should be a "troubleshooting" section? Could this be an MW version dependency? Yakushima (talk) 06:43, 9 August 2012 (UTC)

How else to run update.php?

Hi, all.

Please, help me, a non-expert.

I'm trying to upgrade my local wiki (accessed on a single computer (running Windows XP), the same one where it's hosted) to MediaWiki 1.18.5. I've backed things up and pasted in the files and folders from the extracted archive of the new version. Now I need to run "C:\wamp\www\mywikipedia\maintenance\update.php". I've installed PuTTTY. I don't know how to find the IP address for my local wiki. In PuTTY's "Host Name (or IP Address)" box, I've tried, one at a time, "localhost" and each of the three strings of numbers I find from ipconfig (IP Address, Subnet Mask, and Default Gateway): all four result in errors; I never can get to the login screen.

1. What shall I do?
2. How shall I find the IP address of my local wiki?
3. How can I get to the login screen in PuTTY?
4. What (if any) other way is there to run the script? (I don't want to install emulator after emulator, only to encounter again and again the same problem I'm having with PuTTY.)

Please, help. Thank you very much. — Preslethe (talk) 01:32, 23 September 2012 (UTC)

Update: I went to http://www.php.net/releases/ and got version 5.1.0. I installed it and then used "C:\PHP\php-cgi.exe" to run "C:\wamp\www\mywikipedia\maintenance\update.php". I've just now done it, so I don't yet know of any problems (though Apache did crash); but at least my wiki is accessible again. — Preslethe (talk) 02:03, 23 September 2012 (UTC)

maintenance/update.php: Command not found

I can't run update.php with Putty. What's wrong here?

www.abcde123593.com> maintenance/update.php

maintenance/update.php: Command not found.

www.abcde123593.com> maintenance/update.php

maintenance/update.php: ?php: cannot open

maintenance/update.php: /bin: cannot execute

maintenance/update.php: COPYING: not found

maintenance/update.php: COPYING: not found

maintenance/update.php: COPYING: not found

maintenance/update.php: COPYING: not found

maintenance/update.php: COPYING: not found

maintenance/update.php: COPYING: not found

maintenance/update.php: you: not found

maintenance/update.php: COPYING: not found

maintenance/update.php: COPYING: not found

maintenance/update.php: either: not found

maintenance/update.php: syntax error at line 11: `*' unexpected

--79.218.195.57 21:23, 26 November 2012 (UTC)

Failed opening required '__DIR__/Maintenance.php'

I have the line require_once( __DIR__ . '/Maintenance.php' ); at the top of my maintenance scripts that is giving an error. If I change it to require_once(dirname( __FILE__ ) . '/Maintenance.php' ); it works. Why is the default code not working? How can I fix this? --Tech (talk) 08:55, 24 June 2013 (UTC)

__DIR__ is equivalent to dirname( __FILE__ ), which was added in PHP 5.3.0. MediaWiki requires that version to work. The cause of the error may be that you have different versions of PHP installed on your system, and the "php" command is picking an older one. Maybe there's an alias for the new php binary, like "php5" or "php53" which you should use when invoking maintenance scripts. --Ciencia Al Poder (talk) 09:14, 24 June 2013 (UTC)

On 1and1.com, you just have to use the command php6 instead of php5 (which loads version 5.2.7) or php (which loads php version 4.something). The scripts work great with php6. See http://help.1and1.com/hosting-c37630/linux-c85098/php-c37728/manually-set-the-version-of-php-using-an-htaccess-file-a614325.html for more information.

On HostGator shared accounts from before May 2013, PHP 5.3.x is a rather hidden option. It can be enabled for HTTP requests with a line in .htaccess but only exists at '/opt/php53/bin/php' (not in PATH) for shell use. You can use a .bashrc alias to make it easier, though. caboose (talk) 06:09, 18 November 2013 (UTC)

Maintenance scripts failing due to "cannot access" clearly working localhost port

I have a perfectly functioning 1.29.1 containing a database I updated from a quite old (1.13 I think) SQL backup. Yes I know always use XML not SQL for backup, I exported both but the XML was corrupted. Process to get it updated was noxious involving manually renaming it & slavishly copying priveleges in phpmyadmin, but it can be accessed & edited from the apache2 interface. I ran the update from mw-config and it reported updating everything to 1.29.1 and since then apache2 interface works perfectly.

However, maintenance scripts reliably fail. I can't access any of the administrator or bureaucrat accounts (long forgotten passwords) nor do I want to manually mess with this fragile database. Next step may be try that direct database hack to change a password on a bureaucrat to see if the apache2 web Special:Export will let me back up the entire database to XML. This is an absolute last resort since there are many users in this database I'd like to purge & the update.php may well have not actually updated everything right.

Using more robust dumpBackup.php - and actually all scripts including createAndPromote.php (proper way to create a new user)- I got a known error re "mysql" being unknown that was due to not having php-mysql installed (so I added it, the "mysql" is gone in PHP7 or favor of "mysqli" but this shouldn't matter see T120333). The database I used was the current bitnami installer's native stack - listed as "InnoDB" in LocalSettings.php). I found that the "mysql" vs "mysqli" problem, requiring "php-mysql" installed & the fact that maintenance scripts do not call the same PHP as apache2 all to be very poorly documented. I recommend it get a section at Manual:Errors_and_symptoms. That changed the error from not being able to find "mysql" to this error - which is all I can see even when I have turned on all the traces including SQL's:

Database.php: Cannot access the database: No such file or directory (localhost:3307)

I also discovered the problem with accessing as root@localhost which is well known but this can't be the issue as it's the user specified in LocalSettings.php that is calling the DB, not root. I changed "mysql" to "mysqli" in following, changed $wgDBuser, no effect:

$wgDBtype           = "mysql";
$wgDBserver         = "localhost:3307";
$wgDBname           = "bitnami_mediawiki";
$wgDBuser           = "bn_mediawiki";

However localhost:3307 is exactly where the database is running for the (working) apache2 web interface, which is accessing it via this exact same DBuser & DBname & DBserver - where else would it get such credentials? The only thing differing is the PHP installation invoked by command line & by apache2...

Without maintenance scripts I can't make bureaucrat accounts or otherwise back this thing up, so I can't try again with a fresh install not using bitnami, or any other method. I have run these scripts as root (with sudo) and as myself, using PHP5.6 and also PHP7.0, same results from Database.php. Yes I restarted many times with ctlscript.sh and got the "OK" message, saw localhost:3307 restart with the clear message

mysql  started at port 3307
Syntax OK
httpd started at port 80

then it fails with that message above on very next command

Database.php: Cannot access the database: No such file or directory (localhost:3307)

— Preceding unsigned comment added by Mere troll nothing to see here (talk • contribs)

When you use "localhost" as the database server, it connects through a socket and not through TCP/IP. The "No such file or directory" is because it's trying to locate the socket file (named "3307") which can't be found. Use 127.0.0.1 as server name to connect through the port. This is already documented at Manual:$wgDBserver. --Ciencia Al Poder (talk) 09:57, 6 October 2017 (UTC)

usability issues in script names

Really some of these are VERY hard to guess what they do from their names.

Usability#Poorly named and documented maintenance scripts

— Preceding unsigned comment added by Mere troll nothing to see here (talk • contribs)

Unless reported nothing would be done to fix this. --Ciencia Al Poder (talk) 09:57, 6 October 2017 (UTC)

Date of recent change to a page

Is there a maintenance script that outputs the date of the recent change to the content of a page? If not, how can I get this information directly from the database? Regards from Germany, --Mosmas (talk) 08:54, 25 March 2019 (UTC)

You can try the parse.php maintenance script passing {{REVISIONTIMESTAMP: page name }} as the text to parse with the page name. --Ciencia Al Poder (talk) 10:18, 25 March 2019 (UTC)

¡Muchas gracias! This works perfect for me. --Mosmas (talk) 12:14, 25 March 2019 (UTC)

How to use the maintenance script added to page

Instructions with NameCheap

Onlyforwikiapps (talk) 18:06, 7 August 2021 (UTC)