Project:Support desk

Welcome to the MediaWiki Support desk. This is a place where you can ask any questions you have about installing, using or administrating the MediaWiki software.

(Read this message in a different language)

See also

• Other places to ask for help

Before you post

• Check the FAQ and Errors and symptoms .
• If your question is about a specific feature, check the relevant technical manual , end-user help or extension page and consider asking on its talk page .
• For issues about the mediawiki.org website, report to Village Pump instead.
• Ask technical questions about Wikimedia websites on meta:Tech instead.

Post a new question

1. To help us answer your questions, please indicate which version of MediaWiki you are using, as found on your wiki's Special:Version page:
2. If possible, add $wgShowExceptionDetails = true;error_reporting( -1 );ini_set( 'display_errors', 1 ); to LocalSettings.php in order to make MediaWiki show more detailed error messages.
3. Please include the web address (URL) to your wiki if possible. It's often easier for us to identify the source of the problem if we can see the error directly.
4. To start a new thread, click the box with the text "Start a new topic".

انا من معجبين بكم

Since I've started a data refresh process that's necessary for Semantic MediaWiki, I'm seeing the following error message at the bottom of every page:

Warning: is_executable(): open_basedir restriction in effect. 
File(/usr/bin/php) is not within the allowed path(s): 
([...]/:/tmp/) in [...]/includes/Wiki.php on line 655 

Line 655 refers to something beginning

if ( !wfShellExecDisabled() && is_executable( $wgPhpCli ) )

No shell access as I'm on a shared host (with Suhosin enabled). Decreasing JobRunRate from "1" to e.g. "0.5" helps somewhat to reduce occurrences of the error message, but it does not solve the issue, let alone speed up the process.

With some googling you'll find a variety of solutions for PHP configuration issues involving "open_basedir restriction in effect", but almost none of them seems to cover this specific situation. The exception may be here, where the third suggestion about setting $wgPhpCli to a dummy value (?) might or might not be helpful in my case.

Any idea what could be done about it?

Some additional notes. The problem persists even if the refresh process has been cancelled. I also noticed that a lot of wikis are affected by the same issue, although no bugzilla report has been submitted yet.

OK, this may be a bug in MW 1.22:

• $wgPhpCli used to have a default value of 'php', without any requirement to set it explicitly in LocalSettings.php.
• In MW 1.22, the default value appears to have become '/usr/bin/php', pointing to a file which does not exist, hence the error message above. Explicitly reverting to a value of 'php' woukd appear to solve the issue.

Is that correct?

It was changed to /usr/bin/php even before than 1.19.

You can change $wgPhpCli in your LocalSettings if you need to, that's fine if that solves your problem.

Thanks for responding. There have not been any issues on my MW 1.19.7 installation, so something else must be involved. But at least the error message no longer shows up.

Had the same problem in 1.23alpha installations and fixed it by setting $wgPhpCli = 'php';

Thanks for Fix it.

Before:global $wgJobRunRate, $wgPhpCli, $IP;   ... 639 Line
After:global $wgJobRunRate, $wgPhpCli, $IP;    ...639 Line
             $wgPhpCli = 'php';               ...640 Line

Adding $wgPhpCli = 'php'; to /wiki/LocalSettings.php worked on my configuration as well. Thanks for sharing.

(In my LocalSettings.php I actually had to add a new line for $wgPhpCli. Searching for that variable only gave me occurences in DefaultSettings.php - just an addition which may help other MediaWiki newbies like me.)

There may be a catch though. I now have a job queue of well over a million. Does MW somehow need this to run jobs?

Aha!

https://www.mediawiki.org/wiki/Manual:Job_queue#Changes_introduced_in_MediaWiki_1.22

There's the rub (although I'm not sure I understand this completely). Thanks, Ciencia Al Poder, for explicitly adding this to the documentation.

Bug report and some workaround at: https://www.mediawiki.org/wiki/Topic:Pudv6x1hmrxi8zo3

I am getting a strange pear mail error after installing it on Fedora Server and checking the include path through following the checklist on PEAR's site. Here's all the debug info I got:

Webpage:

[3b4977d818b6fe8f04e8b74a] /index.php?title=Special:ConfirmEmail MWException: PEAR mail package is not installed

Backtrace:

from /usr/share/mediawiki/includes/mail/UserMailer.php(369)

#0 /usr/share/mediawiki/includes/mail/UserMailer.php(173): UserMailer::sendInternal()

#1 /usr/share/mediawiki/includes/user/User.php(3068): UserMailer::send()

#2 /usr/share/mediawiki/includes/user/User.php(3042): User->sendMail()

#3 /usr/share/mediawiki/includes/specials/SpecialConfirmEmail.php(145): User->sendConfirmationMail()

#4 /usr/share/mediawiki/includes/htmlform/HTMLForm.php(729): SpecialConfirmEmail->submitSend()

#5 /usr/share/mediawiki/includes/htmlform/HTMLForm.php(619): HTMLForm->trySubmit()

#6 /usr/share/mediawiki/includes/htmlform/HTMLForm.php(635): HTMLForm->tryAuthorizedSubmit()

#7 /usr/share/mediawiki/includes/specials/SpecialConfirmEmail.php(118): HTMLForm->show()

#8 /usr/share/mediawiki/includes/specials/SpecialConfirmEmail.php(79): SpecialConfirmEmail->showRequestForm()

#9 /usr/share/mediawiki/includes/specialpage/SpecialPage.php(701): SpecialConfirmEmail->execute()

#10 /usr/share/mediawiki/includes/specialpage/SpecialPageFactory.php(1428): SpecialPage->run()

#11 /usr/share/mediawiki/includes/MediaWiki.php(316): MediaWiki\SpecialPage\SpecialPageFactory->executePath()

#12 /usr/share/mediawiki/includes/MediaWiki.php(904): MediaWiki->performRequest()

#13 /usr/share/mediawiki/includes/MediaWiki.php(562): MediaWiki->main()

#14 /usr/share/mediawiki/index.php(49): MediaWiki->run()

#15 /usr/share/mediawiki/index.php(45): wfIndexMain()

#16 {main}

pear version:

PEAR Version: 1.10.15

PHP Version: 8.2.18

Zend Engine Version: 4.2.18

Running on: Linux localhost.localdomain 6.8.9-200.fc39.x86_64 #1 SMP PREEMPT_DYNAMIC Thu May  2 18:44:19 UTC 2024 x86_64

pear list:

Installed packages, channel pear.php.net:

=========================================

Package          Version State

Archive_Tar      1.5.0   stable

Auth_SASL        1.2.0   stable

Console_Getopt   1.4.3   stable

Mail             2.0.0   stable

Mail_Mime        1.10.12 stable

Net_SMTP         1.12.1  stable

Net_Socket       1.2.2   stable

PEAR             1.10.15 stable

PEAR_Manpages    1.10.0  stable

Structures_Graph 1.1.1   stable

XML_Util         1.4.5   stable

ls -lah on /usr/share/pear:

drwxrwxr-x.  11 caddy apache 4.0K May 20 20:59 pear

ls -lah on /usr/share/pear/

drwxrwxr-x.   2 caddy apache  162 May 20 20:59 Mail

php.ini

;;;;;;;;;;;;;;;;;;;;;;;;;

; Paths and Directories ;

;;;;;;;;;;;;;;;;;;;;;;;;;

; UNIX: "/path1:/path2"

include_path = ".:/usr/share/pear/"

the pear bool was true when checking, and the include path included pear when using check_php

@Reesericdotci: You shouldn't install PEAR globally for it to be used by MediaWiki, it's in the MW vendor/ directory already along with all other PHP dependencies. How did you install MediaWiki? You may need to either make sure you've downloaded all submodules, or run composer update --no-dev -o.

I installed MediaWiki using `sudo dnf install mediawiki` - I can try symlinking to vendor maybe?

Alright, running composer update --no-dev -o in /var/www/wiki worked for me - thank you!

i activate numbering of paragraphs in my user preferences. Then when displaying the page itself numbering is:

Sommaire
1 2 Welcome to MediaWiki.org help pages
2.1Reading
2.2Editing
2.3Advanced editing
2.4Collaboration
2.5Personal customization
2.6Wiki administration

Strange: There is nothing between level 1 and level 2 on first line and all is under level 2.

Then making modify source + preview with a forced TOC, all is under level 1:

Sommaire
1Welcome to MediaWiki.org help pages
1.1Reading
1.2Editing
1.3Advanced editing
1.4Collaboration
1.5Personal customization
1.6Wiki administration

Can someone analyse and correct the display ? Thanks. --Christian 🇫🇷 FR (talk) 09:04, 18 May 2024 (UTC)

What "page itself"? Please provide clear and full steps to reproduce something somewhere, including URLs.

it is written in the title, read the complete topic please. --Christian 🇫🇷 FR (talk) 08:39, 20 May 2024 (UTC)

This might have something to do with the change of the heading structure that is rolling out. Although I have proper spacing between the numbers and the titles. I suggest we wait a week or so more, before fixing this to allow changes to settle down.

thanks sometimes things appear strange to me, so I just warn. --Christian 🇫🇷 FR (talk) 10:18, 21 May 2024 (UTC)

Specify for PHP processing which method to use in your control panel - Apache or CGI. If it is Apache, select CGI.

Hi, i update MW and moved the site from hosting to VDS. Now i get this is error: I moved the site from Warning: is_dir(): open_basedir restriction in effect. File(/tmp) is not within the allowed path(s): (/var/www/www-root/data:.) in =/var/www/www-root/data/www/ih1344788.vds.myihor.ru/includes/libs/filebackend/fsfile/TempFSFile.php on line 90

How the fixed error? I've read about this PHP parameter and can't figure out what to do.

I still see the problem in MediaWiki 1.41.1

Bug report and some workaround at: https://www.mediawiki.org/wiki/Topic:Pudv6x1hmrxi8zo3

Problem Fixed.

Results: Specify for PHP processing which method to use in your control panel - Apache or CGI. If it is Apache, select CGI.

MediaWiki 1.17wmf1
PHP 5.2.12 (apache)
MySQL 5.0.90-log

There is a problem with a temporary folder path resolving.
Php on server side sets this directive as following:
upload_tmp_dir = /home/XXXXX/hdlwiki.com/tmp
and
open_basedir = /home/XXXXX/
However Wiki ignores these directives and tries to use /var/tmp
which is out of the allowed path.
This warning I received during Wiki installation:

     Warning: is_dir() [function.is-dir]: open_basedir restriction in effect.

     File(/tmp) is not within the allowed path(s): (/home/XXXXX/) in /home/XXXXX/hdlwiki.com/www/config/Installer.php on line 474
     Warning: Your session.save_path value (/tmp) appears to be invalid or is not writable.

     PHP needs to be able to save data to this location for correct session operation.

As a result I cannot upload files by url. The system returns an error:

     Warning:  tempnam() [<a href='function.tempnam'>function.tempnam</a>]: open_basedir restriction in effect.

     File(/var/tmp/) is not within the allowed path(s): (/home/XXXXX/)in/home/XXXXX/hdlwiki.com/www/includes/upload

     /UploadFromUrl.php on line 101

What can be a solution for such problem.

Set the TMP (or TEMP or TMPDIR) environment variables for what you want your temp directory. (for the upload by url error)

For the install error, this can be caused if php is configured to store session files in the temp directory (sesssion.save_path in your php.ini). This should cause logins to not work at all, but perhaps only mediawiki is dissallowed, and php session handlers don't have the open_basedir restriction. If you get that warning when installing, but can still log in after the install is done, then the warning is in error, and is a bug in the installer (should probably file a bug about it).

Where should I set TMP variable? I have these in my LocalSettings.php

$wgEnableUploads  = true;
$wgAllowCopyUploads = true;
$wgUploadPath = "{$wgScriptPath}/images";
$wgUploadDirectory = "{$IP}/images";
$wgTmpDirectory = "{$wgUploadDirectory}/temp";

$wgGroupPermissions['sysop']['upload_by_url'] = true;

and I still have the above mentioned error. The folders for uploads are all writable. The Special:Upload shows Could not create temporary file. in red.

putenv("TMP={$wgUploadDirectory}/temp");

UploadFromUrl appears to not support wgTmpDirectory, I believe this is a bug.

Really I'd consider it a bug in wfTempDir() function. Imports, and diffs (depending on config) are also affected.

Thank you! This solved the problem. Can it be fixed in the following MW release?

Dunno if the fix will make it into 1.17, but in 1.18 it most likely will.

I still see the problem in MediaWiki 1.41.1

The only workaround is to add

$wgTmpDirectory = ini_get('upload_tmp_dir');

to LocalSettings.php

I'm having issues creating the common css, or any other css for that matter, I get this error:

Fatal error: Cannot declare class FileContentHandler, because the name is already in use in /var/www/domain123.com/domainxyz.com.com/fruitwiki/includes/content/CssContentHandler.php on line 0 *

• domain names have been changed

The wiki works otherwise well, editing, loging in, history, etc, I assume this is some sort of php error (from research), but where do I solve it? I should also point out that this is an older wiki 1.35.0.

No one? Was it that specific?

it shows 1 rank which is incorrect. i tried to log in/off, but didnt help

What rank are you talking about?

What I need to do remove or hide the discussion tab ?

thanks

@AlexMeneghin: Have you had a look at Removing tabs?

I'm trying to upgrade from MW 1.25 (yes…) to 1.41.1 and I get this error on the database tables upgrade (web frontend):

...index page_name_title already set on page table.
...skipping: index change_tag_rc_tag_id doesn't exist.
Converting djvu metadata...
An error occurred:
Error 1146: Table 'Foo.actor' doesn't exist
Function: RefreshImageMetadata::execute
Query: SELECT  img_name,img_size,img_width,img_height,img_metadata,img_bits,img_media_type,img_major_mime,img_minor_mime,img_timestamp,img_sha1,img_actor,image_actor.actor_user AS `img_user`,image_actor.actor_name AS `img_user_text`,comment_img_description.comment_text AS `img_description_text`,comment_img_description.comment_data AS `img_description_data`,comment_img_description.comment_id AS `img_description_cid`,img_metadata  FROM `image` JOIN `actor` `image_actor` ON ((actor_id=img_actor)) JOIN `comment` `comment_img_description` ON ((comment_img_description.comment_id = img_description_id))   WHERE img_major_mime = 'image' AND img_media_type = 'OFFICE'  ORDER BY img_name ASC LIMIT 1  

What can I do? The script doesn't create the table.

I created it myself according to the Gerrit change. And all the other errors like img_actor, img_description_id, missing PRIMARY KEY on templatelinks etc.