Project:Support desk

Jump to navigation Jump to search

About this board

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:

Before you post

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".

I do not have access to the root folder: (/bin/bash)

6
Sokote zaman (talkcontribs)

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

MarkAHershberger (talkcontribs)

Can you remove the open_basedir restriction?

Sokote zaman (talkcontribs)

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

Bawolff (talkcontribs)

/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)

Sokote zaman (talkcontribs)

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

Bawolff (talkcontribs)

are they giving a different warning? (The warning you posted shouldnt really prevent executing things. If /bin/bash isnt executable, it will instead call whatever command it is directly)

Reply to "I do not have access to the root folder: (/bin/bash)"
Ethwald (talkcontribs)

Hi,


I built a new wiki and migrated all the files from our old wiki.

Is there a way to redirect paths? Say if a user access a wiki page/URLs from the old wiki it will redirect to the new wiki including the path. Because what is happening right now is it redirects but they all go to main page of the new wiki.

A lot of links within the wiki point to absolute URL within wiki itself. Is there a way to do it properly?

Ernstkm (talkcontribs)

If you are on a shared hosting platform where you do not have full administrative access to the web server, this could be a challenge, but what you want is documented here for the Apache web server, for example.

It's a (rather broad) web server administration question, rather than a MediaWiki question, and seems beyond the scope of what people could feasibly help you with here without more specifics.

As far as fixing absolute URLs within the wiki, the proper way to do it, as I'm sure you know, is to use [[wikilinks]], or the localurl: or fullurl: magic words, if for some reason you needed more control over the URL than regular wikilinks provide. Both of those let you get an absolute URL for resources on the wiki without hard-coding anything (that you would need to change later if you're ever in this situation again). You could simply search-and-replace all of the articles with the absolute URLs within the wiki interface itself, or do a SQL UPDATE query on the underlying database to fix them.

There is also pywikibot, which is a Python solution for doing things like this, but requires programming (even more so than SQL queries).

Hope that helps. A little.

Ethwald (talkcontribs)

Thank you, will check it out

Bawolff (talkcontribs)

yes, for example with apache rewrite rules. You need to be more specific about how you are redirecting things currently and what your setup looks like currently for any advice more specific than that.

Ethwald (talkcontribs)

@Bawolff thanks for the reply. I would like to redirect it like this..

Since many users bookmarked some important pages from our old wiki say the below example:

http://oldwiki.sample.ph/mediawiki/index.php/somepage1#somepage1.1

will redirect to new wiki: http://newwiki.sample.ph/mediawiki/index.php/somepage1#somepage1.1

I have migrated all the data from old to new and I need to setup the redirection. Redirecting all the pages from old to new, can this be done? Sorry I am not that technical but I will read on it if you can help me where to look for possible solution/s.


Regards

Bawolff (talkcontribs)

which web server are you using?

Ethwald (talkcontribs)

Apache2

Bawolff (talkcontribs)
Ethwald (talkcontribs)

Hi,

Can you help me with this please?


Alias /test1 /var/www/html/test1

Alias /test2 /var/www/html/test2

Alias /Wiki /var/www/html/mediawiki

RewriteEngine On

RewriteCond %{HTTP_HOST} !newwiki.samplesite.com$ [NC]

RewriteRule ^/(.*)$ http://newwiki.samplesite.com/$1 [L,R=301]

----

The redirection works. It redirects to newwiki.samplesite.com including paths..

But it redirects also the test1 and test2 sites. Is there a way to only redirect the Alias /Wiki?

Your reply is very much appreciated.

Ethwald (talkcontribs)

Thanks! will read on it.

Reply to "Redirecting paths"

Classical source editing - odd behavior while inserting text

3
Summary by Wgkderdicke

The odd behaviour while inserting text in the editor window seems not to be a Mediawiki issue.

Wgkderdicke (talkcontribs)

I am still using the classical source editor instead of the visual editor. In doing so I encountered an odd behaviour while inserting text. At least for me.

It is about copy and paste. You copy something elsewhere and paste it in the editor window where the cursor is. The cursor is placed right after the pasted text. The line with the cursor moves right up to the top of the editor window. The just pasted text is above this line and invisible. At once.

But one could think that one rather would like to take a look at the just inserted lines. Without scrolling. It used to be different before, then it changed at some point.

Is this in my eyes odd behaviour a Mediawiki feature or bug or comes this change of behaviour with some updated toolbox round the editor?

Thanks for an answer in advance!

Ammarpad (talkcontribs)

Looks like phab:T262835, although maybe different. Can you read that task and see whether it is the same thing?

Wgkderdicke (talkcontribs)

I read that task. I think that T262835 is another issue.

I checked the Mediawiki editor with several browsers by using the sandbox page on de.wikipedia.org. It happens in every browser. After that I took a look at the HTML source. The editor window is created by a textarea tag. Googeling the textarea tag led me to w3schools.com. The explanation page of the textarea tag comes with an example. I tried that. And it happend there, too. Far and wide no Mediawiki in sight.

This seems not to be a Mediawiki issue.

max-width in Vector skin to control site layout width

17
111.69.202.141 (talkcontribs)

It's one of the dumber design aspects of MediaWiki and Wikipedia and their skins that the site fills 100% of the screen width, regardless of resolution, leading to a ridiculous appearance on high resolution monitors.

Short of a grid layout or other sophisticated approaches, what is required is a sensible max-width for the entire site layout, in the order of 1000 - 1300 px I suggest, allowing the site to scale horizontally below that but freeze on decent res screens.

I had a bunch of CSS modifications for Monobook that worked well, but they made use of the #globalWrapper which is not present in Vector. I am trying to migrate my old Monobook styling across to Vector.

I played around with adding styles to the various page elements in Vector, and even the <body> tag, but ended up frustrated trying to get the header and sidebar elements to cooperate.

Has anyone worked out some CSS for Vector that does the trick?

MarkAHershberger (talkcontribs)

This is as close as I can get:

/* upper blue line */
#mw-head-base {
	margin-left: auto !important;
	margin-right: auto !important;
  max-width: 1000px !important;
}
/* lower blue line + footer content */
#footer {
	margin-left: auto !important;
	margin-right: auto !important;
  max-width: 1000px !important;
}
/* main content */
#content {
	margin-left: auto !important;
	margin-right: auto !important;
  max-width: 1000px;
}
111.69.202.141 (talkcontribs)

Yep I got about as far myself.

  1. mw-page-base can be styled similarly but the page tabs, personal links, and the sidebar (which would now float over top of the content on lower resolutions) stump me.
MarkAHershberger (talkcontribs)

Just came up with something I like a little better:

/* upper blue line */
#mw-head-base {
	margin-left: auto !important;
	margin-right: auto !important;
	max-width: 1000px !important;
}
/* lower blue line + footer content */
#footer {
	margin-left: auto !important;
	margin-right: auto !important;
	max-width: 1000px !important;
}
/* main content */
#content {
	margin-left: auto !important;
	margin-right: auto !important;
	max-width: 1000px;
}
#bodyContent {
	z-index: 10;
}
#mw-navigation {
	margin-right: auto !important;
	max-width: 1190px;
        min-width: 1000px;
	position: absolute;
	top: 0;
        left: 50%;
        margin-left: -500px;
}
div#mw-panel {
	position: relative;
	left: 0;
	margin-left: -190px;
        width:160px;
}
div#mw-head {
	position: relative;
        right: 0;
        margin-right: 0;
        max-width: 1000px;
}
This post was hidden by 31.31.187.156 (history)
MarkAHershberger (talkcontribs)

I don't have time to do more now. And I still don't understand why you don't adjust your window to make it look better. But maybe someone else can offer more help.

74.91.102.250 (talkcontribs)

For me, I want to do this because my browser window has other tabs that conform to modern browsing standards, so I don't want to resize my window every time I switch to or from a wikipedia tab.

If someone is able to help, I think I almost have it, on a very vanilla vector-skinned site: http://www.aerenamasters.com/wiki/index.php?title=MediaWiki:Common.css

I can't figure out how to make the navigation behave well:

/* working ... */
#content{
        margin-left:auto !important;
        margin-right:auto;
	max-width: 950px;
}

#footer {
	margin-left: auto !important;
	margin-right: auto;
	max-width: 950px;
}

/* testing */
#mw-navigation {
        margin-left: auto !important;
	margin-right: auto;
	max-width: 1140px;
        top: 0;
}

Thanks for any help!

MarkAHershberger (talkcontribs)

For anyone who wants to try this but doesn't know how, you need to put it on your common.css page.

Spas.Z.Spasov (talkcontribs)

For Vector skin put next lines into MediaWiki:Vector.css or into your custom vector.css.

    /* set max width and fix the background */
    html,
    body {
    	position: relative;
    	margin-left: auto !important;
    	margin-right: auto !important;
    	max-width: 1280px;
        background-position: top left;
        background-repeat: repeat-x;
    	background-size: 100% 5em;
        background-image: url(/skins/Vector/images/page-fade.png);
        background-color: #f6f6f6;
        background-image: -webkit-gradient(linear,left top,left bottom,color-stop(50%,#ffffff),color-stop(100%,#f6f6f6));
        background-image: -webkit-linear-gradient(top,#ffffff 50%,#f6f6f6 100%);
        background-image: -moz-linear-gradient(top,#ffffff 50%,#f6f6f6 100%);
        background-image: linear-gradient(#ffffff 50%,#f6f6f6 100%);
    }
    
    /* set blue right border */
    .mw-body { border-right: 1px solid #A7D7F9; }
    
    /** fix the position of:
    			personal user menu
    			search bar
    			the pop-up indicator of language selector
    			search suggestions 
    **/
    #p-personal { right: 3pt; }
    #p-search { margin-right: 3pt; }
    .imeselector { position: fixed; }
    .suggestions { right: 3pt !important; }

If you want to apply this CSS for the restricted pages, write down next line into your `LocalSettings.php`, but first check this comment:

    $wgAllowSiteCSSOnRestrictedPages = true;
88.145.181.85 (talkcontribs)

Thank you so much! Exactly what I was looking for.

Spas.Z.Spasov (talkcontribs)

The problem that I can not solve completely is the behaviour of some pop ups as these of Extension:Popups.

Varlin (talkcontribs)
Varlin (talkcontribs)

Spas.Z.Spasov's CSS causes some offset problems (with Extension:Popups, with some unfolding combobox and with some dialogs). This alternative option seems to cause less offsets.

/* set max width and fix the background, see skinVector.patch */
#wikirouge-bodycontent-wrapper {
	position: relative;
	margin-left: auto !important;
	margin-right: auto !important;
	max-width: 1100px;
}

    html,
    body {
        background-position: top left;
        background-repeat: repeat-x;
    	background-size: 100% 5em;
        background-image: url(/skins/Vector/images/page-fade.png);
        background-color: #f6f6f6;
        background-image: -webkit-gradient(linear,left top,left bottom,color-stop(50%,#ffffff),color-stop(100%,#f6f6f6));
        background-image: -webkit-linear-gradient(top,#ffffff 50%,#f6f6f6 100%);
        background-image: -moz-linear-gradient(top,#ffffff 50%,#f6f6f6 100%);
        background-image: linear-gradient(#ffffff 50%,#f6f6f6 100%);
    }
    
    /** fix the position of:
    			personal user menu
    			search bar
    			the pop-up indicator of language selector
    			search suggestions 
    **/
    #p-personal { right: 3pt; }
    #p-search { margin-right: 3pt; }
    .imeselector { position: fixed; }
    .suggestions { right: 3pt !important; }

But it needs to be combined with this patch :

--- skins/Vector/includes/templates/index.mustache (date 1571250157017)
+++ skins/Vector/includes/templates/index.mustache (date 1571250157017)
@@ -1,4 +1,5 @@
{{{html-headelement}}}
+<div id="wikirouge-bodycontent-wrapper">
<div id="mw-page-base" class="noprint"></div>
<div id="mw-head-base" class="noprint"></div>
<div id="content" class="mw-body" role="main">
@@ -32,5 +33,6 @@
{{! html-unported outputs <div id="mw-navigation"> and <div id="footer"> }}
{{{html-unported}}}
{{{html-printtail}}}
+</div>
</body>
</html>
Vishkujo (talkcontribs)

How do you use the patch? (Or where do you put it?)

Thanks.

Varlin (talkcontribs)

You have to edit this file

skins/Vector/includes/templates/index.mustache

And add the lines marked with a " + " (here, just a div tag) at the right place.

(This syntax enables you to make it automatically using some tools)

Spas.Z.Spasov (talkcontribs)

The idea provided by @Varlin is great, except the part we need to edit some core files that would cause some additional actions on update. So the another way to add such wrapper is by using the a hook in the LocalSttings.php file:

/**
 * Skin Vector Max Width Wrapper
**/
$wgHooks['AfterFinalPageOutput'][] = 'skinVectorWidthWrapper::onAfterFinalPageOutput';
class skinVectorWidthWrapper{
        public static function onAfterFinalPageOutput( $output ) {
                $out = ob_get_clean();
                // change final html in $out
                ob_start();

                /* split the string contained in $html in three parts:
                 * everything before the <body> tag
                 * the body tag with any attributes in it
                 * everything following the body tag
                 * Ref.: https://stackoverflow.com/a/2216352/6543935 */
                $matches = preg_split('/(<body.*?>)/i', $out, -1, PREG_SPLIT_NO_EMPTY | PREG_SPLIT_DELIM_CAPTURE);

                echo $matches[0] . '<div id="skin-vector-maxwidth-wrapper">' . $matches[1] . $matches[2] . '</div>';
                return true;
        }
}

Then the CSS code in Vector.css should be similar as the sown above:

/**
 * Skin Vector Max Width, see skinVectorWidthWrapper::onAfterFinalPageOutput
**/
#skin-vector-maxwidth-wrapper {
    position: relative;
    margin-left: auto;
    margin-right: auto;
    max-width: 1460px;
}

html,
body {
    background-position: top left;
    background-repeat: repeat-x;
    background-size: 100% 5em;
    background-image: url(/skins/Vector/images/page-fade.png);
    background-color: #f6f6f6;
    background-image: -webkit-gradient(linear,left top,left bottom,color-stop(50%,#ffffff),color-stop(100%,#f6f6f6));
    background-image: -webkit-linear-gradient(top,#ffffff 50%,#f6f6f6 100%);
    background-image: -moz-linear-gradient(top,#ffffff 50%,#f6f6f6 100%);
    background-image: linear-gradient(#ffffff 50%,#f6f6f6 100%);
}

@media print {
	#skin-vector-maxwidth-wrapper {
	    position: relative;
	    margin-left: 0;
	    margin-right: 0;
	    max-width: 100%;
	}
	
	html,
	body {
	    background:none;
	}
}

/**
 * Skin Vector Max Width: fix the position of:
 *    personal user menu
 *    search bar
 *    add right blue border
**/
#p-personal { right: 3pt; }
#p-search { margin-right: 3pt; }
.mw-body { border-right: 1px solid #A7D7F9; }

When I have enough time, I will create a small extension in order to provide this functionality in more elegant way.

Lbillett (talkcontribs)

If your standards are low enough, simply adding a max-width to Mediawiki:Vector.css as below will at least keep the content constrained. It's not centered and the interface links will be way out to the right, but you won't have to look at sprawling content on your colleagues monitor.

#bodyContent {
  font-size: 0.81em;
  max-width:1000px;
}
Reply to "max-width in Vector skin to control site layout width"

Why isn't the refresh link active

11
68.110.86.107 (talkcontribs)

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?

Majavah (talkcontribs)

What do you mean by "refresh link"?

68.110.86.107 (talkcontribs)

refresh under the more tab on each page

MarkAHershberger (talkcontribs)

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.

68.110.86.107 (talkcontribs)

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.

68.110.86.107 (talkcontribs)

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

MarkAHershberger (talkcontribs)

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

The1gofer (talkcontribs)
MarkAHershberger (talkcontribs)

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.

The1gofer (talkcontribs)

can I add css to activate it?

Sokote zaman (talkcontribs)
Reply to "Why isn't the refresh link active"

Preventing to create empty pages

23
Summary by Fokebox

Need to find out one more detail

Fokebox (talkcontribs)

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?

Wargo (talkcontribs)
Ciencia Al Poder (talkcontribs)

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

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

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

Bawolff (talkcontribs)

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

Fokebox (talkcontribs)

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?

Ciencia Al Poder (talkcontribs)
Fokebox (talkcontribs)

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

Bawolff (talkcontribs)

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

Fokebox (talkcontribs)
Bawolff (talkcontribs)

Try

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

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

Fokebox (talkcontribs)

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

Fokebox (talkcontribs)

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

Matěj Suchánek (talkcontribs)
action == 'edit'
& user_age == 0
& article_namespace == 0
& added_lines rlike 'https?://'
Fokebox (talkcontribs)

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

Matěj Suchánek (talkcontribs)

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

Fokebox (talkcontribs)

Thanks!

The whole code looks now so:

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

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

Wargo (talkcontribs)

Maybe set exception to "File" namespace.

Fokebox (talkcontribs)

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

Ciencia Al Poder (talkcontribs)

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

Fokebox (talkcontribs)

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

Fokebox (talkcontribs)

Thx! Works perfect!

Reply to "Preventing to create empty pages"

MediaWiki edit.php slow at saving pages

2
2001:56A:732B:5C00:C450:1D4F:CDFF:C94D (talkcontribs)

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.

Bawolff (talkcontribs)

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

Enable Profiling to figure out where mediawiki is stuck.

Reply to "MediaWiki edit.php slow at saving pages"

Infoboxes not populating correctly

2
Chinghis (talkcontribs)

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

Bawolff (talkcontribs)

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

Reply to "Infoboxes not populating correctly"

Question about the writeapi right

9
Costas Athan (talkcontribs)

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?

Bawolff (talkcontribs)

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.

Ammarpad (talkcontribs)

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.

Costas Athan (talkcontribs)

@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.

Ammarpad (talkcontribs)

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.

Costas Athan (talkcontribs)

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.

Bawolff (talkcontribs)

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)

Costas Athan (talkcontribs)

@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.

Bawolff (talkcontribs)

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.

Reply to "Question about the writeapi right"

Global user page customization

1
Sokote zaman (talkcontribs)

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

Reply to "Global user page customization"