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
Is it possible to make REVISION*** to show the affected revision instead of the last one?123:25, 17 September 2014
References123:23, 17 September 2014
I see search results page instead of article2222:40, 17 September 2014
Can`t edit preferences121:54, 17 September 2014
Suppressing replacement of line breaks with spaces720:36, 17 September 2014
Undo or delete everything since a certain date120:35, 17 September 2014
Wiki spam617:53, 17 September 2014
Mobile linking017:36, 17 September 2014
New links not acknowledging that page exists417:17, 17 September 2014
Problem moving images between wikis015:24, 17 September 2014
Wikispecies help215:08, 17 September 2014
RandomInCategory213:14, 17 September 2014
Updating without Updating *_from_namespace fields in links tables.412:36, 17 September 2014
[RESOLVED] I got a syntax error while I trying to set up my wiki412:30, 17 September 2014
Problem with getting skins work with most recent MediaWiki version209:40, 17 September 2014
[RESOLVED] How to integrate Bumpin.com tool bar?609:32, 17 September 2014
[RESOLVED] PHP errors when trying to upgrade709:05, 17 September 2014
installing pywikibot108:25, 17 September 2014
Upload file warning700:08, 17 September 2014
[RESOLVED] Trouble uploading after installation2220:27, 16 September 2014
First page
First page
Previous page
Previous page
Last page
Last page

Is it possible to make REVISION*** to show the affected revision instead of the last one?

For example, I would like to use something like a "citation needed" template. But I would also like to use a human-readable timestamp to indicate when the "citation needed" template (actually just a user-friendly mark) was inserted to the page. Unfortunately REVISIONYEAR, REVISIONMONTH and REVISIONDAY2 show the last change date and time only.

Thanks. (195.234.75.155 11:54, 17 September 2014 (UTC))

195.234.75.15511:54, 17 September 2014

Put subst: in front of it. For example, use {{subst:REVISIONMONTH}} instead of {{REVISIONMONTH}}. It will then get "baked" into the page when you save it, so it won't change in the future.

Jackmcbarn (talk)23:25, 17 September 2014
 

References

Edited by another user.
Last edit: 23:23, 17 September 2014

Hello,

I am new to Media Wiki and am trying to add references to a corporate Media Wiki page I am building. I have the Cite extension installed, but when I add <ref>tags</ref>, they just appear in-line in the document. I've even tried copying content from Wikipedia to make sure that my formatting is correct. Do I have to install template:ref list? If so, how do I do that?

Thanks

4.30.145.16617:52, 17 September 2014

You need to install Extension:Cite.

Jackmcbarn (talk)23:23, 17 September 2014
 

I see search results page instead of article

I've recently upgraded from MediaWiki 1.22 to 1.23, and I notice now that when I type in a search term, I always see a search results page, even if there is an article that matches the name.

  • Before, if I typed "XYZ" and if there is an article named "XYZ", the system displayed that article right away.
  • Now, I get a results page that says "There is a page named XYZ on this wiki", lists that page and then a bunch of other pages that link to it.

Is there a setting that's changed that I'm not aware of? Can somebody point me in the right direction?

Thanks!

Supasaru (talk)19:09, 25 July 2014

I have the same behaviour, I find it annoying, but since it worked before and there anyway are obviously no efforts to change this, I fear some people might even think that's intended.

88.130.122.1319:29, 25 July 2014

In my opinion that's the best way to handle this (but, like i said, that's my personal opinion). What is, if i want to search for the string "XYZ" in other articles? There is only one button "search", not like in past a button for "full article" and "search".

Florianschmidtwelzow (talk)14:36, 26 July 2014

Click on "containing XYZ" and you will be brought to the search page. The fact that hitting enter opens the search, although a page with exactly this name is present, is really confusing. Afterwards I always have to click the page name as if MediaWiki was asking me, if I really meant my search serious. This change lowers user experience. Or is there an option, which I could set to work around that bug?

88.130.96.13115:26, 26 July 2014
 
 

Wikipedia, the biggest user of the MediaWiki software (if I'm not mistaken) continues to bring you directly to page XYZ, and not a search results page.

This leads me to believe there's a setting somewhere, but where? Anybody have an idea?

Supasaru (talk)23:48, 26 July 2014

I could not believe that, but you are right: While on Wikipedia this works correctly, it is broken e.g. on a system of mine (running MW 1.23.1). I also want to know, how I can fix this for my system!

There is no fitting documentation at Manual:Configuration_settings#Search

88.130.96.13100:15, 27 July 2014

Ähm, yeah :) I have tested it now with Vector skin on my private wiki (which is running 1.24wmf12), and if i search for a page which exist, i will be redirected to this, not to the search result page. In my custom skin i will be redirected to the search result page ever, so do you use a custom skin? Then you must change the search button from fulltext to go :)

Florianschmidtwelzow (talk)12:58, 27 July 2014

Yes, I do use a custom skin. I still remember how I put a comment in my skin file at the place, where the MediaWiki devs changed the display of the search buttons, because I couldn't get it to work properly for me: The display of the buttons alwaysgot messed up, so I decided to leave them both for now. But does that (the presence of two instead of one button) also influence what happens when I hit enter (because that is where I see the problem and where it annoys me most)?

88.130.76.19813:04, 27 July 2014
 

I'm using Vector with no custom skinning, so I don't understand what's causing a search results page to appear.

Supāsaru14:57, 27 July 2014
 
 
 

Does anybody have any answers to this?

Supāsaru12:03, 3 August 2014

I have also the version 1.23.2 and when I type XYZ in research I have a list with the 2 possibilities if the page exists

first line : XYZ second line : "including XYZ" They apperas when I move the mousse

But don't clic on the glass

Chantoune (talk)18:00, 3 August 2014
 

→ Bump ←

I continue to experience this "bug." Does anybody know the cause?

Supāsaru12:31, 19 August 2014

Is your wiki publicly accessible so we can look what's doing?

Ciencia Al Poder (talk)16:47, 20 August 2014

Sorry - no, it isn't.

Is there anything you'd like me send show you? Screenshots? Excerpt from LocalSettings.php?

Supāsaru01:24, 22 August 2014

Describe how do you submit the search form:

  • Pressing the enter key when inside the search box
  • Click on the search button
  • Another option?

Post an example search results page URL.

Ciencia Al Poder (talk)09:10, 22 August 2014

¡Hola Ciencia al poder!

URL of the search page: http://localhost/index.php?title=Special%3ASearch&profile=all&search=Travel+checklist&fulltext=Search

I have typed the search query and hit Enter, and I've also clicked on the magnifying glass within the search box. I don't see another option to click / type.

Here is a screenshot of the search results page.

Troubleshoot SERP instead of page.tiff

Thanks in advance for your help.

(I apologize for taking this long to reply. My MySQL server went kaput, and it took me a while to get it back going.)

Supāsaru21:53, 27 August 2014
 
 
 
 

I noticed that in the URL I provided above, it's a little different from what I see on Wikipedia. (The search is very fast on Wikipedia, but if you're watching, you'll see that the URL has &go=Go appended to the end. ) Mine doesn't have that.

Is this what's making the difference? I tried adding this query string to the URL and hitting enter, and I still see only a search results page.

Does this offer a clue?

Supāsaru16:29, 1 September 2014

You have to replace "fulltext" with "go" ;) That is the reason for this behavior. Fulltext means "always to search result page", and Go means " go to page, if query matches title, or go to search result page".

Just an idea, have you set $wgVectorUseSimpleSearch to false in your LocalSettings.php?

Florianschmidtwelzow (talk)18:07, 1 September 2014

Hi Florianschmidtwelzow.

I think we're onto something. I don't have $wgVectorUseSimpleSearch in my LocalSettings.php file. (Just for fun, I added it and set it to true and that didn't work.)

I manually removed &fulltext=search with &go=Go in my browser's address bar, and that worked - I landed directly on the page.

Now, why did my wiki stop doing this on its own when I upgraded? What do I change to make it do that again?

Supāsaru00:28, 3 September 2014
 
 

→ Bump! ←

Does anybody think this has to do with the Vector skin?

I've just upgraded to 1.23.3, and I'm still having the same problem using Vector. Monobook brings me directly to the article page when I use the search.

Supāsaru22:40, 17 September 2014
 

Can`t edit preferences

To whom I may concern,

hakuson.de/index.php/

Software Version MediaWiki 1.23.3 PHP 5.5.16-nmm1 (apache2handler) MySQL 5.6.17-nmm1-log Lua 5.1.5

is my setting. The problem is that I cannot edit the preferences. I can see the specialpage, but i am not able to edit the content. (Can not change anything)

I searched in google and mediawiki documentation for two hours and found nothing, so i am asking for help.

Thank you very much. Greetings Christoph Endruschat

Answer to: cvcaq@gmx.de

93.214.198.12119:59, 17 September 2014

Hi Christoph,

what exactly do you mean with "I cannot edit"? Are you unable to actually change the values inide the different fields? Or can you not save them? Until hearing the contradictory I assume the later. In this case you obviously met some error condition. See How to debug, reproduce the error and then check the PHP error log for more information!

88.130.95.19621:54, 17 September 2014
 

Suppressing replacement of line breaks with spaces

When editing plain text in a text editor, then copying it and pasting it into the MediaWiki edit field, all line breaks are replaced with spaces (immediately upon pasting, not upon submitting the edit). How can this be prevented (i.e. so that it functions like the edit box for this wiki)? This behaviour does not depend on whether the text editor's word wrap setting is enabled or disabled.

MediaWiki 1.16.2/PHP 5.3.8 (apache2handler)/MySQL 5.0.77-log. Wiki is restricted; can't provide access.

See also [1].

Tristan Lall (talk)01:51, 27 February 2012

Probably something wrong with the program you're copying from, or your web browser.

Bawolff (talk)16:09, 28 February 2012

Browser is Chrome 17, Internet Explorer 9 and Firefox 10; program is Word 2010, Notepad (Windows 7) and Notepad++ 5.9.2. But copying and pasting from within the edit box doesn't replace line breaks. I'm guessing that the wiki is silently inserting a placeholder character at the end of each line in its own edit box; if that's not present (i.e. it came from a regular plain or rich text editor), it filters the break out.

I think it's a wiki configuration thing, since this behaviour isn't present on any of the WMF wikis (that I know of). What do I change in the configuration options to make it go away (either per-user or globally)?

Tristan Lall (talk)19:00, 28 February 2012

Also, when you paste text into the edit box, sometimes you the removal of line breaks is visible. (Slow script execution?) It goes in with the break, then a fraction of a second later, it removes the break.

Tristan Lall (talk)21:04, 28 February 2012

Umm, the main difference between this site's edit box and the normal (Default) edit box is Extension:WikiEditor. Maybe try using that extension.

Bawolff (talk)02:29, 29 February 2012

Already using WikiEditor (version 0.2.0). Also have UsabilityInitiative (Version 0.1.1) and Vector (Version 0.2.0), among others.

Tristan Lall (talk)17:45, 29 February 2012
 
 
 
 
 

Undo or delete everything since a certain date

Is there a maintenance script or extension to delete all changes to a wiki since a certain date?

I recently updated an neglected wiki from 1.16 to 1.23.3. It had been abandoned about four years. During this time, spammers had created thousands of user accounts, created pages and made edits. I currently have the wiki locked down, so no one can make edits. I would simply like to "undo" all of the changes since (for example) Jan. 1, 2010. Only spammers have made changes since that date. I do not care if these page and user deletions are recorded in recent changes or if revision histories are kept.

I have found extensions to block or ban users and IP addresses (but not to automatically delete these same users' page edits). I have found extensions to delete changes made by a particular user or IP address. But are all too time consuming and limited, given the amount of spamming. I would simply like to "revert" the wiki to its 2010 state.

Cmjohannes (talk)07:23, 17 September 2014

Hi!

such a script does not come with the MediaWiki core. There are maintenance scripts to really remove all deleted revisions and there is the UserMerge extension to remove a single user (by merging him with Anonymous), but this is a single action and I don't think you want to do that hundreds of times.

You can try with the extensions Extension:Nuke, Extension:DeletePagePermanently and Extension:BlockAndNuke or with a combination of those. Especially BlockAndNuke looks promising I think as it can batch delete a huge number of pages with just a few commands. Also does BlockAndNuke come with a maintenance script, which allows to delete all revisions, which were not made by users in a specified list. With a few MySQL commands you will be able to create a list of the first n users in your database (of which most or all are "ok") and then make the extension delete everything else. This should already bring you a huge step forward. And(!), if UserMerge is installed as well, it even does merge the users into one single account effectively deleting them as well. Note however that I have not tried the extension and I don't know, which strange behaviours it has. Remember to make a backup before you start!

88.130.95.19620:27, 17 September 2014
 

Hello, I am one of the administrators of this wiki (http://www.ichscotlandwiki.org/index.php?title=Intangible_Cultural_Heritage_in_Scotland) that I will use for my PhD research. It has been affecting by massive spam for several months. We upgraded the software, we installed both Nuke and Block and Nuke (by putting in the white lists only the administrators) extensions, we regularly change the question for the registration (using Google reCAPTCHA), which also requires the confirmation through email link, and added a black list provided by MediaWiki. However, this wasn't enough to either stop the spam or even slow it down. Can anyone suggest further actions to be undertaken? Any advice welcome.

2.122.80.22718:23, 15 September 2014

Hello!

It seems, that you haven't setup ConfirmEdit correctly. If i go (logged out) to Special:UserLogin&type=signup to create a new account i can do that without solving a captcha. Have you set up ConfirmEdit, especially the Triggers, correcly?

To use ConfirmEdit to protect for spam registrations, you should have this line in your LocalSettings.php:

$wgCaptchaTriggers['createaccount'] = true;
Florianschmidtwelzow (talk)18:47, 15 September 2014

Ah, and: Everyone can, without solving a Captcha, edit the contents of this wiki, that's the heavon for spam bots :D

Florianschmidtwelzow (talk)18:48, 15 September 2014

Thank you very much, I'll try this solution.

2.122.80.22711:01, 16 September 2014

Hello Florianschmidtwelzow, the command was already $wgCaptchaTriggers['createaccount'] = true; however, we realised that some people are asked for the CAPTCHA question when they are about to fill the form to create an account, others are not. How can this happen?

2.122.80.22714:57, 16 September 2014

Ok, now i have a captcha, that's much better :) I can't say, why some users get a captcha and some not. Can you post all ConfirmEdit related configuration settings in your LocalSettings.php (remove the client and secret id from reCaptcha ;))?

Florianschmidtwelzow (talk)16:04, 16 September 2014
 
 
 
 
 

Mobile linking

Mediawiki 1.22.0

Hello,

I have two wikis linked 'mainwiki.com' and 'de.mainwiki.com' now I have installed MobileFrontend, but I cant link the two wikis via $wgMobileUrlTemplate. How to link these sites together? Im using 'm.mainwiki.com' and 'de.m.mainwiki.com' for mobile.

The problem seems to be that the URL´s for the sites are not similar as of lenght. Is there anyway to link these sites without changing 'mainwiki.com' URL I.E. 'fr.mainwiki.com'?

Thanks.

Samuel Peter9 (talk)17:36, 17 September 2014

New links not acknowledging that page exists

When a user creates a new link (colored red), and then goes to the link to create a new page and save it, then comes back to the original page, the link will still be red. It will be the shade of red of a visited empty link, but it will still show that the page does not exist. This lasts until a new link/page is created, or I 'touch' the LocalSettings.php file on the command line, at which point I can't find anything on Google like this.

The version of mediawiki for that site is 1.23.0, but I have another test site on the same server that is at 1.23.3. php version is 5.3.3.

I've updated extensions, etc. and still no change. Has anyone seen anything like this? Is there a maintenance script that will help? Thanks

Cfschulte 314 (talk)14:58, 16 September 2014

Have you some kind of caching activated? If yes, how it's configured?

Florianschmidtwelzow (talk)15:52, 16 September 2014

The only things I have set for cache are

$wgMainCacheType    = CACHE_NONE;
$wgMemCachedServers = array();

Commenting them out does nothing. I was expecting it to be a cache issue because the ugly workaround is to reopen the edit page and hit 'save' a second time.

Cfschulte 314 (talk)16:11, 16 September 2014
 

The last user who asked about this on #mediawiki had forgotten to set up the job queue properly, i.e. run it with a crontab. I also suggest that you go through Manual:Performance tuning.

Nemo06:11, 17 September 2014

It took some playing around with this, but it seemed to work. Thanks!

Cfschulte 314 (talk)17:17, 17 September 2014
 
 

Problem moving images between wikis

Dears,

I have a private enterprise wiki ver 1.23 on CENTOS 7 with MariaDB Distrib 5.5.37 with PHP 5.4.16

This is a new installation.

I'm trying to import images from another wiki. I'm trying the following command.

[root@wikitemp maintenance]# php importImages.php ../images_to_import/

The result is:

Import images

Importing foto.jpg...Segmentation fault (core dumped)

I have also tried to put $wgMaxShellMemory = 10000000; $wgUseImageMagick = false; in LocalSettings.php

and put in php.ini

post_max_size=8000M upload_max_filesize=2000M


Do you have any idea? I have another way to import images?

Thanks a lot.

Ennio Balocchi

212.162.111.21015:24, 17 September 2014

Wikispecies help

For Wikispecies, under the Navigation section on the left, the Help section is pointed back to MediaWiki even though there is a local help page. How can I modify it so that it points back to the local page?

OhanaUnitedTalk page15:32, 16 September 2014

This can be changed on wiki with the Interface message helppage:

wikispecies:MediaWiki:Helppage Just edit this page and insert the new link (e.g. "Help:Contents" without ") :) Hint: You need the right to edit interface messages.

Florianschmidtwelzow (talk)15:45, 16 September 2014

Yes I have the rights. I just didn't know which MediaWiki page I needed to edit. Thanks.

I carried out the change and it was reflected in Monobook. However, it didn't change in Vector skin. Any reason why?

OhanaUnitedTalk page15:08, 17 September 2014
 
 

RandomInCategory

I used to use something like http://www.mediawiki.org/wiki/index.php?title=Special%3ARandomInCategory&category=Template_extensions - it worked in 1.24wmf14 but is gone in 1.24wmf21 (2691b4d) (same version as here on Meiawiki). On mediawiki.org it just redirect to a help page, on enwiki it redirect to Special:RandomInCategory.

Is it just gone, or is it a bug? Because it was really nice feature because you could add "&redirect=no"

Christian75 (talk)17:19, 16 September 2014

You have to request index.php from the Script path (mediawiki.org/w/), not from article path (mediawiki.org/wiki/). So the correct link should be:

https://www.mediawiki.org/w/index.php?title=Special:RandomInCategory&wpcategory=Template_extensions

And on enwiki i can't reproduce a redirect to the Special page (that would be false). Please notice, too, that Wikipedias running 1.24wmf20 atm, they will be upgraded tomorrow.

Florianschmidtwelzow (talk)11:38, 17 September 2014

ok, thanks. The w versus wiki confusion comes from my try to convert the syntax form my wiki to mediawiki.org. With version 1.24wmf14 it was possible to skip the special page and go directly to a random page with your example (and category instead of wgcategory), like Special:RandomInCategory/Template_extensions. The reason I want the ?title version is because I used it like shift-alt-x (random page) from a monobook.js script - shift-alt-x doesnt work here, but on enwiki it does).

Christian75 (talk)13:14, 17 September 2014
 
 

Updating without Updating *_from_namespace fields in links tables.

I just updated to 1.24wmf21 (2691b4d) (same version as here) from 1.24wmf14 and it started to "Updating *_from_namespace fields in links tables." which takes looong time. If a break it, and restart update.php it just restart the updating of the fields.

Is it possible to break the updating (and not get the updating of the fields again) and just get the new fields when the page is changed or hit the refreshlinks from the job queue?

Christian75 (talk)10:46, 16 September 2014

I just removed everything from the function doDBUpdates() but return true; in the file populateBacklinkNamespace.php in maintenance, which btw. states "* Optional upgrade script to populate *_from_namespace fields" - but it didnt look like it was optional.

Christian75 (talk)16:32, 16 September 2014

You shouldn't change any core files, if you don't know, what you do :) More information about that.

Depending on the size of your wiki, the update process can take a long time. For this, you can use the maintenance script, but, if you want, you can wait until the pages have self updated (on every edit), which will create the necessary values to the table. So the maintenance script is optionally, not a single function ;)

So your options:

-> use the maintenance script, to populate the fields
-> wait until the fields will create themself

Note: If you aren't very familar in running a wiki or won't have much of overhead (short update cycles, possible untested scenarios wih third party extensions and so on), you should use the official thid party releases of MediaWiki instead of he wmf-builds, which are used on wmf wikis :)

Florianschmidtwelzow (talk)11:53, 17 September 2014

thanks, but its not possible to " use the maintenance script, to populate the fields" [later] because the update.php will restart the population of the fiels if I just break the update.php and restart it again, and there is no option to skip the population. But populateBacklinkNamespace.php has an option to start indexing from a specific number which is nice. The private wiki had 600.000 pags so its a long process. It took really long time to add the extra fields...

Christian75 (talk)12:17, 17 September 2014

Oh, yeah, sorry, my fault. This maintenance script should run after the update.php script (so it will do automatically). Then you should take the time and let the script running, really ;)

Florianschmidtwelzow (talk)12:36, 17 September 2014
 
 
 
 

[RESOLVED] I got a syntax error while I trying to set up my wiki

Hello,

Recently I trying to build my Wiki site which is hosted in 2freehosting.com.

And there are some basic information for my site:

Website: http://dpwwiki.3eeweb.com/wiki/

MediaWiki Version: 1.23.3

Main reason while I use this version is MediaWiki version which provided from hosting site is too old for me (v1.18.1).


After I uploaded all files in archive when I downloaded from MediaWiki website, and I trying to set up my site, an error occurred:

Parse error: syntax error, unexpected 'level' (T_STRING) in /home/u732177279/public_html/wiki/includes/Title.php on line 2097

(URL: http://dpwwiki.3eeweb.com/wiki/mw-config/index.php)


I have no idea to deal with this error.

Is there any solution to deal with it?

120.105.3.10007:47, 17 September 2014

Hello!

That sounds scary. Can you post line 2097 from includes/Title.php please? Have you uploaded all files new, or overwritten some old?

Florianschmidtwelzow (talk)08:03, 17 September 2014

Hello, Florianschmidtwelzow,

Here's line 2097 from includes/Title.php:

[SOME OUTPUT CUT]


if ( preg_match( '/^' . preg_quote( $user->getNametion level on the source page, but it's


[SOME OUTPUT CUT]

and I'm sure I uploaded all files new.

Is there any errors on this line?

120.105.3.10010:09, 17 September 2014

Yes, this isn't correct. It seems, that the lines 2097 to 2164 was removed. Can you download your MediaWiki version again and upload all files after you delted the old ones?

Florianschmidtwelzow (talk)11:33, 17 September 2014

Thank you, Florianschmidtwelzow.

I'll re-download my MediaWiki version and upload all files again.

120.105.3.10012:09, 17 September 2014
 
 
 
 

Problem with getting skins work with most recent MediaWiki version

Edited by another user.
Last edit: 21:23, 16 September 2014

Hey guys, I Updated Media Wiki 1.23 to 1.24 due to the fact, that the new VisualEditor that supports IE does not seem to work with 1.23 Now i get an message telling me to download Skins because they are not available. But i have my skins in the "skins/" directory in my media wiki installation . I Have also set "require_once "$IP/skins/Vector.php";" and "$wgDefaultSkin = "vector";" but still it is not working so far. Any Ideas on how to fix this?

213.172.115.2114:15, 16 September 2014

MediaWiki 1.24alpha PHP 5.4.4-14+deb7u12 (apache2handler) MySQL 5.5.38-0+wheezy1

213.172.115.2114:20, 16 September 2014
Edited by another user.
Last edit: 09:40, 17 September 2014

You should really follow the migration guide :)

Or, in your case, don't just download the newest development version of MediaWiki (what is, btw, not the best practice for third-party wikis), download the newest version of the skin as well. So, remove the contents of your skin direcktory (if you don't need them anymore, but at least all PHP files in the root of skins/) and download the newest version of Vector (which isn't bundeled into MediaWiki core anymore, one more thing why a tarball installation is recommended, vector and monobook are still there) from git:

(github)https://github.com/wikimedia/mediawiki-skins-Vector

(wikimedia-git)git clone https://gerrit.wikimedia.org/r/mediawiki/skins/Vector

Now change the require_once line in your LocalSettings.php to match the new path (skins/Vector/Vector.php) and have fun with MW 1.24 :)

Florianschmidtwelzow (talk)15:58, 16 September 2014
 
 

[RESOLVED] How to integrate Bumpin.com tool bar?

Hello, can anyone tell me please if it is possible to integrate the Bumpin tool bar on my wiki website?

Website of the tool bar: Bumpin.com

All i need to do is to add this code but i'm not sure on wich file i need to add it. <script type="text/javascript" src="http://www.bumpin.com/bar"></script>

  1. MediaWiki 1.23.1
  2. PHP 5.4.31 (cgi-fcgi)
  3. MySQL 5.5.36-cll-lve

Thank you

Karldan (talk)04:57, 26 August 2014

Read Manual:Interface/JavaScript to see how include JavaScript code.

To include a script URL (for example, <script type="text/javascript" src="http://www.bumpin.com/bar"></script>

you should use instead: $.getScript('https://www.bumpin.com/bar');

Ciencia Al Poder (talk)09:32, 27 August 2014

Thank you for your answer,

I'm not a good coder, i inserted the code you show me in LocalSettings.php but no success. all i had is a white page. I'm not sure if this is the right file to insert this code.

I will try some other string you show me in Manual:Interface/JavaScript

Thank's again.

Karldan (talk)20:07, 29 August 2014

Seriously. Where on earth I pointed you to alter LocalSettings.php?

Ciencia Al Poder (talk)17:07, 31 August 2014

Sorry buddy, don't get mad, all i said is i tried this in my LocalSetting.php, i didn't said you pointed me there, if this is not the good file to put this code, just point me to the good file, that's all...As i said, i'm only asking for a little help because i'm NOT A CODER, i'm trying to get my way into all of this geez...

Karldan (talk)18:27, 31 August 2014

Usually you include JavaScript by adding it to one of the MediaWiki-pages of your wiki, e.g. to the page MediaWiki:Common.js in your wiki.

88.130.101.16821:57, 31 August 2014
 
 
 
 
 

[RESOLVED] PHP errors when trying to upgrade

I'm attempting to update our version of Mediawiki. I've been following the upgrade instructions and have uploaded all of the new files to the server. When I go to /mw-config/index.php, I see this error:

Fatal error: Access to undeclared static property: LanguageConverter::$languagesWithVariants in ..../public_html/help/includes/User.php on line 1369

I've searched all over and have not found any references to this error.

Any advice would be greatly appreciated.

198.84.227.12322:45, 14 September 2014

Mediawiki version: 1.23.3 PHP version: 5.4.30 MySQL version: 5.5.37-cll

198.84.227.12322:47, 14 September 2014

What version are you upgrading from?

Jackmcbarn (talk)00:57, 15 September 2014

1.17.0

209.167.40.1220:35, 15 September 2014

Did you extract/upload the new files to a new directory and then move over only a few files, or did you extract/upload the new files right on top of the old installation? You should do the former.

Jackmcbarn (talk)20:47, 15 September 2014

I backed up the images and extensions folders and the LocalSettings.php file then deleted the folder and installed fresh.

198.84.227.12322:31, 15 September 2014
 
 
 
 
 

installing pywikibot

Based on the instuctions in https://www.mediawiki.org/wiki/Manual:Pywikibot/Installation#Download_Pywikibot

The easiest way to download Pywikibot is to use the latest nightly release. Just download the pywikibot zip file to your computer and decompress the file – there is no further installation required.

So I downloaded the core.zip file. But where do I decompress it? I thought it should go into

Python27/Lib/

so I created a pywikibot directory there and put the decompressed file tree into that directory, but my attempts to run

python setup.py build python setup.py install

both produce the error message

error: package directory 'pywikibot' does not exist

I already tried asking on the IRC #pywikibot channel but received no response. Thanks Kerry Raymond (talk) 05:26, 17 September 2014 (UTC)

Kerry Raymond (talk)05:26, 17 September 2014

This sounds like a good question for the talk page of the link that you have provided (if the instructions on the corresponding wikipage are unclear). How long did you wait for an answer on #pywikibot? Normally they are pretty active if you are lucky with the timezones.

AKlapper (WMF) (talk)08:25, 17 September 2014
 

Upload file warning

I have been unable to avoid the following warning message every time I try to upload an image to my wiki. I have enabled file uploading in my php settings and .ini files and the issue persists. Any suggestions are much appreciated to allow me to upload images without getting errors like this. Thank you!

WARNING MESSAGE:

"Upload warning

Could not store file "C:\Windows\Temp\phpE3F6.tmp" at "mwstore://local-backend/local-public/1/11/Tags-01.jpg"."

Estate wiki (talk)19:05, 10 September 2014

Can you post the contents of your LocalSettings.php? Make sure that you redact passwords, etc. from it first.

Jackmcbarn (talk)22:24, 10 September 2014
Edited by another user.
Last edit: 21:14, 16 September 2014

See below. I've removed what I considered to be sensitive info and replaced it with "----". Please let me know if there is any other information you need. Thanks so much.

<?php
# This file was automatically generated by the MediaWiki 1.23.0
# installer. If you make manual changes, please keep track in case you
# need to recreate them later.
#
# See includes/DefaultSettings.php for all configurable settings
# and their default values, but don't forget to make changes in _this_
# file, not there.
#
# Further documentation for configuration settings may be found at:
# https://www.mediawiki.org/wiki/Manual:Configuration_settings

# Protect against web entry
if ( !defined( 'MEDIAWIKI' ) ) {
 exit;
}

## Uncomment this to disable output compression
# $wgDisableOutputCompression = true;

$wgSitename = "----";

## The URL base path to the directory containing the wiki;
## defaults for all runtime URL paths are based off of this.
## For more information on customizing the URLs
## (like /w/index.php/Page_title to /wiki/Page_title) please see:
## https://www.mediawiki.org/wiki/Manual:Short_URL
$wgScriptPath = "/mediawiki";
$wgScriptExtension = ".php";

## The protocol and server name to use in fully-qualified URLs
$wgServer = "----";

## The relative URL path to the skins directory
$wgStylePath = "$wgScriptPath/skins";

## The relative URL path to the logo.  Make sure you change this from the default,
## or else you'll overwrite your logo when you upgrade!
$wgLogo = "$wgStylePath/common/images/wiki.png";

## UPO means: this is also a user preference option

$wgEnableEmail = true;
$wgEnableUserEmail = true; # UPO

$wgEmergencyContact = "----";
$wgPasswordSender = "----";

$wgEnotifUserTalk = false; # UPO
$wgEnotifWatchlist = true; # UPO
$wgEmailAuthentication = true;

## Database settings
$wgDBtype = "mysql";
$wgDBserver = "localhost";
$wgDBname = "----";
$wgDBuser = "----";
$wgDBpassword = "----";

# MySQL specific settings
$wgDBprefix = "";

# MySQL table options to use during installation or update
$wgDBTableOptions = "ENGINE=InnoDB, DEFAULT CHARSET=utf8";

# Experimental charset support for MySQL 5.0.
$wgDBmysql5 = false;

## Shared memory settings
$wgMainCacheType = CACHE_NONE;
$wgMemCachedServers = array();

## To enable image uploads, make sure the 'images' directory
## is writable, then set this to true:
$wgEnableUploads = true;
#$wgUseImageMagick = true;
#$wgImageMagickConvertCommand = "/usr/bin/convert";

# InstantCommons allows wiki to use images from http://commons.wikimedia.org
$wgUseInstantCommons = false;

## If you use ImageMagick (or any other shell command) on a
## Linux server, this will need to be set to the name of an
## available UTF-8 locale
$wgShellLocale = "en_US.utf8";

## If you want to use image uploads under safe mode,
## create the directories images/archive, images/thumb and
## images/temp, and make them all writable. Then uncomment
## this, if it's not already uncommented:
#$wgHashedUploadDirectory = true;
## Set $wgCacheDirectory to a writable directory on the web server
## to make your wiki go slightly faster. The directory should not
## be publically accessible from the web.
#$wgCacheDirectory = "$IP/cache";

# Site language code, should be one of the list in ./languages/Names.php
$wgLanguageCode = "en";

$wgSecretKey = "----";

# Site upgrade key. Must be set to a string (default provided) to turn on the
# web installer while LocalSettings.php is in place
$wgUpgradeKey = "----";

## Default skin: you can change the default skin. Use the internal symbolic
## names, ie 'cologneblue', 'monobook', 'vector':
$wgDefaultSkin = "vector";

## For attaching licensing metadata to pages, and displaying an
## appropriate copyright notice / icon. GNU Free Documentation
## License and Creative Commons licenses are supported so far.
$wgRightsPage = ""; # Set to the title of a wiki page that describes your license/copyright
$wgRightsUrl = "";
$wgRightsText = "";
$wgRightsIcon = "";

# Path to the GNU diff3 utility. Used for conflict resolution.
$wgDiff3 = "";

# The following permissions were set based on your choice in the installer
$wgGroupPermissions['*']['createaccount'] = false;
$wgGroupPermissions['*']['edit'] = false;

# Set $wgNoFollowLinks to true if you open up your wiki to editing by
# the general public and wish to apply nofollow to external links as a
# deterrent to spammers. Nofollow is not a comprehensive anti-spam solution
# and open wikis will generally require other anti-spam measures; for more
# information, see https://www.mediawiki.org/wiki/Manual:Combating_spam
$wgNoFollowLinks = false;

# End of automatically generated settings.
# Add more configuration options below.
Estate wiki (talk)20:42, 16 September 2014

Are you using Apache, IIS, or something different? Make sure that the user you're running as has permission to write to the images directory.

Jackmcbarn (talk)21:16, 16 September 2014

This is running on IIS. How can I verify that the user has permission to write to the images directory?

Estate wiki (talk)21:29, 16 September 2014

Make sure the IUSR_whatever account can write to it. Check/fix this in the Security tab of the directory's Properties window.

Jackmcbarn (talk)22:27, 16 September 2014
 
 
 
 
 

[RESOLVED] Trouble uploading after installation

After installing to the latest version of mediawiki, I am unable to upload text files, and get the following messege: Could not open lock file for "mwstore://local-backend/local-public/d/dc"

How can I fix this?

173.85.173.4201:20, 14 May 2012

I fixed it. chmod 777 images directory.

173.85.173.4202:23, 14 May 2012
Edited by another user.
Last edit: 15:40, 21 July 2012

Hi,

I've got the same problem but it is not fixed by chmod 777 images.

Ive just upgraded to 1.19 and

  1. I cannot upload image files - getting the message Could not create directory "mwstore://local-backend/local-public/archive/d/d8".
    • I have made the mediawiki/images directory and all sub-directories writeable
    • I had added $wgFileExtensions = {'gif', 'png'); to LocalSettings.php
    • I have tried incuding $wgUploadPath = '/mediawiki/images'; to LocalSetting.php
  2. Current images files stored in the wiki
    1. are displayed correctly using [[Image:pic.gif]],
    2. but not if resized e.g. [[Image:pic.gif|640px]]

Amy suggestions appreciated

Kirby

86.184.214.10120:22, 26 May 2012

le dossier mediawiki et tout son contenu devrait apartenir au même usager que celui utilisé par le service Apache... Dans mon cas, www-data... Alors j'ai fait "chown -R www-data: mediawiki" pour régler mon problème.

70.81.74.13215:02, 8 July 2012

... En passant, je ne pense pas que ce soit une bonne idée de tout le mettre en 777, ça peut causer une brèche de sécurité.

70.81.74.13215:03, 8 July 2012

My french is rusty, but I think that I agree with you.

Setting 777 permissions is really a bad idea.

On my system, I had this problem too. I got here by googling the error message.

I fixed the problem by setting the image directory's owner to apache. And since nothing but a readme was in that directory, I didn't even need a recursive chown.

 chown apache. /var/www/mediawiki119/images

That was the path on my CentOS 6.3 system.

I wonder if there is an even less crude solution.

There is. Read Manual:Configuring file uploads

DHR (talk)07:31, 4 November 2012
 
 

check your "$wgFileExtensions = {'gif', 'png');" entry

you need to create an array, something like this:

$wgFileExtensions = array('gif','png');

2001:480:10:160:0:0:0:312121:47, 7 August 2012
 

For me chmoding uploads, uploads/*, uploads/*/* uploads/*/*/* to 777 helped (but please check with someone mor wiki-security aware that this doesn't imply any threats). For you it may be images, images/*, ... as it seems our wiki has some special settings.

89.103.184.11217:20, 21 June 2012

Making things 777 means any user can write to the directory, which means if anyone somehow gets access to your server (aka security vulnrability in something else), or if there are other users of your server, they can write stuff to the images directory. A better approach is to make the images folder either owned by the apache user, or in the apache's user's group, and only let the apache user have said permissions.

Bawolff (talk)12:15, 9 July 2012
 
 

Mi sukcesis per

# chown apache -R /path/to/your/wiki/
# chgrp apache -R /path/to/your/wiki/
AceroChevalosta (talk)06:05, 14 November 2012

I just solved this issue on Fedora by installing mod_fcgid.

I hope this helps someone. :-)

Ogredeschnique (talk)23:51, 7 April 2013

c'est dans quels dossier merci !

109.190.75.20814:50, 29 September 2013
 
 

made the change [$sudo chmod 777 /etc/mediawiki/images] on Ubuntu 12.04, Mediawiki version 1.22.1

Boom problem gone

Carlc888 (talk)23:01, 10 February 2014

Just an update after a few minutes trying to fix that problem on my Mac : I would had this step to solve the access problem :

- add a $wgTmpDirectory = "/Applications/XAMPP/xamppfiles/htdocs/your_wiki/images/temp"; OR whatever path you want... and do the chmod on this specific folder

[$sudo chmod 777 /Applications/XAMPP/xamppfiles/htdocs/your_wiki/images/temp]

Only then you know what the fu** the wiki is doing! ;)

Have fun.

80.119.70.6020:27, 16 September 2014
 
 
First page
First page
Previous page
Previous page
Last page
Last page