Project:Support desk

From MediaWiki.org
(Redirected from Support desk)
Jump to: navigation, search
vde   This page is for questions relating to the MediaWiki software.

Welcome to MediaWiki.org's Support desk, the central on-wiki place to ask MediaWiki questions!

The greater purpose of this page is to make our Manual and other available help so good that you do not have to come here to ask questions, or making them easier to find.

There are other ways for of communication as well (IRC, mailing lists etc.). Read more here.

Before you post

Post a new question

  1. To help us answer your questions, please always indicate which versions you are using:
    • MediaWiki (reported by your wiki's Special:Version page)
    • PHP (likewise)
    • Database (likewise, e.g. MySQL 5.5)
  2. Please include the URL of your wiki unless you absolutely can't. It's often a lot easier for us to identify the source of the problem if we can look for ourselves.
  3. To start a new thread, click "Start a new discussion".

Archiving topics

Topics are automatically archived when they have been inactive for three weeks. If a question you have asked is approaching this limit and still has not been answered, please 'bump' it to prevent it being archived. However do not 'bump' for other reasons.

Start a new discussion

Contents

Thread titleRepliesLast modified
Please add a account deletion procedure!512:04, 26 November 2014
自己在公司内部搭建的media wiki,每次编辑完后点提交时大约要5秒左右的响应时间211:55, 26 November 2014
How to remove all of the hash tags/anchors/tracking codes from URLs when clickeking Email app in Extension:AddThis??011:41, 26 November 2014
Sending emails411:03, 26 November 2014
After upgrade to 1.23.6, links displayed with corrupted text for greater than and less than brackets310:40, 26 November 2014
"Error creating thumbnail: Error code: 2"1310:31, 26 November 2014
CSS not working in Hebrew Wikipedia110:26, 26 November 2014
How to remove all of the hash tags/anchors/tracking codes from URLs when clickeking Email app in Extension:AddThis?009:31, 26 November 2014
Database error when saving a page107:11, 26 November 2014
Changing the OAuth consumer callbackURL206:45, 26 November 2014
Disable API access for external sites?722:58, 25 November 2014
ResourceLoader: Add Javascript for logged in users621:35, 25 November 2014
Mediawiki Image APIs018:52, 25 November 2014
[RESOLVED] LocalSettings.php being ignored215:09, 25 November 2014
Pictures with Interwiki and Commons311:06, 25 November 2014
Public pages for unregistered users111:00, 25 November 2014
[RESOLVED] Memory Error When Trying To Upload Image To Wiki010:57, 25 November 2014
Migrate from XWIKI to MediaWIKI209:08, 25 November 2014
Upgrade from MW 1.18.1 to 1.23.5 broke sysop and Bureaucrat users functionality900:32, 25 November 2014
How do you to set a hyperlink to launch in a separate window instance. 200:23, 25 November 2014
First page
First page
Previous page
Previous page
Last page
Last page

Please add a account deletion procedure!

Please add a account deletion procedure!

2601:E:CC00:23:8A53:2EFF:FEEC:12BA14:53, 25 November 2014

MediaWiki itself is not made to delete user accounts of some users. User accounts (logged in (with usernames) or not (with IP's)) are central in the daily wiki usage. The Username/ID is connected with revisions of pages, used in discussions and so on. It's no trivial to delete a user correctly, so there is no feature in core and no working extension (iirc). You can use Extension:UserMerge to merge users. So you can use it to delete user accounts, e.g. when you merge account XY with a pseudo user account "Anonymous". All contributions will be attributed to this user account, without any chance to revert this action!

Florianschmidtwelzow (talk)15:12, 25 November 2014
 

Please provide a usecase for it. :) When somebody has made an edit and then the account is deleted, how should that be displayed?

AKlapper (WMF) (talk)15:33, 25 November 2014

That is e.g. useful to delete accounts of spammers. Anyway: What he is asking for technically is already possible - no need to invent something new...

88.130.69.19815:46, 25 November 2014

To mass delete spam accounts, it's maybe much easier to use the maintenance script, which was built for this use: Manual:RemoveUnusedAccounts.php and read the Manual:Combating_vandalism#Cleaning_up.

Florianschmidtwelzow (talk)08:55, 26 November 2014

Yeah, it depends: If the spammer has only created new pages, then I usually use this maintenance script, which allows to completely delete pages. This makes the user account unused in the sense of the removeUnusedAccounts.php script. Anyway, if the spammer changed "good" pages, which you do not want to delete just because a spammer put his junk into them, then the spammer's account will not be unused in that sense - and in this case I merge the junk into one "junk account" (the Anonymous account).

88.130.69.19812:04, 26 November 2014
 
 
 
 

自己在公司内部搭建的media wiki,每次编辑完后点提交时大约要5秒左右的响应时间

在局域网内搭建的wik,版本为1.23.5,使用LAMP平台,每次编辑完页面点提交后反应很慢,不管编辑内容是多少,最少要5秒页面才会跳转。是哪里的设置有问题吗?

Dier2014 (talk)06:10, 26 November 2014

Hi!

Our Chinese is not very good so I used Google to have your text translated to English:

---

The company built its own in-house media wiki, takes about five seconds or so the response time after the point when editing each submission.

In the LAN built wiki, version 1.23.5, using LAMP platform, after each finished editing the page point to submit response is very slow, no matter how much editorial content, at least to 5 seconds before the jump page. Where is the setting is the problem?

---

88.130.69.19811:47, 26 November 2014

I understand that saving a new revision is slow. After clicking the "Save" button, the wiki needs up to 5 seconds to leave the editing page and to display the wiki page again.

Set up profiling so that requests are logged in a profiling log file. Then save a page and post us the part of the profiling log, which shows the slow page save.

88.130.69.19811:54, 26 November 2014
 
 

How to remove all of the hash tags/anchors/tracking codes from URLs when clickeking Email app in Extension:AddThis??

How to remove all of the hash tags/anchors/tracking codes from URLs when clickeking Email app in Extension:AddThis??I am using Mediawiki 1.20

Nehakangri (talk)11:41, 26 November 2014

Sending emails

Can someone please explain the syntax needed in local settings to set up an email confirmation and a password reminder. Mediawiki is on a localhost and accessed through local intranet. What do I need to do to set up an auto reply for user reminder and email authentication? PLease couldyou provide simple step by step instructions. Running mediawiki 1.23.6 and xampp v3.2.1. Thanks.

46.32.110.24109:56, 25 November 2014

Manual:$wgSMTP has some examples

Ciencia Al Poder (talk)11:07, 25 November 2014

I have had a look, but really do not understand the guidance. Do I need to install any other software to enable emails to be sent? I am running running php v4.2.7.1. Thanks.

46.32.110.24107:17, 26 November 2014

PHP 4.2.7.1? That shouldn't be possible.

MediaWiki requires PHP 5.3.2 or later to run. See Manual:Installation requirements

Ciencia Al Poder (talk)10:35, 26 November 2014

My mistake, that was phpMyAdmin!. I am running php v5.5.15

46.32.110.24111:03, 26 November 2014
 
 
 
 

After upgrade to 1.23.6, links displayed with corrupted text for greater than and less than brackets

Versions: MediaWiki 1.23.6 PHP 5.5.19 (cgi-fcgi) MySQL 5.1.73-log

I recently upgraded from an older version to 1.23.6. The upgrade seems to go okay, except that all the Wiki's links are displayed wrong. The actual content of the Wiki is okay, but the "build-in" links display with < at the beginning and > at the end. Looking at the source xml of one of the links, it appears as: <searchprofile-articles>

It appears that the intended string is getting double encoded: The less than sign is encoded to < and then that is re-encoded to <

This obviously is an artifact of some part of the upgrade since it doesn't happen on a clean install. I can't find anything in the LocalSettings.php file that would explain the difference. I'm not sure where to look.

The Wiki URL is http://grace97330.org/Wiki

Bruce Stephens (talk)06:29, 25 November 2014

Try running rebuildmessages.php or rebuildLocalisationCache.php --force

Ciencia Al Poder (talk)11:05, 25 November 2014

Is there a way to run these if I don't have access to bash on the server (they charge extra for this and I'm on a budget). The rebuildLocalisationCache.php script refuses to run when specified directly from a browser url.

Bruce Stephens (talk)01:01, 26 November 2014

See Localisation#Caching. You probably need to remove all rows of the l10n_cache table. With phpmyadmin you could do that. There's an option to truncate the table: removing all rows of it. Just be sure to not drop the table itself.

Ciencia Al Poder (talk)10:40, 26 November 2014
 
 
 

"Error creating thumbnail: Error code: 2"

Edited by another user.
Last edit: 10:32, 20 November 2014

G'day,

I recently moved my MediaWiki from one server to another. Everything seems to work well except thumbnail generation: I receive "Error creating thumbnail: Error code: 2"

I have reviewed and tried the various documented online solutions without success. My LocalSettings.php is

$wgEnableUploads = true;
$wgUseImageMagick = true;
$wgImageMagickConvertCommand = "/usr/bin/convert";

I can confirm that ImageMagick is installed (version 6.7.7-10) and the convert command path works when I try it from the Mediawiki directory prompt. . MediaWiki is looking into the right place for images (full images upload and display fine). I temporarily changed permissions to 777 on /images and on /images/temp just to see if that solved a problem. It didn't. I tried specifying

$wgMaxShellMemory = 512 000; 
$wgMaxShellFileSize = unlimited;

But that didn't solve the problem. I tried specifying the /images/temp directory with $wgTmpDirectory = "$IP/images/temp"; but that didn't solve the problem either. For kicks I tried using /etc/alternatives/convert but that didn't work either. I logged out of the wiki after each change and 'hard' refreshed my browser just to make sure that I was looking at the new settings effects. My MediaWiki is in /var/www/html/wikiname. It is version 1.23.2.

Convinced that imagemagick isn't being called or exiting properly I followed the links and got:

me@star:/usr/bin$ ls -l /usr/bin/convert
lrwxrwxrwx 1 root root 25 Nov  3 17:39 /usr/bin/convert -> /etc/alternatives/convert
me@star:/usr/bin$ ls -l /etc/alternatives/convert
lrwxrwxrwx 1 root root 20 Nov  3 17:39 /etc/alternatives/convert -> /usr/bin/convert.im6
me@star:/usr/bin$ ls -l /usr/bin/convert.im6
-rwxr-xr-x 1 root root 6320 Mar  6  2014 /usr/bin/convert.im6
me@star:/usr/bin$ dpkg -S /usr/bin/convert.im6
imagemagick: /usr/bin/convert.im6

I tried changing the LocalSettings command path to /usr/bin/convert/im6 but it didn't help. I'm out of troubleshooting ideas. Any suggestions?

129.65.56.9602:57, 20 November 2014

You say you have this:

$wgMaxShellMemory = 512 000; 
$wgMaxShellFileSize = unlimited;

But Manual:$wgMaxShellFileSize doesn't mention "unlimited" as a valid value, and also I think "512 000" is not a valid number in PHP. It should generate a parse error. Could you please verify that?

Ciencia Al Poder (talk)10:43, 20 November 2014

G'day, I was following (http://www.mediawiki.org/wiki/Manual_talk:Image_administration) suggestion and similar posts elsewhere reporting that this solved their similar problem even when no memory limitation was expected. I did not receive a parser error in MediWiki responses, looking in ~/apache2/error I don't see one, but I also commented out this trial after it did not resolve the problem.

129.65.56.9616:54, 20 November 2014

The fact that you didn't get a parser error with that invalid code suggests that your LocalSettings.php file is being ignored altogether...

This, that and the other (talk)00:47, 21 November 2014
Edited by another user.
Last edit: 10:29, 22 November 2014

Thanks, but not true. Chances are good that I'm not looking in the right place for a parser error that doesn't report in the MediaWiki. LocalSettings.php is the effective configuration file because if I set #wgEnableUploads = false; then my MediaWiki doesn't allow uploads. I've sequentially tried these fixes, but either it's a 'more than one variable problem' or something else is causing an abnormal exit from ImageMagick. From the active LocalSettings.php

## To enable image uploads, make sure the 'images' directory
## is writable, then set this to true:
$wgEnableUploads = true;
$wgUseImageMagick = true;
$wgImageMagickConvertCommand = "/usr/bin/convert";
#$wgSVGConverterPath = "/usr/bin";
#$wgImageMagickTempDir = "IP$/images/temp";
#$wgMaxShellMemory = 300000;
#$wgMaxShellFileSize = 300000;
#$wgMaxShellTime = 220;
#$wgTmpDirectory = "/var/www/html/wikiname/images/temp";
#$wgUseImageReseize = true;
#$wgGenerateThumbnailOnParse = true;
##$wgSVGConverterPath = "/usr/bin";
#$wgTmpDirectory = "$IP/images/temp";
129.65.56.9617:46, 21 November 2014

I should have mentioned:

  • MediaWiki 1.23.2
  • PHP 5.5.9-1ubuntu4.5 (apache2handler)
  • MySQL 5.5.40-0ubuntu0.14.04.1
129.65.56.9620:35, 21 November 2014
 

Note that every line starting with a "#" character in LocalSettings.php is ignored, since it's a PHP comment.

Note that $wgImageMagickTempDir = "IP$/images/temp"; should be $wgImageMagickTempDir = "$IP/images/temp"; instead. And the value of $wgSVGConverterPath doesn't make sense. Still, all of those configuration variables are commented out, so they aren't being used in your installation.

Ciencia Al Poder (talk)10:33, 22 November 2014
 
 
 
 
 

CSS not working in Hebrew Wikipedia

Hi,

Hebrew Wikipedia looks like it's broken (no CSS). It's been like that for a very long time now.

Here's an example: http://he.wikipedia.org/wiki/%D7%98%D7%99%D7%99%D7%A1_%D7%97%D7%9C%D7%9C This is true for all pages in Hebrew.

Any idea who should fix this?

Thanks, Sagi Koren

Sagikoren (talk)14:41, 25 November 2014

Can't see a problem? It looks like any other Wikipedia :/ Can you add a screenshot and give some more information (which browser?).

Florianschmidtwelzow (talk)15:06, 25 November 2014
 

How to remove all of the hash tags/anchors/tracking codes from URLs when clickeking Email app in Extension:AddThis?

A thread, Thread:Project:Support desk/How to remove all of the hash tags/anchors/tracking codes from URLs when clickeking Email app in Extension:AddThis?, was moved from here to Extension talk:AddThis. This move was made by Florianschmidtwelzow (talk | contribs) on 26 November 2014 at 09:31.

Database error when saving a page

I am currently running a private wiki (MediaWiki 1.23.0rc0, php 5.4.34 (cgi-fcgi), mysql 5.5.40-36.1-log, LUA 5.1.5). Problem I'm facing is the wiki shows a warning saying "Database error. A database query error has occurred. This may indicate a bug in the software." everytime I save a page. The lucky is the page is then saved. How I solve this error? Thank you.

36.84.227.11205:19, 26 November 2014

Hello,

have you made an update? Did you forget to run update.php? Can you set $wgShowSQLErrors in your LcoalSettings.php to true to see the complete error message with more details?

Florianschmidtwelzow (talk)07:11, 26 November 2014
 

Changing the OAuth consumer callbackURL

How does the creator of an OAuth consumer change the consumer's callback URL? Change happens, especially in dev and test environments, and the URL may need to change. At the moment, my consumer (70dcdf4058772ddc6e89a90170e4febe) is still in proposed state, and I am unable to change the URL on the manage page (while I am able to change the RSA key or allowed IP address).

I am sorry if this is the wrong forum. I first tried asking on the Current Issues site-oriented forum first, since it is not so much a software issue as it is a data issue on this site.

Also, how does one request a consumer to be approved? It has been in proposed state for a week, no one has asked me about, and it is not obvious where/how to request a change.

Thanks, FYI this is for a new Commons project: https://github.com/ddennedy/wikimedia-video-editing-server

Ddennedy (talk)19:25, 25 November 2014

Which software are you using? Does it have to do with MediaWiki?

88.130.69.19823:02, 25 November 2014

It is new software in that github link that is using the MediaWiki OAuth extension API.

More information about the project is on this wiki page: https://github.com/ddennedy/wikimedia-video-editing-server/wiki/Requirements-Specification

The sofware uses commons.wikimedia.org as the OAuth endpoint but not really MediaWiki software. The problem I have is around the MediaWiki UI for editing the OAuth consumer or the process to request a change to data that I am unable to edit.

Ddennedy (talk)06:45, 26 November 2014
 
 

Disable API access for external sites?

I don't want others to use the API (read or write).

Can I restrict the API access so only my own server cann access it?

93.184.128.1716:15, 10 November 2014

Not inside MediaWiki, but you can create rules in your webserver.

The access to the api has the following characteristics:

  • Access from the clients (users) of your wiki, for example to add a page to the watchlist
    Those HTTP requests should have a "Referer" (sic) header from the page originating the request.
  • Access from external sources
    Those HTTP request won't have a "Referer" header, or they'll contain a different server. But note that they could fake a Referer header!

This is a bit weak, but may be useful to you.

Ciencia Al Poder (talk)10:42, 11 November 2014
 

Hmm, the question is: who are "others"?

Florianschmidtwelzow (talk)11:36, 11 November 2014
 

Sorry for the late reply and thanks for the suggestions.

I'd prefer a safe method only allowing API calls from my own server. So "others" is any extenal website or app.

Could I restrict read rights for api.php?

Subfader (talk)18:07, 16 November 2014

No, there's no configurable user right for restricting api reads.

Ciencia Al Poder (talk)10:31, 17 November 2014
 

You could add a new virtual host to your apache configuration pointing to another webroot, copy your actual wiki into it (which will use the same database as your actual wiki) and activate API (and disable it on your actual, public wiki). Now add a htaccess and deny requests from all hosts, except localhost/127.0.0.1. Nevertheless: this seems to be an ugly workaround. I'm wondering, why you don't want to activate the API for all users? All, what you can do in the API can be done through the webinterface, too :)

Florianschmidtwelzow (talk)01:10, 23 November 2014

Someone could grab all my content and make an own site / app with it, no?

Subfader (talk)21:52, 25 November 2014

That is how the internet works. He could btw also parse the HTML code of the wiki to get the content. If you don't want others to read your content, then don't publish it. And: No, also storing it online at a "secured" place will not help you, just have a look at the latest celebrity photo leaks.

88.130.69.19822:58, 25 November 2014
 
 
 
 

ResourceLoader: Add Javascript for logged in users

I have a few KB worth JS which I add in the skin when the user is logged in.

I'd like to add that code to MediaWiki:Common.js. Can I use ResourceLoader so it is only applied to logged in users?

Subfader (talk)18:02, 22 November 2014

Hello,

sure. Just create a new ResourceLoader module and add a function to the hook BeforePageDisplay and add the module only, if the user is logged in, example:

$wgResourceModules['zzz.custom.js'] = array(
	'scripts' => array(
		// path to the script
	),
	'dependencies' => array(
		// if you have any
	),
	'localBasePath' => __DIR__,
	'remoteExtPath' => '/'
);
$wgHooks['BeforePageDisplay'][] = 'onBeforePageDisplay';
 
public static function onBeforePageDisplay( OutputPage &$out, Skin &$skin ) {
	$user = $out->getUser();
 
	if ( $user->isLoggedIn() ) {
		$out->addModules( 'zzz.custom.js' );
	}
}
Florianschmidtwelzow (talk)22:50, 22 November 2014
 

You can use MediaWiki:Group-user.js, which will apply to logged in users only.

Legoktm (talk)02:33, 23 November 2014

Will be this loaded for every logged in user, or just for those, who are in the group users?

Florianschmidtwelzow (talk)22:12, 23 November 2014

All users, who are logged in, are in the group user. ;-)

88.130.120.522:31, 23 November 2014
  • facepalm* Ah, oops, my fault :P Thanks!
Florianschmidtwelzow (talk)09:15, 24 November 2014

Didn't know Manual:User group CSS and Javascript. Thanks!

Florianschmidtwelzow, I'll keep that noted. I'm new to RL and this is some basic example how to use it.

Subfader (talk)21:35, 25 November 2014
 
 
 
 
 

Mediawiki Image APIs

I am wondering if there is an API to fetch the image URL for a page on Wikipedia in BULK.

The API that I looked at is https://en.wikipedia.org/w/api.php?action=query&format=json&redirects=&prop=extracts%7Cpageimages%7Crevisions&pithumbsize=200&exlimit=1&exintro=&explaintext=&exsectionformat=plain&titles=Abraham_Lincoln%7CChina%7CJapan

but I get image URL only for the first title.

Sanchitr (talk)18:52, 25 November 2014

[RESOLVED] LocalSettings.php being ignored


I've been using MediaWiki 1.23.6 for the last few days. I tried to change the logo without success and assumed that I had the image path wrong. I now realise that ANY changes I make to LocalSettings.php have absolutely no effect at all - in fact, I can delete the file and my wiki runs just fine without it.

What's causing this and how do I fix it?

I'm running on localhost with XAMPP, PHP Version 5.5.15 and MySQL 5.6.20

88.104.241.5011:20, 25 November 2014

That most likely means that you are editing the wrong LocalSettings.php file.

Another option would be that the code in that file got cached somewhere in an opcode cache, but as far as I know XAMPP does not come with one configured (at least not by default).

88.130.94.7011:49, 25 November 2014
 

Hello!

MediaWiki always looks for the LocalSettings.php in the same directory as the index.php. So, check, if there is a file with this name or maybe a symlink or something else. If you don't know, if you cahnged something at some files in MediaWiki you should think about to download a new copy of MediaWiki and "update".

Florianschmidtwelzow (talk)11:49, 25 November 2014

Solved the problem, but the cause is too embarrassing to state publicly. The situation was entirely due to me being a bit silly.

88.104.241.5013:29, 25 November 2014
 
 

Pictures with Interwiki and Commons

Edited by another user.
Last edit: 21:53, 14 November 2013

Hi everyone,

I installed 8 wikis - 7 different languages and 1 commons. Only at the commons it is allowed to upload images. On each Wiki I installed the extention Interwiki and set it up. It is working properly to swap between the languages. At the sidebar I set a link to upload directly into the commons. This is working as well.

$wgUseInstantCommons is activated at the language-wikis, but I'm not able to include the images out of the commons into the other wikis.

I've tried: [[File:picturename.jpeg]] only a link to a not existing page within the same wiki is shown

commons:File:picturenname.jpeg a link to the picures page at the commons is show.

But how do I include the picture itself?

Any help is appreciated!

Thanx

) TS
87.178.191.2116:30, 17 March 2013

You probably need to allow uploading but disable Special:Upload on the wikis where you don't want uploading (see Manual:Hooks/SpecialPage_initList).

Also, I think you'll want to use $wgForeignFileRepos instead of $wgUseInstantCommons to point to your own commons instead of commons.wikimedia.org.

MarkAHershberger(talk)13:37, 18 March 2013
 

Got same problem. Made everything by Scenario 4 from here: http://www.mediawiki.org/wiki/Manual:Wiki_family#Scenario_4:_Multiple_wikis_sharing_common_resources

For File:Mypicture.jpeg I get red link File:mypicture.jpeg,

which link to
http://pool.mywiki.com/Special:Upload?wpDestFile=mypicture.jpeg

For pool:File:mypicture.jpeg I get blue link pool:File:mypicture.jpeg, which link to right

http://pool.mywiki.com/File:picture.jpeg

but I want image - not just link.

J-avdeev (talk)08:15, 25 November 2014

For me solution was - to use $wgForeignFileRepos (https://www.mediawiki.org/wiki/Manual_talk:$wgForeignFileRepos)

$wgForeignFileRepos[] = array(

  'class'            => 'FSRepo',
  'name'             => 'sharedFsRepo',
  'directory'        => '/home/my_user/public_html/wiki/media',
  'url'              => 'http://www.my_wiki.com/media',
  'hashLevels'       => 0,

);

J-avdeev (talk)11:06, 25 November 2014
 
 

Public pages for unregistered users

Currently I am setting up public pages for unregistered users through apache DocRoot. I want to post a public page now through MediaWiki for unregistered users. How can I do this? MediaWiki - 1.19.20 PHP - 5.3.3 MySQL - 5.0.77

Ludba (talk)21:28, 24 November 2014

[RESOLVED] Memory Error When Trying To Upload Image To Wiki

Mediawiki 1.16.4, PHP 5.3.25, SQL 5.5.32

Am trying to upload an image file to my Mediawiki. It's a .png file, 6012px x 1153px and weighs in at 202KB. I've uploaded 'large' images before without a problem. On this occasion, I get the following error.

Fatal error: Allowed memory size of 52428800 bytes exhausted (tried to allocate 20795508 bytes) in /home/locallan/public_html/includes/media/Bitmap.php on line 213

Advice would be welcome.

Seedier Wiki (talk)18:13, 25 July 2013

Please upgrade to at least 1.19.

You need to increase your allowed memory size. Try adding

ini_set('memory_limit', '128M');

to your LocalSettings.php.

MarkAHershberger(talk)21:33, 25 July 2013

Thank you. Before changing anything else, I reduced the 'physical' width of the .png file by 1000px and tried again to upload it. As is often the illogical case with images, the file size increased five fold to around 1MB but the image uploaded without difficulty. Unless I read of a major problem associated with retaining Mediawiki 1.16.4, I will do so for the time being. So I suppose this is resolved.

Seedier Wiki (talk)13:30, 24 November 2014
 
 

Migrate from XWIKI to MediaWIKI

Hello,

do anyone know what's the easiest way to convert XWIKI content to MediaWIKI

Thanks in advance

197.14.49.3413:12, 12 May 2014

Me too ! Many erros in try to import xml of xwiki !

189.22.10.6619:38, 24 June 2014
 

+1

193.183.161.2009:08, 25 November 2014
 

Upgrade from MW 1.18.1 to 1.23.5 broke sysop and Bureaucrat users functionality

Upgrade from MW 1.18.1 to 1.23.5 broke sysop and Bureaucrat users functionality

User listed in sysop and Bureaucrats MediaWiki Output receives Permission error when clicking on restricted links.

/index.php/Special:ConfirmAccounts
Permission error You do not have permission to <action-confirmaccount>, for the following reason: The action you have requested is limited to users in the group: Bureaucrats.

/index.php/Special:UserLogin/signup
Permission error You do not have permission to create this user account, for the following reason: The action you have requested is limited to users in the group: Administrators.

/index.php?title=Special:ListUsers&group=bureaucrat
Displays user.

/index.php?title=Special:ListUsers&group=sysop
Displays user.

/index.php/Main_Page

Product Version MediaWiki 1.23.5 PHP 5.3.17 (apache2handler) MySQL 5.6.20-log

Thank you

Tcaton-nm (talk)21:54, 20 November 2014

Hi!

Two things: On Special:ConfirmAccounts, does it really contain the text <action-confirmaccount> at that place? This points to a missing language label. Anyway, since the special page itself is there, the extension obviously is installed in some way.

If I remember correctly, the usernames on Special:ListUsers are not cached, but displayed "live". Anyway, have a look at the database table user_group. Are there rows for the according user? User_id in ug_user and the name of the group written as a word in ug_group?

88.130.125.3323:03, 20 November 2014

I used links off: /index.php/Special:ListGroupRights under Groups: Bureaucrats & Administrators to test my Permissions.


These all gave me Permission Error:

index.php/Special:Maintenance

index.php/Special:UserCredentials

index.php/Special:ConfirmAccounts

index.php/Special:UserLogin/signup


Once again these URLs do display my username:

index.php?title=Special:ListUsers&group=sysop

index.php?title=Special:ListUsers&group=bureaucrat




My USERID is listed twice: from user:user_id in user_groups:ug_user.

Confusingly all user_groups:ug_groups are displayed as BLOB.

Thanks for helping!!!

Tcaton-nm (talk)00:04, 21 November 2014

I think you should be able to actually read the contents of the fields, if you do a SELECT query and add the CONVERT() function to it like this:

CONVERT(ug_group USING utf8)
88.130.80.15213:37, 21 November 2014
 

Yes labels in <> on all the error pages:

<action-maintenance>
<action-lookupcredentials>
<action-confirmaccount>

I will research: "missing language label".

Working on CONVERT function - THANKS!!!

Tcaton-nm (talk)16:18, 21 November 2014
 

It appears I have an answer.
In MediaWiki 1.18.1 logging into EDir created user names using the EDir convention: Uppercase Uppercase lowercase rest of username.....
Logging into Upgrade MediaWiki 1.23.5 forced Username to: Uppercase lowercase rest of username....
Simply editing all usernames in DB to be Uppercase first character only fixed it.

Tcaton-nm (talk)20:16, 21 November 2014

Alright, the problem then was not that the (old) usernames did no longer have the right permissions, but that you in fact got logged in with a different username and this user had a different ID in the user table and so did not get the permissions assigned. Sounds to me like something was changed in the (external?) login mechanism you are using.

88.130.80.15223:36, 21 November 2014

I believe MediaWiki 1.23.5 forces all my logins:
USERNAME
USername
username

To:
Username

All 4 succeed logging into my Edir account: USername.
Forces Username displayed to: Username,
Browser saves same password to 4 usernames:
USERNAME
USername
username
Username

Still can't Merge accounts: USername to Username.

Only way to fix is delete all USernames from database and leave orphaned records!

Tcaton-nm (talk)18:01, 24 November 2014

Renamed in Database: USername to U1ername.
Merged: U1ername to Username, with success.

Can anyone tell me if this will either break anything or leave orphaned records?

Thanks.

Tcaton-nm (talk)18:11, 24 November 2014

I expect that the UserMerge extension works with the user ID, not with the user name. That means: It should work, but what you do is not what is supposed to be done. I would double check, if usernames are displaying correctly after that, e.g. in the page histories.

As for your usernames: MediaWiki username must start with a capital letter. That means that your user "username" is invalid. You should not have users with first letter in lowercase. As for the other variations, I think they might be OK. There is a maintenance script, which can check users for validity. You might want to run it to see...

Anyway, I think that the problem originates in the way you are doing the login/registration of user accounts for MediaWiki. MediaWiki should not change any user name. So "USername" and "Username" are two different accounts, but whether you supply the one or the other should not cause problems.

88.130.94.7000:10, 25 November 2014
 
 
 
 
 

How do you to set a hyperlink to launch in a separate window instance.

How do you set a hyperlink to launch in a different window - I DO NOT want to launch within the same window as my page is displayed. - go to another page or launch a pdf

normally - you can do following: where: target="_blank" which launches the page in another window or tab.

<a href="http://iswiki.hdfowler.com/mediawiki/index.php?title=Daily_Invoice_Processing" class="external-link" target="_blank">Daily Invoice Process</a>

184.164.106.16718:05, 24 November 2014

Why do you think it's a good idea to define how a link is opened (new tab vs new window) in a user's browser, instead of letting the user have the usual default behavior of her/his browser?

Malyacko (talk)22:23, 24 November 2014

If you want all external links to do so, MediaWiki has a setting for it: $wgExternalLinkTarget. Just add the following to your LocalSettings.php:

$wgExternalLinkTarget = '_blank';

Anyway, please note that doing so forces all external links to open in new windows, which by many users is regarded to be bad behaviour.

88.130.94.7000:23, 25 November 2014
 
 
First page
First page
Previous page
Previous page
Last page
Last page