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

Javascript not working at all

Basically no javascript is working on my wiki, and what works and doesn't work seem to change almost daily. At one point everything worked and after that point I didn't change anything. Then things broke one at a time. Sometimes even the patrol AJAX trick where it doesn't open a new window isn't working. I really have no idea what's going on or how to fix it. I've done all the usual things, tried clearing my cache, did a hard refresh, used different browsers, etc. Nothing! The only lead I have to go on is I've used FireBug and it's returned an Error: Unknown Dependency: JSON on all pages. I'm not sure what this means however.

Link to wiki common.js

  • Mediawiki: 1.23.5
  • PHP: 5.6.7-1~dotdeb.2 (fpm-fcgi)
  • MySQL 5.6.21-1~dotdeb.1

If there's any other info you need let me know and I'll get it

Psycho Robot (talk)22:06, 5 May 2015

The CentralNotice extension seems to require a "json" module that's not present on your wiki. Since your wiki doesn't seem to be part of a wiki farm, it probably doesn't make sense to have that extension, so simply disable it.

Ciencia Al Poder (talk)01:48, 6 May 2015

Yes, that was the problem. Thank you for helping me track that down. I feel compelled to point out that I didn't install that, it was someone else, I swear! Everything I even think about installing works perfectly all the time.

Psycho Robot (talk)03:30, 6 May 2015
 
 

How to make all pages as protected?

Hello, I want to make possible only commenting in my Wiki. How to make it easely?

1. Make all the current and future pages as Protected. And turn on the Commenting at all. I need help to make all the already published pages as Protected. Can you advice me?

2. Any other way to prevent any editing by common Users, allowed only commenting?

Thank you!

PrometheusAla (talk)18:09, 5 May 2015

Restrict editing to sysops, allow for talk NS using Extension:Lockdown. Didn't test it though.

Subfader (talk)19:03, 5 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

This is the command line that was used:

php compressOld.php -e 20141231235959

Did this command in effect compress all the edits prior to Dec. 31, 2014?

Kuhitkuhit (talk)16:18, 5 May 2015
 
 
 
 
 

[RESOLVED] 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

Yes, the web team allowed me a shell access to a different system and I managed to run the scripts! Deleting 15,100 bots at once was amazing. Thank you very much for your help. I am marking this discussion as RESOLVED.

Tanonero (talk)13:26, 5 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

I put following line into localsettings: $wgShowEXIF = false;

It seems to be ok now.

Elektronix 70 (talk)12:57, 5 May 2015
 
 

[RESOLVED] Database error: "1054: Unknown column 'rev_sha1' in 'field list' (localhost)"

I have wiki on my old laptop (MediaWiki:1.17.0 MySQL:5.5.21 PHP:5.3.18 phpMyAdmin: 3.5.3). Now I've decided to move it to my new laptop (MediaWiki:1.20.3 MySQL:5.5.29 PHP:5.4.12 phpMyAdmin:3.5.7). By phpMyAdmin interface i have exported the database on my old laptop and in the same way imported it on my new laptop. After setting the user account and restarting the apache and mysql services, while trying to access my wiki from browser i receive the following error message:

A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was: (SQL query hidden) from within function "Revision::fetchFromConds". Database returned error "1054: Unknown column 'rev_sha1' in 'field list' (localhost)".

Am I missing smth? Anyway I do appreciate the real help to solve the issue.

NB. At LocalSettings.php on my old laptop there are was a line $wgDBprefix = "mdw_"; which I copied to LocalSettings.php on new laptop.

Axuwon (talk)02:30, 22 March 2013

You're likely missing running update.php

Ciencia Al Poder (talk)11:10, 22 March 2013

Running the update.php do solved the issue!

Axuwon (talk)06:59, 25 March 2013

I'm running update.php to update mediawiki 1.15.1 to 1.21.1 on my laptop. I changed MySQL user to root at Localhost.php.

During running the update.php, there is a error 1054: unknown colum 'rev_sha1' in 'field list'(localhost).

The step where error happened was "batch conversion of user_options: A database query syntax error has occurred.

I appreciate it if anybody could help me to solve this issue.

115.91.55.21914:49, 9 June 2013

Have a look at the threads on this very page. There already were three or four concerning this issue and I think they had a solution.

88.130.73.13715:26, 9 June 2013
 

Yes, refer to Thread:Project:Support desk/upgrade problems: 1.11 -- 1.21

Ciencia Al Poder (talk)17:34, 9 June 2013

Thank you...I had the same problem and this helped me.


Thank you,

168.167.134.10112:00, 5 May 2015
 
 
 
 
 

How to Upgrade MediaWiki 1.12 to 1.24

Currently, we are using MediaWiki 1.12 and wanted to upgrade it to the latest stable version i.e. MediaWiki 1.24. The associated PHP version is 5.1.6-39 and MYSQL version is 5.0.77-4. Please provide me the steps which needs to follow. The development environment is WINDOWs and our PROD is linux based. Kindly help me on this regards.

69.174.58.2006:25, 9 April 2015

First, you should upgrade your webserver system. PHP 5.1.6 is really old and the support for it was stopped in MediaWiki 1.16 (which is stopped, too, and may contain security holes like your actual version), see Compatibility. The support for this php version was already stopped by php, too, see [1] (eol 8 years ago now: http://php.net/eol.php). After this, you can follow Manual:Upgrade to upgrade your installation, but read the complete document first before you start your work, there are important notices about how to upgrade from an old version of MediaWiki. And the most important thing: Backups, backups, backups :)

Florianschmidtwelzow (talk)06:43, 9 April 2015

Hi,

Can we do fresh installation of MediaWiki 1.24 on server and then move the existing contents from MediaWiki 1.12 to 1.24 by dumping the data from existing MYSQL to newer version.

69.174.58.2007:20, 9 April 2015

What do you mean with dumping? Maybe i would be possible, but it would take more time and work to do it and i wouldn't do that :)

Florianschmidtwelzow (talk)07:28, 9 April 2015

Hi,

So if I understand your suggestion correctly, you are saying that 1- upgrade the existing PHP to the compatible version of PHP (used in MediaWiki 1.24). 2 - Then follow the manual upgrade to upgrade the existing MediaWiki version to never version.

question -by manual upgrade, would it upgrade the MYSQL too ? or we need to upgrade it 1st before upgrading the MediaWiki.

69.174.58.2007:48, 9 April 2015

Hi Florian,

Please reply on my above understanding.

69.174.58.2009:23, 9 April 2015
 
 
 
 

Hi,

It is bit difficult from Mw 1.12 to Mw 1.23, recently we upgraded from Mw1.12 to Mw1.21 , faced lot of issues with skins,tables,and customized extensions,

1.Do you customized any predefined mediawiki tables?. 2.you developed your own skin? 3.list of extension also post here.

then i will assist you in this upgrade.

Rajeshrjsh (talk)05:45, 22 April 2015

Hi Rajesh,

We did not customize any said features, so I hope it would be a smooth upgrade. Will let you know once I start upgrading it on my dev machine, but before that I wanted to upgrade the existing XAMPP. Very-very thank you for proving me assistance.

Naimish88 (talk)09:45, 23 April 2015
 
 

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

When you install an extension, you add it to LocalSettings.php.

However, for some extensions you also have to update the database. This can either be done via the shell (which is recommended) or via the web updater in mw-config/. And in order to run the web updater you will have to open mw-config/index.php with your web browser. As far as I understand, this is the point, which throws the error 403, which it should not do.

88.130.126.7011:18, 5 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

thanks :]

146.175.202.3009:22, 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
 
 
 
 
 

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
 

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