Project:Support desk

Welcome to the MediaWiki Support desk, where you can ask MediaWiki questions!

(Read this message in a different language)

See also

Other places to ask for help:

• Chat rooms
• Email groups
• StackOverflow (third-party)
• Unofficial MWUsers forum (third-party)

Before you post

• Check the basic How does MediaWiki work? guide.
• 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 Current issues instead.
• For trying out wiki editing, use the Sandbox instead.

Post a new question

1. To help us answer your questions, please indicate which versions you are using, as found on your wiki's Special:Version page:
   • MediaWiki version
   • PHP version
   • Database type and version
2. 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.
3. To start a new thread, click "Start a new topic".

Since updating to 1.35, my refresh link isn't active. I can't seem to find any settings for that, does anyone know what might be the problem?

What do you mean by "refresh link"?

refresh under the more tab on each page

The refresh link is probably added by a gadget or something. For instance, I found this in one of the wikis I work on:

/* This line adds the "Refresh" tab to all pages*/
mw.util.addPortletLink ('p-views', '?action=purge', 'Refresh');

Search your MediaWiki namespace for action=purge and you may find what you're looking for.

That's interesting. It does have "<li id="ca-purge" class="is-disabled"><a href="/index.php?title=MediaWiki:Common.css&amp;action=purge">Refresh</a></li>" in the source. But I don't have an entry for it in mediawiki:common.css.

I'm not really familiar with CSS. Do you know how I would reactivate it?

Can you provide a link to your wiki so we can check it out?

@MarkAHershberger I don't think you are going to be able to see it unlessed you are logged in, but here is the link, and as screenshot. https://www.crewsgenealogy.com/wiki/File:Screen_Shot_2020-10-23_at_9.34.45_AM.png

I appreciate that my permissions on your wiki do not allow me to see that, but what I mostly wanted was a link to your wiki to see if we could identify anything that could be causing the problem.

But, no, I couldn't find anything. Without more rights on your wiki, I can't see anything that would cause the problem.

can I add css to activate it?

Page named:

MediaWiki:Gadget-purgetab.js

Build

And put the contents of this link in it:

https://en.wikipedia.org/wiki/MediaWiki:Gadget-purgetab.js

Need to find out one more detail

I have a problem at my wiki, most of the users are school pupils and they often create just empty pages adding just a couple words. Are there any tool that can prevent to create empty pages or pages with just couple of words?

Extension:AbuseFilter

Extension:AbuseFilter will work for this. You can create a rule like this:

 page_id==0
 &!("#redirec" in lcase(added_lines))
 & (new_size < 20)

Guys, can you help me please. How to download Extension:AbuseFilter for older version of my wiki. I have 1.29.1

you should use a newer version. Mediawiki 1.29 hasnt been recieving security updates for over a year.

That said, you can get old versions from github https://github.com/wikimedia/mediawiki-extensions-AbuseFilter/archive/REL1_29.zip . I'm not sure if github downloads include vendor dependencies (prob not) so you also have to run composer install --no-dev in the AbuseFilter directory after you have unpacked it

It seems to be that I have successfully installed the extension. So we shall I put this code?:

page_id==0
 &!("#redirec" in lcase(added_lines))
 & (new_size < 20)

In localsettings.php file?

Have you tried reading the manual at Extension:AbuseFilter?

Yes, now I try to use it ) Thanks

So, when I try to save the filter in this code:

page_id==0
 &!("#redirec" in lcase(added_lines))
 & (new_size < 20)

I have a system mistake, that there is an error in syntax

Syntax seems fine to me, are you sure you tried to add that code exactly?

Here what I have, see the screenshot:

https://hkar.ru/119Ck

Try

article_articleid==0
 &!("#redirec" in lcase(added_lines))
 & (new_size < 20)

instead (older versions of abusefilter might require that instead).

Thanks! Now all seems to be fine, all works!

Can you also help me how to create a filter that will not allow to non-registered users to insert external links in articles?

action == 'edit'
& user_age == 0
& article_namespace == 0
& added_lines rlike 'https?://'

Hi! Can you please help me. I want to make an exception for uploaded files. So it it necessary to provide description and the filter blocks uploading if there isn't such description. So I want users allow to upload files without descriptions

Adding article_namespace !== 6 & or action !== 'upload' & should suffice.

Thanks!

The whole code looks now so:

article_articleid==0
 &!("#redirec" in lcase(added_lines))
 & (new_size < 30)
 & action !== 'upload'

Hello! I have updated my wiki to 1.35 and enables VisualEditor. So if I upload the image via VisualEditor, it shows me a message that cannot create empty page. Shall I add to the code exception for uploading a file via VisualEditor

Maybe set exception to "File" namespace.

I can try, can you please let me know how to make such exception to the code I have already

Change action !== 'upload' to article_namespace !== 6

I guess I do something wrong. I have following code:

article_articleid==0
 &!("#redirec" in lcase(added_lines))
 & (new_size < 30)
 & action !== 'upload' to article_namespace !== 6

And I cannot save it as I have message with error

Thx! Works perfect!

Hello,

I found a similar issue in the forums, but that thread uses an older version of mediawiki and I am fairly certain my issue does not come from extensions, so I am making a new post.

I am using MediaWiki 1.31.1, PHP 7.2.24-0ubuntu0.18.04.6, and MySQL 5.7.31-0ubuntu0.18.04.1. I am using edit.php to generate pages but it's taking a long time to save the page, about 10 seconds. This is really slow because I have a similar server generating the same content that takes less than 1 second to save.

I compared the two servers and it looks like they have the same extensions enabled in LocalSettings.php, I also compared the two server's mysql settings using 'show variables' and couldn't find anything notable. So I'm pretty lost as to what is causing this slowdown. If anyone has any ideas as to what could potentially cause this slowdown, or have any idea on how to debug/log whatever happens during a page save, that would be greatly appreciated.

10 seconds sounds almost like some timeout is reached (firewall blocking something?)

Enable Profiling to figure out where mediawiki is stuck.

OK, this may take some explaining. I know only a little HTML, and less about making a wiki work. We use a locally hosted MediaWiki for our Systems Support team. We use an infobox to display pertinent info about PCs or other devices, and on some pages we can have three or four boxes. The infoboxes pull the info from an inventory database. When originally set up, the database was a CSV file. Since that time, and even before I started, the inventory was moved to Snipe-IT and MySQL.

The problem with our Wiki now is that most of the infoboxes were not updated to pull from the correct location.

This was the old code:

{{#get_file_data:file=inventory-computers|format=CSV with header|delimiter=,|data=title=Title,location=Location,hostname=hostname,label=Label(s),IP=Static IP address,MAC=MAC address,access=Remote Access,device=Device,servicetag=Service Tag,expressservicecode=Express Service Code,bios=BIOS Version,os=Operating System,network=Network Drop,video=Video Drop,audio=Audio Drop|filters=title=KIOSK}}

And here's the Infobox code that we use:

Finally, here’s how I have determined that the code should be written to pull from the correct database: </nowiki>{{#get_db_data:db=snipeit|from=assets a JOIN locations l ON l.id=a.location_id Join models m ON m.id=a.model_id|where=a.name='KIOSK'|data=title=a.name, location=l.name, label=a._snipeit_labels_5, Asset_tag=a.asset_tag, MAC=a._snipeit_mac_address_1, os=a._snipeit_operating_system_2, hostname=a._snipeit_hostname_3, access=a._snipeit_remote_access_6, servicetag=a._snipeit_service_tag_7, expressservicecode=a._snipeit_express_service_code_8, bios=a._snipeit_bios_version_9, network=a._snipeit_network_drop_10, support=a._snipeit_support_url_17, IP=a._snipeit_ip_address_4, device=m.name}}

</nowiki> On the first few pages that I updated with this code, all was well – it pulled information from the correct database, etc. But the problem occurs when we have two or more infoboxes on the page: It seems to pull info from the first box on the page to create any boxes that follow, and then duplicates the older info again in the same box. Unfortunately, our wiki is not publicly accessible so I can’t direct you to an example. But I’m thinking this is probably very elementary and I’m just missing a bracket or something. Thanks! Here are the particulars on our setup. We do have the ParserFunctions extension installed, as well. MediaWiki version: 1.29.1 PHP version: 7.0.33-0ubuntu0.16.04.16 (apache2handler) Database type and version: MySQL, 5.7.31-0ubuntu0.16.04.1

the get_db_data is a fairly obscure extension. My first guess would be bug in the extension.

According to the relative documentation the writeapi user permission enables the groups with that permission (*, user, bot) to use the write API.

The write API includes modules like Delete for example for deletion of pages.

The delete permission is set to true for the sysop group, but is not set at all for the * group in the DefaultSettings.php file. Despite the fact that the writeapi permission is enabled for the unregistered users and the fact that the delete permission is not defined for them, deleting a page through the write API is not possible for users that aren't logged in.

My question is which permissions does actually the writeapi permission give to the groups to which is assigned or in other words what does block the execution of a delete request through the API for the unregistered users?

honestly, i thought we were getting rid of the writeapi permission. It doesn't really do all that much useful and breaks mediawiki if you take it away.

Any permission not defined for a group is the same as false.

I think you're also fundamentally misunderstanding the `writeapi` permission. It does not grant people ability to carry-out privileged action associated with each and every api module.

It only allows write access via the api endpoint. But each individual module will do its permission checks and only users with the required permission will be allowed to carry-out the action. The required permissions are the same as used via the web ui. So if you don't have 'delete' permission via the web, you'll definitely not have it via the api either. The same thing applies for every other permission.

@Ammarpad

Since there are permission checks for each end every module, what's the point of having a permission called "writreapi"? If a certain permission is given to a group like "edit" or "rollback" for example, that should automatically mean that the users of this group have all the required rights to perform these actions also by using the API.

Point of permission is to control write action via the api. Even though same permissions as on the web are required for each individual action, api entry point have capability to allow users to do (or abuse) things in incredible ways.

If a certain permission is given to a group like "edit" or "rollback" for example, that should automatically mean that the users of this group have all the required rights to perform these actions also by using the API.

That's already the case and I have mentioned that above.

Point of permission is to control write action via the api. Even though same permissions as on the web are required for each individual action, api entry point have capability to allow users to do (or abuse) things in incredible ways.

Well, that's what made me start this thread. I have a wiki that allows editing only to registered users and as an extra security measure I had disabled the writeapi permission for the * group. That had as a result a 403 error by the VisualEditor and unfortunately it is not possible to give the writeapi permission specifically to the VisualEditor.

It was suggested to me though that disabling the writeapi does not really offer any extra security as the writeapi performs the same permission checks as the web interface.

So that's the critical question: Does keeping the writeapi enabled increases in any way the security risk or does the fact that the same permission checks are performed for every action, practically means that disabling the API does not offer any real benefit?

That's already the case and I have mentioned it above

When I say automatically, I mean without explicitly controlling it. In other words to remove such a permission and just keep the others.

restricting write api does not offer any security benefits. There is basically zero reasons to ever revoke that right (which is why i think it should be removed from mediawiki)

@Bawolff

well, my initial impression was that the writeapi permission was offering certain groups the ability to use all of the write API's modules independently of other permissions. Obviously, that's not the case. If users can't perform an action through the web interface, then they can't perform it neither by using the API. For example users without the edit permission can't use the edit module of the API to make an edit.

I see only one possible case for the writeapi permission to exist. Is there a possibility for users that have the edit permission to perform more actions through the API compared to the web interface? For example the edit module has a bot parameter. Could a user who has the edit permission set it to true, despite the fact that we talk about a human user?

If the later is true then maybe there is a reason for existence for the writeapi permission, not for users who don't have certain rights, but for the ones they have those rights, as a measure of preventing extra configuration that are only possible via the API.

If that's not true, then indeed it offers nothing except a little bit extra confusion and as a result it should be removed.

no that's not possible.

Original motivation was more around preventing easy data exfiltration and protection against performance issues if a bug is found, when the api was first develped. It became less and less relavent as time went on.

Hello

How can I set a set of templates for each person's user page by default so that it automatically shows up inside the user page after creating an account?

Thanks

hello

How to modify the address of the (/bin/bash) folder to the following address:

/home/example/tmp/wgTmpDirectory/

Warning: is_executable(): open_basedir restriction in effect. File(/bin/bash) is not within the allowed path(s): (/home/example/:/tmp:/var/tmp:/opt/alt/php73/usr/share/pear/:/dev/urandom:/usr/local/lib/php/:/usr/local/php73/lib/php/) in /home/example/domains/example.com/public_html/mediawiki/includes/shell/Command.php on line 311

Thank you for your help

Thanks

Can you remove the open_basedir restriction?

Thank you for your response

I do not want to use root for security and I have installed MediaWiki on the user.

And I can not access open_basedir.

Please help me to give (/ bin / bash) the address to the user from root

Thank you for your help

Thanks

/bin/bash is a file not a folder. It is insecure to put this in a directory writable by your webserver. You probably do not want to do what you are asking to do. It is significantly worse for security than not having open_basedir.

Additionally the path to bash is not configurable in mediawiki, so you cant anyways.

That said, that warning is just a warning, mediawiki should continue to work fine (however some security features that depend on bash will be disabled, specificly resourse limits on external commands)

Thank you very much for the useful information you provided

Question: Can I solve this problem by customizing the MediaWiki source?

Because I have installed two plugins that need a bash to run properly and completely

Hi guys,

As a relative noobie to mediawiki I am looking to get a little help regarding a very basic SSO project. I have a php based web site "mysite" which requires user login. I am trying to come up with a php script that does the following:

1) User logs into mysite

2) The user login scripts executes a "wikilogin.php" script

3) The wikilogin.php script logs into mywikisite and creates the required cookies in the browser

4) User can now go to mywikisite and access pages etc. without having to log into mywikisite

I am not trying to build any logic to manage user creation/change/deletion or password change. The assumption for now is simply that credentials are identical across the 2 applications.

I have tried to put together a basic "wikilogin.php" which uses the mediawiki api as follows:

  a) Get a logintoken using "api?action=query&meta=tokens&type=login&format=json

  b) Parse out the returned logintoken to a string variable

  c) Perform the login using "api?action=clientlogin&username=joe&password=secret&logintoken=<token from step 2>"&loginreturnurl=http:mysite,org"

however I am running into the error:

  "code": "badtoken", "info": "Invalid CSRF token."

I have tried to change "type"="csrf" in step 1), however then I get:

  "code": "nologintoken","info": "The \"logintoken\" parameter must be set."

Below is the php - any help would be much appreciated.

Thanks

Dennis

//

<?php

$ch = curl_init();

curl_setopt($ch, CURLOPT_URL,"http://mywikisite.org/api.php");

curl_setopt($ch, CURLOPT_POST, 1);

curl_setopt($ch, CURLOPT_POSTFIELDS,

            "action=query&meta=tokens&type=login&format=json");

// Receive server response ...

curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);

$server_output = curl_exec($ch);

//echo $server_output;

$logintoken_array = json_decode($server_output);

$logintoken = $logintoken_array->query->tokens->logintoken;

echo $logintoken;

curl_setopt($ch, CURLOPT_URL,"http://mywikisite.org/api.php");

curl_setopt($ch, CURLOPT_POST, 1);

curl_setopt($ch, CURLOPT_POSTFIELDS,

"action=clientlogin&username=joe&password=secret&logintoken=" . $logintoken . "&loginreturnurl=http://mywikisite.org");

// Receive server response ...

curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);

$server_output = curl_exec($ch);

echo $server_output;

curl_close ($ch);

?>

Forgot to mention versions:

mediawiki 1.34.4

php 7.2

i think you need to tell curl to save and send cookies for the login to work.

You may also be interested in reading about SessionManager - which i think is the more proper way to do what you are trying to do in MediaWiki.

Hi Bawolff,

Thanks for your help - I was able to make some progress: I rewrote the php script to write a cookie file and then login using action=clientlogin which thankfully returned the following response:

{ "clientlogin": { "status": "PASS", "username": "Admin" }}

However, I think I am still missing something: once this login was successful I was expecting in the same browser to be able to open a mediawiki page without logging in, however the main page is still showing "not logged in".

I also noticed that after the script successfully logged in, there was nothing listed in the browsers "Storage/Cookies" list under the domain.

Is this a case of me not understanding how cookies work?

Any help appreciated.

Dennis

EDIT: or will I need to programmatically open the wiki page from php using something like Headers() after using setcookies() to set the cookies?

EDIT#2:

OK so a little further progress:

I logged in as normal directly through the wiki main page to determine cookie behavior and saw that 3 cookies are created:

1) session cookie containing a token

2) username cookie

3) user ID cookie

I then added code to the php script which replicates these exact cookies after the login is completed using the newly acquired token to create the session cookie.

What I notice is that I can run my php script and see the 3 cookies get created and when the script echos the page, it shows as logged in.

However the moment I click on a link to go to a different wiki page, the user ID and session cookies disappear and only the user ID cookie remains "in the browser" and the page logs out.

So it seems I am close, but the elusive part is how to get those cookies to persist so that the session stays logged in?

php:

<?php

$cookie_jar = tempnam('/volume1/web/cookies','cookie');

//retrieve token

$c = curl_init('http://mywikisite/api.php?action=query&meta=tokens&type=login&format=json');

curl_setopt($c, CURLOPT_POST, 1);

curl_setopt($c, CURLOPT_HEADER, 0);

curl_setopt($c, CURLOPT_RETURNTRANSFER, 1);

curl_setopt($c, CURLOPT_COOKIEFILE, $cookie_jar);

curl_setopt($c, CURLOPT_COOKIEJAR, $cookie_jar);

$page = curl_exec($c);

$logintoken_array = json_decode($page);

$logintoken = $logintoken_array->query->tokens->logintoken;

echo $logintoken;

curl_close($c);

//log in

$c = curl_init('http://mywikisite/api.php');

$post = [

    'action' => 'clientlogin',

'password' => 'xxxxxxxxx',

    'username' => 'admin',

    'logintoken' => $logintoken,

'loginreturnurl' => 'http://1mywikisite/index.php'

];

$c = curl_init('http://mywikisite/tng/wiki/api.php');

curl_setopt($c, CURLOPT_POST, 1);

curl_setopt($c, CURLOPT_POSTFIELDS, $post);

curl_setopt($c, CURLOPT_HEADER, 0);

curl_setopt($c, CURLOPT_RETURNTRANSFER, 1);

curl_setopt($c, CURLOPT_COOKIEFILE, $cookie_jar);

curl_setopt($c, CURLOPT_COOKIEJAR, $cookie_jar);

$page = curl_exec($c);

curl_close($c);

//create 3 cookies

$cookie_name = "tng_upgrade_12_3_wiki__session";

$cookie_value = $logintoken;

setcookie($cookie_name, $cookie_value, time() + (86400 * 30), "/"); // 86400 = 1 day

$cookie_name = "tng_upgrade_12_3_wiki_UserID";

$cookie_value = "1";

setcookie($cookie_name, $cookie_value, time() + (86400 * 30), "/"); // 86400 = 1 day

$cookie_name = "tng_upgrade_12_3_wiki_UserName";

$cookie_value = "Admin";

setcookie($cookie_name, $cookie_value, time() + (86400 * 30), "/"); // 86400 = 1 day

//open wiki

$c = curl_init('http://mywikisite/index.php?title=Main_Page');

curl_setopt($c, CURLOPT_HEADER, 0);

curl_setopt($c, CURLOPT_RETURNTRANSFER, 1);

curl_setopt($c, CURLOPT_COOKIEFILE, $cookie_jar);

curl_setopt($c, CURLOPT_COOKIEJAR, $cookie_jar);

$page = curl_exec($c);

echo $page;

curl_close($c);

?>

The normal approach would be for your script to set its own cookies, and then use sessionmanager so that mediawiki recognizes those cookies and then sets its own cookies appropriately.

I think the reason why your code isnt working is because you are assuming that the login token will be the same as the session cookie value (i dont think it is)

Hi Bawolff.,

Thanks again - based on your earlier reply, I managed to figure out that the returned token is NOT the same as the session cookie token (as you also mentioned above). I was able to get curl to write the cookies to a temporary "cookie jar" file which I then read, parse into an array after which I submit a set of setcookie() commands which create the cookies in the browser.

The one minor issue I had is that it seems that action=clientlogin does not (yet?) support a "rememberMe" attribute (despite documentation showing an example using it), but since I am now fairly fluent in cookie baking, I am able to tweak the expiry time to get a session length I would like.

I am only able to use v. 1.34.4 due to other constraints, but perhaps rememberMe was introduced in 1.35.xx?

In any case, many thanks for your help!

Thanks

Dennis

I am new to mediawiki and am wondering about the display of site title:

I have a title string set in $wgSitename. I noticed that some skins display this title in the upper left corner of the screen, for example "Timeless" does display the title whereas "Monobook" does not.

Are any other options available to control this behavior preferably without messing with the html?

Thanks

Dennis

"when using different skins", that means you want different styles and looks. If you mean the sitename to look like it does in Timeless across skins, that's not possible. The main reason different skins exist is to give different looks, you should just choose the one you like best. Other than that, the only remaining option is the one you mentioned, that's to tinker with the html, maybe worthwhile, maybe not.

Thanks for your reply, and I do understand the purpose of skins :-) I am just a bit surprised that skins exist which do not display the site title (which unfortunately include those that work out of the box for me). The question was whether there exist any config options for this and based on your reply it seems the answer is "no", so on to html tweaking.

Thanks

Dennis

I'll figure out what they've done to add this.

For some odd reason, when viewing page revisions, "Username (Administrator)" is displayed beside my name despite being in the bureaucrat group (bureaucrat, sysop, widgeteditor in that order under ug_group in the db). Where everyone else's displays "Username (Bureaucrat)" and I can't quite figure out why. Any idea on how to remedy this? I already tried "createAndPromote.php --bureaucrat --sysop [user] [password] --force" which does nothing because I'm already a bureaucrat, there are no jobs in the job queue, I've hard-refreshed, I tried removing and re-adding administrator rights, I'm at a loss as to how to correct the display of this. )(Also: I know 1.33 is old, we're upgrading to 1.35 on a test site currently but waiting until we have VE working to switch). Thanks.

Product	Version
MediaWiki	1.33.0 (62dc614)
PHP	7.3.15 (cgi-fcgi)
MySQL	5.7.28-log
ICU	57.1

What is actually appending the "(Administrator)" label? is that an extension or JS script?. I believe core is not doing that, so the first thing to do is to figure out what's adding it in the first place.

Ah, interesting. I'll have to look. I (incorrectly) assumed it was core doing it. Thanks for taking the time.