Project:Support desk

Jump to: navigation, search

About this discussion

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".


By clicking "Add topic", you agree to our Terms of Use and agree to irrevocably release your text under the CC BY-SA 3.0 License and GFDL
2001:780:0:B:AC5B:653:8B79:D6D7 (talkcontribs)

Hello!

I have a running MediaWiki with the global $wgLanguageCode = "de". When a user changes his language, to lets say 'en', the user interface is still in 'de'. How can that be?

The database also has the changed setting 'en' set. The query I use is

SELECT up_user as `User`, convert(up_value using UTF8) as `Language` FROM wiki.user_properties where up_property = 'language';

So I guess its a bug?

2001:780:0:B:AC5B:653:8B79:D6D7 (talkcontribs)

I'm running MediaWiki 1.24.2

88.130.87.34 (talkcontribs)

Hi!

What do you see when you later visit the user preferences again? Does it then still say "Language: German"?

You might try running a TRUNCATE query on the tables l10n_cache and objectcache in your database - this should clear cached texts and force MediaWiki to take the texts from the actual source files.

Reply to "User language is not honored"
119.81.6.19 (talkcontribs)

Hi Team,

Am trying to upload files into mediaWiki(i installed mediaWiki in Bluemix), Am not able to find the upload file option under tolls section. Under special pages section I found an option to import/export files, am able to successfully export the pages from mediawiki, but facing issue while uploading the same file(error: Data at the root level is invalid. Line 1, position 1).

Please help.

Thanks,

Sampath

88.130.87.34 (talkcontribs)

If I had to guess I would say: The upload file link only appears, if file upload is a) generally enabled and if b) the user has permission to actually upload files.

For a complete guide on how to configure file uploads, see Manual:Configuring file uploads!

Reply to "Upload file Option in media wiki"
194.11.254.132 (talkcontribs)

I have problem with search result in a mediawiki. In the result of search I'm getting first image and then later pages. It is possible to change search setting? I would like to have first pages and then images. If there is not possible to change setting. Could you please tell me how I can turn off the image search?

Thank you in advance!

88.130.87.34 (talkcontribs)

I do not know how you can adjust that images do no longer appear as first results. Maybe someone else does? ...

In the meantime you can at least change the value of $wgNamespacesToBeSearchedDefault and take the namespace with the images out of the default. Basically that means: Set the value of NS_FILE to false.

Reply to "Search Problem"

Inserting Internal & external Video / Audio into page?

1
AmazingTrans (talkcontribs)

What is the best way to insert uploaded mp3 / avi / etc or youtube video on a wikipage?

Reply to "Inserting Internal & external Video / Audio into page?"

Updating Russian wiki: page titles won't resolve

1
This comment was hidden by 185.5.152.240 (history)
Reply to "Updating Russian wiki: page titles won't resolve"

Problem using [[Extension:Interwiki]] with MW 1.18

7
Lieutenant S. Reznov (talkcontribs)

When I try to add or edit prefixes, it gives an error.

Fatal error: Call to undefined method Xml::hidden() in /home/content/01/7537801/html/EN-40K Sturmkrieg/extensions/Interwiki/Interwiki_body.php on line 165

I'm using the 1.17 version, which on the extension page is the same for 1.18.

This post was posted by Lieutenant S. Reznov, but signed as Inquisitor Ehrenstein.

Krinkle (talkcontribs)

Are you really using the 1.17 version? It says on Extension:Interwiki to use the extension as of r92408 for MediaWiki 1.17 or MediaWiki 1.18.

In the extension code at r92408, there is no call to Xml::hidden in Interwiki_body.php on line 165. About 5 versions before that revision it was replaced with Html::hidden.

So it looks like you're not using "the 1.17/1.18 version".

Krinkle (talkcontribs)

I've added direct snapshot download links to the correct branches of the extension on Extension:Interwiki.

Lieutenant S. Reznov (talkcontribs)

Ok. I download the version that I have on en.sturmkrieg.com which is 1.17, and it works fine there, but it must not be the specific extension for that version of MediaWiki.

Thanks, I'll download the 1.18 version then.

This post was posted by Lieutenant S. Reznov, but signed as Inquisitor Ehrenstein.

Lieutenant S. Reznov (talkcontribs)

Thanks, it worked.

This post was posted by Lieutenant S. Reznov, but signed as Inquisitor Ehrenstein.

Lieutenant S. Reznov (talkcontribs)

http://en40k.sturmkrieg.com/Space_Marines

The interwiki links in the fanfiction section don't seem to show up.

This post was posted by Lieutenant S. Reznov, but signed as Inquisitor Ehrenstein.

Lieutenant S. Reznov (talkcontribs)

It thinks it's a language version.

This post was posted by Lieutenant S. Reznov, but signed as Inquisitor Ehrenstein.

Reply to "Problem using [[Extension:Interwiki]] with MW 1.18"

Adress confirmation does not work anymore with MW 1.20.1

11
Tido~mediawikiwiki (talkcontribs)

Yesterday I have updated my Wiki from 1.15.x to the new version 1.20.1

-> Everything works fine except the e-mail adress confirmation. If I register myself as a new user I get a e-mail with a confirmation link, but if I click on this link I get the following error message:

"Ungültiger Bestätigungscode. Möglicherweise ist der Bestätigungszeitraum verstrichen. Versuche bitte, die Bestätigung zu wiederholen." (Translation: Confirmation code not valid. Timeout - please try to repeat the confirmation.")

The PHP Version is 5.3.8.

Any thoughts about this behavior?

This post was posted by Tido~mediawikiwiki, but signed as Tido.

Carchaias (talkcontribs)

It is the same on my new 1.20.1. php is 5.3.16. http://blechschaden.bplaced.net/wiki/index.php?title=Spezial:Version

Carchaias (talkcontribs)

That was filed as a bug on:

https://bugzilla.wikimedia.org/show_bug.cgi?id=42592

Ciencia Al Poder (talkcontribs)

The exact translation should be Invalid confirmation code. The code may have expired. (Invalid confirmation code. The code may have expired.) which is MediaWiki:Confirmemail invalid.

Carchaias: Are you sure it's the same bug?

Tido~mediawikiwiki (talkcontribs)

@Ciencia Al Poder: Applying the patch mentioned here fixed the problem.

@Carchaias: Thanks a lot for the link which showed the way to the solution!

This post was posted by Tido~mediawikiwiki, but signed as Tido.

80.153.17.59 (talkcontribs)

Thanks alot @Carchaias & Tido: The patch did the trick :)

Ciencia Al Poder (talkcontribs)

Fixed in MediaWiki 1.20.2

150.244.85.59 (talkcontribs)

I have mediawiki 1.21.1, and after try this patch and set timezone in my php.ini files as here explained, I continue getting the message "Invalid confirmation code. The code may have expired." Could I try something else? Thank you.

I have these versions: MediaWiki 1.21.1 PHP 5.4.4-14 (apache2handler) SQLite 3.7.13 with full-text search support

Ciencia Al Poder (talkcontribs)

View your user table, and look at the user_email_token_expires field and see if its value makes sense. It should be a date in the form of year (4) month (2) day (2) hour (2) minute (2) second (2). That's the date when the confirmation code expires,

150.244.85.59 (talkcontribs)

Thanks a lot @Ciencia Al Poder: In my case the "new user" is not being inserted in the user table, so I cannot check the user_email_token_expires field. I have checked (just in case) the sqlite file permissions, but everything is correct.

What else could it be happening?

Ciencia Al Poder (talkcontribs)

The only thing I can advise is to enable debug while creating a new user to see if the debug log gives any error when creating the user, and/or report a bug on bugzilla.

Reply to "Adress confirmation does not work anymore with MW 1.20.1"

403 Forbidden, when viewing the downloaded file

3
Nicolayka (talkcontribs)

If you view the downloaded file on a link - http://site1111111.ru/index.php/File:Glitterhelm_Caverns.png

Error "403 Forbidden".

As a result, I can not rename the downloaded file, delete it, or just view

What to do? Thank you.

Nicolayka (talkcontribs)

up

Ciencia Al Poder (talkcontribs)

Your site doesn't seem to be accessible (DNS is not known).

But anyway, check your server's error log. And see Manual:How to debug. First of all you should make sure where the error comes from: from MediaWiki/PHP or from the webserver. The problem is most likely the web server, that has some misconfiguration.

If enabling MediaWiki debug it doesn't generate any MediaWiki debug logs, then the problem is the server configuration.

Reply to "403 Forbidden, when viewing the downloaded file"

Is it possible to share templates between multiple wiki's?

6
Dries (talkcontribs)

We have 3 kind of users and we want to make a wiki for every kind. We now have a lot of templates and images in one wiki. Is it possible to set up other wiki's (I know that the upload folder is sharable) which can make use of the other templates? That way we don't have to make every template 3 times.

Thanks for any information!

Allen4names (talkcontribs)

See Manual:$wgEnableScaryTranscluding.

Doug (talkcontribs)

With ScaryTransclusion, you can actually share templates from any MediaWiki wiki, including the WMF wikis. I have used this on a private wiki experimentally with good results. It takes some work thought figure out what happens with various combinations of substitution and raw.

Ciencia Al Poder (talkcontribs)

Another option is use Special:Export on the source wiki and Special:Import on the target wiki where you want the templates imported.

Doug (talkcontribs)

This option will not share the templates, it simply copies them.

Dries (talkcontribs)

I thought of that too as a solution if nothing else works. But, thanks to Doug and Allen4names I hope everything will work out.

Thanks guys!

Reply to "Is it possible to share templates between multiple wiki's?"
DMR (talkcontribs)

I recently downgraded my mediawiki from 1.19 to 1.16 to establish a working environment for an outdated extension. Since I'm no expert in all this database/php stuff I thought it would be easiest to just download the entire wiki and update it on my local machine. Here is what I did:

  • downloaded the wiki, copied it to a backup folder
  • downloaded Cygwin terminal since I'm on a windows machine
  • downgraded the wiki via Cygwin terminal
  • skipped the database update since I thought the database needs no changings
  • installed the extension
  • reuploaded the 1.16 wiki with the extension


While the regular accessing functions of the Wiki work just fine, I find myself unable to create new users or admit changes in the personal settings. When attempting, I receive various database errors. After a short search in Google it looks like that the databse isn't working properly with the Wiki due to the un-updated database. Now I wanted to update it and the manual told me to run the command "php update.php" in the maintenance folder. But how do I do that? Cygwin does not know the command "php". Do I have to do this on the server directly? If so, how to do that? I connect to the server via FileZilla which does not provide a command line.

Thanks in advance

88.130.64.45 (talkcontribs)

Yes, you have to execute the php command directly on the server. If you do not have command line access to the server, you cannot do that. In that case you could try using your browser to use the web updater in mw-config/index.php instead.

However, I would not recommend this. Downgrades generally are not supported.

There are several reasons. E.g. while doing an upgrade changes to the database are done, e.g. content is moved from one column to another or content in a column is modified in a way. However, there are no scripts in older releases, which could undo these changes. So the upgraded DB will not work properly with an older version of MediaWiki. If you want to downgrade, you should do that by taking an old backup, in which you have only used the old version. Using an old MediaWiki version with a newer database will break things (just like happened in your case). Another problem in which you are likely to run after having done a downgrade is that a new upgrate (to in your case MediaWiki 1.19) will not work correctly: While upgrading, the updater checks, if some columns in the DB are there. If they are not, some update routine is executed. This routine can also populate columns with content or change existing content. If however you have a DB, which was already updated some time before, but then used with an older version of MediaWiki, these updates will no longer take place and you will end up with missing/wrong content, which was inserted (or not inserted) by the old MediaWiki version, which you downgraded to.

Bottomline is: Take a database backup from before your downgrade and it will work with 1.19 or take an older database backup from MediaWiki 1.16 and it will work with 1.16. Everything else might -at least in the long run- leave you with a broken system.

DMR (talkcontribs)

Thank you for the quick response! Well, this ain't any good news for my wiki. We started with 1.19 so there is no old database backup. Is it possible to start a new wiki on 1.16 with a new database and all and just import the written articles, categories and uploaded files?

To do this manually would be a huge pain in the butt.

Ciencia Al Poder (talkcontribs)

You can try Manual:Backing up a wiki#XML dump, but be aware that this will only get the content of pages. All user accounts will be gone.

You should really consider if that extension is worth to do this.

88.130.80.170 (talkcontribs)

Whatever you do now: Since you don't have an unbroken backup, you have to live with the fact that you possibly have -maybe partly- broken records for some pages/users.

Apart from Ciencia's idea another option would be to upgrade back to 1.19 again and to continue using 1.19. All user accounts and files and so on will then still be there.

Both options are not ideal. But given the available possibilities I would upgrade to 1.19 as soon as possible. I guess you one day want to do further updates anyway (because of security wholes, or extensions, which are only compatible with newer versions or whatever). The longer you continue working with 1.16 while you can no longer use the Update Wizard for updating to 1.19, the more things might get broken.

Afterwards make this old extension compatible with 1.19. That is way better than messing up your wiki even more. ;-)

DMR (talkcontribs)

Appreciate your input guys. I do have unbroken backups though, I could easily return to 1.19 back-up wise. The other option that you mentioned (@88.130.80.170) to just upgrade my current 1.16 wiki to 1.19 would of course leave the extension broken. I don't have the skill to make an old extension compatible with newer versions.


What Ciencia Al Poder mentioned sounds like something worth considering. At this very moment the wiki holds about 5 to 6 users. All the work is in the articles written and files uploaded and there's where the priority lies.


My wiki is for students of my university to share protocols, scripts and exam questions with another so that we can prepare properly for upcoming tests. The problem with that though is that our teachers went through the old wiki and found the old questions and therefore replaced theirs with newer questions. To prevent this from happening again I installed a feature to restrict certain pages. Now this extension was only supported till 1.17. I searched for other similar extensions but failed to find any that are up to date.
Gotta have to think about how to proceed.

88.130.80.170 (talkcontribs)

Are you sure that you need an extension? MediaWiki knows which user group a visitor is in (e.g. users, who are not logged in are in the user groups "*" and "user" I think). And MediaWiki allows to set up permissions based on these groups (can be done in LocalSettings.php). Tell me, if I am wrong, but is it not possible to set the right "view" for the group "*" to false? Doesn't that take away the possibility to view pages?

When you have people who are trusted (you said you only have a few accounts), then you could add another group to their account and give this group the right "view".

66.30.96.212 (talkcontribs)
66.30.96.212 (talkcontribs)
Reply to "How to run the update script"