Project:Support desk

From MediaWiki.org
(Redirected from Support desk)
Jump to: navigation, search
vde   Welcome to MediaWiki.org's Support desk, where you can ask MediaWiki questions!

There are also other places where to ask: IRC, mailing lists, Q&A etc.

Before you post

Post a new question

  1. To help us answer your questions, please always indicate which versions you are using (reported by your wiki's Special:Version page):
    • MediaWiki
    • PHP
    • Database
  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".
Start a new discussion
First page
First page
Previous page
Previous page
Last page
Last page

Open the index.php - How??

We are using MW 1.22 and we want to install the extension CheckUser. I installed CheckUser on another Wiki and the only thing to do was to open mypage.com/mw-config/index.php (running index.php) after uplaoding all the files and adding requireidunno in LocalSettings. But yeah, this method (visiting [mypage.com]/mw-config/index.php) ain't work on MW 1.22. After loading "Error 403" appears, although mw-config/index.php exists. I've accses on only one directory. The server and the wiki belongs to my wiki partner and I try to help him.

Don't include extensions in index.php

Ciencia Al Poder (talk)02:32, 5 May 2015
 

RL: Eliminate render-blocking JavaScript and CSS in above-the-fold content

Pagespeed Insight returns the warning: "Eliminate render-blocking JavaScript and CSS in above-the-fold content".

This mainly affects the JS in the header from RL.

E.g. on https://www.mediawiki.org/wiki/Manual:Contents: [1]

Why not on Wikipedia? Example: http://en.wikipedia.org/wiki/Diff [2]

How can I fix it for my own wiki?

Subfader (talk)21:27, 4 May 2015

Just forget it.

I have tried exactly the same a few days ago; if you speak German I can link you the thread from the German WP. It is just not possible - at least not in a reasonably maintainable way.

I cannot say why Google does not complain for the WP page, but in my tests it already was enough to place any style defintion in the HTML directly. Then Google was happy. That this style did not apply to content above the fold, was not interesting for Google. Also that all the other styles, which did apply above the fold, still were in the blocking stylesheet also was not interesting for Google. I had not improved the situation, but Google did no longer show the error. To cut a long story short: Do not give much about Google's warnings in this regard. They don't mean much.

Google will already give a way better score, if the different JavaScripts were concatenated into one instead of into four files. This will also save a few connections on load. At least that would be what I would try fixing first. However, I do not know, how RL internally decides to merge or not to merge different styles. It might be that, if we just always merge everything, we later have way more entries in cache, which in fact are hardly ever used as they are to special...

88.130.87.20221:59, 4 May 2015

Hi, yes I'd be interested in the deutsche Diskussionsseite :)

The WP article seems to have been a bad example. Here is also JS load.php in the head. This and the script tags cannot be moved to the bottom?

79.228.77.21022:46, 4 May 2015
 
 

ResourceLoader vs CDN subdomain for css scripts

I have three ~5 KB CSS scripts which only affect single pages and a forum extension.

They don't change often and so I host them on a cdn-like subdomain (far-future-expire, cookieless etc).

Is it nontheless better to embed the CSS using RL (addModuleStyles)?

Subfader (talk)13:29, 3 May 2015

Or is it even a bad idea at all to host CSS (and JS) on a different domain? I think I've read somewhere that the CSS and JS files load much faster when hosted on the same domain as the website.

Subfader (talk)13:45, 3 May 2015

From a performance point of view, hosting stuff on different domains is bad: In order to get information from another domain, you will need a new DNS lookup and a new TCP connection. When this happens a few time during your request, it sums up and can actually be perceived, especially when using a slow connection as you usually have with mobile devices. You can calculate with around 250ms for each additional file, that has to be downloaded that way (plus the time needed to transfer the actual content, but if the file is small that should be way below 100ms). Hosting everything on the same domain will save you the DNS lookup and the time needed to get the new connection, but the ressource loader honestly is kind of a performance killer. Concatenation of CSS is nice and is the right idea, but what the ressource loader does is just slow. I have not tested it, but I would guess that transferring a number of small (minified) CSS files with separate requests will still be way faster than using the ressource loader.

88.130.122.16814:31, 3 May 2015

Thanks for the clearification for the additional DNS lookups. I just thought: Onc cached by the user it wouldn't matter.

About RL: You are aware how fast Wikipedia loads?

I even think about adding my main skin CSS (63 KB) to RL. Is it a good idea?

Subfader (talk)15:35, 3 May 2015

In fact, when you program for MediaWiki, using the resource loader is a handy option and yes, I also use it myself. I am maintaining a few skins that are technically Vector clones and so they also have their CSS/JS loaded through the resource loader. Having nearly the complete CSS loaded through the resource loader is btw. also what Wikipedia does. I don't know how it's configured at Wikipedia, but I guess that it does not deliver a precached file from the file system. Instead, it invokes PHP and I guess it does a few MySQL queries to get the cached stuff somewhere from an internal DB table. If you have kind of a CDN this should not really hurt, but it will always be faster to only read an existing file than having to invoke PHP, MySQL and to fetch stuff from inside a DB.

88.130.122.16816:37, 3 May 2015

Thanks for your thoughts.

Until a dev tells me differently I will stick to my few CSS files.

Subfader (talk)17:00, 3 May 2015
 

For WMF, basically ALL caching layers are used in their optimal setup. Operation caching in PHP (or actually HHVM these days), in memory caching with memcached and output caching with varnish (for caching at the network request layer) and lastly multiple locations for serving content. Without this, your performance will probably be less than Wikipedia.

Basically, this is what CDNs do as well, but you don't have to configure it yourself with a CDN of course.

Note that RL does a lot more btw. It is also handles dependency management, de-duplication, partitioning (so you only load the stuff you need, kind of important with thousands of lines of CSS and JS that is used throughout MediaWiki), right to left language support etc. etc.

Anwyay, MediaWiki will use RL for all it's own resources regardless, so if you add a bit of JS and your performance tanks, then you should probably do a bit more reading on RL, because you are likely not using it correctly :)

TheDJ (Not WMF) (talkcontribs)18:26, 3 May 2015
 
 
 
 
 

using HTMLForm class vs adding HTML directly

Hello,

When building custom forms in wikimedia specialpages, you have the option to directly inject your own HTML into the page, or use the mediawiki HTML form builder class. My question is, what are the advantages of using the built in form builder vs just injecting the HTML using getOutput()->addHTML() ? Thanks.

146.175.202.3013:16, 4 May 2015

The HTMLbuilder applies the proper escaping to everything. Using raw html is a bit more adventurous because you need to make sure yourself that you are not introducing a security leak. Especially in forms, with user input, taking care of proper escaping is something not to take lightly.

TheDJ (Not WMF) (talkcontribs)21:03, 4 May 2015
 

Could not create directory "mwstore://local-backend/local-public".

I am working on a MediaWiki 1.24.2 installation with Oracle DB. This is behind a company firewall with nothing facing the public. A requirement is that it must use Oracle so I cannot change this. The installation is up and I can edit and create pages without issue. I was able to import the pages from the old 1.19 version (MySQL DB).

Whenever I try to upload a file, I get the error Could not create directory "mwstore://local-backend/local-public".

The mediawiki/images directory is currently 777 (recursively) but the error still comes up (yes, I know, but until I find out why it isn't working, I got nothing). $wgFileExtensions = array('png', 'gif', 'jpg', 'jpeg', 'doc'); $wgUploadPath = '/images'; $wgEnableUploads = true;

I have googled this several different ways and gone a several pages deep on each one looking for an answer. I know a little php, but would not call myself an expert. I realize the path presented is an alias.

It looks like an image very BRIEFLY shows up in the /images path when trying to upload, but then the error happens and the image is deleted (based on working with one of our *nix guys and watching log files).

V3rlon (talk)19:55, 4 May 2015

Now published after control of the generated pages

How do I receive confirmation page to appear after they create users?

Cgtay.trkmen (talk)20:14, 28 April 2015

I'm sorry, but I do not understand your question.

What is the situation, in which you are?

What do you want to change?

88.130.113.10223:12, 28 April 2015

1) sends a request to create user page. 2) approve admin 3) page is published

88.242.179.24123:27, 30 April 2015
 

Perhaps you are looking for: Extension:ConfirmAccount ?

TheDJ (Not WMF) (talkcontribs)13:55, 29 April 2015

My guess is Extension:Approved Revs or the more complex Extension:FlaggedRevs.

88.130.124.9800:17, 1 May 2015

Users create pages won't run. Admin confirm published the page when it examines the, also only get admin edit.

88.242.179.24112:33, 1 May 2015

=> Extension:Approved Revs!

88.130.76.2212:49, 1 May 2015

actually Approved revs will only show the text of "approved". that is it. But we dont want to show user created page before it gets approved.

81.213.42.15818:59, 4 May 2015
 
 
 
 
 

[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

Along with the $wgServer = "http://123.123.12.12"; fix, I had to set $wgUsePathInfo = false; also

130.76.32.5116:03, 5 December 2014
 

great replacing localhost with ip address worked for me

93.169.59.15906:39, 25 January 2015

This worked for me as well!

Remember to copy the trailing semicolon.

131.156.136.19515:24, 4 May 2015
 
 
 

How to use SMTP with HHVM?

I am stuck in the pear installation. I can send SMTP manually through HHVM pear, but Mediawiki keep showing "PEAR mail package is not installed".

How to config HHVM so that Mediawiki could SMTP?

https://www.mediawiki.org/wiki/Manual:$wgSMTP https://phabricator.wikimedia.org/T91919

Zoglun (talk)15:38, 24 March 2015

How to select nth-child of grandparent element instead of direct parent element

Is it possible to select the nth-child of its grandparent element (2nd parent), versus it's parent element? I researched and apparently there are no CSS parent selectors.

My source code is located at http://dev.brickimedia.org/wiki/User:Codyn329/Sandbox/4

I want to do this so I can highlight the current day out of all the days on the calendar. However, since the way I nested it..

<div class="calendar-all-days">
   <div class="calendar-week">
      <div class="calendar-day">

When I select the parent of .calendar-day, it goes to .calendar-week instead of .calendar-all-days.

The main CSS block I'm trying to use to do this is here (Note - I'm using a magic word in a parser function (#css from Extension:CSS) so direct input of {{CURRENTDAY}} in the parentheses should be OK I assume):

.calendar-day:nth-child({{CURRENTDAY}}) {
  background: #27ae60;
  color: #fff;
  font-weight: bold;
}
Codyn329 (talk)01:21, 29 April 2015

Notice - I accidentally made a duplicate, can someone delete the other one please? Thanks

Codyn329 (talk)01:22, 29 April 2015
 

I tried to research this and the only option I can come up with is using js instead of {{#css: }}

// this is just a function to create a simple "nthParent" in jQuery
// http://stackoverflow.com/questions/8180320/how-to-find-nth-parent-of-an-element-using-jquery
$.fn.nthParent = function( n ) {
    var p = this;
    for( var i = 0; i < n; i++ )
        p = p.parent();
    return p;
}
 
var date = new Date().getDate();
 
$( '.calendar-day:nth-child( ' + date + ' )' ).nthParent( 2 ); // selects the grandparent element of the nth-child
GeorgeBarnick (talk)13:09, 4 May 2015
 

[Resolved] Cannot upload docx files

Edited by author.
Last edit: 10:28, 2 May 2015

Version Mediawiki 1.15.4 (on my computer) PHP 5.3.0 (apache2handler)

Hi I have recently updated from Microsoft Office 2003 to Office 2013. I am now unable to upload docx files. I have added docx to Local Settings. when I attempt to upload a docx file I can see that docx files are permitted: Permitted file types: png, gif, jpg, jpeg, docx, pdf, doc, xls, ppt.

However why I try I get the message: Cannot upload this file because Internet Explorer would detect it as "application/zip", which is a disallowed and potentially dangerous file type.

I checked on the MediaWiki extensions page and as suggested added: $wgAllowJavaUploads = true;

But that did not make any difference. I have a feeling that this maybe because I am running an old version of MediaWiki!

Thank you for any assistance.

Ron Barker (talk)10:27, 2 May 2015

MediaWiki 1.15 is vulnerable and no longer supported, and this problem doesn't happen on new versions of MediaWiki. Please upgrade.

As alternative, there's a hack for older versions: Thread:Project:Support desk/Trying to upload a doc file gives error: "Cannot upload this file because Internet Explorer would detect it as "application/msword", which is a disallowed and potentially dangerous file type."

Ciencia Al Poder (talk)02:00, 3 May 2015
 

JPG Pictures are displayed upside down depending on size

See http://wiki.dc-car.de/index.php?title=Test-pdf_Seite

It is independent of the browser.

What can I do to fix it ?

Claus

MediaWiki 1.24.2 PHP 5.5.24 (cgi-fcgi) MySQL 5.1.73-log

Elektronix 70 (talk)08:00, 4 May 2015

I purged all the cached images by going to [1]. Now all JPGs are upside down. Did you recently upgrade your MW or imagemagick installation or something ? At some point the software stack started respecting the 'orientation' parameter of the JPGs, which it didn't in the past. And when I go to the original it also shows upside down for me, so likely the EXIF orientation actually tells mediawiki that this image should be rendered upside down. You should rotate the original with an external application and then reupload it, and re purge all the thumbnails.

TheDJ (Not WMF) (talkcontribs)09:07, 4 May 2015
 

Unusually Large database: 8GB

Edited by another user.
Last edit: 16:46, 2 May 2015

The database in question is more than 8GB in size, which is an unusually high amount of data. Isn't it that generally even larger MediaWiki installations have databases no bigger than 2-3GB. Of the 8GB of data, 5GB of all content is placed in the mz_text table.

What i would like to find out is, how did this come about?

  • Below is the "statistics" of the wiki
Page statistics
Content pages 180,951
Pages
(All pages in the wiki, including talk pages, redirects, etc.)
267,194
Uploaded files 14,476
Edit statistics
Page edits since Portal to The Philippines was set up 667,012
Average edits per page 2.50
24.182.18.12715:37, 2 May 2015

For each text change, that is saved, MediaWiki creates exactly one new revision. Each revision points to exactly one record in the text table; most likely this will not be an old record, which just can be re-used, but a record will be newly created when the user saves the page. Each entry in the text table holds the complete text of the according page (and not only parts of it).

So if you have 667.012 edits, then you will have around that number of rows in the text table. The size of each of these rows obviously depends on the length of the text. If the text table is around 5 GB = 5.000.000 KB in size, this means that your average text is around 7,5 KB big. I don't know your texts, but that sounds like a possible length to me.

Do you in fact want to reduce the size of the database? If so, this is most likely possible - with and without removing data from it.

88.130.101.23821:15, 2 May 2015

Yes I really would like to reduce the size of the database without deleting records.

24.182.18.12718:00, 3 May 2015

As detailed on Manual:Reduce size of the database, you can e.g. compress the contents of the text table and you can compress future revisions. You can also permanently delete archived revisions, which will in fact permanently remove those revisions, which are not visible to the public anyway.

Additionally, you could even remove the page histories - however, that would permanently remove all old revisions and their texts.

To refresh the searchindex (and a few other tables), you can run the maintenance script rebuildall.php. See Manual:Rebuildall.php! Additionally to having a smaller DB size, this might also be useful to get deleted pages removed from your search results.

88.130.122.16821:09, 3 May 2015

I tried the "compressOld.php" specifying all edits prior to 2015 (2009 to 2014). But that only reduced my database by 500meg. I must be doing something wrong.

I would say that only about 3% of my pages in the wiki were created in 2015. So the compress command should have compressed over 90% of the edits. Yet....

24.182.18.12721:53, 3 May 2015
 
 
 
 

Error creating thumbnail Error code: -1

Error creating thumbnail Error code: -1

Some images say Error creating thumbnail Error code: -1. Not display that error in all images, but some display that error or is too late to create thumbnail.

Version is like this:

MediaWiki : 1.24.2

PHP : 5.4.39 (apache)

MySQL : 5.0.45-log

ImageMagick : 6.9.1-1

Dlwnsgud0819 (talk)12:15, 25 April 2015

If that happens with some images, it may be that they're large or complex enough which makes the thumbnail to fail. It may be that it requires more memory than the available memory of the server, or the allowed memory to use by PHP. See Manual:$wgMaxShellMemory and Manual:$wgMaxShellFileSize, and try using higher values.

Ciencia Al Poder (talk)22:26, 25 April 2015

I already set that paramiter($wgMaxShellFileSize = 307200; $wgMaxShellMemory = 409600;), but It doesn't work. Also php limit is already 128M (I checked by memory_limit in phpinfo.)

Dlwnsgud0819 (talk)23:46, 25 April 2015

Best you can do then is follow Manual:How to debug to set up a debug log, that will print the exact command used to create the thumbnail, and execute that same command from the shell to see if it gives any error message.

Ciencia Al Poder (talk)03:13, 27 April 2015

This is the log which shows error:
wfShellExec: /bin/bash '/home/xxxwiki/user/w/includes/limit.sh' 'OMP_NUM_THREADS='\''1'\'' '\''/usr/local/bin/convert'\'' '\''-background'\'' '\''white'\'' '\''/home/xxxwiki/user/w/images/2/2d/gggg.gif'\'' '\''-thumbnail'\'' '\''418x600!'\'' '\''-set'\'' '\''comment'\'' '\''File source: http://xxxwiki.xxx/w/index.php/gggg.gif'\'' '\''-depth'\'' '\''8'\'' '\''-rotate'\'' '\''-0'\'' '\''/tmp/transform_e203a7abc952-1.gif'\''' 'MW_INCLUDE_STDERR=1;MW_CPU_LIMIT=0; MW_CGROUP='\'''\''; MW_MEM_LIMIT=409600; MW_FILE_SIZE_LIMIT=307200; MW_WALL_CLOCK_LIMIT=180; MW_USE_LOG_PIPE=yes'

[thumbnail] thumbnail failed on xxxwiki.xxx: error -1 "" from "'/usr/local/bin/convert' '-background' 'white' '/home/xxxwiki/user/w/images/2/2d/gggg.gif' '-thumbnail' '418x600!' '-set' 'comment' 'File source: http://xxxwiki.xxx/w/index.php/gggg.gif' '-depth' '8' '-rotate' '-0' '/tmp/transform_e203a7abc952-1.gif'"

[thumbnail] Removing bad 95389-byte thumbnail "/tmp/transform_e203a7abc952-1.gif". unlink() succeeded

Dlwnsgud0819 (talk)06:22, 27 April 2015

Do you have shell access? You should try to paste that command on the shell and see if it gives an error message. The strange thing is that apparently it succeeds in creating the file, because it says it was removing a bad thumbnail from the temp directory, which is the same it was trying to create.

Ciencia Al Poder (talk)22:43, 27 April 2015
 
 
 
 
 

My entire history/user page/talk page has vanished

I have been a wiki editor since 2006. I've made over 12,000 edits. This morning my talk page and user pages have vanished, and my edits have been reset to zero. What on earth happened?

Czolgolz (talk)14:37, 3 May 2015

On which language edition ? And is this about the account User:Czolgolz ?

TheDJ (Not WMF) (talkcontribs)16:54, 3 May 2015

Hmm...not sure what happened, but it's fixed now. Thanks!

Czolgolz (talk)21:09, 3 May 2015

Your SUL account currently shows around 11.000 edits with by far the most of them in enWP. The last SUL changes have been done in 2012 and 2013. No recent changes (e.g. as of today).

88.130.122.16821:15, 3 May 2015
 
 
 

Maintenance script and metadata.ini

Hello, this is me again, I am writing because I am still struggling with running maintenance scripts. I am working on MediaWiki 1.24.2, PhP 5.3.8, and MySqQL 5.5.21. After having been assaulted by SPAM in the past days, I am trying to clear a huge list of bots by using deleteArchivedRevisions and removeUnusedAccounts. I've been trying to do this both from web broswer (with the extensions Maintenance) and from terminal. However, in the former I can just get a list of revisions and accounts to be removed and I can't activate the --delete function (I guess it's normal this way), in the latter I get the mysterious:

parse error, expecting `T_OLD_FUNCTION' or `T_FUNCTION' or `T_VAR' or `'} in /home/etc etc/maintenance/removeUnusedAccounts.php on line 34

I don't have a clue on what it is actually expecting as I don't believe that I should modify that file in the maintenance. Can anybody suggest anything?

Tanonero (talk)15:05, 2 May 2015

I believe that I can overcome this problem by adding the related option to the metadata.ini in the Maintenance folder. However, I am trying different combinations but I can't get it done. Does somebody know how to add the parameter --delete of deleteArchivedRevisions.php to

[deleteArchivedRevisions]
enabled = 1

and the parameter --delete of removeUnusedAccounts.php to

[removeUnusedAccounts]
enabled = 1

?

Tanonero (talk)18:25, 2 May 2015

First, I would not try to run this strange extension, which almost certainly is a security risk. But I would try making the shell work correctly.

PHP versions used by Apache and on the shell can be different - and often are. Which PHP version do you have on the shell? You can check that by just calling PHP with the parameter -v and nothing else. I guess you are currently using an old version on the shell, which is the reason for this error you got.

88.130.101.23821:42, 2 May 2015

Yes, you're right, by executing

php -v

I get 4.3.4 as PhP version, whereas the PhP of my server is 5.3.8. Is there anything I can to do upgrade that version so as to execute the scripts correctly?

Tanonero (talk)20:37, 3 May 2015

Newer versions of PHP can be available under another name, e.g. as php53, php55, php56 or so. If they are and if so under which name, is determined by the setup of the server. Your host will know that!

88.130.122.16820:55, 3 May 2015
 
 
 
 

Mediawiki on Debian Jessie shows blank pages

Edited by another user.
Last edit: 20:08, 3 May 2015

Just updated my old debian Weezy that runs on 1.23 wiki/visualeditor with php 5.4.39 and mysql 5.5.43 to the new debian Jessie, all update was done right, but, now the pages are blank. But, if i launch the editor, content is already here... hurra... but if i previsualize or other stuffs, the page remains blank...

So, i decide to follow an advice given here http://www.mediawiki.org/wiki/Manual:Errors_and_symptoms#All_pages_have_no_content.2C_but_when_editing_a_page_the_wiki_text_is_there and i update my wiki to the 1.24.2 with the visualeditor associated to the 1.24. After doing it all, i run the database update and.... the pages are empty now... Adding the error report it shows me the error below :

Warning: spl_object_hash() expects parameter 1 to be object, null given in /var/www/mediawiki-1.24.2/mediawiki-1.24.2/includes/Title.php on line 184
Catchable fatal error: Argument 1 passed to MediaWikiTitleCodec::__construct() must be an instance of Language, null given, called in /var/www/mediawiki-1.24.2/mediawiki-1.24.2/includes/Title.php on line 195 and defined in /var/www/mediawiki-1.24.2/mediawiki-1.24.2/includes/title/MediaWikiTitleCodec.php on line 567

Any suggestions ?

2.14.170.3523:44, 2 May 2015

Did you upgraded all the extensions as well? Try disabling all extensions to see if one of them is causing the problem.

Ciencia Al Poder (talk)20:10, 3 May 2015
 

[RESOLVED] Resource Loader adds CSS in style tag not load.php?

I'm not sure if I'm using the Ressource Loader correctly.

I have 4 KB worth of CSS for my Special:Search. Since it's only used on that page I don't want to add the CSS to MediaWiki:Common.css.

How can I add it to RL via an extension?

That's my setup:

 $wgResourceModules['MyExt.onSpecialSearch'] = array(
        'styles' => 'modules/MyExt.onSpecialSearch.css',
        'localBasePath' => __DIR__,
        'remoteExtPath' => '/',
 );
 
 //  onBeforePageDisplay ...
 
 if( $title == "Special:Search" ) {
   $out->addModules( 'MyExt.onSpecialSearch' );
 }

This way my CSS is added as a dynamic style tag in the DOM so my CSS rules only apply after the page is painted already with the default CSS.

That's annoying so maybe I do it wrong. I expected the CSS to be added to one of the top load.php link tags.

Subfader (talk)16:15, 2 May 2015

If I understand your question correctly, the problem is not to get the module included on only and exactly Special:Search. That is working correctly. Instead the problem is the order in which your module gets added (after other modules).

According to Manual:$wgResourceModules you can define a key position => top for your module. Maybe you will then have to give your styles a high specificity so that they are not overwritten by those styles, which are loaded after that, but as far as I understand it, this should basically make your styles apply first and only.

88.130.101.23821:50, 2 May 2015
 

Looking at the documentation, I'd say you should use addModuleStyles instead of addModules

Ciencia Al Poder (talk)22:52, 2 May 2015

Exactly. All CSS that do not belong to JS modules should be loaded using addModuleStyles

TheDJ (Not WMF) (talkcontribs)10:24, 3 May 2015

Thanks, now I understand! Will use addModuleStyles for CSS only additions. It adds the code to load.php as expected :)

Subfader (talk)13:17, 3 May 2015
 
 
 

[RESOLVED] compressOld.php

The command is php compressOld.php <database> [options...]

Manual:CompressOld.php#Usage

I want to compress all edits prior to December 31, 2014

So in the [[options...] what would be my option parameter?

Kuhitkuhit (talk)19:51, 2 May 2015

The script has the option -e, which defines the end date. Reading the source code, the script expects the value to be an integer with a length of 14 signs. This integer is then used to compare it against the value from rev_timestamp in your database. This means that you have to provide the date in the format, which is specified on Manual:Timestamp.

I have updated Manual:CompressOld.php to make that more clear.

88.130.101.23821:05, 2 May 2015

Thank you.

24.182.18.12718:06, 3 May 2015
 
 

Make the API use memcache?

Edited by 0 users.
Last edit: 12:49, 23 March 2015

Is it possible to let the API make use of memcache?

I'd like to add a ~500 ms query on every article so memcache would come in handy.

93.184.128.2612:49, 23 March 2015

The api already uses memcached if installed in appropriate places.

Sounds more like you want to use varnish/squid to cache full responses.

Bawolff (talk)17:41, 26 March 2015

Does it? I see $wgMemc only used in ApiMain.php for makeHelpMsg().

Can I request that on phabricator?

Subfader (talk)17:05, 3 April 2015

Subfader: I'm not sure I understand.

Most of the API is (relatively) cheap sql queries with no clear way to do appropriate expiration. Thus memcached is not usually used, although I believe there is a couple places where the API calls into other parts of MW which use memcached.

If you want to make a somewhat repetitive api query, and don't care if the result is mildly out of date, set the maxage and smaxage parameters when making the api request, to how many seconds you want to cache. The maxage controls how long the user caches the api request, where smaxage (if you have varnish or squid installed) controls how long to cache for everyone [Assuming the request isn't something private, like retrieving a deleted page, or making an edit].

For example, if you do https://commons.wikimedia.org/w/api.php?action=query&titles=File:Vincent_Willem_van_Gogh_038.jpg&prop=imageinfo&iiprop=extmetadata&smaxage=600

The first person to make that request will take the normal amount of time, however the response will be saved for up to 600 seconds, and anyone else who visits that exact url in the next 600 seconds will get the saved version, much faster, but potentially outdated.

Bawolff (talk)05:45, 23 April 2015

Thanks for the info, Bawolff. I don't use vanish or squid.

Subfader (talk)16:35, 3 May 2015
 
 
 
 

Trying to upload a doc file gives error: "Cannot upload this file because Internet Explorer would detect it as "application/msword", which is a disallowed and potentially dangerous file type."

Using v 1.17.0. Have successfully uploaded doc files in earlier version of mediawiki, upgraded without changing any settings and now is not working.

Any clues what can be wrong?

Rgs,

/N

Nkq18:48, 23 August 2011

The problem is that the mime type for Word Documents is in the "Blacklisted mime types" by default

If its just Word documents you want to allow, then add the following to your LocalSettings.php . If there is anything else you want to allow, just remove it from the array :

$wgMimeTypeBlacklist = array ( "text/html", "text/javascript", "text/x-javascript", "application/x-shellscript", "application/x-php", "text/x-php", "text/x-python", "text/x-perl", "text/x-bash", "text/x-sh", "text/x-csh", "text/scriptlet", "application/x-msdownload", "application/x-msmetafile", "application/x-opc+zip", "application/vnd.ms-powerpoint", "application/vnd.msexcel" );

  1. The $wgMimeTypeBlacklist is the same as defined by default, except I removed
  2. "application/msword" to allow word docs
ReadersDigestUK13:25, 18 November 2011

Many thanks. I can now upload docx files. All I need to do now is work out how to open word docx files in the browser. I can work round this by doing what I used to do with pdf files, and that is click on properties and copy the url in there. Once again many thanks.

Ron Barker (talk)12:25, 3 May 2015
 

Just as a note, MS word documents can be dangerous to upload due to the faking-it-as-a-java-applet vulnerability (could allow someone to do evil things to your wiki), which is why they're on the blacklist. In 1.18 we started scanning such files for such issues better, so as of 1.18 MS word files are no longer blacklisted.

Bawolff14:32, 18 November 2011

Many thanks, I would love to upgrade if I could, but it is far too complicated for me to do that. The explanations on here and elsewhere pre-supposes that anyone wishing to upgrade know all about MediaWiki and php. I don't. I did manage to download and install MediaWiki and Wamp onto my pc, but I had nothing to loose if anything went wrong. The difference now is that by attempting to upgrade I could loose my wiki, and I cannot contemplate that,

Kind regards and thank you for the warning.

Ron Barker (talk)12:34, 3 May 2015
 
 
First page
First page
Previous page
Previous page
Last page
Last page