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
First page
First page
Previous page
Previous page
Last page
Last page

Bot or so?

Dear Member,

The wiki

http://www.newyorkweb.co/wiki

has a lot of unclear contributions of doubtfull users.

It might be because of a bot or so.

How can I verify the IP addresses of the users or contributions?


Thank you.

Hansie

Hansie (talk)20:13, 5 November 2014

Oh yeah, that's called "normal spam" problem :D You should consider to use some extensions to avoid these spam bots to from editing and/or registering on your wiki. Read the Manual:Combating_spam to know how to do what :) The first step yould be some good captcha ;)

Florianschmidtwelzow (talk)21:11, 5 November 2014

Thank you Florian!

It was easy to implement ReCaptha, but an error while registering :

"

New York City could not send your confirmation mail. Please check your email address for invalid characters.

Mailer returned: Policy restriction in effect. The fifth parameter is disabled on this system

".

But a confirmation mail was send. I used a normal e-mail address.

What's wrong?

Hansie

Hansie (talk)22:05, 5 November 2014

Hello! This error comes, because your hoster hosts php in safe_mode. In this mode, php's mail() function will return false with a warning when called with the fifth parameter (MediaWiki uses this parameter iirc) which MediaWiki interprets as an error while sending the e-mail (and add the above error message), see the Manual for more information.

You should ask your hoster to disable the completly senseless safe_mode. This function is deprecated in php 5.3 and removed in 5.4 anyway.

Florianschmidtwelzow (talk)21:56, 6 November 2014

Florian,

I got 2 responces from my webhoster:

1 The issue is that we only allow 4 parameters and you seem to be using 5. You need to make sure that you use only 4 parameters when sending the email.

2 Also Safe Mode is disabled on our servers by default.

I got also the next information: PHP Version 5.3.29 : http://www.one-docs.com/php5/ : safe_mode Off Off.

Hans

Hansie (talk)11:07, 9 November 2014

Hello!

The 5. parameter is an official parameter documented on the php.net Manual page, so i don't think, that the developers will remove or implement a workaround for this; most hosters allow 5 parameters. So i would suggest to ask your hoster, why they block additional paramters to the mail() function.

You can try to open a bugreport in bugzilla (BUGREPORT), but i think it doesn't have much success.

Florianschmidtwelzow (talk)22:10, 10 November 2014
 
 
 
 
 

Does anyone know where I might be able to find a copy of the files for this extension. I have searched for hours with no luck.

Thanks, Don

Dcshank (talk)21:38, 7 November 2014

Hi Don!

I do not know an extension called PDFThumbs, but there is an exte called Extension:PDFThumbnails. Its files seem to be no longer online currently, but the extension page still points to a website. Maybe you can write its owner a mail asking him for the files...

88.130.88.17322:52, 7 November 2014
Edited by another user.
Last edit: 01:52, 24 November 2014

Yeah, That's the one. I saw for several other Apps like Drupal. Maybe that is where PDFThumbs got stuck in my head. Somewhere I think I found two authors, but no way to reach either.

  ------------------Break for some time-----------------

Silly me. If I would have read the instructions, it does not have a directory. It was sitting quite pretty all by itself in the extensions directory.

So, I have a copy of the code. Is there a good place to put it, besides somewhere public on one of my servers?

After weeks of trying to make something work, It was doing what I needed to begin with, just not enough lights on upstairs any longer for me to see it :p


Thanks 88.130.88.173.

Dcshank (talk) 01:52, 24 November 2014 (UTC)

75.161.126.119 01:50, 24 November 2014 (UTC)03:11, 8 November 2014

Just out of interest, where did you find the code? If the extension isn't publicly available, we may as well delete (or at least archive) the extension page.

This, that and the other (talk)10:07, 24 November 2014

It was on my server the entire time. I was looking for a folder by that name, but it was just a file in the extensions folder. Should I upload it somewhere? Or should I post a link to a copy on my server? Or is there no interest in it any longer? I found I did not need if for what I wanted to do, so it is taking up space at the moment, but someone may want to make use of it.

Dcshank (talk)23:00, 27 November 2014

If you're prepared to host a publicly-accessible copy of the PHP file, that would be better than nothing. At the moment this extension is not available anywhere on the Internet (at least, as far as I could find).

This, that and the other (talk)01:35, 28 November 2014
 
 
 
 
 

new user welcome message

How can I change the welcome message when a new user is registered? A new user is directed to the following page:


Special:UserLogin&action=submitlogin&type=signup&returnto=wiki main page


The message a new user gets is:

Your account has been created. You can change your EU_WRAP preferences if you wish.

Return to wiki main page.


Thanks

46.185.245.20506:04, 27 November 2014

Hi!

You can change the message by edit this wiki page: MediaWiki:Welcomecreation-msg. You need the interface edit right to change interface messages (default for administrators).

Florianschmidtwelzow (talk)13:25, 28 November 2014
 

Long term support release

Is it correct, that the 1.24-version gets the LTS status? Since the release of the 1.24.0-version this version is marked as LTS version on the download page. The version lifcylce page states, that besides 1.19 the 1.23 version is the current LTS version and will be maintained until May 2017.

Wgkderdicke (talk)12:29, 28 November 2014

1.23 and 1.27 are/will be LTS versions. 1.24 will not be one and will only have the short lifetime up to November 2015.

The page Download should be fixed accordingly!

88.130.71.19012:36, 28 November 2014

YesY Done Correct, LTS is 1.23 not 1.24. Fixed in Template: Template:DownloadMediaWiki

It needs to be go through translation workflow first.

Some pings: @Shirayuki, Amire80, Nemo_bis, Hoo man, Jack Phoenix:

Florianschmidtwelzow (talk)12:41, 28 November 2014
 
 

Trying to create a custom button to old edit toolbar with onClick function

Edited by another user.
Last edit: 10:34, 28 November 2014

How can I create a new button in the old toolbar with a custom onClick js function?

I'm trying to create it with the addbutton() function but it does not work at all, and I do not know how should I pass my custom function to the addbutton.

p.e:

if ( mw.toolbar ) {
    
          function test(){

                    alert("Hi"); 
                    
          }

          mw.toolbar.addButton({speedTip:"Hi", onClick: function(){prueba()} });
}

The button appears, but when clicking on it, it does not do anything...

any ideas?

Ty!!

Intentandocrearunboton (talk)13:57, 27 November 2014

You've defined function test, but at onClick you're calling prueba(). You have to use the same name.

You can even simplify it to:

mw.toolbar.addButton({speedTip:"Hi", onClick: test });

That way, you only need to pass the function name (without the parentheses), because it will work as a function reference itself.

Ciencia Al Poder (talk)10:37, 28 November 2014
 

[RESOLVED] Special pages broken after upgrade to 1.24

I have just moved my mediawiki 1.15 installation over to a new server and upgraded to the 1.24 version.

PHP version 5.6.0; MySQL version 5.6.21

The upgrade seemed to go smoothly, with some expected problems. I had to remove StartProfiler.php; I had to remove old skins; I removed the out-of-date extension FCKEditor; the AutomaticRemoteUser extension does not seem to be working. I can worry about the extensions later, though.

Right now I can view and edit pages OK, which is why I say the upgrade seems to have gone fine.

However, none of my Special pages work! They all give an error similar to:

Fatal error: Call to undefined method SpecialSpecialpages::setContext() in E:\www\wiki\includes\specialpage\SpecialPageFactory.php on line 553

UPDATE: I fixed it. The error was caused by an old GoogleMaps extension that was deprecated. I thought it was commented out but it wasn't!

Thanks!

GnomeSkull (talk)19:13, 27 November 2014

After Upgrade from 1.23.7 to 1.24.0 I got Error

I'm happy that MediaWiki release new update, It's been a month since I using MediaWiki engine and I need learn more, recently I created new website using the latest version before new update which is MediaWiki 1.23.7, until I got email today that MediaWiki released new update, instantly I update after reading the manual. But I face this error:

[30a3b0f8] [no req] Exception from line 61 of /MYFOLDER/includes/WebRequest.php: MediaWiki does not function when magic quotes are enabled.

Backtrace:

  1. 0 /MYFOLDER/includes/Setup.php(544): WebRequest->__construct()
  2. 1 /MYFOLDER/includes/WebStart.php(121): require_once(string)
  3. 2 /MYFOLDER/index.php(43): require(string)
  4. 3 {main}

I'm so frustrated, please help.

UPDATE[edit | edit source]

Still frustrated with the latest update finally I downgrade with overwrite the file to the original version I use before (1.23.7)

Alid abdul (talk)05:59, 27 November 2014

The obvious fix for the error is to disable magic quotes

http://php.net/manual/security.magicquotes.disabling.php

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

Been reading that I'm still confused hehe, not that expert with this kind :( Btw I tried to add the line on the .htaccess file but no luck :(

Alid abdul (talk)03:46, 28 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

谢谢你的回复,我去试一试;我的英语也不好,所以只能通过翻译来和你们沟通

Dier2014 (talk)01:37, 27 November 2014

Thank you for your reply, I went to try it; my English is not good, so come and you can only communicate through an interpreter

---

88.130.94.16202:05, 27 November 2014

Here are the steps:

  • Rename the file StartProfiler.sample to StartProfiler.php.
  • In this file: Make sure that the profiler is used: Set $wgProfiler['class'] to "Profiler" like so:
$wgProfiler['class'] = 'Profiler';
It should not be set to "ProfilerStub".
  • In LocalSettings.php, at the end of the file, add this:
// Path to your log file. Adjust this line!
$wgDebugLogFile = '/var/www/mediawiki/path/to/my/logfile/Logfile.log';

// Only record profiling info for pages that took longer than this
$wgProfileLimit = 0.0;
// Don't put non-profiling info into log file
$wgProfileOnly = false;
// Log sums from profiling into "profiling" table in db
$wgProfileToDatabase = false;
// If true, print a raw call tree instead of per-function report
$wgProfileCallTree = false;
// Should application server host be put into profiling table
$wgProfilePerHost = false;
 
// Settings for UDP profiler
$wgUDPProfilerHost = '127.0.0.1';
$wgUDPProfilerPort = '3811';
 
// Detects non-matching wfProfileIn/wfProfileOut calls
$wgDebugProfiling = false;
// Output debug message on every wfProfileIn/wfProfileOut
$wgDebugFunctionEntry = 0;
// Lots of debugging output from SquidUpdate.php
$wgDebugSquid = false;

Save a wiki page.

Check the logfile.

We need the information from the according request. This information will contain a table with percentages. This is what we need!

88.130.94.16202:23, 27 November 2014
 
 
 
 
 

Editor disappeared after upgrading wiki to latest version

So I just updated my wiki to 1.23.6 version (previously 1.22.1).

I kept everything the same, same local settings and everything, uploaded the new package through FTP and ovewrote everything existent, ran the mw-config, then tested the wiki and the editor simply disappeared, there isnt even a minimalistic editor, its just the editing page with no editor at all.

The only error appearing in my error log is this one, which Im not sure has anything to do with this issue

  • PHP Fatal error: Class 'ResourceLoaderLanguageNamesModule' not found in /home/comptf/public_html/includes/resourceloader/ResourceLoader.php on line 437

I have all these lines on my localsettings

require_once( "$IP/extensions/WikiEditor/WikiEditor.php" );
$wgDefaultUserOptions['usebetatoolbar'] = 1;
$wgDefaultUserOptions['usebetatoolbar-cgd'] = 1;
$wgDefaultUserOptions['wikieditor-preview'] = 1;
$wgDefaultUserOptions['wikieditor-publish'] = 1;


Server info:

  • PHP Version 5.4.33
  • MySQL Version 5.6.21

My wiki is the following: comp.tf

Kanecow (talk)03:42, 13 November 2014

It seems you downloaded the false WikiEditor version. The required class ResourceLoaderLanguageNamesModule was added in MediaWiki 1.24, which the extension seems to be built for. So, please download WikiEditor again for REL1_23 and try again :)

Florianschmidtwelzow (talk)12:50, 13 November 2014

this doesnt seem to be the case. Just did that and it's still not working

Kanecow (talk)15:20, 13 November 2014

If that function has been added in 1.24, it will be the case. :-) Maybe you now still have a cache problem; try emptying all caches you have, e.g. on the server, maybe on a proxy in between and in your browser...

88.130.124.21917:17, 13 November 2014

but i never even installed or touched anything that has to do with 1.24

I simply updated my installation with a 1.23.6 package directly downloaded from here.

Kanecow (talk)20:24, 13 November 2014

I believe these are two different problems. I do not necessarily see a connection between the class name "ResourceLoaderLanguageNamesModule", which obviously is missing, and the missing Editor.

Does the class name error still happen? If so, you can find the source of the class name error by searching the files of your wiki installation for the text "ResourceLoaderLanguageNamesModule". This should tell you where this (wrong?) class is used.

Please make sure that you followed our manual Upgrade; especially please make sure that no old files of the old MediaWiki version have been left behind as explained in Manual:Upgrading#Files_remaining_that_may_cause_errors!

88.130.103.9922:08, 13 November 2014
 
 
 
 

Can anyone else help me out with this issue. My wiki is a big big and Im missing out on a lot of potential edits

Kanecow (talk)21:27, 18 November 2014
 

Please help, I have faced with the same problem when I had upgraded my wiki from 1.20.6 to 1.22.13

Fokebox (talk)21:58, 18 November 2014

I have just noticed that on my local wiki of the same updated wiki 1.22 all works fine. Can be a reason from hosting!?

Fokebox (talk)22:41, 18 November 2014
 

By me the problem was resolved as soon as I removed Vector extension, cause in the new version this skin is built-in

Fokebox (talk)17:11, 19 November 2014

The Vector skin is built into MediaWiki - and it also was in your old version. I guess you mean you have uninstalled the Vector extension. This extension now is included in the Vector skin or in the MediaWiki core and is no longer needed.

88.130.112.21901:50, 20 November 2014
 

bump

Kanecow (talk)04:35, 27 November 2014

Why bump? you said the issue has been resolved after removing Extension:Vector

Ciencia Al Poder (talk)10:41, 27 November 2014

No I didn't. Where did you see that?

Kanecow (talk)19:48, 27 November 2014

It was Foxebox who said he had the same problem and we solved his issue.

88.130.71.19000:28, 28 November 2014
 
 
 
 

Content Not Showing In Wiki

I have an old version of Mediawiki (1.16.4) which I use for local history research. When I tried to access it today, none of the content would display. Regardless of which page I navigate to, the Mediawiki code can be seen in edit mode but does not render when I exit that mode. Any suggestions, please?

Seedier Wiki (talk)15:02, 21 November 2014

Hi!

This most likely is this problem: Manual:Errors_and_symptoms#All_pages_have_no_content.2C_but_when_editing_a_page_the_wiki_text_is_there.

Most likely a MediaWiki upgrade should solve it!

88.130.80.15215:32, 21 November 2014

Thanks. The reason I'm still using 1.16.4 is my lack of knowledge regarding upgrading. Is it 'easy'? Which version can I move too with minimal hassle? How do I protect the wiki text during upgrade? There are around 2.5m words, hundreds of images and thousands of hours invested in the project so far.

Seedier Wiki (talk)15:41, 21 November 2014

Just seen reference to upgrading to a minimum of 1.22.1 but I'd welcome advice on queries posted previously. I'm a bit out of my depth!

Seedier Wiki (talk)15:46, 21 November 2014

Upgrading is not really difficult. When you do it for the first time, you will need some time to do it, but it should be feasible.

Some notes:

Make sure you have a working backup: All files of the MediaWiki installation and the database!

Your wiki text, images and so on will all stay as they are during upgrade; anyway, I can only repeat that: Make sure, that your backup is working! Try extracting it and see, if a wiki, which you have set up from the backup, works!

Finally: Which versions of PHP and of MySQL are you using? The page Special:Version in your wiki will tell...

88.130.80.15218:22, 21 November 2014

In Special:Version, it is like all the other pages, blank wiki page template with no content. However, my server cPanel shows that it is using PHP version 5.4.35 and MySQL version 5.5.40-cll.

Although you're making it sound like a 'small' job, I would prefer that the upgrade be carried out by someone who knows what they are doing. Is there anyone on here who would consider taking on the task for a few bob?

My prime concern is for the wiki content which is very 'valuable'. I simply cannot risk it.

Seedier Wiki (talk)20:18, 21 November 2014
 

On the subject of upgrading, I have access to Softaculous in my server's cPanel. Would you recommend using a Softaculous script to uggrade from MediaWiki 1.16.4 to either 1.19.21 or 1.23.6 both options being available to me. I ask because I am aware that there have been some issues with using Softaculous to update various packages.

Seedier Wiki (talk)21:00, 21 November 2014
 

Well, 1.16 is not supported anymore and has security bugs. You should upgrade to one of the supported versions.

As a last resort, apply the patch provided in bug 58640 in your code.

Ciencia Al Poder (talk)18:28, 21 November 2014

The bug fix seems to relate to MediaWiki 1.22.0 and not 1.16.4 which I've been using?

Seedier Wiki (talk)20:19, 21 November 2014
 
 
 
 
 

1.23.6 Upgrade error

Everything Food & Drink
MediaWiki 1.23.5
PHP 5.3.28 (cgi-fcgi)
MySQL 5.5.37-35.1
Lua 5.1.5

I've posted this error at the extension page, but have not had any replies, can someone please help me with this error, thanx


Catchable fatal error: Argument 3 passed to ConfirmAccountUIHooks::setRequestLoginLinks() must be an instance of SkinTemplate, none given in /public_html/w/extensions/ConfirmAccount/frontend/ConfirmAccountUI.hooks.php on line 27

Still need some help !

Mlpearc (open channel)21:48, 5 November 2014

Where are you calling ConfirmAccountUIHooks::setRequestLoginLinks()? Checking the extension's source code, the third argument must be an instance of SkinTemplate.

88.130.125.3718:33, 27 November 2014
 

Help please change the copyright in the wiki

Help please change the copyright in the wiki. I do not know where it is changing

87.249.29.21009:46, 27 November 2014

Importing a pdf file through php

I've noticed the importImages.php enables one to upload images from a local directory. I would like to do this for a pdf instead of an image and importImages.php doesn't seem to work with the .pdf extension.

Thank you

Mfort123 (talk)22:04, 26 November 2014

What error do you get when you try uploading a file with this script?

Here is the source code: https://github.com/wikimedia/mediawiki/blob/master/maintenance/importImages.php

88.130.94.16222:12, 26 November 2014

I had commented out $wgFileExtensions in the LocalSettings.php file which was set to 'pdf'. I had alread uploaded pdf files before, so I didn't think this was the source of the problem. Now it works and yes I know there is the --extension that I could have used. Silly mistake on my part.

Mfort123 (talk)00:30, 27 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
 

The best person to fix problems on hewiki Amir. I don't see a problem, but maybe he'll be able to help.

MarkAHershberger(talk)18:22, 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

I was able to truncate the table, but it didn't fix the problem. Are there other caches that I should try clearing?

Bruce Stephens (talk)17:18, 26 November 2014
 
 
 
 

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
 
 
 
 

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
 
 
 
 

"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
 
 
 
 
 

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
 
First page
First page
Previous page
Previous page
Last page
Last page