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

Warning: imagepng() [function.imagepng]: open_basedir restriction in effect.

This is my features:

  • Mediawiki: Version 1.23.5
  • PHP: Version 5.3.5 (cgi-fcgi)
  • MySQL: Version 5.1.73-log
  • OS Hosting: Windows
  • My wiki:www.itadmowiki.it

Hello, I recently moved my site to another host and so far so good . Finished to send files via FTP I opened the MainPage and I found these errors:


Warning: imagepng() [function.imagepng]:open_basedir restriction in effect. File (D:\Temp\/transform_90a34c7283bc-1.png) is not within the allowed path(s): (e:\d:\) in E:\kunden\homepages\33\d549879353\www\wiki\includes\media\Bitmap.php on line 600


Warning: imagepng() [function.imagepng]:Invalid filename in E:\kunden\homepages\33\d549879353\www\wiki\includes\media\Bitmap.php on line 600


Warning: file_exists() [function.file-exists]:open_basedir restriction in effect. File (D:\Temp\/transform_90a34c7283bc-1.png ) is not within the allowed path(s): (e:\d:\) in E:\kunden\homepages\33\d549879353\www\wiki\includes\media\MediaHandler.php on line 689


Warning: filesize() [function.filesize]:open_basedir restriction in effect. File (D:\Temp\/transform_90a34c7283bc-1.png) is not within the allowed path(s): (e:\d:\) in E:\kunden\homepages\33\d549879353\www\wiki\includes\filebackend\FileBackendStore.php on line 163

I could not find a solution , I hope you can help me sincerely . Thank you for the help you give me .

Hobur (talk)18:10, 30 October 2014

Apparently, your host has set up a temp directory for PHP on D:\Temp\, but they have set up open_basedir restriction in php.ini to e:\d:\, which looks odd, because it should be e:\;d:\ (note the separator between both paths), so it seems to not allow accessing any other path outside of the wiki installation directory.

You can contact your host about that, or manually set $wgTmpDirectory to a path within your MediaWiki installation (E:\kunden\homepages\33\d549879353\www\wiki\tmp for example)

Ciencia Al Poder (talk)10:51, 31 October 2014
 

What did you try already? The first result that I found by using an internet search engine is http://stackoverflow.com/questions/1846882/open-basedir-restriction-in-effect-file-is-not-within-the-allowed-paths

AKlapper (WMF) (talk)10:52, 31 October 2014

Thanks for the replies, I had already tried everything, using the internet search. I contacted my host and I'm still waiting for their response. I try now to set $wgTmpDirectory manually. Thank you very much for your help .

Hobur (talk)19:39, 31 October 2014
 
 

PdfHandler Extension doesn't work on MW1.23

Hey everybody,

i have a apache server system on windows 2003 server running. There i have two mediawiki installations one version is 1.23.2 and the other 1.21. Both have the same configuration in localsettings.php for pdfhandler extension:

require_once ("$IP/extensions/PdfHandler/PdfHandler.php"); $wgPdfProcessor = 'C:\Programme\gs\gs9.10\bin\gswin32.exe'; $wgPdfPostProcessor = 'C:\Programme\ImageMagick-6.8.7-Q16\convert.exe'; $wgPdfInfo = 'C:\Programme\xpdfbin-win-3.03\bin32\pdfinfo.exe'; $wgPdftoText = 'C:\Programme\xpdfbin-win-3.03\bin32\pdftotext.exe';

On my mediawiki 1.21 that works fine, but on my mediawiki 1.23.2 i am not able to get a preview of an uploaded pdf, it doesn't do anything (no error message at all). Funny thing, if I choose older uploaded pdfs on my mediawiki 1.23.2 (which had already a preview image) it works fine. It looks like mediawiki or PdfHandler Extension is not longer able to generate pictures in image folder. Folder rights are fine. How am I able to check whether PdfHandler Extension is really called or not?

Any idea would be welcome.

Regards, Max

212.185.112.25118:42, 31 October 2014

MyWiki: Database Error & Unknown bug

Hi guys, :-D

today I installed some extensions for MyWiki and after that I got a database error and an unknown bug :-\ (link: http://suriyaakudo.bplaced.net/wiki/index.php?title=Main_Page). Special pages like Stats or Version (http://suriyaakudo.bplaced.net/wiki/index.php?title=Special:Version) are operating well. :-)


Yours,

Suriyaa Kudo (iSC Inc.) (talk)13:12, 31 October 2014

Hello,

maybe you can say, which extension(s) you have installed? Does they need a database update (it seems so)? Have you run update.php (or the webinstaller) to adjust the database schema to fit the new extensions?

Florianschmidtwelzow (talk)14:10, 31 October 2014

And you want to add $wgGitBin = false; to LocalSettings.php to eliminate that error you currently get in top of Special:Version.

88.130.114.16714:56, 31 October 2014

I see no php error/warning on the Special:Version page? :o

Florianschmidtwelzow (talk)15:22, 31 October 2014

Right, he obviously fixed it. :-)

88.130.77.1118:10, 31 October 2014
 
 
 
 

MediaWiki 1.23.5 can't find diff3 unless open_basedir = none

Is it smart/necessary to set "open_basedir = none"? I am upgrading my MediaWiki to v1.23.5.

With open_basedir = default, I get:

  • PHP 5.4.25 is installed.
  • GNU diff3 not found.
  • Found GD graphics library built-in.

With open_basedir = none, I get:

  • PHP 5.4.25 is installed.
  • Found ImageMagick: /usr/bin/convert.

Setting $wgDiff3 = "/usr/bin/diff3"; in LocalSettings.php makes no difference. By default, open_basedir is set to webroot/:/tmp

Iantresman (talk)17:34, 31 October 2014

blank white wiki home page

Edited by 2 users.
Last edit: 12:18, 27 October 2014

Hi All,

I moved my wikis location and created a new subdomain for my wiki. lets call it wiki.blahblah.co.uk

I edited the localsettings.php to reflect the new location ($wgScriptPath and $wgServer) the wiki has remained on the same server just in a new folder location. The SQL details have not changed.

I found this;-

http://www.mediawiki.org/wiki/Manual:Errors_and_symptoms#You_see_a_Blank_Page

I have followed the instructions but still a blank page. is there another place I need to check.

It is located on server 2008r2 with IIS 7.5

09:38, 27 October 2014

What does the error logs say?

Ciencia Al Poder (talk)10:57, 27 October 2014

which error logs? PHP Server IIS?

91.244.229.3309:55, 29 October 2014

That would be a start. But also, as explained on that link:

You can also set a value for error_log in PHP.ini and read the PHP error log to find out what's going on. In some cases, PHP errors might also be recorded in the web server error log.

Ciencia Al Poder (talk)10:29, 29 October 2014

This is the error in the PHP log

[31-Oct-2014 09:01:56 Europe/Dublin] PHP Parse error: syntax error, unexpected 'to' (T_STRING) in G:\site\Wiki\LocalSettings.php on line 130

91.244.229.3309:02, 31 October 2014

I'm looking at the localsettings.php inside the wiki folder. this is line 130

$wgCacheDirectory to a writable directory on the web server

this bit above should have had a # before it to be

    1. set $wgCacheDirectory to a writable directory on the web server

it still fails to function so I checked php error log again. and got [31-Oct-2014 09:14:04 Europe/Dublin] PHP Fatal error: Function name must be a string in G:\site\Wiki\LocalSettings.php on line 20

91.244.229.3309:19, 31 October 2014
 
 
 
 
 

Frames like on mediawiki frontpage

Hello I am new to this and wondering how mediawiki has done the frames like on the front page I have linked a image for reference

http://imgur.com/kkf8tBl

Thank you.

86.128.197.9322:33, 27 January 2013

They're just using CSS. Granted, finding out how the front page is formatted isn't simple, but if you edit this template, you'll see that they html ids like "mainpage_topbox" are used so that CSS from MediaWiki:Common.css (since moved to MediaWiki:Gadget-site.css) can create a box using:

#mainpage_topbox {
        background: #f9f9f9;
        padding: 0px;
        border: 1px solid #aaaaaa;
        margin: 0.2em 10px 10px;
}
MarkAHershberger(talk)00:51, 28 January 2013
 

I have got the same question. Could anybody explain step by step how to crate main page like on MediaWiki?

84.204.22.13009:16, 24 June 2013

Quick and dirty way:

  1. Type {{:MediaWiki}} in the "Input text" box on Special:ExpandTemplates.
  2. Copy the result to your own main page
  3. Copy everything from MediaWiki:Gadget-site.css on mediawiki.org to MediaWiki:Common.css on your own Mediawiki installation
  4. The page will now be filled with tons of broken links, redlinks and broken file links; it will look like crap, but it will be easy to replace the content with your own
  5. Cleanup

A few things you should know:

  • Special:ExpandTemplates will substitute ALL templates, parser functions and variables, destroying the original code. The code of the main page and all used templates can be kept intact if exported using Special:Export, but a lot cleanup will be needed (e.g. cleaning up tons of templates and even installing extensions).
  • Much of the css from MediaWiki:Gadget-site.css can be removed. The rest may either be kept in your MediaWiki:Common.css or moved to your new main page (use inline css for this).
jonkerz ♠talk22:37, 24 June 2013

Thanks! I have created beautiful main page)))

84.204.22.13009:32, 25 June 2013

Hi, trying to do the same thing. When trying to do the:

Type {{:MediaWiki}} in the "Input text" box on Special:ExpandTemplates.

I get no result at all. What am I doing wring?

Jonas08:56, 9 December 2013

Go to Special:ExpandTemplates (on mediawiki.org, not your local installation), enter "{{:MediaWiki}}" in the large text box labelled "Input text:" (not the small one labelled "Context title..."). Press OK. Did that work for you?

jonkerz ♠talk14:57, 26 May 2014
 
 

Where to move the Gadget-site.css? I've just put it in my mediawiki main folder but my main page still looks ugly.

80.149.194.7011:05, 31 October 2014
 
 
 

How to localize things like "Contents" and menu labels?

Hi, guys! I was wondering how I can localize all of the Mediawiki-generated content on local language wikis. This is the url to the wiki: http://translations.ted.org/wiki/Main_Page

As you can see, there are multiple language versions, with English being the main one. There is content in other languages, but for example, in this Spanish article, the heading of the auto-generated contents list is "Contents" rather than "Índice." Also, the interface is not localized (so things like "Edit," "Discussion" etc. are all in English). How to fully localize the local language sections?

I've read the wiki family guide, but I am not sure I understand the process completely. If I install the separate wikis for each language, do the users have to translate things like the word "Contents" and the menu labels on their own, or are there already localized versions that I could use? Also, if I were to do this with the existing wiki (the one linked to), how do I preserve the existing content? So that if I end up installing separate wikis for each language, I will still have the same content in the Spanish wiki. Since it seems that this would create new domain names for each language, is there a way to globally rewrite URLs to point to the right articles in the language? I am a beginner at Mediawiki, so I may be missing something obvious.

Symbolt (talk)10:56, 31 October 2014

image will not show in special-side: newest files

hi !

I had a little problem with upload file (-> https://www.mediawiki.org/wiki/Project:Support_desk#IIS7.2FWin7_-_Problem_by_open_basedir__49974) - now fixed. but in the following the problem is that the image will not show on specialside "newest files".

not a blocker but like to fix too.

did someone had a idea ?

regards Jan :-)

JanTappenbeck (talk)07:12, 31 October 2014

Could you give us a link to your wiki (if it's publicly readable)?

Look at the HTML code of the generated pages an see where the image URL is pointing at. Maybe you need to adjust $wgUploadBaseUrl if you changed the upload directory.

Ciencia Al Poder (talk)10:55, 31 October 2014
 

[RESOLVED] IIS7/Win7 - Problem by open_basedir

Hi !

when I upload a image I get following message (independent of the upload-extension):

Warning: is_file(): open_basedir restriction in effect. File(C:\Windows\Temp\phpDF6C.tmp) is not within the allowed path(s): (C:\Windows\Temp;C:\Windows\TEMP;C:\inetpub\wwwroo t;C:\mediawiki;C:\mysqldumper) in C:\mediawiki\includes\filebackend\FSFile.php on line 60

Notice: Undefined index: file-mime in C:\mediawiki\includes\upload\UploadBase.php on line 463

Warning: fopen(): open_basedir restriction in effect. File(C:\Windows\Temp\phpDF6C.tmp) is not within the allowed path(s): (C:\Windows\Temp;C:\Windows\TEMP;C:\inetpub\wwwroo t;C:\mediawiki;C:\mysqldumper) in C:\mediawiki\includes\upload\UploadBase.php on line 379

Warning: fopen(C:\Windows\Temp\phpDF6C.tmp): failed to open stream: Operation not permitted in C:\mediawiki\includes\upload\UploadBase.php on line 379

Warning: fread() expects parameter 1 to be resource, boolean given in C:\mediawiki\includes\upload\UploadBase.php on line 380

Warning: fclose() expects parameter 1 to be resource, boolean given in C:\mediawiki\includes\upload\UploadBase.php on line 381

Warning: fopen(): open_basedir restriction in effect. File(C:\Windows\Temp\phpDF6C.tmp) is not within the allowed path(s): (C:\Windows\Temp;C:\Windows\TEMP;C:\inetpub\wwwroo t;C:\mediawiki;C:\mysqldumper) in C:\mediawiki\includes\upload\UploadBase.php on line 997

Warning: fopen(C:\Windows\Temp\phpDF6C.tmp): failed to open stream: Operation not permitted in C:\mediawiki\includes\upload\UploadBase.php on line 997

Warning: fread() expects parameter 1 to be resource, boolean given in C:\mediawiki\includes\upload\UploadBase.php on line 998

Warning: fclose() expects parameter 1 to be resource, boolean given in C:\mediawiki\includes\upload\UploadBase.php on line 999

Warning: fopen(): open_basedir restriction in effect. File(C:\Windows\Temp\phpDF6C.tmp) is not within the allowed path(s): (C:\Windows\Temp;C:\Windows\TEMP;C:\inetpub\wwwroo t;C:\mediawiki;C:\mysqldumper) in C:\mediawiki\includes\utils\ZipDirectoryReader.php on line 148

Warning: fopen(C:\Windows\Temp\phpDF6C.tmp): failed to open stream: Operation not permitted in C:\mediawiki\includes\utils\ZipDirectoryReader.php on line 148

could someone have an idea?

reagards Jan :-)

85.233.12.11414:05, 30 October 2014

This in fact is an open_basedir problem. Anyway, the path to the temp/ folder and what you have in open_basedir seems to be the same. Paths also are separated correctly by ";" as they should be...should work...

People sometimes use the forward slash also when defining the open_basedir path on Windows. Does it work, when you define the paths e.g. like C:/Windows/Temp?

88.130.93.8315:42, 30 October 2014

hi !

I fix the upload-problem by the side https://www.drupal.org/node/1580216

I set following parameter in php.ini and reset II7:

upload_tmp_dir =c:\temp

and add this path to open_basedir.

now the upload runs without mistake.

reagards Jan :-)

JanTappenbeck (talk)07:09, 31 October 2014
 
 

[RESOLVED] CSS is not loading properly

I've been up and down Google for the last few hours and I'm completely stumped for this problem. I've been using PHP for years but I have no idea of MediaWiki's inner workings and this completely escapes me.

I have a Wiki running on MediaWiki 1.18 (just upgraded today to see if it would fix the problem; it did not). For a long time everything has been completely find (a glitch here, one there, nothing serious). Two days ago, a user came to me and told me that the website looked "odd". When I asked to see what he meant, he showed me a site with no formatting (except inline styles)--that is, Times New Roman, white background, etc. I thought it might be his computer only, but then a second user came forward, and I checked it on another computer of mine, and it had the same issue. Mystified as to why I did not have this error on my main computer, I cleared my cache. Lo and behold, the CSS became blank.

Using Chrome's inspect element, I found the URLs of all the loaded stylesheets (3, to be exact, all loaded from load.php), and opened them in a new tab. Everything worked--that is to say, all of the CSS printed out properly. However, when I view the same resource in Chrome's resources tab, it is blank.

Oddly, even though the JS is loaded from load.php, it is working fine.

When reloading the page with "Inspect Element" open, I get this warning: Resource interpreted as Other but transferred with MIME type undefined. However I'm not sure if this is related. (My guess is that it is not.)

  • MediaWiki: 1.18.0
  • PHP: 5.2.14 (cgi-fcgi)
  • MySQL: 5.0.91-log

Attached are links to a few images. This issue happens in both Chrome and Firefox (other browsers untested) and on multiple computers as aforementioned.

Again, I must emphasize that this problem just started a few days ago. (The Wiki has been up since September 8th.) Except for a few additions to Vector.css, nothing has been changed. Any help or advice is appreciated. Been banging my head on my desk for hours now!

Eric01:01, 3 December 2011

I discovered that, indeed, MIME type is related here. When I opened the site in IE and checked the dev tools, I get these errors:

SEC7113: CSS was ignored due to mime type mismatch 
load.php?debug=false&lang=en&modules=mediawiki.legacy.commonPrint%2Cshared%7Cskins.vector&only=styles&skin=vector&*
SEC7113: CSS was ignored due to mime type mismatch 
load.php?debug=false&lang=en&modules=site&only=styles&skin=vector&*
SEC7112: Script from http://********/load.php?debug=false&lang=en&modules=startup&only=scripts&skin=vector&* was blocked due to mime type mismatch 
Special:Version
SEC7112: Script from http://********/load.php?debug=false&lang=en&modules=skins.vector&only=scripts&skin=vector&* was blocked due to mime type mismatch 
Special:Version
SEC7112: Script from http://********/load.php?debug=false&lang=en&modules=site&only=scripts&skin=vector&* was blocked due to mime type mismatch 
Special:Version

How can I ensure that load.php is serving the CSS MIME type properly? In mime.types, it lists "text/css css", so I'm not sure what else I can do.

Eric01:53, 3 December 2011

Resolved.

Appended the following to .htaccess, and the problem is resolved.

RewriteCond %{QUERY_STRING} only=styles
RewriteRule ^load.php - [QSA,E=content_type:text/css]

RewriteCond %{QUERY_STRING} only=scripts
RewriteRule ^load.php - [QSA,E=content_type:text/javascript]

<FilesMatch "load\.php">
        Header set Content-type %{content_type}e
</FilesMatch>
Eric19:18, 3 December 2011

This does not fix the problem. Is this bug ever going to be fixed?

67.182.161.11118:28, 5 April 2012
 

I have this extact same issue on an IIS install, every other page refresh results in no CSS. Can you translate this into an IIS URL Rewrite rule. I tried to save the above example in an htaccess file and import it but it doesn't like part of the E--- portion of the rule.

IIS7 on windows Server 2008 R2 and 2012 R2 results in same behavior. Been working on this for days trying to figure it out.....

Shane

206.54.145.25416:19, 2 October 2014
 
 

Not resolved. Such work-around should not and is not required by MediaWiki.

Something else is causing this to go wrong, this may fix it for you, but I'd like for this to be further investigated.

Krinkle00:02, 6 December 2011

I belive i'm getting same issue, after some clicks load.php just stops sending css and images. If i delete browser history and access the wiki if loads fine, if i reload the problems begin. I am using 1.18.1 version.

NunoSeita03:39, 20 March 2012

Did you try alternate browsers?

Jasper Deng (talk)04:28, 22 March 2012
 

I am having the same problem after upgrading from 1.17 to 1.18.2. Everything else seems to be working fine. I don't see any errors.

97.75.74.10 S37H19:03, 28 March 2012

I have this on my .htaccess and fix the problem: RewriteCond %{REQUEST_URI} !^/(redirect|load|texvc|index).php

186.214.51.7502:48, 13 April 2012
 

I hit this problem too (1.20.3, Firefox).

Cause: conflicting document root settings seems to make load.php choke on finding its stylesheets.

  1. in apache configuration file DocumentRoot "/path/to/mediawiki"
  2. in LocalSettings.php wgScriptPath ="/mediawiki";

Solution: wgScriptPath = "";

Hat-Tip to someone at StackOverflow

Richardbourke (talk)12:11, 29 April 2013
 

I had this problem too. I am using Apache rewrite rules to make very short URLs.

RewriteEngine On
RewriteRule ^(images/|skins/|(api|img_auth|index|redirect)\.php) - [L]
RewriteRule ^/*$ /index.php?title=Main_Page [L,QSA]
RewriteRule ^(.+)$ /index.php?title=$1 [L,QSA]

After upgrading, there are more top-level PHP scripts that are part of MediaWiki, including load.php, which is a new script used to obtain skin CSS and images.

I added all the new top-level PHP scripts to my rewrite rule and restarted Apache.

RewriteEngine On
RewriteRule ^(images/|skins/|(api|img_auth|index|load|opensearch_desc|redirect|thumb|trackback)\.php) - [L]
RewriteRule ^/*$ /index.php?title=Main_Page [L,QSA]
RewriteRule ^(.+)$ /index.php?title=$1 [L,QSA]

This fixed my problem.

193.9.13.13814:16, 25 April 2012

193.9.13.138's comment saved my day! I encountered the same thing: after upgrading to short URL (using a sandbox installation worked fine), the css is not loading but I can still see the page content. However, I had to add a "/" in the beginning for it to work, like this:

RewriteRule ^/(images/|skins/|(api|img_auth|index|load|opensearch_desc|redirect|thumb|trackback)\.php) - [L]

Hopefully it will help some one. BTW, 193.9.13.138's last rule

RewriteRule ^(.+)$ /index.php?title=$1 [L,QSA]

is not recommended by Mediawiki and something like the following line should be used.

RewriteRule ^/?wiki(/.*)?$ %{DOCUMENT_ROOT}/index.php [L]
Wikihy com (talk)01:26, 18 November 2013

Where do you add the mentioned statements?

196.214.37.2612:19, 4 December 2013

Your webserver config file. In my case, httpd.conf

Wikihy com (talk)12:28, 4 December 2013
 
 

-

Wikihy com (talk)01:26, 18 November 2013
 

There is also bug in PHP: https://bugs.php.net/bug.php?id=64836 that may cause this problem.

Gnomeby (talk)21:43, 8 February 2014

And here the Gentoo bug: https://bugs.gentoo.org/show_bug.cgi?id=467756

Ciencia Al Poder (talk)11:18, 9 February 2014

If your variables.less is missing some variables, the less compiler will not compile the CSS output properly, and you'll get an error like this:

/*

exception 'Exception' with message 'variable @collapsible-nav-heading-color is undefined:
failed at `ight.woff") format("woff"),` /var/lib/mediawiki/skins/vectorcatalyst/catalyst.less
on line 17' in /var/lib/mediawik/includes /libs/lessc.inc.php:3581
Stack trace:
#0 /var/lib/mediawiki/includes/libs/lessc.inc.php(2125): lessc_parser->throwError('variable @colla...', 351)
#1 /var/lib/mediawiki/includes/libs/lessc.inc.php(1880): lessc->throwError('variable @colla...')
#2 /var/lib/mediawiki/includes/libs/lessc.inc.php(1503): lessc->get('@collapsible-na...')
#3 /var/lib/mediawiki/includes/libs/lessc.inc.php(714): lessc->reduce(Array)
#4 /var/lib/mediawiki/includes/libs/lessc.inc.php(311): lessc->compileProp(Array, Object(stdClass), Object(stdClass))
#5 /var/lib/mediawiki/includes/libs/lessc.inc.php(249): lessc->compileProps(Object(stdClass), Object(stdClass))
#6 /var/lib/mediawiki/includes/libs/lessc.inc.php(223): lessc->compileCSSBlock(Object(stdClass))
#7 /var/lib/mediawiki/includes/libs/lessc.inc.php(719): lessc->compileBlock(Object(stdClass))
#8 /var/lib/mediawiki/includes/libs/lessc.inc.php(311): lessc->compileProp(Array, Object(stdClass), Object(stdClass))
#9 /var/lib/mediawiki/includes/libs/lessc.inc.php(249): lessc->compileProps(Object(stdClass), Object(stdClass))
#10 /var/lib/mediawiki/includes/libs/lessc.inc.php(223): lessc->compileCSSBlock(Object(stdClass))
#11 /var/lib/mediawiki/includes/libs/lessc.inc.php(719): lessc->compileBlock(Object(stdClass))
#12 /var/lib/mediawiki/includes/libs/lessc.inc.php(311): lessc->compileProp(Array, Object(stdClass), Object(stdClass))
#13 /var/lib/mediawiki/includes/libs/lessc.inc.php(249): lessc->compileProps(Object(stdClass), Object(stdClass))
#14 /var/lib/mediawiki/includes/libs/lessc.inc.php(223): lessc->compileCSSBlock(Object(stdClass))
#15 /var/lib/mediawiki/includes/libs/lessc.inc.php(719): lessc->compileBlock(Object(stdClass))
#16 /var/lib/mediawiki/includes/libs/lessc.inc.php(189): lessc->compileProp(Array, Object(stdClass), Object(stdClass))
#17 /var/lib/mediawiki/includes/libs/lessc.inc.php(829): lessc->compileImportedProps(Array, Object(stdClass), Object(stdClass), Object(lessc_parser), '/var/lib/mediaw...')
#18 /var/lib/mediawiki/includes/libs/lessc.inc.php(189): lessc->compileProp(Array, Object(stdClass), Object(stdClass))
#19 /var/lib/mediawiki/includes/libs/lessc.inc.php(829): lessc->compileImportedProps(Array, Object(stdClass), Object(stdClass), Object(lessc_parser), '/var/lib/mediaw...')
#20 /var/lib/mediawiki/includes/libs/lessc.inc.php(311): lessc->compileProp(Array, Object(stdClass), Object(stdClass))
#21 /var/lib/mediawiki/includes/libs/lessc.inc.php(305): lessc->compileProps(Object(stdClass), Object(stdClass))
#22 /var/lib/mediawiki/includes/libs/lessc.inc.php(220): lessc->compileRoot(Object(stdClass))
#23 /var/lib/mediawiki/includes/libs/lessc.inc.php(1927): lessc->compileBlock(Object(stdClass))
#24 /var/lib/mediawiki/includes/libs/lessc.inc.php(1950): lessc->compile('/*?** Catalyst ...', '/var/lib/mediaw...')
#25 /var/lib/mediawiki/includes/libs/lessc.inc.php(2022): lessc->compileFile('/var/lib/mediaw...')
#26 /var/lib/mediawiki/includes/resourceloader/ResourceLoaderFileModule.php(809): lessc->cachedCompile(Array)
#27 /var/lib/mediawiki/includes/resourceloader/ResourceLoaderFileModule.php(719): ResourceLoaderFileModule->compileLESSFile('/var/lib/mediaw...')
#28 /var/lib/mediawiki/includes/resourceloader/ResourceLoaderFileModule.php(692): ResourceLoaderFileModule->readStyleFile('vectorcatalyst/...', false)
#29 /var/lib/mediawiki/includes/resourceloader/ResourceLoaderFileModule.php(321): ResourceLoaderFileModule->readStyleFiles(Array, false)
#30 /var/lib/mediawiki/includes/resourceloader/ResourceLoader.php(812): ResourceLoaderFileModule->getStyles(Object(ResourceLoaderContext))
#31 /var/lib/mediawiki/includes/resourceloader/ResourceLoader.php(546): ResourceLoader->makeModuleResponse(Object(ResourceLoaderContext), Array, Array)
#32 /var/lib/mediawiki/load.php(43): ResourceLoader->respond(Object(ResourceLoaderContext))
#33 {main}
*/

To fix this, make sure you have these defined in your skin's less variables file (usually variables.less) e.g.

@collapsible-nav-heading-color: #4d4d4d;
Jonathanischoice (talk)05:17, 11 September 2014
 
 
 

Someone on stack exchanged fixed it by modifying $wgServer in LocalSettings.php. Changing the $wgServer from localhost to the static IP of the machine, eg:

## The protocol and server name to use in fully-qualified URLs
## $wgServer = "http://localhost";
$wgServer = "http://123.123.12.12";


Seemed to do the trick for me! This was using version 1.23.5 (latest version as of 10/30/14).

63.241.40.12719:46, 30 October 2014
 

Cannot contact the database server: Access denied for user

So I upgraded the mediaWiki version by overwriting the old version with new version. I upgraded from 1.22.6 to 1.23.5. But as soon as I overwrote the directory and tried to open the website on web browser, I got :

(Cannot contact the database server: Access denied for user 'newqmrasite'@'localhost' (using password: YES) (localhost))

PLEASE HELP!!!!!!

35.20.11.9517:37, 29 October 2014

Hello!

This is an issue of your configuration :) Please check, if the username and password of your database user (which has access to the database you want to use) is correctly written and is valid (maybe, try to login with these data from the console, if possible).

Florianschmidtwelzow (talk)18:48, 29 October 2014

Thanks for the reply! I have tried that already. The servername, database name, user and password are all correct in localsettings. I have changed the password for the user through phpmyadmin and updated it in localsettings but I keep getting the same message.

Somebody please help me out! My job depends on it!

35.20.11.9519:16, 29 October 2014

Overwriting an old wiki version with the files from a newer tarball does not touch LocalSettings.php. If it worked before and does not work now, then you must have changed something with LocalSettings.php. What did you do? Have you recreated the file?

Anyway, what you can do is to put the following lines at the very bottom of your LocalSettings.php file:

echo $wgDBserver . "\n";
echo $wgDBname . "\n";
echo $wgDBuser . "\n";
echo $wgDBpassword . "\n";
die("END");

This will put out the according information onto the wiki page (do not forget to remove them again afterwards!). Is this information - all four of them - correct?

88.130.93.8319:48, 29 October 2014

Thanks a lot for the reply!

I pasted the code at bottom of localsetting.php. It printed out the correct information. But still I am still getting the same error. Here's website qmrawiki.canr.msu.edu

I will be forever thankful to you if you help me out!!!

69.176.157.10123:23, 29 October 2014
Edited by author.
Last edit: 08:09, 31 October 2014

For this page i get the following error:

ERROR: Semantic MediaWiki must be installed for Semantic Forms to run!

???

Can you try the following?:

  1. Create a new file called test.php (e.g. test, you can choose any other name, if you want, with the file extension php)
  2. Insert the following, save and upload to your webspace:
<?php
$wgDBserver = 'localhost';
$wgDBuser = 'newqmrasite';
$wgDBpassword = '';
$wgDBname = '';
 
$mysqli = new mysqli( $wgDBserver, $wgDBuser, $wgDBpassword );
 
if ( mysqli_connect_errno() ) {
    die( "Failed:" . mysqli_connect_error() );
}
 
if ( $mysqli->select_db( $wgDBname) ) {
    echo 'Connected and DB selected.';
} else {
    echo 'Something went from (select_db())';
}
 
$mysqli->close();

Insert the correct data for server, username and password!

If you transferred the file to your server, open it in your webbrowser and give us the output :)

Florianschmidtwelzow (talk)06:46, 30 October 2014
 
Edited by author.
Last edit: 15:36, 30 October 2014

While I - just like Florian - see the error message about Semantic Forms, this is not the initial issue.

The error "Access denied for user 'username'@'hostname'" is caused be incorrect credentials. For example I see that you are using two different MySQL usernames: You used "newqmrasite" in your first post, but now you use "wikiuser". Again, please make sure that you are using the correct username!

@ Florian: Is it intended that in your script you are not defining $wgDBname (while you are later using it)?

88.130.93.8315:01, 30 October 2014
 
 
 
 
 

[RESOLVED] Fatal error: Interface 'Psr\Log\LoggerInterface' not found

Hello,

Update to the latest version of mediawiki failed when running update script and when displaying pages: Fatal error: Interface 'Psr\Log\LoggerInterface' not found in /var/www/parts-unknown/org/mediawiki/core/includes/debug/logger/Logger.php on line 46

This would be version 1.23.6, although I can't verify it with the Special:Version page, because I get the error above.

home% php --version
PHP 5.5.18 (cli) (built: Oct 28 2014 20:09:10) 
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2014 Zend Technologies
    with Zend OPcache v7.0.4-dev, Copyright (c) 1999-2014, by Zend Technologies
home% mysql --version
mysql  Ver 15.1 Distrib 5.5.39-MariaDB, for FreeBSD10.1 (amd64) using readline 6.3
home%
Benfell (talk)21:32, 29 October 2014

Hello,

this seems to be NOT 1.23.6, \Psr\Log\LoggerInterface prerequirement was merged yesterday into master branch of MediaWiki core (currently 1.25alpha), so you maybe downloaded MediaWiki from git?

To fix this, you need to install the vendor directory for mediawiki. For this you can just run composer install if you have shell access and composer installed, or you clone the vendor git repository into your mediawiki root directory:

git clone https://gerrit.wikimedia.org/r/p/mediawiki/vendor.git

Florianschmidtwelzow (talk)06:33, 30 October 2014

Seems like magic, and I have no idea what it actually did, but it worked. My wikis are apparently back on line. Thanks!

Benfell (talk)18:36, 30 October 2014
 
 

Generating PDF book without list of references (Collection extension)

I'm using Mediawiki as documentation platform and I'm also generating a PDF book with Collection extension.

However the generated PDF book has about 10% of pages just long lists of references and sources which are not useful. Is there a way to prevent reference lists from getting into the book?

83.150.117.414:24, 8 December 2013

If you're running into this problem, you should file a feature request for this new functionality.

MarkAHershberger(talk)16:28, 14 March 2014

This is what I do at Wikibooks:

I create a special wiki page that is the "print version" of the entire book in a single wiki page, for example:

As you can see, the "edit view" of the print version of a book looks something like this:

= Introduction =
{{:Robotics/Introduction}}
= Contributors =
{{:Robotics/Contributors}}
= Stepper Motors =
{{:Robotics/Stepper Motors}}
= Navigation =
{{:Robotics/Navigation}}
= Resources =
{{:Robotics/Resources}}
= References =
{{:Robotics/References}}

Then I go to each and every wiki-page of the book, hunting for the magic words "<references />" and "{{reflist}}" and make sure each one (if there is one on the page) is inside "noinclude" tags, like this: "<noinclude>{{reflist}}</noinclude>". Except for the very last "References" page of the book, which has a "{{reflist}}", but it does not have any "noinclude" tags.

Then when I look at the "normal view" of the print version of the book ( http://en.wikibooks.org/wiki/Robotics/Print_version ), those references are not included at the end of each page (because of the "noinclude" tags), but only in one giant list of references at the very end of the book.

I suppose you could make a "print version without references" page identical to the "print version" page, except delete the two lines

= References =
{{:Robotics/References}}

so that "print version without references" page never includes the magic words "<references />" and "{{reflist}}" unless they are hidden by the "noinclude" tags. Then you could produce the PDF file from that one big "print version without references" page.

More details: http://en.wikibooks.org/wiki/Help:Print_versions

p.s.: I'm one of the people who often thinks articles at Wikipedia and elsewhere don't have enough sources. Please consider yourself lucky that you have so many references and sources.

DavidCary (talk)17:37, 21 March 2014

Thank you very much David! You're very helpful.

The references I'm getting are mostly meaningless references to my wiki itself (mostly image URLs) which I wanted to eliminate for clarity. I'll try the tricks provided!

77.86.204.600:23, 31 October 2014
 
 
 

„Import fehlgeschlagen: Verlust der Sessiondaten. Bitte versuche es erneut.“

Tach, ich möchte diesen Artikel (1) mit allen Versionen bei mir im Wiki importieren (hochladen). Allerdings erscheint die ganze Zeit „Import fehlgeschlagen: Verlust der Sessiondaten. Bitte versuche es erneut.“ Was ich gemacht habe: Ich habe den Haken aus "Nur aktuellste Version" rausgenommen und speicherte diese Datei als XML auf meiner Festplatte. Beim Importieren in meinem Wiki erscheint dieser Text. Zuvor habe ich nur die aktuellste Version importiert und es klappte einwandfrei. Bedauerlicherweise liegen bei diesem Artikel sehr viele Versionen vor und ich dachte mir, es wäre viel zu viel für ein 30GB Server (später werde ich noch wechseln). Wie lässt sich dieses Problem beheben? Denn ich brauche alle Versionen dieser Seite und nicht nur eine, da sonst nach der Meinung von einem Wikipedianer URV wäre und das möchte ich vermeiden.

87.150.158.18716:47, 30 October 2014

Hallo,

du könntest das XML File, wenn du Shellzugriff hast (bspw. über SSH), das Wartungsskript importDump.php verwenden. Ansonsten weiß ich ad hoc auch nicht weiter :)

Florianschmidtwelzow (talk)16:54, 30 October 2014

Danke. Ich habe das Verzeichnis aufgerufen und komme nicht rein: <domain>/maintenance/importDump.php lautet die Adresse. Leider komme ich nicht durch. (Ironischerweise kann ich /mw-config/index.php5 aufrufen und ich bekomme Zugriff) Gibt es eine andere Möglichkeit? Also in LocalSettings befinden sich keine Infos, die einen Zugang auf diese Datei gewähren.

87.150.158.18717:26, 30 October 2014

Du kannst wartungsscripts auch nicht im Browser aufrufen ;) Die musst du über eine Shell bspw. über SSH aufrufen. Wenn du keinen SSH Zugriff auf den Server hast, dann kannst du keine Wartungsskripts nutzen. Wie gesagt, eine andere Möglichkeit, Exports zu importieren, kenne ich nicht.

Florianschmidtwelzow (talk)19:44, 30 October 2014
 
 
 

User must select a license on upload page

Hi there, In the project I am working on I don't want users to be able to upload files using the special:upload page when they have not selected a licence. In the same manner you are restricted to upload certain file types, would it be possible to restrict users from uploading files without choosing a licence? My knowledge in Java Script is limited but I understand php fairly well.

Thank you

41.223.25.5214:19, 26 October 2014

Hello,

you can try to use the Hooks/UploadForm:BeforeProcessingUploadForm:BeforeProcessing hook]], which is called just before the input data is processed and can abort the upload. Compared with the function SpecialUpload::showRecoverableUploadError you should be able to output a user friendly error message without loosing the input data.

Florianschmidtwelzow (talk)15:20, 30 October 2014
 

Error: invalid time

https://meta.wikimedia.org/wiki/Help_Forum/Archive_2

This archive was created on ??? Someone should fix this.Vchimpanzee (talk) 22:27, 29 October 2014 (UTC)

Vchimpanzee (talk)22:27, 29 October 2014

This is about fixing a specific template on Meta so I'd rather bring that up on the page of Meta's Help Forum itself. You could fix this.

AKlapper (WMF) (talk)10:43, 30 October 2014
 

[RESOLVED] provider migrated to php 5.5, wiki doesn't load

Hello

my provider migrated two days ago to php 5.5, and since then my wiki (http://www.olliw.eu/storm32bgc-wiki/) doesn't load anymore.

my MediaWiki version is 1.23.2

I first thougfht that the issue is related to the .htaccess, which does a redirect:

<Files LocalSettings.php>

deny from all

</Files>

RewriteEngine On

RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-f

RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-d

RewriteRule ^(.*)$ %{DOCUMENT_ROOT}/storm32bgc-wiki/index.php5 [L]

but removing it didn't help. Using the cntrl+U of firefox to watch the recieved html code displays the content of the file index.php5, i.e. it seems as if the require './index.php'; is not executed.

I'm at a loss, and would much appreciate any hint or tip or indication in which direction to look for.

Thx Olli

88.65.189.8621:13, 28 October 2014

Hi Olli!

Obviously files with the file extension php5 currently are sent to the user instead of being executed by PHP. How exactly this can be solved depends on the server setup. Most likely adding an according AddHandler directive to .htaccess helps.

Apart from that I don't see a reason why you should redirect everything to the index.php5 file - maybe you have already solved the problem, when you change the redirect to point to index.php instead?!

88.130.124.4821:44, 28 October 2014

Thanks a LOT for the answer, but I guess I don't understand

the index.php5 and index.php files are exactly those shipped with mediawiki, so, it's not like that I have done anything here

the server used to use the .php5, when I enter the url with .php it also uses the .php5, but this had been like that also before

the redirect doesn't seem to be the issue, at least then I remove that part from the .htaccess or delete the .htaccess completley, then the .php would yield a page not found error while the .php5 results in the same behavior, so it seems the server still goes for the .php5. I checked what you suggested and changed .php5 to .php in the redirect: one then gets some wiki info when entering the correct url, but it looks as if the layout is missing, and the home url doesn't work at all.

what I don't quite understand is why the behavior should have changed, I mean, the wiki is up and runing for 8 month now. As regards the .php5 vs .php thing my understanding was that MediaWiki would handle things correctly, irrespective of the providers preference.

My thoughts/conclusions might be totally nonsense, I'm just totally confused by what I see, it doesn't make sense to me.

I need to research what AddHandler does, can't comment hence, but many thanks for the hint.

THX

(BTW: I've contacted before the provider, but they refused to help)

88.65.189.8623:16, 28 October 2014

OK, your tip was great !!! it's nearly back to working

what occured to me was to also look at the LocalSettings.php, and indeed there the .php5 extension was specified. Together with your suggested change of the redirect, the wiki seems to work. It seems that the rules as regards the .php5 have changed.

The only thing which is not yet working is the url http://www.olliw.eu/storm32bgc-wiki/, somehow it isn't extended by the index.php (if one enters http://www.olliw.eu/storm32bgc-wiki/index.php it works).

Anyway, a BIG step forward, THANKS so much so far :)

88.65.189.8623:36, 28 October 2014

That URL is working for me currently; I had to clear the browser cache to actually see it.

It seems like your host has changed the handling of php5 files: Before their PHP update they obviously were parsed by PHP, after they are not. Given that your wiki is working correctly with the php files, I am not sure, if you still need correct handling for php5 files. Anyway, an example AddHandler directive for .htaccess might be one like this:

AddHandler x-httpd-php5.5 .php5

This should make php5 files be parsed by PHP 5.5 - assumed the host uses some default setup.

88.130.124.4813:27, 29 October 2014

Ahh, and you might be interested in doing a MediaWiki upgrade: MediaWiki 1.23.2 has known security issues. You should update to the current version of the 1.23 development branch. Currently that is 1.23.5!

88.130.124.4813:30, 29 October 2014
 

thanks! I too concluded that the .php5 handling has somehow changed (and obviously not consistently, an url is appended using the index.php5 file, but is not processed by php LOL). I currently solved the issue by simply renaming/erasing the file index.php5, so that index.php is called. That's why it works now after a cache upadte. I'm still looking for better solutions, since the .php5 vs .php thing breaks some other links, but at least the wiki is back! Yes, I know there is an upgrade to 1.23.5, but the release notes didn't indicated that it might solve the issue, and without having basic things working it's IMHO not wise to attempt an upgrade :) Thanks again to everyone!

88.65.189.8607:34, 30 October 2014
 
 
 
 
 

[RESOLVED] php error - file_get_contents

hi !

I get following error message in php_errors.log:

[21-Oct-2014 09:07:59 UTC] PHP Warning: file_get_contents(): Unable to find the wrapper "https" - did you forget to enable it when you configured PHP? in C:\mediawiki\extensions\SpamBlacklist\BaseBlacklist.php on line 273 [21-Oct-2014 09:07:59 UTC] PHP Warning: file_get_contents(https://meta.wikimedia.org/w/index.php?title=Spam_blacklist&action=raw&sb_ver=1): failed to open stream: No such file or directory in C:\mediawiki\extensions\SpamBlacklist\BaseBlacklist.php on line 273

can someone help ?

reagards Jan :-)

85.233.12.11409:12, 21 October 2014

You may need to enable the PHP extension php_openssl.dll

http://stackoverflow.com/questions/11453487/xampp-and-file-get-contentshttps

Alternatively, replace all URLs on $wgSpamBlacklistFiles that have "https:" with "http:", or remove them

Ciencia Al Poder (talk)09:54, 21 October 2014
 

Hello!

You should ask this question on Extension_talk:SpamBlacklist. SpamBlacklist wants to import some files from meta-wiki with a secure https connection. But it seems, that your webhost doesn't support this. So you should remove the s from https (so it's http:// only), which isn't really recommended, or you should ask your hoster to activate https as a wrapper.

Or: You copy the contents of https://en.wikipedia.org/w/index.php?title=MediaWiki:Spam-blacklist into your local site MediaWiki:Spam-blacklist and add this site to

$wgSpamBlacklistFiles = array(
   "[[MediaWiki:Spam blacklist]]"
);
Florianschmidtwelzow (talk)09:56, 21 October 2014

hallo !

this part will run now - thanks for help!

regards Jan

85.233.12.11407:37, 30 October 2014
 
 

KeyCaptcha not Working on Reg Page

A thread, Thread:Project:Support desk/KeyCaptcha not Working on Reg Page, was moved from here to Extension talk:KeyCAPTCHA. This move was made by Florianschmidtwelzow (talk | contribs) on 30 October 2014 at 06:48.

Extension:Approved Revs

Installed “Extension:Approved Revs” to prevent publishing changes to a page until approval. For that, I did the below changes but still I could not see the (approve) link on history page. Also, the changes made on the pages are published directly to all the users.

1. Created a folder “ApprovedRevs” inside extension folder and copied all the files.


2. Executed the DB scripts to create the DB objects


3. Added the below configuration in the LocalSettings PHP file


      require_once( "$IP/extensions/ApprovedRevs/ApprovedRevs.php" );

      $wgGroupPermissions['*']['edit'] = false;

      $egApprovedRevsBlankIfUnapproved = true;

      $wgGroupPermissions['*']['viewlinktolatest'] = false;

      $wgGroupPermissions['sysop']['viewlinktolatest'] = true;

      $egApprovedRevsAutomaticApprovals = false;

      $egApprovedRevsShowApproveLatest = true;


Am I missing anything? Appreciate your help. Thanks


Regards Gopi. R
2001:4898:80E8:EE31:0:0:0:223:43, 29 October 2014
First page
First page
Previous page
Previous page
Last page
Last page