Project:Support desk/Flow/2013/12

This page is an archive.

Please ask questions on the current support desk.

[Solved] Running into problems even before installing the wiki

Edit: Please ignore this, it was a problem with my host which is solved now :)

I just downloaded and placed all MediaWiki's 1.21.3 into my web server. When visiting the wiki's main site, it tells me it can't find LocalSettings.php and to set up the wiki. So I click the setup link but I'm returned with this: http://i.imgur.com/HEyZm8N.png

Any suggestions? Wolf3825 (talk) 06:30, 1 December 2013 (UTC)

User agent

Can the user agent of the browser shown on a page? We would like to show the user agent on the German Wikipedia article about user agents.

Special:Version: MediaWiki 1.23wmf4 (49ec115), PHP 5.3.10-1ubuntu3.8+wmf2 (apache2handler), MySQL 5.5.34-MariaDB-1~precise-log Doc z (talk) 12:43, 1 December 2013 (UTC)

Hi!

That would only work, if for each page hit, the page would be rendered again, including the User Agent. I don't think that's possible: You would have to turn off caches (which I guess you can't do) and you would need code, which displays the user's user agent. The latter would be easy to do with PHP, but I don't think you get an admin to add something like that on an official Wikipedia site. 88.130.92.214 13:01, 1 December 2013 (UTC)

You would have to turn off caches - indeed, that probably impossible.

Thanks. Doc z (talk) 13:03, 1 December 2013 (UTC)

Yepp, that would have a performance impact, which surely is not wanted. I mean you can also add a link in the "Weblinks" section pointing to a page, which displays the user agent. Apart from that it would be an interesting question whether it would be possible to render a whole page cached except a certain part of it, which is computed newly each time. I know of content management systems, which can do exactly that, but it requires quite some code and some logic inside the system (different caches, markers for the areas to be post processed and the post precessing itself). I have not heard of such a functionality when it comes to MediaWiki processing the content itself. However, I still think it is not doable with a reasonable amount of effort. :-( 88.130.92.214 13:58, 1 December 2013 (UTC)

Yeah, we are not going to disable cache on any Wikimedia site (for performance reasons). [There is support for doing this in MediaWiki, but it doesn't really get used on Wikimedia sites]

If you really wanted to do this, you could maybe use javascript to dynamically add the user-agent to the page. That skips all the caching issues. Bawolff (talk) 19:34, 1 December 2013 (UTC)

Антикаптча- заказывай/зарабатывай

I'm getting this message with 1.21.1

Fatal error: Call to a member function addMessage() on a non-object in PATH/wiki/extensions/EmbedVideo.php on line 84 When I comment the line out it moves to another line with addMessage() or to another file with addMessage().

Anyone have advise on how to get my wiki back up and running? Mattvn (talk) 00:25, 2 December 2013 (UTC)

Hi!

You can comment the line in LocalSettings.php, which includes/requires EmbedVideo.php. This will deactivate the extension, but at least your wiki will show up again.

According to Extension:EmbedVideo this extension is not (yet) compatible with MediaWiki 1.21. This has also been reported in the issue tracker, but the developer has not yet fixed it. The file EmbedVideo.php, which I found here does not have 84 lines, so I cannot say, what causes the error for you. 88.130.115.127 01:24, 2 December 2013 (UTC)

Thanks for that. I later got the same error with google sitemaps extension so commented that out that out too. Then I got a response saying maybe I didn't run the updater... so when I tried, I selected the language, hit submit then get the following error at the existing wiki stage:

Fatal error: Call to a member function Parse() on a non-object in PATH/wiki/ipbwiki_interface.php on line 1191

Seems others have had this issue when I search the web but I can't find the solution. Any help appreciated. Mattvn (talk) 02:08, 2 December 2013 (UTC)

It would help to have a stack trace for that error. That will show what was called before this error happened. Configure PHP so that it outputs a stacktrace or writes it to error log and then produce the error again! 88.130.115.127 03:50, 2 December 2013 (UTC)

Since it seems you didn't read the upgrading manual before, it will be a good idea to do that now, and follow the steps provided to see if you missed something or did something in the wrong way (unpacking old files over new ones, maybe?) Ciencia Al Poder (talk) 11:22, 28 January 2015 (UTC)

[RESOLVED] how to empty a too large watchlist ?

Hello,

Because of a bad configuration of my bot account on fr.wikipedia.org (it's now resolved) I have added every pages I edited during some months. Now its watchlist contains 473,894 items ! Of course, I don't watch these articles, and thats a problem when I use Pywikipedia because it sometimes refresh its local list.

I'd like to know if there is a way to empty this watchlist. Of course https://fr.wikipedia.org/wiki/Special:EditWatchlist/raw don't work...

If I can't do it myself, when should I fill a request to ask an operator to do it directly on the database ?

Regards Hercule (talk) 09:38, 2 December 2013 (UTC)

Hi!

Can't you use the API to first get a few watched pages and then remove them from your watchlist? Repeat until all pages are gone.

The other option would be to ask someone with direct database access, if he can run a MySQL query, which removes all your watched rows from the DB. This query might look something like

DELETE FROM watchlist WHERE `wl_user` = <user_id-of-your-bot>;

The user id of your bot seems to be "346772", see here: http://fr.wikipedia.org/w/api.php?action=query&list=allusers&aufrom=HerculeBot&aulimit=1

I think the direct MySQL query will be much faster. 88.130.83.17 16:43, 3 December 2013 (UTC)

The API recursive call would be the very last option.

Where can I "ask someone with direct database access" ? Do I need to create a bug ? 213.190.91.21 08:48, 4 December 2013 (UTC)

I don't know that. If I were you I would ask on the IRC channel "mediawiki" on Freenode. There usually are some of the guys, who in the end are the ones who fix that kind of problem. They should be able to help you with that. 88.130.103.56 13:02, 4 December 2013 (UTC)

Unfortunatly I can't use IRC... Hercule (talk) 13:36, 4 December 2013 (UTC)

I was so kind to ask on IRC. Seems like the correct channel for such tech questions is #wikimedia-tech or #wikimedia-operations. MaxSem is currently having a look at it... 88.130.103.56 14:31, 4 December 2013 (UTC)

Thank you very much Hercule (talk) 14:45, 4 December 2013 (UTC)

MaxSem says the query finished. The list should be empty again now. 88.130.103.56 14:50, 4 December 2013 (UTC)

It's empty. Thank you and thanks to him. Hercule (talk) 14:52, 4 December 2013 (UTC)

:-) 88.130.103.56 15:00, 4 December 2013 (UTC)

possibility do direct on Wikipedia pages

I am the owner of www.forumekspert.pl on the main page we are prsent interested facts on daily basis. Is itpossible to add hyperlink that would transfer to wikipedia file about given event/person? 212.109.148.29 (talk) 10:51, 2 December 2013 (UTC)

Hi!

You can add links to a wiki page with this syntax: [http://www.example.org Link to example.org].

Another option would be to insert it as

<a href="http://www.example.org">Link to example.org</a>

, but that is nt recommended. 88.130.115.127 13:56, 2 December 2013 (UTC)

You can also add interwiki links to Wikipedia so you can use [[wikipedia:Articlename|Articlename]] to link to your preferred language version of Wikipedia (for example, pl.wikipedia.org)

Example SQL sentence to insert a row in the interwiki table to link to pl.wikipedia.org articles using [[wikipedia:]] links:

INSERT INTO interwiki (iw_prefix, iw_url, iw_local, iw_trans) VALUES ('wikipedia', 'http://pl.wikipedia.org/wiki/$1', 0, 0);

Ciencia Al Poder (talk) 10:38, 3 December 2013 (UTC)

Actually Wikipedia: is an interwiki prefix that's included by default, so no sql statement needed Bawolff (talk) 03:38, 4 December 2013 (UTC)

Cienca proposed to use the prefix "wikipedia" to point to the Polish(!) Wikipedia. If that's clever depends on the focus of the user's wiki. Should it make sense for him and if the interwiki prefix "wikipedia" is defined already, then I guess it would need a INSERT INTO ... ON DUPLICATE KEY update ... or - maybe simpler - an UPDATE query. 88.130.103.56 03:56, 4 December 2013 (UTC)

Good point. I totally didn't notice that. With the interwiki that comes default, you can also use links like [[wikipedia:pl:Some page on polish wiki]] Bawolff (talk) 07:41, 4 December 2013 (UTC)

Mobile View Included

Will a mobile view be included in MediaWiki by default soon? Dude1717 (talk) 21:46, 2 December 2013 (UTC)

"included in MediaWiki" means "included in MediaWiki tarballs for download"? For the time being, Extension:MobileFrontend AKlapper (WMF) (talk) 09:25, 3 December 2013 (UTC)

Problem in the installation.

Hello,

After moving the files to the the /var/www/html folder in a CentOS, we open in firefox the index.php and they tell us that it cannot find the Localsettings.php so we go to the "set up the wiki" and it shows as a white page.

I am using a mediawiki 1.21.3.

Best regards,

HGF 193.144.147.74 (talk) 12:28, 3 December 2013 (UTC)

Hi!

A blank page points to a PHP error. Check your servers error log to see what is happening! 88.130.83.17 13:17, 3 December 2013 (UTC)

I think we already sorted this out on IRC yesterday, anyway: Looking at the web server error log is always helpful, and in this case it was https://bugzilla.wikimedia.org/show_bug.cgi?id=42205 AKlapper (WMF) (talk) 13:48, 4 December 2013 (UTC)

Groups in protect page not being displayed

Hello everyone. I am trying to protect a page to edition to allow only users from a determinated group to edit. I already added the group permission:

$wgGroupPermissions['*']['edit'] = false;
$wgGroupPermissions['Dev']['edit'] = true;
$wgGroupPermissions['Infra']['edit'] = true;
$wgGroupPermissions['Interface']['editinterface'] = true;
$wgGroupPermissions['Test']['edit'] = true;
$wgGroupPermissions['Viewer']['read'] = true;

but they are not showing there, the only ones that i can select are:

Allow all users
Block new and unregistered users
Administrator only

How can I change that?

MySQL 5.5
Wiki 1.21.3 Andre Froes (talk) 16:01, 3 December 2013 (UTC)

Hi Andre,

that is because groups only show up in Special:UserRights. However, you might be interested in Extension:Lockdown, which might help you. 88.130.103.56 21:13, 3 December 2013 (UTC)

Try $wgRestrictionLevels. (Note, that that works on the level of rights, not on the level of usergroups). Bawolff (talk) 01:43, 4 December 2013 (UTC)

Click a Hyperlink Opens up a File Download

My apologies, I am pretty new to Mediawiki.

Quite randomly when I am clicking through a file download with the most recent hyperlink attempts to open at the bottom of my browser. I haven't been able to find any other discussion about this. These are hyperlinks directing to other pages and not downloadable files. You can then click on the link again, and it works correctly. This can happen on any link at any given time. Looking for any advice you can give.

Thank you.

Product Version MediaWiki 1.19.2 PHP 5.3.3-7+squeeze17 (apache2handler) MySQL 5.0.67-log 107.1.105.72 (talk) 16:37, 3 December 2013 (UTC)

Do I understand correctly that this dialogue can open for any link, e.g. for links in your pae's content, but also for links from inside a menu? 88.130.103.56 21:10, 3 December 2013 (UTC)

That's odd. I would recommend trying to capture the headers for one of these download requests. Specificly what is the content-type and content-disposition headers (content-disposition might not be set. Normally its not supposed to be) for the requests that result in the download.

Also what does the file that is downloaded look like? Bawolff (talk) 01:46, 4 December 2013 (UTC)

[RESOLVED] Getting an error message whenever I try to edit a page

When I try to edit any page on our Wiki, I get the following error message:

Warning: Parameter 1 to controlEditAccess() expected to be a reference, value given in /home/cornell/public_html/wiki/includes/Hooks.php on line 133

What does this mean and how do I fix this error? Many thanks. 24.8.191.65 (talk) 17:32, 3 December 2013 (UTC)

Hi!

That means that somewhere on the server you have a line of code, which calls controlEditAccess(). This function expects several parameters and in your case the first one is a value, but it should be a reference. The simple/hacky solution is to add a "&" char in the function call or to remove it in the function itself, each time in front of the first parameter. See debug for more information on how to get a backtrace of the error. 88.130.103.56 21:08, 3 December 2013 (UTC)

controlEditAccess() is called from a hook, so it's most probably a problem with one of the extensions installed in your MediaWiki. Please be sure that you have downloaded the version of every extension that matches the version of your MediaWiki installation, otherwise incompatibilities like this may arise.

You can identify what extension is responsible for that error by disabling (removing/commenting its reference in LocalSettings.php) all extensions and enabling one by one until you reproduce the problem again. Ciencia Al Poder (talk) 10:32, 4 December 2013 (UTC)

Ciencia is right. E.g. Extension:AccessControl would be one of the candidates. 88.130.103.56 13:00, 4 December 2013 (UTC)

Great, I will take a look at the extensions installed and make sure all of the versions match up. If not, I will add the & to the call or remove the function. Thanks! 24.8.191.65 04:46, 5 December 2013 (UTC)

I found the problem extension and disabled it and now everything works fine. Thanks for the help. Consider this one resolved. 24.8.191.65 17:44, 7 December 2013 (UTC)

Import of structured data

Hello everybody,

is it possible to import structured data directly to MediaWiki?

I have a lot of technical descriptions in XML, which can be checked for completeness against a DTD. Can I import this data to MediaWiki or change directly the database? Furthermore tables of contents should be generated automatically. When XML-Data are changed, the associated articles in the Wiki should be changed. Is it possible by a plugin to change the database directly? Can different versions of articles be displayed due to the type of user (e. g. draft version for the developer, current version for the user)?

Is it possible to use MediaWiki for such a use-case?

Thanks for your suggestions! 451plus (talk) 13:54, 4 December 2013 (UTC)

Yes, it is possible.

No, it doesn't happen out of the box.

It will take some programming, so if you want help understanding what is needed, please post a follow-up. ☠MarkAHershberger☢(talk)☣ 18:45, 13 March 2014 (UTC)

[RESOLVED] Database error after upgrading

Hello,

I just installed the latest version of mediaWiki (was obligated to do so after our previous server running it crashed) I tried to restore our DB backup and now it gives me the following error:

A database error has occurred. Did you forget to run maintenance/update.php after upgrading? See: https://www.mediawiki.org/wiki/Manual:Upgrading#Run_the_update_script
Query: SELECT page_id,page_len,page_is_redirect,page_latest,page_content_model FROM `page` WHERE page_namespace = '0' AND page_title = 'Hoofdpagina' LIMIT 1 
Function: LinkCache::addLinkObj
Error: 1054 Unknown column 'page_content_model' in 'field list' (localhost)

I have absolutely no idea what version was running previously. Is there any possibility of restoring our data? I already ran the update.php script. it does make media wiki work but empties the database as result.

Kind regards 82.161.110.79 (talk) 16:17, 4 December 2013 (UTC)

Hi!

When you are a MySQL expert and when MySQL is configured accordingly then there might be a slight chance to undo the changes by using MySQL tools. However, that is not likely...

You say that before the upgrade you get this error message. This points to the fact that you are using a database, which has last been updated for an older version of MediaWiki. There is nothing bad about that; getting this error then is usual behaviour. What exactly do you mean with "empties the database"? Does it show you the main page with some default text on it or does it not show you any page at all?

However, when after running update.php this database does not show the pages then I guess that your database in fact does not contain them?! Maybe you imported only the structure of the old DB, but not the actual content? Or the dump was created with --no-data flag or something like that? In that case take a backup, which contains your stuff (including the data!) and use that one.

Also take note of this thread: http://www.mediawiki.org/wiki/Project%3ASupport%20desk/Flow/2013/06#h-%5BRESOLVED%5D_upgrade_from_1.16.1_to_1.21.1_failing-2013-06-27T13%3A47%3A00.000Z There things worked with some dirty hacks and when - instead of the shell - the web updater was used. 88.130.103.56 17:19, 4 December 2013 (UTC)

Hello, Thanks for the response!

Ehm. It seems i somewhat explain the issue wrong previously.

The database does still appear intact after running the update script but the wiki however does not show our old data. All i get is an empty home page with the default text. When i do however surf to the info page of the wiki it does show the amount of edits/users etc correctly.

Taking a look at the DB with phpmyadmin shows that it does contain data. however it is not readable because it's saved in binary format. As example: There are currently 600+ 'text' entries in the database saved as binairy blobs. Which to my knowledge i can't read.

If anyone could give me some advice on how to handle this issue it'll be appreciated! :)

Kind regards 2001:980:44DD:1:E424:743F:E22:30E8 13:25, 6 December 2013 (UTC)

Let me get this straight:

• In your database you still have the text of your "old" wiki.
• The Special:Statistics page shows you information, which obviously are based on that "old" data.
• But when you open a page then it is not there.

I am only guessing, but: What do you have in the page table? This table links a certain page name to the according text. I could imagine that a problem in this table (like the table has been emptied or so) could cause MediaWiki to no longer find pages and their text, although the text itself is still there.

Btw.: Just out of curiosity: Do you have a backup from before the update? This would be one of those cases, where - if I were you - I would use it. 88.130.81.37 14:10, 6 December 2013 (UTC)

Resolved!

Sorry but it appears the bottleneck in my case was PhPMyadmin. It crashed halfway through the database import.

Importing the database backup through CLI commands fixed the issue.

Thanks for the replies nontheless!

Kind regards 2001:980:44DD:1:E424:743F:E22:30E8 15:37, 6 December 2013 (UTC)

Yeah, partly-missing data. That's also what I thought. Great to see it's working now! 88.130.81.37 16:53, 6 December 2013 (UTC)

How create a user groups

Hey guys, I'm trying create users groups and delegate permissions for his, but this isnt working. How do this? DouglasBerndt (talk) 19:34, 4 December 2013 (UTC)

Hi!

Se here: Manual:user groups and especially Manual:$wgGroupPermissions. 88.130.119.161 22:03, 4 December 2013 (UTC)

Hello,

Of course, i know this articles, but I have some questions about this.

Where, in mysql stay the table with user groups? I try user_groups and other, but I dont meet.

For example, I created a group called 'admins', but he dont appear on table user_groups. 200.175.44.252 13:40, 5 December 2013 (UTC)

The database table is the table user_groups. However, it does not contain what you think it contains. It is not the setup of the groups that appears in that table. Assign a user to a group using Special:UserRights and then this user and the group name will appear there. 88.130.119.161 14:06, 5 December 2013 (UTC)

I understand your tips, but i dont understand this user rights, I cant know with $wgGroupPermissions create some group user, for example. This isnt clear for me.

For example, this lines:

$wgGroupPermissions['ninja']['bot']    = true;
$wgGroupPermissions['ninja']['block']  = true;
$wgGroupPermissions['ninja']['delete'] = true;

With this lines create a user groups, if this not set in any user default. 200.175.44.252 17:48, 5 December 2013 (UTC)

Hi!

You create the user group in LocalSettings.php. All you have to do is to add some lines to the array $wgGroupPermissions. That way your above example creates the user group "ninja".

However, this code alone does not set this user group for any user! At that point the group is only available, but nothing more. You will at that time see it when you visit the page Special:ListGroupRights in your wiki.

Next go to the page Special:UserRights on your wiki and provide a user, whose rights you want to change. You will then see all the different groups, which are available. By default this will be "sysop", "bureaucrat" and "bot". Since you have the according configuration in LocalSettings.php, there will also be the group "ninja". Now check the groups as you wish and apply the changes. After that step your user is member of the according groups!

You will now see the user on your wiki on the page Special:ListUsers when you select the according group. And now you will also have the according rows in the database table user_groups. 88.130.81.37 18:13, 5 December 2013 (UTC)

I realy used your tips, I did not know this Special pages existed, thanks. 200.175.44.252 18:59, 5 December 2013 (UTC)

I realy used your tips, I did not know this Special pages existed, thanks. 200.175.44.252 19:01, 5 December 2013 (UTC)

Graphviz extension

I wonder if Graphviz extension can be added 204.13.59.70 (talk) 21:25, 4 December 2013 (UTC)

That depends:

• On your own wiki maybe, if you want to risk your security then yes.
• On Wikimedia wikis - for above reason - definitely not. 88.130.119.161 01:07, 5 December 2013 (UTC)

How to form a search query in MediaWiki with multiple terms in the srsearch parameter?

I have two terms A and B (strings) and I want all Wikipedia pages that have both these terms A and B, with no constraint regarding the order in which they appear and any phrase query or anything like that. I just want all result pages to be containing both these terms.

What is the syntax of the MediaWiki query that I should be constructing for the srsearch parameter?

Should I use srsearch="A|B" or srsearch="A&B" or srsearch="A,B" or srsearch=A|B

From the results I am getting, I am unable to make this decision.

Any advise is highly appreciated. 122.248.182.61 (talk) 09:03, 5 December 2013 (UTC)

(Answering an old question in case anyone comes looking for an answer.)

If you type the search "A B" or "B A" into the search field, you'll get the same results. So, use URI-encoding ("+" for " ") and you'll have what you want: https://www.mediawiki.org/w/api.php?action=query&list=search&srsearch=B+A&srbackend=LuceneSearch&format=jsonfm

Note that in doing this I got a strange error: bug 62608 ☠MarkAHershberger☢(talk)☣ 18:19, 13 March 2014 (UTC)

MediaWiki extension development: Adding a tab

I have a question related to developing a MediaWiki extension. We have developed the extension as a special page and now want to integrate it into the wiki site such that a link is displayed in a tab at the top of the page (just like the article and discussion tabs/links) which should link to the special page, and which should pass on information on which page we came from. Having searched the documentation I couldn't find anything related to this. Is this doable and if so how? Thanks for any advice. Robertpba (talk) 10:57, 5 December 2013 (UTC)

Hi!

Yes, that is doable. In your extension you should call a hook and add the tab using that hook. Check the list of available hooks to see, which hook is the right one. SkinTemplateNavigation might be a good choice. 88.130.119.161 14:02, 5 December 2013 (UTC)

Many thanks, I'll give it a try! Robertpba (talk) 14:45, 5 December 2013 (UTC)

Turn off the Spam protection filter

Heyo,

in my private closed Wiki with only a hand of known users I have a Problem with my spam protection filter.

Everytime I am writing words like via-gra or somthing else, vhat can come often in my texts, he wont save my changes.

How can I turn off the spamprotection complete?

Thanks. Philippfinck (talk) 21:00, 5 December 2013 (UTC)

Hi Philipp!

Two possibilities:

• If you are using an extension, uninstall that extension (see Special:Version).
• If you have set up $wgSpamRegex, remove it. 88.130.81.37 21:09, 5 December 2013 (UTC)

No, I am using none of that things.

I´m using the Extentions Guestbook, Cite, InputBox, ans OpenSearch XML. Philippfinck (talk) 21:31, 5 December 2013 (UTC)

Strange. What is the exact error message, which is displayed when you try to save such spammy words? 88.130.81.37 21:38, 5 December 2013 (UTC)

I am using the german version of MediaWiki.

by saving of the articele i come to a site named "Spamschutzfilter" who says:

"Der Text, die du speichern willst, wurde vom Spamschutzfilter blockiert. Das liegt wahrscheinlich an einem Link auf eine externe Seite.

Der folgende Text wurde vom Spamfilter gefunden: <SPAMTEXT>" Philippfinck (talk) 21:46, 5 December 2013 (UTC)

This text is coming from the language label spamprotectiontext. You could now search the MediaWiki source code for this word "spamprotectiontext" and check, in which context it is used. That should tell you, which variable causes display of the message. 88.130.81.37 23:12, 5 December 2013 (UTC)

How to render TOC at a custom place by PHP

I'm editing my skin file to display TOC in the right sidebar rather than on the top of the article. I've tried next code:

<div class="sidebar">
	<div class="sidetoc"><?php
		$this->mForceTocPosition = true;
		$text = '<!--MWTOC-->';
		return $text;
	?></div>
</div>

expecting my includes/parser/Parser.php would complete the positionning.

function formatHeadings( $text, $origText, $isMain = true ) {
...

if ( $this->mForceTocPosition ) {
	return str_replace( '<!--MWTOC-->', $toc, $full );
} else {
	return $full;
}

Yet it didn't change anything. Could someone please tell me how I was supposed to do? I'am pretty much a noob at PHP editing and it's quite hard to figure it out on my own. Thank you. Cafeinlove (talk) 22:38, 5 December 2013 (UTC)

Your snippet will just return the HTML comment. In order to get the expected result you would have to have a parser object through which you can send your comment so that the parser replaces it with the actual TOC. However, even if you called a parser object I am not sure if it contains the article at the point in rendering when your sidebar is being created = when you would need it. Without testing, I guess that you would have to parse the whole article a second time.

You won't be able to do something like that inside a hook I think. So any stuff in PHP will become rather expensive as you will basically have to render the article twice: Once to get the article and once to get the TOC. I wouldn't want that.

Have you tried to achieve that with CSS? 88.130.81.37 23:08, 5 December 2013 (UTC)

I used to do this in that way, by combining position:fixed and margin-left, but would like to slightly change the DOM structure to ease my responsivizing work.

I understand your point though, but then how about setting a plugin that puts __TOC__ into <div class="sidetoc" />? Something like Extension:ForceTocOnEveryPage. Cafeinlove (talk) 00:46, 6 December 2013 (UTC)

I am not sure, if I got you, but the ForceTocOnEveryPage extension is executed in a hook inside the parser object. The extension can add the TOC, because the code, which is generated at that point is parsed afterwards, The sidebar in contrast is not. I guess the same goes for div class=sidetoc: When it is not added from inside the parser object, it - by default - won't be parsed afterwards.

However, it might make sense for you to use this extension anyway: That kind of guarantees that the TOC appears everytime at exactly the same place of the DOM.

Another idea would be: Check Manual:Hooks and see, if there is a hook, which allows modifiying the generated TOC. If so use it and save the source code of the TOC in a global variable. Later, when you are creating your sidebar, take the stuff from the global variable and put it there. However, this is not really clean and it would only work, if the sidebar would be processed after the main content (what would seem logical to me, but what I don't know).

Another idea might be to use jQuery to manipulate the DOM the way you need it. 88.130.81.37 01:02, 6 December 2013 (UTC)

Thank you for the comment, I'm learning a lot from it. I am going to launch several tests to see at which moment TOC is parsed, and perhaps try to find a workaround with the document you just linked me to. Cafeinlove (talk) 01:35, 6 December 2013 (UTC)

Word Document 2010/2013 to mediawiki format

Hi,

Can somebody help me out converting word document 2013/2010 version to mediawiki format? I looked at various ways online most of them are not working at all :(

Let me know!

Thanks! 108.232.30.64 (talk) 02:38, 6 December 2013 (UTC)

Try http://en.wikipedia.org/wiki/Help:WordToWiki 88.130.81.37 03:08, 6 December 2013 (UTC)

MediaWiki 1.22 causes error: Invalid magic word "rootpagename"

Hi! I am from Russia, sorry to my English. I have a problem with update. Short text of error 'invalid magic word 'rootpagename

Version MediaWiki 1.22

Backtrace:

#0 C:\Program Files (x86)\OTRS\Apache\htdocs\wiki\includes\MagicWord.php(238): MagicWord->load('rootpagename')
#1 C:\Program Files (x86)\OTRS\Apache\htdocs\wiki\includes\parser\Parser.php(4919): MagicWord::get('rootpagename')
#2 C:\Program Files (x86)\OTRS\Apache\htdocs\wiki\includes\parser\CoreParserFunctions.php(91): Parser->setFunctionHook('rootpagename', Array, 1)
#3 C:\Program Files (x86)\OTRS\Apache\htdocs\wiki\includes\parser\Parser.php(267): CoreParserFunctions::register(Object(Parser))
#4 [internal function]: Parser->firstCallInit()
#5 C:\Program Files (x86)\OTRS\Apache\htdocs\wiki\includes\StubObject.php(79): call_user_func_array(Array, Array)
#6 C:\Program Files (x86)\OTRS\Apache\htdocs\wiki\includes\StubObject.php(99): StubObject->_call('firstCallInit', Array)
#7 C:\Program Files (x86)\OTRS\Apache\htdocs\wiki\includes\cache\MessageCache.php(996): StubObject->__call('firstCallInit', Array)
#8 C:\Program Files (x86)\OTRS\Apache\htdocs\wiki\includes\cache\MessageCache.php(996): StubObject->firstCallInit()
#9 C:\Program Files (x86)\OTRS\Apache\htdocs\wiki\includes\cache\MessageCache.php(974): MessageCache->getParser()
#10 C:\Program Files (x86)\OTRS\Apache\htdocs\wiki\includes\Message.php(696): MessageCache->transform('$1 ??? {{SITENA...', true, Object(LanguageRu), Object(Title))
#11 C:\Program Files (x86)\OTRS\Apache\htdocs\wiki\includes\Message.php(496): Message->transformText('$1 ??? {{SITENA...')
#12 C:\Program Files (x86)\OTRS\Apache\htdocs\wiki\includes\Message.php(553): Message->toString()
#13 C:\Program Files (x86)\OTRS\Apache\htdocs\wiki\includes\OutputPage.php(846): Message->text()
#14 C:\Program Files (x86)\OTRS\Apache\htdocs\wiki\includes\OutputPage.php(889): OutputPage->setHTMLTitle(Object(Message))
#15 C:\Program Files (x86)\OTRS\Apache\htdocs\wiki\includes\Article.php(555): OutputPage->setPageTitle('???????????????...')
#16 C:\Program Files (x86)\OTRS\Apache\htdocs\wiki\includes\actions\ViewAction.php(44): Article->view()
#17 C:\Program Files (x86)\OTRS\Apache\htdocs\wiki\includes\Wiki.php(439): ViewAction->show()
#18 C:\Program Files (x86)\OTRS\Apache\htdocs\wiki\includes\Wiki.php(305): MediaWiki->performAction(Object(Article), Object(Title))
#19 C:\Program Files (x86)\OTRS\Apache\htdocs\wiki\includes\Wiki.php(565): MediaWiki->performRequest()
#20 C:\Program Files (x86)\OTRS\Apache\htdocs\wiki\includes\Wiki.php(458): MediaWiki->main()
#21 C:\Program Files (x86)\OTRS\Apache\htdocs\wiki\index.php(55): MediaWiki->run()
#22 {main}

Pchelinov.a (talk) 07:32, 6 December 2013 (UTC)

Hi!

The magic word "rootpagename" has been added in MediaWiki 1.22, see Release_notes/1.22 and bug 6747. Btw way final version of MediaWiki 1.22 has not yet been released. Maybe you are using an older version (an older RC or a beta version), which does not yet contain this new magic word? 88.130.81.37 14:21, 6 December 2013 (UTC)

Maybe so, but after upgrade from 1.21.3 to 1.22.0 I get:

[9f34ab5a] /index.php/Main_Page Exception from line 316 of /var/www/html/mediawiki-1.22.0/includes/MagicWord.php: Error: invalid magic word 'rootpagename'

I've simply downloaded mediawiki-1.22.0.tar.gz; expanded it into /var/www/html/mediawiki-1.22.0; copied LocalSettings.php and images from previous version; run php update.php in maintenance. 120.147.16.155 08:56, 7 December 2013 (UTC)

120.147.16.155 08:56, 7 December 2013 (UTC)

sorry for double post.

I think 1.22 has been released. I downloaded it from http://www.mediawiki.org/wiki/Download 120.147.16.155 08:59, 7 December 2013 (UTC)

RELEASE-NOTES-1.22 states that MediaWiki 1.22 is an alpha-quality branch and is not recommended for use in

production. That's probably right! 120.147.16.155 11:33, 7 December 2013 (UTC)

It was released yesterday 90.215.111.103 12:42, 7 December 2013 (UTC)

I confirm the same behaviour on my installation. Web upgrade from 1.20.2 to 1.22.0 results in the bespoke error:

"[642fd5f3] /wiki/index.php/Main_Page Exception from line 316 of /var/www/mediawiki-1.22.0/includes/MagicWord.php: Error: invalid magic word 'rootpagename'"

and same stacktrace as written in first post. 91.52.193.216 17:41, 7 December 2013 (UTC)

I see you're using russian language. I remember seeing similar problems for older versions too. Maybe you need to run rebuildLocalisationCache.php --force Ciencia Al Poder (talk) 17:48, 8 December 2013 (UTC)

The RELEASE-NOTES-1.22 file in the current download at http://www.mediawiki.org/wiki/Download still says:

== MediaWiki 1.22 ==

THIS IS NOT A RELEASE YET

MediaWiki 1.22 is an alpha-quality branch and is not recommended for use in production. 203.206.131.20 23:31, 8 December 2013 (UTC)

This has been fixed inbetween; Download does no longer contain this text. 88.130.110.231 01:44, 9 December 2013 (UTC)

Not for me. Still the above mentioned text. 203.206.131.20 03:47, 9 December 2013 (UTC)

Confirmed. The "alpha-quality" paragraph is indeed contained in the current RELEASE-NOTES-1.22.

So why is the 1.22.0 then declared "stable" here: http://www.mediawiki.org/wiki/Download 194.77.167.34 08:36, 9 December 2013 (UTC)

OMG indeed! permalink as of writting this - Current REL1_22 Branch Ciencia Al Poder (talk) 10:46, 9 December 2013 (UTC)

Phh, a forgotten line. If a sack of rice falls in China, it's a bigger problem. Honestly guys!

However, it is in fact not the first time that such problems after a major release happen. E.g. the version, which was published as "1.21.0" still showed the version number 1.21.0.rc3. Maybe there really is still room for improvement.

So what about the invalid magic word "rootpagename"? 88.130.127.250 16:08, 10 December 2013 (UTC)

Yeah honestly.

I do not care about a forgotten line of README text. Question is: Was that line simply forgotten or did someone mess something (else) up?

I ran an upgrade on a very basic wiki installation (no additonal/custom extensions, skins, whatever) and it failed, forcing me to do a complete rollback on the DB. You simply do not expect this kind of error when there is a "stable" version which - hopefully - has been tested (upgrade-wise). 194.77.167.34 15:24, 16 December 2013 (UTC)

If this line was forgotten or somehow else put there, you can see in the Git repository. There you can check each single commit. I already did when the topic "wrong line" was brought up and the result is: The line was always there and has just been forgotten to be removed. There even was one last commit, which especially updated the README file; however: This line was forgotten.

As for your rollback problem it is hard to say what caused this without having more information and an exact error message. However, please put this to a different thread, should you still be in need of a solution for that! 88.130.119.59 15:52, 16 December 2013 (UTC)

I've experiencing a similar error every time I attempt to upgrade even with older versions (1.20+).

Error: invalid magic word 'noglossary'

I disable all my extensions while upgrading (Removing the extensions from the LocalSettings.php and temporarily changing the extensions directory)

then restore the extensions after the upgrade.

This may also help in your situation. It can be an annoying workaround and I'd be grateful if a better solution was found. KemikalElite (talk) 07:40, 12 December 2013 (UTC)

This "solution" may not work, as some extensions may need to be included during the upgrade if they need to change things in the database. Ciencia Al Poder (talk) 10:18, 13 December 2013 (UTC)

I know of extensions, which add/change stuff in the DB when they themselves are installed or updated. But I have never seen an extension change the DB when MediaWiki was updated. Do you have an example for that? 88.130.119.59 15:56, 16 December 2013 (UTC)

You're supposed to update extensions at the same time you update MediaWiki, since they should match the MediaWiki release version, and when you upgrade such extensions (that have their own database objects) you should run update.php Ciencia Al Poder (talk) 20:35, 16 December 2013 (UTC)

> when you upgrade such extensions (that have their own database objects) you should run update.php

When you update the extension; that's clear. Your first statement made it sound like you update MediaWiki and do not change anything with an extension and out of a sudden the extension wants to change the database. I do not know of any case, where that happens. Good that you clarified this. 88.130.119.59 22:08, 16 December 2013 (UTC)

BUMP: So, forgetting about the RELEASE-NOTES detail, and given that the 1.22.0 download has not changed, what can I do to upgrade from 1.21.3 to 1.22.0 ? I get "Error: invalid magic word 'rootpagename'" after that upgrade. 120.147.16.155 10:58, 19 December 2013 (UTC)

I just tried another upgrade from 1.20.6 to 1.22 and again got "Error: invalid magic word 'rootpagename'" there too.

If others are not getting this error it must either be my environments which are all CentOS 6.5 x64 / MySQL 5.1.67 or 5.1.71 or something in my databases.

I don't run extensions. 120.147.16.155 11:58, 19 December 2013 (UTC)

I'm pretty sure it is a caching issue. If I build a fresh VM and restore the 1.21.3 DB and files, then perform the upgrade to 1.22 - it works. It is only on my "production" machines that I get "Error: invalid magic word 'rootpagename'" after performing the same upgrade. (Although dynamic, my home IP is 120.147.16.155 throughout this thread, but I'm at work now so I'll have a different IP.) 203.206.131.20 22:59, 19 December 2013 (UTC)

So, I tried to fix it thusly :(

1. php rebuildall.php

• • Rebuilding fulltext search index (if you abort this will break searching; run this script again to fix):

Dropping index...

Rebuilding index fields for 2078 pages...

500

1000

1500

2000

Rebuild the index...

Done.

• • Rebuilding recentchanges table:

Loading from page and revision tables...

$wgRCMaxAge=7862400 (91 days)

Updating links and size differences...

Loading from user, page, and logging tables...

Flagging bot account edits...

Flagging auto-patrolled edits...

Deleting feed timestamps.

Done.

• • Rebuilding links tables -- this can take a long time. It should be safe to abort via ctrl+C if you get bored.

Refreshing redirects table.

Starting from page_id 1 of 2078.

100

200

300

400

500

600

700

800

900

1000

1100

1200

1300

1400

1500

1600

1700

1800

1900

2000

Refreshing links tables.

Starting from page_id 1 of 2078.

"" is not a valid magic word for "rootpagename"

[fcdec2da] [no req] Exception from line 316 of /var/www/html/mediawiki-1.22.0/includes/MagicWord.php: Error: invalid magic word 'rootpagename'

Backtrace:

1. 0 /var/www/html/mediawiki-1.22.0/includes/MagicWord.php(239): MagicWord->load(string)
2. 1 /var/www/html/mediawiki-1.22.0/includes/parser/Parser.php(4982): MagicWord::get(string)
3. 2 /var/www/html/mediawiki-1.22.0/includes/parser/CoreParserFunctions.php(91): Parser->setFunctionHook(string, array, integer)
4. 3 /var/www/html/mediawiki-1.22.0/includes/parser/Parser.php(271): CoreParserFunctions::register(Parser)
5. 4 /var/www/html/mediawiki-1.22.0/includes/parser/Parser.php(287): Parser->firstCallInit()
6. 5 /var/www/html/mediawiki-1.22.0/includes/parser/Parser.php(4823): Parser->clearState()
7. 6 /var/www/html/mediawiki-1.22.0/includes/parser/Parser.php(367): Parser->startParse(Title, ParserOptions, integer, boolean)
8. 7 /var/www/html/mediawiki-1.22.0/includes/content/WikitextContent.php(300): Parser->parse(string, Title, ParserOptions, boolean, boolean, NULL)
9. 8 /var/www/html/mediawiki-1.22.0/includes/content/AbstractContent.php(239): WikitextContent->getParserOutput(Title, NULL, NULL, boolean)
10. 9 /var/www/html/mediawiki-1.22.0/maintenance/refreshLinks.php(244): AbstractContent->getSecondaryDataUpdates(Title)
11. 10 /var/www/html/mediawiki-1.22.0/maintenance/refreshLinks.php(172): RefreshLinks::fixLinksFromArticle(integer)
12. 11 /var/www/html/mediawiki-1.22.0/maintenance/refreshLinks.php(53): RefreshLinks->doRefreshLinks(integer, boolean, integer, integer, boolean, boolean)
13. 12 /var/www/html/mediawiki-1.22.0/maintenance/rebuildall.php(58): RefreshLinks->execute()
14. 13 /var/www/html/mediawiki-1.22.0/maintenance/doMaintenance.php(113): RebuildAll->execute()
15. 14 /var/www/html/mediawiki-1.22.0/maintenance/rebuildall.php(65): require_once(string)
16. 15 {main} 203.206.131.20 23:49, 19 December 2013 (UTC)

Have you tried rebuildLocalisationCache.php --force ? Ciencia Al Poder (talk) 10:06, 20 December 2013 (UTC)

Just calling that script did nothing, calling with --force fixed this issue for me. Arantius (talk) 16:25, 24 December 2013 (UTC)

[RESOLVED] ABBR

Hi! What extension allows you to use the template ABBR? Pchelinov.a (talk) 10:54, 6 December 2013 (UTC)

Hi!

I don't know of a Template:ABBR. Do you mean Extension:EnableAbbrTags? 88.130.81.37 14:18, 6 December 2013 (UTC)

Just in case, if you confused it with the ordinary <abbr>, this should be supported, compare the sanitizer.php snippet shown on meta. Be..anyone (talk) 16:52, 6 December 2013 (UTC)

No, i mean http://ru.wikipedia.org/wiki/%D0%A8%D0%B0%D0%B1%D0%BB%D0%BE%D0%BD:Abbr. In my wiki it is not work! 103.16.26.85 05:36, 9 December 2013 (UTC)

You probably want to start debugging by taking a look at your browser's error console, then. :) AKlapper (WMF) (talk) 10:37, 9 December 2013 (UTC)

О, спасибо что заставили искать инфу самому! Простите за тупость! В общем, в самом шаблоне нужно прописать

<abbr style="font-family: Monospace; font-size:1.3em; background: #CCEEEE; color: #055;" title="{{{1}}}">{{{2|[?]}}}</abbr><noinclude>
 [[Category:Templates]]</noinclude>

Тогда, разумеется, шаблон заработает! Всё гениальное просто! Pchelinov.a (talk) 11:24, 9 December 2013 (UTC)

Works fine here, I pasted it into the Project:Sandbox here and tested the effect of {{:Project:Sandbox|abbreviation|abbr}} in a preview on another page. Be..anyone (talk) 10:10, 12 December 2013 (UTC)

I don't understand your Russian text. However, for the template, which Pchelinov.a linked, you will need the Parser extensio installed. This extension comes with current versions of MediaWiki by default, but must be installed explicitly. 88.130.78.142 13:07, 12 December 2013 (UTC)

Yes, you are right. This extension installed with MediaWiki. I said, that I have succeeded. Wiki first time use and only now realized how work templates/ Pchelinov.a (talk) 14:04, 12 December 2013 (UTC)

Cool! 88.130.78.142 14:46, 12 December 2013 (UTC)

[RESOLVED] POST data lost during redirecting

Hi, I am creating an extension handling data sent by an external application. Data are sent via POST method. If the user is not logged in, I forward him into LogIn page using this code http://mediawiki.sourcearchive.com/documentation/1:1.14.0-1/classEditPage_7eca8a4db7d21663be3a691ad7cfdabe.html

Unfortunatelly, the POST data get lost during this operation. Is there any possibility how to LogIn while having POST data still available?

THX. Vasek Velorex (talk) 01:09, 7 December 2013 (UTC)

POST data is not carried over when you perform a HTTP redirect.

A solution may be to save it inside SESSION and restore it after a successful login. Ciencia Al Poder (talk) 20:27, 9 December 2013 (UTC)

Great idea, thank you. I labeled the thread as RESOLVED Velorex (talk) 16:13, 10 December 2013 (UTC)

Call to undefined function libxml_disable_entity_loader() in .. SVGMetadataExtractor.php on line 79

This is only showing up on a few pages on my wiki installation after upgrading from 1.16 to 1.19.9. Domain bahaimedia.org The following pages are affected:

Category:Administrative_images Special:NewFiles Special:ListFiles

Here is the related part of the file from SVGMetadata...

                // Expand entities, since Adobe Illustrator uses them for xmlns
                // attributes (bug 31719). Note that libxml2 has some protection
                // against large recursive entity expansions so this is not as
                // insecure as it might appear to be. However, it is still extremely
                // insecure. It's necessary to wrap any read() calls with
                // libxml_disable_entity_loader() to avoid arbitrary local file
                // inclusion, or even arbitrary code execution if the expect
                // extension is installed (bug 46859).
                '''$oldDisable = libxml_disable_entity_loader( true );'''
                $this->reader->setParserProperty( XMLReader::SUBST_ENTITIES, true );              $this->metadata['width'] = self::DEFAULT_WIDTH;
                $this->metadata['height'] = self::DEFAULT_HEIGHT;

Thanks for any help!

Edit: I've reverted to an old version of the software. You won't find the error anymore. Someone suggested this could be fixed by upgrading to php 5.2.11 or later. Please ignore. T0lk (talk) 09:20, 7 December 2013 (UTC)

Try upgrading to php 5.3 or later if you want to get the current version of Mediawiki 90.215.111.103 12:41, 7 December 2013 (UTC)

Extension:centralauth

Hi I think there is a problem in centralauth it says this error Warning: call_user_func() expects parameter 1 to be a valid callback, function 'wmfLoadInitialiseSettings' not found or invalid function name in /home/paladox/public_html/en/includes/SiteConfiguration.php on line 595 please fix it. I am running Mediawiki 1.23 Wmf 6 it wasn't working in the Wmf of 1.22 I am not sure about 1.21 but I am sure that it was a problem in 1.22 and 1.23 please fix it. 90.215.111.103 (talk) 12:50, 7 December 2013 (UTC)

If you are using not-yet-releasesd software (1.23 isn't released yet), this is the wrong place to ask for support. You should file a bug report for this. ☠MarkAHershberger☢(talk)☣ 16:27, 14 March 2014 (UTC)

Downloads on front page

This post by 90.215.1.14 was moved on 2015-07-11. You can find it at Project:Village Pump/Flow/2013#Downloads on front page. wargo (talk) 13:12, 7 December 2013 (UTC)

[RESOLVED] Fatal: PHP was compiled without JSON support

http://wikinfo.org/x/Nihon/mw-config/index.php?page=Welcome

I'm getting the message: "Fatal: PHP was compiled without JSON support. You must install either the PHP JSON extension or the PECL jsonc extension before installing MediaWiki." while trying to install 1.22 but php -i returns json

json support => enabled json version => 1.3.1 JSON-C headers version => 0.11 JSON-C library version => 0.11

I did install json after getting the first error message:

apt-get install php5-json Reading package lists... Done Building dependency tree Reading state information... Done The following NEW packages will be installed:

 php5-json

0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. Need to get 19.8 kB of archives. After this operation, 119 kB of additional disk space will be used. Get:1 http://archive.ubuntu.com/ubuntu/ saucy/universe php5-json amd64 1.3.1+dfsg-2 [19.8 kB] Fetched 19.8 kB in 0s (65.1 kB/s) Selecting previously unselected package php5-json. (Reading database ... 159262 files and directories currently installed.) Unpacking php5-json (from .../php5-json_1.3.1+dfsg-2_amd64.deb) ... Setting up php5-json (1.3.1+dfsg-2) ... php5_invoke: Enable module json for cli SAPI php5_invoke: Enable module json for apache2 SAPI

but I still get the error message

I did not, and do not, get this message with 1.21.2

http://wikinfo.org/x/1.21.2/mw-config/index.php?page=Welcome Fred Bauder (talk) 13:43, 7 December 2013 (UTC)

Have you checked the output of phpinfo() to see, if JSON is listed as activated there as well? Do you maybe have to restart the server in order to make Apache/PHP actually use the module? 88.130.111.103 14:47, 7 December 2013 (UTC)

Yes, restart fixed it. Fred Bauder (talk) 23:34, 7 December 2013 (UTC)

Great! 88.130.116.81 23:48, 7 December 2013 (UTC)

Extension: article-related and also for unregistered users available rating system

MediaWiki: 1.21.3 'My' wiki: Main Page Grepolis Wiki

I am looking for a MediaWiki extension which allows all wiki readers to rate every page on the wiki. An IRC user has already referred me to the category 'rating extensions'. The problem is that I have no programming knowledge and cannot recognize whether any of these extensions fits to my wishes. I also need an extension which is compatible with the skin and the MediaWiki version I use.

Is anybody able to help me? I would be highly pleased.

Greetings from Germany! 2.244.168.195 (talk) 23:20, 7 December 2013 (UTC)

I push it to the top. 2.244.232.2 16:40, 13 December 2013 (UTC)

In the vain hope that you'll look almost two months later: I would recommend Extension:FlaggedRevs because that is what WMF uses. ☠MarkAHershberger☢(talk)☣ 17:11, 4 February 2014 (UTC)

[RESOLVED] Change Default Calender Style

Hi, How can I change default calender style for everyuser in my own wiki? Omidh (talk) 04:11, 8 December 2013 (UTC)

Which calender are you speaking of? 88.130.116.81 12:28, 8 December 2013 (UTC)

Iranian Calender, I can change it in my user options but i want something default because all of my users are iranian. Omidh (talk) 14:37, 8 December 2013 (UTC)

Ok. And how do you display the calender in your wiki? I guess that must be done with an extension, right?

And second question: Do you want to change the CSS styles or do you want to change the date format (e.g. 17 Azar 1392 SH instead of 8 December 2013 AD)? 88.130.116.81 16:17, 8 December 2013 (UTC)

I want to change the date format (e.g. 17 Azar 1392 SH instead of 8 December 2013 AD), I don't think an extension is necessary, I just want to make this calender default for every user. Omidh (talk) 17:58, 8 December 2013 (UTC)

Ahh, I think I understand now. You want that all the different pages inside MediaWiki display dates in your locale format, e.g. the pages action=history or Special:RecentChanges.

I must say I am no expert for that, but what you want does not sounds so strange, that no one can have had the idea to change that before you. Can you check, if there is a wikipedia project, which does display the dates in the format you want? I did not find an Iranian wikipedia and I don't know, which would then be the one to look at.

Ha, it is even more simple: You say there is a user option for that? And you say that it is your wiki? Then you can solve this by setting the according user option by default. $wgDefaultUserOptions contains more information on that. You will have to check, how this option is named and which value you have to set to get your date format.

That way it will automatically be set for every user. 88.130.116.81 18:57, 8 December 2013 (UTC)

Oh yes, you are right. thanks but there is still one problem, i read description and i know i should use $wgDefaultUserOptions['date']

but my date style is not in the list:

Date format. Options:

'default': No preference

'mdy': 16:12, January 15, 2001

'dmy': 16:12, 15 January 2001

'ymd': 16:12, 2001 January 15

'ISO 8601': 2001-01-15T16:12:34

what i want:

17 Azar 1392

$wgDefaultUserOptions['date'] = ???? Omidh (talk) 09:48, 9 December 2013 (UTC)

Have a look at your user preferences, check the source code of that page and there search for "mw-input-wpdate-ISO_8601". That is the place, where the ISO 8601 option is defined. Somewhere near there should also be the date format you want. You will see that in the source code, there are several ids defined. I think what you need to know is the part of that id, which follows after the mw-input-wpdate-; that is what I would try setting as value. 88.130.110.231 12:02, 9 December 2013 (UTC)

it was "mw-input-wpdate-persian".

Thanks, Problem Solved. Omidh (talk) 15:45, 9 December 2013 (UTC)

Nice!

This definitely solves the issue for all new users. What I am not sure about is, if it also automatically applies to all old users, who registered before you changed this default value. So as a last step you could run the maintenance script userOption.php in order to make sure the default is also set for all old users. 88.130.91.210 02:43, 10 December 2013 (UTC)

It worked but I got a warning

PHP Notice: Use of undefined constant persian - assumed 'persian' in /var/www/wiki/LocalSettings.php on line 268

It says the "persian" variable is undefined but how it is possible? It changed my date style Omidh (talk) 05:59, 10 December 2013 (UTC)

This happens because in LocalSettings.php on line 268 you did not quote the value "persian". The error will go, when you set it in quotes like so:

$wgDefaultUserOptions['date'] = 'persian'; 88.130.127.250 12:43, 10 December 2013 (UTC)

Thanks again! Omidh (talk) 16:26, 10 December 2013 (UTC)

Generating PDF book without list of references (Collection extension)

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

However the generated PDF book has about 10% of pages just long lists of references and sources which are not useful. Is there a way to prevent reference lists from getting into the book? 83.150.117.4 (talk) 14:24, 8 December 2013 (UTC)

If you're running into this problem, you should file a feature request for this new functionality. ☠MarkAHershberger☢(talk)☣ 16:28, 14 March 2014 (UTC)

This is what I do at Wikibooks:

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

• http://en.wikibooks.org/w/index.php?title=Robotics/Print_version&action=edit
• http://en.wikibooks.org/w/index.php?title=Blender_3D:_Noob_to_Pro/Print_version&action=edit

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

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

Then I go to each and every wiki-page of the book,

hunting for the magic words "<references />" and "{{reflist}}"

and make sure each one (if there is one on the page) is inside "noinclude" tags, like this:

"<noinclude>{{reflist}}</noinclude>".

Except for the very last "References" page of the book, which has a "{{reflist}}", but it does not have any "noinclude" tags.

Then when I look at the "normal view" of the print version of the book ( http://en.wikibooks.org/wiki/Robotics/Print_version ),

those references are not included at the end of each page (because of the "noinclude" tags),

but only in one giant list of references at the very end of the book.

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

= References =
{{:Robotics/References}}

so that "print version without references" page never includes the magic words "<references />" and "{{reflist}}" unless they are hidden by the "noinclude" tags.

Then you could produce the PDF file from that one big "print version without references" page.

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

p.s.: I'm one of the people who often thinks articles at Wikipedia and elsewhere don't have enough sources. Please consider yourself lucky that you have so many references and sources. DavidCary (talk) 17:37, 21 March 2014 (UTC)

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

The references I'm getting are mostly meaningless references to my wiki itself (mostly image URLs) which I wanted to eliminate for clarity. I'll try the tricks provided! 77.86.204.6 00:23, 31 October 2014 (UTC)

Unable to call ExtParserFunctions::ifObj()

Hi,

I'm using mediawiki version 1.16.5 and ParserFunctions version 1.5.1.

I've got the error message below when using the component :

Warning: call_user_func_array() [function.call-user-func-array]: Unable to call ExtParserFunctions::ifObj() in /mnt/102/sdb/d/8/patrick.gelin/wiki/includes/parser/Parser.php on line 2920

I can't understand what is the source of the problem. Thank you for your help ! Gelinp (talk) 17:04, 8 December 2013 (UTC)

For the records: ParserFunctions 1.5.1 was released on 2013-01-06. MediaWiki 1.16.5 is not supported and tested anymore since end of 2011. Please consider upgrading to a supported MediaWiki version to receive security updates. AKlapper (WMF) (talk) 10:35, 9 December 2013 (UTC)

Unable to call ExtParserFunctions::ifObj()

Hi,

I'm using mediawiki version 1.16.5 and ParserFunctions version 1.5.1.

I've got the error message below when using the component :

Warning: call_user_func_array() [function.call-user-func-array]: Unable to call ExtParserFunctions::ifObj() in /mnt/102/sdb/d/8/patrick.gelin/wiki/includes/parser/Parser.php on line 2920

I can't understand what is the source of the problem. Thank you for your help ! Gelinp (talk) 17:04, 8 December 2013 (UTC)

check your version of php. older versions of php did not support using call user func with :: notation.

p.s. consider updating mediawiki. your version is outdated 24.114.88.234 18:42, 8 December 2013 (UTC)

TOC begin with zero?

Hello, how can I change the order of the TOC. By default it begins wiht 1. But I want, that it begins with 0. It this possible, an when it is, how can I configure it. Thanks in advance. 178.201.78.89 (talk) 17:34, 8 December 2013 (UTC)

I think that is hardcoded in the according PHP file. However, maybe you find a hook, which allows you to modify the table of contents, before the page is rendered. 88.130.116.81 19:02, 8 December 2013 (UTC)

Inputbox in 1.22.0

• MediaWiki 1.22.0
• PHP 5.3.3
• MySQL 5.0.77-log

Hi, we have a private wiki and recently installed 1.22. When editing a page with an inputbox wiki text, after using WikiEditor "Preview" tab, "Show Preview" works as the save button and saves contents to the main page. If only "Show Preview" is used, everything is fine.

Example wiki text: <inputbox>type=create</inputbox> Dmitry.Kolosov (talk) 17:37, 8 December 2013 (UTC)

If someone can try the same scenario (Edit a random page -> put "<inputbox>type=create</inputbox>" there -> click "Preview" -> click "Show Preview") on their freshly installed 1.22 MediaWiki and let me know how it worked, that would be great. Dmitry.Kolosov (talk) 07:30, 11 December 2013 (UTC)

I can confirm this same bug across more MW versions than 1.22, effects 1.19 and 1.21 with different skins(Vector and a Custom skin). I can also reproduce, just use side-by-side preview, click save and your 'Main page' is rewritten. Very dangerous because it rewrites your main page without warning. All links on page to point back at current page are rewritten to 'Main page'. I'll file a bug report for InputBox. Hutchy68 (talk) 14:13, 16 January 2014 (UTC)

Thank you Hutchy. Here is a link to the bug for tracking purposes. Also a similar bug was filed and fixed recently. Dmitry.Kolosov (talk) 07:44, 9 April 2014 (UTC)

I think I've found something that might help (tested on our 1.24.1 instance).

It appears to be related to the WikiEditor extension, specifically, the preview/changes tabs that come with it. The solution that's worked for me is to disable these tabs in LocalSettings.php using

$wgDefaultUserOptions['wikieditor-preview'] = 0;

HTH Dshinks (talk) 16:41, 11 June 2015 (UTC)

Error on Special:SpecialPages

I've just upgraded to 1.22.0. Most things seem to be working but I can't display Special:SpecialPages. Looking in the error log I get a seg fault the first time I try after restarting Apache. Thereafter every attempt results in the message "zend_mm_heap corrupted". I'm running PHP 5.3.6 with MySQL 5.1.56 and APC 3.1.6. I have a long list of extensions installed. As they haven't been tagged for 1.22 yet I'm using the head version for all those that weren't bundled with MediaWiki. Any ideas? Prh47bridge (talk) 23:37, 8 December 2013 (UTC)

Some further experimentation suggests that it works occasionally but fails at least 9 times out of 10. Prh47bridge (talk) 23:52, 8 December 2013 (UTC)

Does it work when you have disabled all extensions? 88.130.110.231 01:43, 9 December 2013 (UTC)

Unfortunately no. I thought it might be extension related so tried disabling them but it didn't make any difference. Prh47bridge (talk) 09:34, 9 December 2013 (UTC)

What of http://stackoverflow.com/questions/2247977/what-does-zend-mm-heap-corrupted-mean have you tried already, and what was the outcome? AKlapper (WMF) (talk) 10:41, 9 December 2013 (UTC)

Yes I tried that. It didn't seem to make any difference. However, the problem now seems to have resolved itself without me doing anything at all. I'm guessing it was some kind of caching problem although I purged APC and restarted Apache which should have cleared everything. I'm glad the problem has gone away but I'd be even happier if I knew why! Prh47bridge (talk) 14:23, 9 December 2013 (UTC)

search by categories

Hi! I need search by categories as tags - that is, give 2-3 category in the search bar and the result is a list of pages that use all of the tags (categories)! Pchelinov.a (talk) 10:59, 9 December 2013 (UTC)

https://www.mediawiki.org/wiki/Extension:Multi-Category_Search ? AKlapper (WMF) (talk) 15:11, 9 December 2013 (UTC)

Not this... i need something https://ru.wikipedia.org/w/index.php?search=%D0%BA%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1%80%D0%B8%D0%B8+%D0%BF%D0%BE%D0%B8%D1%81%D0%BA&title=%D0%A1%D0%BB%D1%83%D0%B6%D0%B5%D0%B1%D0%BD%D0%B0%D1%8F%3A%D0%9F%D0%BE%D0%B8%D1%81%D0%BA

search by categories must work in search string on main page of Wiki Pchelinov.a (talk) 07:48, 11 December 2013 (UTC)

• Extension:CirrusSearch can make it so you can have queries like incategory:Foo to get all things in such a category
• Extension:DynamicPageList can also create intersected queries of categories and put it on a page

You may want to alter the page MediaWiki:pagecategories on your wiki to read Tags instead of categories. You can also alter what the category namespace is by doing something like $wgExtraNamespaces[NS_CATEGORY] = 'Tag'; Bawolff (talk) 16:14, 11 December 2013 (UTC)

Привет! В общем, по порядку:

Мне нужен такой же поиск как и на вашей MediaWiki.org. На спец странице Wiki написано что установлено Elasticsearch, как я понял у вас вся система на Linux системе...а у меня на Windows 2008 (есть конечно вариант переставить ОС...) и вот эти расширения: CirrusSearch, Elastica, MWSearch. На свою Wiki поставил Elastica, MWSearch, с ними нет проблем, но с CirrusSearch ошибки.

На elasticsearch.org скачал версию для Windows и установил, запустил службу. Пытаюсь добавить строку в LocalSettings.php Wiki require_once " $ IP / расширения / CirrusSearch / CirrusSearch.php " ;

после обновления Wiki, браузер показывает совершенно пустую белую страницу. В файле Errors Apache2 ошибке соответствует строка

[Thu Dec 12 12:23:44 2013] [error] [client 103.16.26.184] PHP Fatal error: require(): Failed opening required 'C:\\Program Files (x86)\\OTRS\\Apache\\htdocs\\wiki\\extensions\\Elastica/Elastica/lib/Elastica/Transport/Http.php' (include_path='.;C:\\php\\pear') in C:\\Program Files (x86)\\OTRS\\Apache\\htdocs\\wiki\\includes\\AutoLoader.php on line 1153, referer: http://srv.complex-it.ru:8080/wiki/index.php/%D0%A1%D0%BB%D1%83%D0%B6%D0%B5%D0%B1%D0%BD%D0%B0%D1%8F:%D0%A1%D0%BF%D0%B5%D1%86%D1%81%D1%82%D1%80%D0%B0%D0%BD%D0%B8%D1%86%D1%8B

и действительно, в папке установленной Elastica нет такого пути и файла Elastica/lib/Elastica/Transport/Http.php (проверил визуально). В папке расширения также такого файла по указанному пути нет. В чём моя ошибка?

Hi! Description:

I need the same search as well as on your MediaWiki.org. On special page says that the set Elasticsearch, СirrusSearch, Elastica, MWSearch. In my Wiki installed Elastica, MWSearch, no problems with them, but with CirrusSearch errors. On elasticsearch.org downloaded version of Windows and install it by running the service. Trying to add a string LocalSettings.php Wiki require_once " $ IP / extensions/ CirrusSearch / CirrusSearch.php " ; and after updating Wiki, the browser displays a completely blank white page. In the file Errors Apache2 error corresponds to line 'C:\\Program Files (x86)\\OTRS\\Apache\\htdocs\\wiki\\extensions\\Elastica/Elastica/lib/Elastica/Transport/Http.php' (include_path='.;C:\\php\\pear') in C:\\Program Files (x86)\\OTRS\\Apache\\htdocs\\wiki\\includes\\AutoLoader.php on line 1153, referer: http://srv.complex-it.ru:8080/wiki/index.php/%D0%A1%D0%BB%D1%83%D0%B6%D0%B5%D0%B1%D0%BD%D0%B0%D1%8F:%D0%A1%D0%BF%D0%B5%D1%86%D1%81%D1%82%D1%80%D0%B0%D0%BD%D0%B8%D1%86%D1%8B

And indeed in the folder installed Elastica no such path and file Elastica / lib / Elastica / Transport / Http.php (checked visually). Folder as the file extension in the specified path is not. What is is my mistake? Pchelinov.a (talk) 08:40, 12 December 2013 (UTC)

Sounds like you got the wrong version of elastica or something. Try downloading the version labelled master from the drop down box at Special:ExtensionDistributor/Elastica Sorry, the download instructions were incorrect for Elastica. I've updated them. The CirrusSearch extension is still a bit experimental, so some of the docs have a little bit to be desired. Bawolff (talk) 19:09, 18 December 2013 (UTC)

My Images Tag does'nt work correctly after upgrading

Hello

I found a very old Wiki (around 8 or 9 years) on our internal network, but it's still in production use of this guys. After migrating to a new Linux Server i've upgraded the wiki to the newsest Version "1.21.3".

After all i found out, that they stored all Images on a FTP Server and linked them with the Tag: Media:http://user:pass@ftpserver:/blah.blah.jpg

Thats awefull ugly in the Old wiki, bcs every Image have a "Media:" before the Image is Displayed, but the Image is Displayed. After the Upgrade this is not working anymore. I just see the Images as text like Media:http://user:pass@ftpserver:/blah.blah.jpg But the Image isnt display anymore.

When i delete one of the beginning "[" then the image is working. Also its working when i just enter the Url of an image, it's only NOT working with two "[" at the beginning. Already i tried the Function $wgAllowExternalImages , helps also nothing.

Worse thing, i cannot change the function to using it globally with one "[" bcs there are also over 500 uploaded images who are using the Image Tag correctly with two"[".

Until now i didn't figured out how i can show up this Images again, bcs manually it's not possible, we are talking about over 7000 Images linked.

I hope someone can give me help or a smart hint.

My Versions: RHEL 6.5

Mediawiki: 1.21.3

PHP: 5.4.22 (apache2handler)

MySQL: 5.5.33-cll-lve

Sorry, i cant post a link to the wiki, it's in a internal Network and not available from Public Internet.

Many Thanks

Fernando Tihozh (talk) 12:46, 9 December 2013 (UTC)

I wonder if this is related to bugzilla:19944. AKlapper (WMF) (talk) 15:10, 9 December 2013 (UTC)

Thank you very much for your hint. i've applied the Changes, but sad it did'nt helps :/

Cheers Tihozh (talk) 08:57, 10 December 2013 (UTC)

I don't know why that worked in your old wiki, but that syntax doesn't make any sense, since [[Media:]] links are for direct-linking files uploaded on the wiki itself, not external ones.

There's no way to make those links work as before, unless you hack into MediaWiki core (this could probably be done in a more clean way using a hook).

I'd recommend rewritting all such links with a bot. Maybe Extension:Replace Text could be used to easily do the replacements, using regular expressions. Ciencia Al Poder (talk) 10:30, 10 December 2013 (UTC)

Thanks for your Answer Cienca

i'm wondering myself how they work with this wiki (it's not used by myself). Horrifying that they hack this Wiki near 10 years like this :)

I will try the Replace extension, hopefully it works.

Thank you 195.112.95.126 12:47, 10 December 2013 (UTC)

[RESOLVED] MediaWiki 1.22.0 upgrade triggers HTTP 500 Internal Server Error

Hi. I'm using MediaWiki and upgraded it several times without any problems. On the weekend I tried to upgrade from 1.21.3 to 1.22.0. Firstly I used the web installer to do so. I got no error messages, but as soon as I tried to load my wiki I got an HTTP 500 Internal Server Error. I tried different browsers and even waited several hours. After that I downgraded to 1.21.3 - everything worked fine again. I retried this three times, using the web installer and update.php script without success. The loading time is about 30 seconds until the 500 error occurs.

Finally I downgraded again and the wiki is functional with 1.21.3. Does anybody have an idea or similar problems?

• MediaWiki: 1.21.3
• PHP: 5.3.27 (cgi-fcgi)
• MySQL: 5.5.31-log
• Web hoster: STRATO 91.64.203.49 (talk) 15:21, 9 December 2013 (UTC)

Hi!

Server errors usually are browser-independant; changing the browser usually does not help.

A server error 500 is a generic error message; it does not tell you anything about the details. Check the server error log (I guess it's the Apache error log)! It should contain more information on that error! 88.130.91.210 01:10, 10 December 2013 (UTC)

I was just setting up a brand new wiki with no mods or extensions on a shared server and ran into a similar problem. Initially the wiki installed without issue, and even displayed the main page. Any attempt to login, however, results in a long wait before giving a 500 error. Additionally, after experiencing this error, the entire wiki becomes similarly non-responsive, regardless of which page is visited, including previously functional pages. Other web pages outside of the wiki seem to work fine. Interestingly, in my case, the wiki is only non-responsive to the person who tried to login (perhaps a cookie issue? Haven't tested it thoroughly), until those other people try to login.

I've tried reinstalling with various options changed, to no avail. When I install under the previous stable version of Mediawiki, however, it runs perfectly for everyone.

I'm posting from my phone so I don't have my versions handy. I know they match or exceed the requirements to run a wiki, though. 99.113.213.192 23:21, 14 December 2013 (UTC)

Yes, I can only repeat myself:

A server error 500 is a generic error message; it does not tell you anything about the details. Check the server error log (I guess it's the Apache error log)! It should contain more information on that error! 88.130.74.3 23:26, 14 December 2013 (UTC)

Sorry, thought I had said something to that. The only server error log I have access to merely mentions that there was a 500 error, with no accompanying explanations or messages, from PHP or otherwise. That said, I can see how that would make my situation difficult to analyze. I mostly wanted to note that the other user was not alone in experiencing this phenomenon, and to perhaps shed more light on it to help discover a cause. 76.90.160.34 10:06, 15 December 2013 (UTC)

I have been experiencing this issue after upgrading from 1.21.3 to 1.22.0 as well.

I have even tried installing a clean installation of MediaWiki 1.22.0 with a new database, no third party extensions or modified settings. I still get the same result of a blank page while waiting for the site to load followed by a 500 error.

It seems a change between 1.21.3 and 1.22.0 is causing incompatibility with some webhosts. KemikalElite (talk) 07:09, 16 December 2013 (UTC)

Hi ,

Instead of going to the main page directly , try going to this address on your wiki:-

http://lead-board.com/wiki1/index.php?title=Special:SpecialPages

replacing lead-board.com/wiki1 with your wiki address and see what happens.

I did get this error as well shortly after upgrading to 1.22 . Leaderboard (talk) 06:40, 16 December 2013 (UTC)

Yeah, it really seems to be only a temporary issue during upgrade, but not after that: People come here and ask, but they do not provide further information, which would be needed to actually solve this. So I guess it must be solved kind of automatically already. I will set this to resolved for now; given the facts there is nothing to do here. 88.130.119.59 13:35, 16 December 2013 (UTC)

Decent forum extensions?

I'm looking to add an integrated forum extension to my Wiki, but all the extensions appear to be buggy and abandoned. I've already looked at the following:

• AWCForum
• LiquidThreads
• WikiForum
• MediaWiki Bulletin Board

Does anyone know of a decent forum extension that is still being maintained? TheAlmightyGuru (talk) 19:49, 9 December 2013 (UTC)

WikiForum is the closest to "forum" and "maintained", I'd wager (disclaimer: I've developed (significant portions of) WikiForum). LiquidThreads is what's being used here, but it has its shortcomings, too. MWBB is ancient and you really want to stay away from it. AWCforum has a strange, restrictive license plus the code wasn't that great.

My suggestion? Either start developing WikiForum further, or (get someone to) work on integrating a real forum (such as phpBB) with MediaWiki. Years ago Wikia released their customizations to phpBB as free and open source software; if you could find someone to turn those hacks to phpBB's core into a real phpBB plugin, that'd be great! After all, there's very little point in reinventing the wheel (forum software), when it's already been invented many times before. Unfortunately most (FOSS) forums don't really integrate with MediaWiki (for example, try finding a plugin/extension that allows a phpBB instance to use MediaWiki's user table as the "master", instead of phpBB's...) and even if there's some kind of a thing to handle logins, there usually isn't support for MediaWiki's wikitext, and that's considered essential by most people. Hence why not-so-ideal solutions like WikiForum & co. have been developed.

Free and open source software by nature is collaborative, which is why I'd want to encourage people to work on enhancing the existing tools instead of trying to fork or reinvent them. Jack Phoenix _(Contact) 20:28, 9 December 2013 (UTC)

Thank you, Jack, for such a fast reply and a helpful overview of the existing extensions. From what I've read from your posts on the WikiForum discussion page, the extension is in desperate need of an overhaul. I wouldn't know where to begin updating the program, but if anyone reading this wants to start working on an update, and has a decent idea of how to go about doing it, I could provide technical assistance and bug testing. TheAlmightyGuru (talk) 20:59, 9 December 2013 (UTC)

"[Nobody]" thanked me

[[User:[Nobody]|[Nobody]]] thanked you for your edit on VisualEditor/Feedback.

2 hours ago | View edit

Can someone explain to me what happened? There isn't a user called "[Nobody]". Deryck C.^Meta 22:46, 9 December 2013 (UTC)

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

it looks like the bug is fixed and awaiting deployment. Aude (talk) 22:52, 9 December 2013 (UTC)

Thanks Aude! I see from the logs that it was probably James F. who gave me that thank you. Did he try to suppress his signature? Or was it a general bug that affected all thank-yous? Deryck C.^Meta 23:32, 9 December 2013 (UTC)

Newbie Install

Trying to install MediaWiki 1.22 After clicking the install, I am never prompted for database info, only language for install. After clicking next, I get the following

Connect to database

[a55d1b52] /mediawiki/mw-config/index.php?page=DBConnect Exception from line 788 of /var/lib/mediawiki/includes/db/Database.php: DatabaseBase::factory no viable database extension found for type 'mysql'

Backtrace:

1. 0 /var/lib/mediawiki/includes/installer/WebInstallerPage.php(487): DatabaseBase::factory(string)
2. 1 /var/lib/mediawiki/includes/installer/WebInstaller.php(275): WebInstaller_DBConnect->execute()
3. 2 /var/lib/mediawiki/mw-config/index.php(61): WebInstaller->execute(array)
4. 3 /var/lib/mediawiki/mw-config/index.php(29): wfInstallerMain()
5. 4 {main} Mjberens (talk) 00:58, 10 December 2013 (UTC)

Hi!

This error happens, because you have selected MySQL as database, but obviously MySQL is not available in your environment. This happens when PHP does not feature MySQL support. Make sure to activate MySQL support in PHP; I guess it is installing this PHP module and restarting the server or compiling PHP again with the module. 88.130.91.210 01:12, 10 December 2013 (UTC)

I had to install php5-mysql. Only after that the message you have described went out.

But I was to install mediawiki to Postgresql.

lol) 89.151.167.60 14:09, 3 January 2014 (UTC)

How to get the edit Token and use Edit API

I intend to use mediawiki API:Edit to edit wiki pages. But I need to get the edit Token first. How can I get that? Do I need to use mediawiki API:login to log in first? Are login token and edit token the same thing? When I use API to log in, how can I get the edit token? Where can I get the value of token if I use action=tokens? I hope someone can help clear my mind. Thanks in advance! 173.34.124.57 (talk) 05:13, 10 December 2013 (UTC)

Use API:Tokens (action=tokens on api.php), so for example, https://en.wikipedia.org/w/api.php?action=tokens. Hope that helps. :) GeorgeBarnick (talk) 07:17, 10 December 2013 (UTC)

MWException

Hi,

My wiki is currently bugged. I think it may have something to do with the same info being submitted twice as a csv import.

As a side effect I'm unable to save pages as well as a few other things.

MediaWiki 1.20.4 PHP 5.3.3 (cgi-fcgi) MySQL 5.0.92-50-log

The error I get using $wgShowExceptionDetails = true; bring up the following,

Thanks in advance for any info

Internal error
Jump to: navigation, search

The Title object did not provide an article ID. Perhaps the page doesn't exist?

Backtrace:

#0 /websites/123reg/LinuxPackage23/yo/ur/si/yoursitehost.co.uk/public_html/partymixers/manager/includes/parser/ParserOutput.php(390): LinksUpdate->__construct(Object(Title), Object(ParserOutput), true)
#1 /websites/123reg/LinuxPackage23/yo/ur/si/yoursitehost.co.uk/public_html/partymixers/manager/includes/WikiPage.php(1749): ParserOutput->getSecondaryDataUpdates(Object(Title))
#2 /websites/123reg/LinuxPackage23/yo/ur/si/yoursitehost.co.uk/public_html/partymixers/manager/includes/WikiPage.php(1617): WikiPage->doEditUpdates(Object(Revision), Object(User), Array)
#3 [internal function]: WikiPage->doEdit('{{Individual Mo...', 'Add more months...')
#4 /websites/123reg/LinuxPackage23/yo/ur/si/yoursitehost.co.uk/public_html/partymixers/manager/includes/Article.php(1820): call_user_func_array(Array, Array)
#5 /websites/123reg/LinuxPackage23/yo/ur/si/yoursitehost.co.uk/public_html/partymixers/manager/extensions/DataTransfer/includes/DT_ImportJob.php(77): Article->__call('doEdit', Array)
#6 /websites/123reg/LinuxPackage23/yo/ur/si/yoursitehost.co.uk/public_html/partymixers/manager/extensions/DataTransfer/includes/DT_ImportJob.php(77): Article->doEdit('{{Individual Mo...', 'Add more months...')
#7 /websites/123reg/LinuxPackage23/yo/ur/si/yoursitehost.co.uk/public_html/partymixers/manager/includes/Wiki.php(594): DTImportJob->run()
#8 /websites/123reg/LinuxPackage23/yo/ur/si/yoursitehost.co.uk/public_html/partymixers/manager/includes/Wiki.php(556): MediaWiki->doJobs()
#9 /websites/123reg/LinuxPackage23/yo/ur/si/yoursitehost.co.uk/public_html/partymixers/manager/includes/Wiki.php(447): MediaWiki->restInPeace()
#10 /websites/123reg/LinuxPackage23/yo/ur/si/yoursitehost.co.uk/public_html/partymixers/manager/index.php(59): MediaWiki->run()
#11 {main}

Budstellabecks~mediawikiwiki (talk) 17:47, 10 December 2013 (UTC)

You are obviously processing jobs in the background. In your stacktrace it is the job "DTImportJob". This job tries to update a page, but it seems like this page is not there. So the correct thing to do would be not to try updating the page, but to try creating it.

The problematic job obviously comes with the extension DataTransfer_PS, so I would check, if an update for this extension is available. 88.130.127.250 21:01, 10 December 2013 (UTC)

Hi,

I have the latest version already installed and still getting the same error Budstellabecks (talk) 00:33, 2 January 2014 (UTC)

Then the extension obviously is not compatible with recent versions of MediaWiki. I don't know if the mechanism of page creation/page update changed within the last versions of MediaWiki, however at least with current versions the extension does not seem to be able to work correctly. You can try contacting the extension author so that he can fix this issue. 88.130.94.158 13:39, 2 January 2014 (UTC)

fatal error message: SemanticMediaWiki

Hi Everyone,

I've installed mediawiki v1.22.0 and upgraded my old wiki mw-config and update.php. However when I load the wiki, I see this message:

Warning: Parameter 3 to addHTMLclass::hAddHtmlTag() expected to be a reference, value given in /var/www/html/wiki/includes/parser/Parser.php on line 4020 Warning: Parameter 3 to addHTMLclass::hAddHtmlTag() expected to be a reference, value given in /var/www/html/wiki/includes/parser/Parser.php on line 4020 Warning: Parameter 3 to parseFeed() expected to be a reference, value given in /var/www/html/wiki/includes/parser/Parser.php on line 4020 Fatal error: Class 'SMWSQLStore3' not found in /var/www/html/wiki/extensions/SemanticMediaWiki/includes/SMW_GlobalFunctions.php on line 286

I don't think I'm missing an extension, so I'm not sure what it is referring to. Any help is greatly appreciated.

Thanks,

Roman Rwberdes (talk) 19:45, 10 December 2013 (UTC)

Did you upgrade Semantic MediaWiki to match the 1.22.0 version as well? Ciencia Al Poder (talk) 10:39, 11 December 2013 (UTC)

Hi Ciencia,

I'm using the latest version of SemanticMediaWiki.

Thanks,

Roman Rwberdes (talk) 16:24, 11 December 2013 (UTC)

Appanrently, this is not a SMW bug.

addHTMLclass::hAddHtmlTag is part of Extension:AddHTML, which is unmaintained (and apparently incompatible with current version of MediaWiki). That causes the warning, which probably causes some other errors in the code which ends in SMW to not load properly all the required classes.

Try disabling the AddHTML extension. Ciencia Al Poder (talk) 10:25, 13 December 2013 (UTC)

Hi Ciencia,

I replaced addHTML with SecureHTML and that got rid of the addHTML errors. However I'm still seeing the following errors. Do you or anyone else know what might be causing these?

Thank you!

Warning: Parameter 3 to parseFeed() expected to be a reference, value given in /var/www/html/wiki/includes/parser/Parser.php on line 4020 Fatal error: Class 'SMWSQLStore3' not found in /var/www/html/wiki/extensions/SemanticMediaWiki/includes/SMW_GlobalFunctions.php on line 286 Rwberdes (talk) 15:54, 16 December 2013 (UTC)

You should try to disable all extensions except SMW, and see if the problem still persists. If not, then another extension is producing the problem (and for the filename where that happens it's not clear for me what extension may be producing this. You can then enable extensions one by one until you find the culprit. Ciencia Al Poder (talk) 10:20, 17 December 2013 (UTC)

[RESOLVED] SubSidebar does not expand

Hi

After upgading to MediaWiki 1.22 the links under the sections in the Sidebar became automaticly hidden under the headings. I would like the sections to be open and not hidden. Is this possible? http://heimskringla.no JJ 31.45.54.164 (talk) 20:51, 10 December 2013 (UTC)

Hi!

That is the collapsible navigation feature, which in 1.22 is integrated into the Vector skin. Formerly it was part of the Vector extension. With the extension you could disable collapsing with

$wgVectorFeatures['collapsiblenav']['global'] = false;

Does that also work with the skin? 88.130.127.250 21:25, 10 December 2013 (UTC)

This is not working! 31.45.54.164 21:53, 10 December 2013 (UTC)

I have just checked the according commit

https://git.wikimedia.org/commitdiff/mediawiki%2Fcore.git/603e6589e7678be099cea50129fde9696ef48c8b

and it does not look like there would be an option to disable this feature.

A nice way would be if it was possible to modify $out->addModules() as you can do with the new hook for $out->addModuleStyles(), however for addModules() I have not seen a hook.

One option might be to add this to the bottom of LocalSettings.php:

unset($wgResourceModules['skins.vector.collapsibleNav']);

This should prevent the skin from loading the collapsiblity-stuff (untested). 88.130.127.250 00:36, 11 December 2013 (UTC)

This did not work. 31.45.54.164 05:23, 11 December 2013 (UTC)

You could modify it with CSS (see Manual:Interface/Stylesheets). Each sidebar section has a element with a specific ID. You can use CSS to control the format, for example, force the display of the contents:

This example forces the content to be displayed always, for the Print/export element of the sidebar:

/* force the display of the contents of the section */
#p-coll-print_export  .body {
	display:block !important;
}
/* Option 1: hide the header */
#p-coll-print_export h3 {
	display:none;
}
/* Option 2: just hide the arrow in the header */
#p-coll-print_export h3 {
	background:none !important;
}

Ciencia Al Poder (talk) 10:58, 11 December 2013 (UTC)

Thanks Ciencia. This work for the print_export section only, using the /* force the display, but could not get it to work on the other section. Do you know where I find the specific ID for the other section I'm using in my wiki at http://heimskringla.no ? JJ 31.45.54.164 18:11, 11 December 2013 (UTC)

View the source code of the page and search for "p-coll-". 88.130.79.219 19:18, 11 December 2013 (UTC)

Thanks, this is working just great :-) 31.45.54.164 21:38, 11 December 2013 (UTC)

I have created (and I am using it on my MediaWiki 1.23 wikis) code that can be added to LocalSettings.php to disable collapsible sidebar in MediaWiki 1.23 without modifications of MediaWiki files. The code is available at:

https://github.com/DavisNT/CodeSamples/blob/master/MediaWiki%20hacks/Disable%20Collapsible%20Sidebar%20on%20MW%201.23.php DavisNT (talk) 16:24, 28 June 2014 (UTC)

any way to reverse the effect of your code, and return to default?

Thanks 188.220.44.109 14:55, 15 July 2014 (UTC)

Remove code from LocalSettings.php and empty the cache dir. 87.148.139.2 08:17, 10 September 2014 (UTC)

[RESOLVED] Fatal exception of type TimestampException after upgrading to Mediawiki 1.22

I just upgrade from Mediawiki 1.21.3 to 1.22 and When i try to view history or edit I get this error

Fatal exception of type TimestampException 83.4.56.148 (talk) 22:12, 10 December 2013 (UTC)

What message do you get when you set $wgShowExceptionDetails = true; at the bottom of LocalSettings.php and reproduce the error after that? 88.130.127.250 22:59, 10 December 2013 (UTC)

I got this:

[41641d83] /index.php?title=Main_Page&action=history Exception from line 342 of /home/soft/public_html/escforumwiki/includes/Timestamp.php: MWTimestamp::setTimezone: Invalid timezone.

Backtrace:

1. 0 /home/soft/public_html/escforumwiki/includes/Timestamp.php(377): MWTimestamp->setTimezone(string)

#1 /home/soft/public_html/escforumwiki/includes/actions/HistoryAction.php(181): MWTimestamp::getLocalInstance()

#2 /home/soft/public_html/escforumwiki/includes/Action.php(567): HistoryAction->onView()

#3 /home/soft/public_html/escforumwiki/includes/Wiki.php(448): FormlessAction->show()

#4 /home/soft/public_html/escforumwiki/includes/Wiki.php(312): MediaWiki->performAction(Article, Title)

#5 /home/soft/public_html/escforumwiki/includes/Wiki.php(602): MediaWiki->performRequest()

#6 /home/soft/public_html/escforumwiki/includes/Wiki.php(467): MediaWiki->main()

#7 /home/soft/public_html/escforumwiki/index.php(49): MediaWiki->run()

#8 {main} 83.4.56.148 23:09, 10 December 2013 (UTC)

Please edit the file includes/Timestamp.php, find public function setTimezone, that should be around line 340, and change the error message from this

throw new TimestampException( __METHOD__ . ' Invalid timezone.' );

to this

throw new TimestampException( __METHOD__ . ' Invalid timezone: ' . $timezone );

Cause the error again and tell us: What is the value of $timezone? 88.130.127.250 23:45, 10 December 2013 (UTC)

CET-1CEST,M3.5.0,M10.5.0/3 83.4.56.148 23:55, 10 December 2013 (UTC)

What you posted there looks very ... interesting.

You have obviously set $wgLocaltimezone to exactly that value in LocalSettings.php. Please double-check that this value is correct. 88.130.127.250 00:09, 11 December 2013 (UTC)

That fixed the problem, thanks! 83.4.56.148 00:13, 11 December 2013 (UTC)

Ok and what have you changed? 88.130.127.250 00:16, 11 December 2013 (UTC)

From 'CET-1CEST,M3.5.0,M10.5.0/3' to 'CET' 83.4.56.148 00:23, 11 December 2013 (UTC)

Yeah, that should really work.

I just learned that your previous date format means something like "Central European Time, 1 hour east from Greenwich, daylight saving starts on the last Sunday in March and ends on the last Sunday in October at 3 AM.

Btw: You have specified a date, but not a time for the start of summertime; I guess that should then be "M3.5.0/2" for 2 o'clock. can you test, if that value works:

CET-1CEST,M3.5.0/2,M10.5.0/3 88.130.127.250 00:42, 11 December 2013 (UTC)

link scroll position

I modified the vector skin using only css to add design with a fixed header and nav, only problem I am having is the links scroll to 0px which is behind the header. I have tried to adjust this with css but I am unable to get the scroll to go anywhere other than to 0px behind the header. Any thoughts would be appreciated. 72.37.249.60 (talk) 22:18, 10 December 2013 (UTC)

Hi!

I assume you are speaking of the links inside the menu? Without seeing your skin with the modifications it is hard to say, but

• maybe you can fix that with a z-index?
• maybe you did a nesting with an absolutely positioned element, which causes other elements to behave unexpectedly

I always suggest using Firebug for Firefox to inspect the CSS and to see, which styles exactly are actually being used for the different elements. For me that has often been a great help! 88.130.127.250 23:02, 10 December 2013 (UTC)

Sorry I did not describe the issue that well.

I am running current versions of everything.

In place of the entire page scrolling I used fixed positioning to lock the header and left navigation in place, which keeps the clients logo and site navigation visible at all times.

The page opens correctly positioned as expected and the content scrolls properly with the header and left navigation remaining in a fixed position.

The problem I am having is when I click a link, such as in the auto-generated contents index menu, and it scrolls to a section, the div content.mw-body scrolls to position at the top of the page as if the header was scrolled out of the way, it does not scroll to the position under the fixed header which is now 152px in height, This causes the correct heading to be hidden behind the fixed header. I cannot use a z-index as this will cause the content to appear on top of the fixed header. Everything I have tried to change using css has had no affect on the position the links scroll to, always 152px too far. Again, any thoughts are appreciated. 72.37.249.60 15:45, 11 December 2013 (UTC)

You say that you have set the header and the left menu at a fixed position. Now when you click a link, e.g. in the table of contents, then this section heading is scrolled to the top of the viewport. The content then ends up at the same place, where your fixed header is so that the content is partly invisible.

Basically this could be solved with an iframe, which sits directly below your fixed menu and all the content is in that iframe. Iframes are old techniques and I don't know how to get MediaWiki to put your stuff inside an iframe.

I thought about whether it might be possible to give mw-body a margin-top of additional 152px, however, this would also move it down, when you are at the top of the page, which is not wanted.

I think maybe it is possible to do that by using a mixture of fixed and absolue positions, but I currently don't know how: I think it does not help to position the body with an absolute position: It then would start at the right place, but when you scroll, it would still go below the header. Also using a fixed position for the content does not help, as you basically want the content to scroll through the viewport.

So you want the element to be positioned relatively or absolutely, but its margin-top should be positioned fixed. This will not work; at leat not when you want both with the same element.

Maybe it is possible to fix that with jQuery? When someone clicks a link to an anchor inside the content (inside .mw-body?), then let jQuery scroll the viewport these 152 pixels up so that the heading appears in the visible area. 88.130.79.219 18:15, 11 December 2013 (UTC)

You are correct but I cannot use an iframe with this project.

I have gone through adjusting the top margins, creating an empty area below the header when the page loads, but the links still direct the anchor to the top of the viewport hidden by the fixed header.

It appears that the links anchor position is being set by script and scrolls it to the top of the viewport.

I have yet to find where that is so I can offset it by the header height. Any input is appreciated. 72.37.249.60 23:24, 11 December 2013 (UTC)

No, I think the link anchors are IDs, which are always present. Is clicking the TOC even the deciding event? The fact that the content also starts being hidden when you just scroll down - without clicking a link - is no problem as it just does not matter that the top-part of the content is not visible then.

But I think that is a problem for any link, which leads to an anchor; either to one on the same page or to one on another page.

I would try this with jQuery: When you click a link inside .mw-body and this link leads to an anchor, then let jQuery move the viewport additional 152px down. 88.130.79.219 23:59, 11 December 2013 (UTC)

Yes you are correct, the anchors are ID's that are always present, the .mw-body is repositioning to place the anchor at the top of the viewport, and it does occur for any link to a topic. Links to other pages are positioned correctly unless directed to a topic on the page.

I am going to try and resolve this with jQuery as you suggested, maybe change the offset or add to the scroll position. I am trying to find where the click event is occuring for the vector skin and where I can capture it to change the scroll event across all pages. Any idea where to find this event? 72.37.249.60 16:20, 12 December 2013 (UTC)

You've got me there: I don't know how that can be achieved in code.

However, I can tell you which logic I would use:

I would try to do this based on a change in the URL: If the URL changes and if it contains an anchor, then scroll additional 152px down. 88.130.78.142 17:56, 12 December 2013 (UTC)

I did get this to work using jQuery.

Added a function to vector.js that watches clicks in #bodyContent, if it contained a hash it will grab the hash and animated a scrollTop: anchorTag.offset.top - 152

Easy enough and done.

Thanks for the input. 72.37.249.60 17:06, 13 December 2013 (UTC)

Can you post the whole code, which you added to vector.js, please? I would like to know how that works as well! :-)

One further note: Instead of changing vector.js, which will get overwritten after each MediaWiki update, you should try, if it also works, if you add your code to the wiki page MediaWiki:Vector.js. 88.130.115.236 17:50, 13 December 2013 (UTC)

I was hoping to modify the click event that is already occurring, but I could not find it.

This code was added to the jQuery function of vector.js and is providing the results I needed.

It adds an animated scroll and offsets the scrollTop position of the anchor.

$('div#bodyContent a').click(function(e) {
	if ($(e.target.hash)) {
		var hash = e.currentTarget.hash.substring(1);
		var anchorTag = $("span[id='" + hash + "']");
		$('html, div#content.mw-body').animate({
			scrollTop : anchorTag.offset().top - 152
		}, 250);
	}
});

72.37.249.60 19:13, 13 December 2013 (UTC)

Why must the 1.22.0 access the mysql through the /var/lib/mysql/mysql.sock?

I update 1.21.3 to 1.22.0. I have set the socket of mysql to another file. But the 1.22.0 must use /var/lib/mysql/mysql.sock to access the DB. I create a symbol link file to link my socket. "php update.php" is OK. But the website still says that can not access DB. 2402:F000:1:4D01:FCDF:8CE6:22F2:1E8A (talk) 01:35, 11 December 2013 (UTC)

Maybe related to switching from using mysql to mysqli for db access.

If you currently have $wgDBServer set to localhost, changing it to be 127.0.0.1 can force php to use the network instead of a local sock. Bawolff (talk) 15:53, 11 December 2013 (UTC)

In php.ini, I also set the mysqli.default_socket to my socket file. Then it's ok now. 2402:F000:1:4D01:D0C5:7D94:8F25:825D 03:29, 12 December 2013 (UTC)

Using SSH to use update.php aborts

When I used SSH to run update.php , what happened is that it aborted , saying that the PHP version is 4.4.8 while infact my PHP version is 5.3.24 . Also , I do not have PHP4 and PHP5 running together.

Why is this happening? View picture

EDIT1 - MediaWiki version - 1.22 , PHP - 5.3.24 , MySQL - 5.0.96 Leaderboard (talk) 02:48, 11 December 2013 (UTC)

Hi!

This error happens for some people. The problem is that there in fact are two different PHP versions: One for the webserver and one for the shell. While the webserver uses PHP 5.3, you have another PHP version on the shell. You can verify that with the command php -v, which on the shell will display you version 4.4.8. Check, if you can execute a newer PHP version on the shell by using a different command: That might be php5 or php53. If another version is available and if so under which name depends on your setup. If it does not work, ask your hoster; he will surely know. :-) 88.130.127.250 03:53, 11 December 2013 (UTC)

Why must the 1.22.0 access the mysql through the /var/lib/mysql/mysql.sock?

This post by Jasper Deng was moved on 2013-12-11. You can find it at Project:Support desk/Flow/2013/12#h-Why_must_the_1.22.0_access_the_mysql_through_the_/var/lib/mysql/mysql.sock?-2013-12-11T01:35:00.000Z. Jasper Deng (talk) 09:26, 11 December 2013 (UTC)

About symlinking the "serialised" directory

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

The manual on creating a wiki family states in one section that the "serialised" folder should not be symlinked. I guess there is a good reason and I would like to know about it. The reason not to do it for the other folders mentioned is quite obvious but here I ran out of knowledge. [[kgh]] (talk) 13:43, 11 December 2013 (UTC)

I don't think that info is correct. I see no reason not to symlink the serialised folder. (In theory you can custom generate some of the serialized content using maintenance scripts, and have it be different for different wikis, but there's really no sane reason to do that) Bawolff (talk) 15:50, 11 December 2013 (UTC)

Heiya Bawolff, thank you for your assessment. I guess I will give it a shot and see if the wiki deteriorates somehow. Shouldn't though considering your thoughts. Cheers [[kgh]] (talk) 09:59, 13 December 2013 (UTC)

If it explodes, do let me know. Bawolff (talk) 07:08, 14 December 2013 (UTC)

Definitely, but no unexpected behaviour so far. I will leave the money on the counter if continues to work out. :) [[kgh]] (talk) 07:58, 14 December 2013 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

How do I get a complete git checkout of all the files needed for MW to work?

Hi,

When I download the latest MW from

https://toolserver.org/~krinkle/mwSnapshots/snapshots/mediawiki-core/mediawiki-latest.tar.gz

then extensions/ dir is empty.

Question

How do I get a complete checkout of all the files needed for MW to work?

Hugs, Sandra 130.225.70.14 (talk) 16:18, 11 December 2013 (UTC)

Hello Sandra, see Download from Git. Qgil (talk) 23:29, 13 December 2013 (UTC)

MediaWiki upgrade services

Hi Everyone,

I'm not sure if this question it allowed at this site. But I was wondering if anyone could suggest a good and reasonably priced mediawiki upgrade service. I've been trying to upgrade our mediawiki for the last 5 months and I always find myself at a dead-end eventually.

Thanks,

Roman Rwberdes (talk) 16:27, 11 December 2013 (UTC)

I know I'm a couple of months late, but you can see the Professional development and consulting or contact me. ☠MarkAHershberger☢(talk)☣ 16:07, 5 February 2014 (UTC)

Making an edit propigate to multiple wikis

I would like to set up two Mediawiki instances on separate servers. I am looking for a way to add an option for a page create or an edit on Wiki A to propagate that same edit to Wiki B. For example, If you created a page on Wiki A and were to check a box at the bottom of the page, on saving, that page would not only be saved to A but also to B. I have looked through the extensions however I have not found one suitable. Anyone point me in the right direction? 2607:2800:102:2FF:A5BC:5C85:3CE4:63E4 (talk) 21:11, 11 December 2013 (UTC)

But basically both wikis should be different and should also contain different content? Then this cannot be done using one and the same set of database tables. You could maybe use the MediaWiki export feature to export the changes in the one wiki and to import it in the other. 88.130.79.219 22:46, 11 December 2013 (UTC)

I have not looked into the Mediawiki API but perhaps there are hooks in there that will let me accomplish this 2607:2800:102:2FF:A5BC:5C85:3CE4:63E4 16:52, 12 December 2013 (UTC)

The faster FTL does not work properly in openssd board

recently I bought openssd board, at first I download greedy or tutorial FTL into the board, it does work ok. However when I use faster FTL, everytime when I copy data into SSD, it will crash. My testing environment:

    source code version : v1.1.0 
    compile FTL code in windows by using Sourcery G++ toolchain.
    testing environment: Ubuntu 12.10 and mount SSD in /mnt directory.
    The SSD capacity is 64G, however when I copy around 8-10 Gbytes, the system will crash, and show kernel BUG at /build/buildd/linux-3.2.0/fs/jbd2/transaction.c: 884! (other error message cannot see due to screen flush)

    Is there any clue for it ? thanks 203.116.198.69 (talk) 02:41, 12 December 2013 (UTC)

Hi there!

I am sorry to tell you, but I guess you are at the wrong place here. Here are guys who know MediaWiki, the software used on Wikipedia. That is what we can help you with. I think you maybe came from this site: http://www.openssd-project.org/wiki/The_OpenSSD_Project and it might be that you can put your question there. Maybe you came here, because you followed the help link on that wiki; which leads here.

You can e.g. contact user Jinsoo on his talk page; he is an admin and did the last edit in that wiki. However, you will need an account to do so - and you cannot create accounts there yourself.

Another idea might be to look for a support forum of your hardware manufacturer and to ask there. 88.130.78.142 03:32, 12 December 2013 (UTC)

OK, Thanks for your information. 203.116.198.69 05:11, 12 December 2013 (UTC)

Multilingual Mediawiki

I am running a mediawiki website which contains about 8000 pages. Recently i have received the translated version of all the 8000 pages. So here my squestion is how can i link those translated pages? i want to show a link to the other langeage version similar as the Wikipedia. What will be the best approach to import the contents? Nasir Khan Saikat • talk • 07:20, 12 December 2013 (UTC)

If you have an interwiki prefix that's a language code, it will be treated as an interlanguage link - See Help:Interwiki#Interwiki_links_to_other_languages. The other language content is then in a separate wiki. This is how wikipedia does multiple languages. Bawolff (talk) 16:44, 12 December 2013 (UTC)

[RESOLVED] IE11 display problems

Problem is solved by giving #p-search element a negative z-index.... thanks for all the input.

When upgrading to IE11, only half of the links in the mediawiki sidebar function. Below a certain point in the list, they do not function. They ARE visible but do not respond when clicked. This exact problem also occurs using FireFox. With IE10, we had different problems with the display (problems with page elements displayed on top of each other) but only when in Compatibility Mode. Any ideas?

MediaWiki 1.20.2 PHP 5.3.8 (cgi-fcgi) MySQL 5.0.51b-community-nt

Thank you very much, Jeff Freund 85.229.204.91 (talk) 09:48, 12 December 2013 (UTC)

Hi Jeff,

the behaviour, which you describe is not "usual" and I also do not know of cases where something like that happened on Wikipedia.

Several ideas:

• have you changed the CSS in some way? Which skin are you using btw?
  • Maybe in the files in the file system?
  • Maybe on the according wiki pages like MediaWiki:Common.css or MediaWiki:Vector.css?
• Is your logo somehow "strange"? Like really big or so?
• Are you using extensions or skins, which modify the output?

Basically: If you just use an unmodified MediaWiki, maybe ideally version 1.22, which is brandnew, and no changes in the skin, then it should also work in the most current browsers. 88.130.78.142 13:13, 12 December 2013 (UTC)

Hi... thanks very much for answering. One of our engineers did an "inspect element" on the sidebar. He says that all links are there but the ones in the bottom half of the column are blocked by the MW search field which id located just below the column of links. In the picture he sent, the 'live' area of the search field appears to be 13-14 lines high (as opposed to the one line high search box that is displayed) and covers exactly the links that are unresponsive. This makes a lot of sense in terms of the other problems we've had....all seem related to parts of the column being somehow "blocked".

Questions then: Is there some way to adjust the size of the search field?.... maybe in the CSS? How is this search field referred to in a CSS?

Whatever causes it, it doesn't happen with IE9 or IE10 (when NOT in compatibility mode).

P.S. the skin is a customized version of monobook and has shown no problems until IE10-11.

Thank you so very much for your attention ... wouldn't know how to proceed without it.

Jeff 85.229.204.91 16:33, 12 December 2013 (UTC)

I think they may have fixed it in Mediawiki 1.22 not sure try updating to see if has fixed the issue 90.215.167.9 17:36, 12 December 2013 (UTC)

You say you use a custom skin, which is based on monobook - while updating MediaWiki would be wise (security-wise), it will not fix your custom skin.

I do not know what causes the problem for you exactly, but if I remember correctly the search box in monobook is located below the sidebar anyway. Meaning: Check if it works in your wiki with monobook and then take a tool like Firebug and see, which CSS styles are different in your custom skin compared to monobook. Especially paddings and margins are interesting; maybe you also did something stange with postion: ....

You say that this problem appears in Firefox and in current versions of IE. That makes me think that it is really a "bug" in the default styles of your custom skin; not a browser hack. Maybe it is even the other way round: You use some browser hack for old IEs and that fixes it for them - keeping it broken for basically any browser, which does intereprete CSS as expected out of the box. 88.130.78.142 17:42, 12 December 2013 (UTC)

aha .... I see what you mean ... I'll try the comparison btwn monobook & the custom skin. Can you help me to know how to locate the Search box in a CSS? I recall having an awful time trying to move sidebar elements up & down... resorting to a trial & error approach finally :-( Again, thank you very much. 85.229.204.91 17:55, 12 December 2013 (UTC)

In Firebug it's really easy: Install it, go to your website, press F12. In the menu, which opens then, in the top row the second icon is a rectangle with blue border. Its hover text says something like "Click an element on the page to inspect it." Click the icon and then in the page click the searchbox. Firebug will automatically show you the expanded HTML code and the CSS rules with their cascade at the right side.

You say you had problems sorting the elements in the sidebar. In that context - speaking about CSS problems - I guess you did that with CSS as well? I nearly don't dare telling you, but you know that you can sort them using the wiki page MediaWiki:Sidebar? 88.130.78.142 18:00, 12 December 2013 (UTC)

no...no.... not THAT kind of sorting. I meant getting the navigation column up beneath the logo, the search box under that & then the toolbox under that. I couldn't figure out what they were called when I looked in the CSS. 85.229.204.91 18:30, 12 December 2013 (UTC)

You need to try upgrading because they would have fixed it by now in 1.22 due to it being released last week and due to windows 8.1 being released in October Paladox2017 (talk) 18:41, 12 December 2013 (UTC)

Problem is solved by giving #p-search element a negative z-index.... thanks for all the input. 85.229.204.91 22:33, 12 December 2013 (UTC)

Mediawiki WYSIWYG Skin IE9 problem

hey,

ive got a little Problem :D.

Quick Infos: Mediawiki 1.17

WYSIWYG Extension

Everything works great with FF and IE10 - but there are many users with IE9.

1. We use Monobook as skin. When i try to open the editor the following happens:
http://s7.directupload.net/images/131212/idkg5no4.jpg

(which means "not enough storage") And the editor doesnt appear

2. I googled and found some links:

http://krasimirtsonev.com/blog/article/CKEditor-Not-enough-storage-is-available-to-complete-this-operation

He says thats cause IE can only do 31 times "createStyleSheet" and offers a workaround.

3. If i change the line in document.js in WYSIWYG\ckeditor\_source\core\dom

from

appendStyleSheet : function( cssFileUrl )

{
if ( this.$.createStyleSheet )
this.$.createStyleSheet( cssFileUrl );
else
{
var link = new CKEDITOR.dom.element( 'link' );
link.setAttributes(
{ rel :'stylesheet',
type : 'text/css',
href : cssFileUrl
});

this.getHead().append( link );
}

to appendStyleSheet : function( cssFileUrl )
{
if ( false )
this.$.createStyleSheet( cssFileUrl );
else
{
var link = new CKEDITOR.dom.element( 'link' );
link.setAttributes(
{
rel :'stylesheet',
type : 'text/css',
href : cssFileUrl
});

this.getHead().append( link );
}

it looks like this:

http://s7.directupload.net/images/131212/b2hn5a97.jpg

Doesnt work too :D. But i have no idea what the else-block exactly do and about the whole thing with php, js and css :D

4. I started with SMW+ (Datawiki), and there is a default skin "ontoskin3". With them everythin is cool - so i think this skin "fixes" the createstylesheet problems. But i cant figure out how - i analyzed the skins, and theyre very different - and im a nub in javascript and css.

I would be very very appreciated if someone could help me out here - i spend a lot of hours and im not able to get it working :D:

My Skin Direcory can be downloaded here:
http://uploadboy.com/h12tvnuu6jn5.html

Regards, 194.156.246.226 (talk) 14:52, 12 December 2013 (UTC)

Please update to Mediawiki 1.19 or higher please. Because 1.17 is unsupported now. If you have php 5.2 please use 1.19 if you have php 5.3 or higher you can use 1.20 or higher. 90.215.167.9 17:38, 12 December 2013 (UTC)

the problem is the editor.

on

http://www.mediawiki.org/wiki/Extension:WYSIWYG#Download

i saw that the extension is only for 1.17.

I tried this with 1.19 and 2.1 but it didnt work 100% - everytime so many bugs.

Or is the difference between "User patched" and "user made" that patched is stable and full working?

I know 1.17 isnt supported, but maybe someone has a clue about the CreateStyleSheet-thing :D

Regards 91.46.115.106 20:50, 12 December 2013 (UTC)

Hi there is a new extension similer to WYSIWYG it is called visual editor which you can see the text the way you see it on the page and edit it or you could try wikieditor 86.173.54.253 07:45, 13 December 2013 (UTC)

Enable extension:flow

Hi how can I enable extension: flow because I would like to try it please Paladox (talk) 18:39, 12 December 2013 (UTC)

For information concerning Extension Flow see Extension:Flow. 88.130.78.142 22:36, 12 December 2013 (UTC)

I have but it doesent tell how to enable it on Mediawiki or how to use it is just telling you about it and how to install it 86.173.54.253 07:43, 13 December 2013 (UTC)

The page in fact does tell you how to enable the extension, that is by simply installing it. However, it does not say much about what the extension does. That might be caused by the fact that this is an early alpha version and maybe the developers do not yet know, what exactly the extension should do in the future.

Also take care of the notes on the page, one of them being: "Installation? Just don't." I think that sums it up nicely. 88.130.115.236 14:05, 13 December 2013 (UTC)

Wiki syntax error, unexpected

My wiki after I LocialSettings.php into the root directory, the following message appears

"Parse error: syntax error, unexpected '<' in /home/a1330563/public_html/zh-tw/LocalSettings.php on line 147"

I check out my LocalSettings.php, line 147 is

<script type="text/javascript" src="http://stats.hosting24.com/count.php"></script>

I do not know what that means :( 42.77.16.253 (talk) 11:37, 13 December 2013 (UTC)

Hi!

That means that you made a mistake in that file, either in line 147 or somewhere before that. It tells you that the smaller-than sign is not allowed at that place.

The file must contain valid PHP code. But the line, which you posted is HTML with a JavaScript, which is no valid PHP code.

What did you want to do? 88.130.115.236 13:58, 13 December 2013 (UTC)

I'm pretty sure you're on a free hosting service, which automatically adds scripts to the page to display ads, and it added that script when MediaWiki prompted you to download the generated LocalSettings.php file. If you're installing MediaWiki in such host, it will not work, because it will try to append that script in load.php URLs and will break scripts and styles of MediaWiki. Ciencia Al Poder (talk) 15:53, 15 December 2013 (UTC)

auto-update a mediawiki upload?

We present the latest install file (*.zip) for our product on our mediawiki. We would like to update this file automatically from our daily build WITHOUT having to manually create a new link to it. Is anyone aware of a technique or extension that might enable this scenario? Have tried replacing the uploaded file manually with a new file that is named the same, but the link from the wiki breaks and will no longer retrieve it.

MediaWiki 1.20.2 PHP 5.3.8 (cgi-fcgi) MySQL 5.0.51b-community-nt

Thank you very much for any help, Jeff Freund 85.229.204.91 (talk) 11:43, 13 December 2013 (UTC)

to clarify a little better: we tried replacing the uploaded file DIRECTLY ON THE SERVER(manually) with a new file that is named the same, but the link from the wiki breaks and will no longer retrieve it. 85.229.204.91 11:54, 13 December 2013 (UTC)

Do you mean you're uploading zip files in MediaWiki using Special:Upload and you want to update it with an automated process? Well, if you don't need to have a version history of the file, I'd simply upload that zip file somewhere else in the server (just outside of MediaWiki files) and provide a direct link to it from MediaWiki.

MediaWiki isn't aware of any changes of the file on the filesystem once it has been uploaded, so it shouldn't break the link at all. Maybe the problem is that it has a different owner/permissions when you replace it on the server and it doesn't have permissions to access it. Ciencia Al Poder (talk) 15:50, 15 December 2013 (UTC)

MIME type warning

I am looking to disable the warning message defined in MediaWiki:Mediawarning from appearing with .doc .docx .xlsz and .xls files. I tried editing the file DefaultSettings.php adding the mime type to the $wgTrustedMediaFormats which worked but apparently this file should not be edited. What is the best way to achieve this?

Thanks 217.146.106.11 (talk) 15:20, 13 December 2013 (UTC)

Hi!

When you edit a file, never do that in DefaultSettings.php. Always edit LocalSettings.php instead!

Do not the first few lines of DefaultSettings.php say that? 88.130.115.236 15:44, 13 December 2013 (UTC)

Thanks but I know DefaultSettings.php should not be edited as I said in my question. I made the change simply as a test then asked what the proper method should be.

$wgTrustedMediaFormats does not appear in LocalSettings.php

So my question still stands. 217.146.106.11 15:54, 13 December 2013 (UTC)

So add it to LocalSettings.php.

DefaultSettings.php simply sets the sane defaults for various global variables. LocalSettings.php is meant for configuration specific to your site, for variables that you want to customize. Jack Phoenix _(Contact) 15:59, 13 December 2013 (UTC)

Errors after update from 1.21.3 or fresh install of 1.22

I'm editing this post title to reflect new and substantially different information:

This problem occurs regardless of:

1. updating a 1.21.3 wiki using Installatron

2. updating a 1.21.3 wiki manually using code downloading direct from mediawiki

3. creating a brand new wiki with 1.22 in a new domain with no previous content

The new wiki behaves slightly differently than the updated wikis: the initial page takes a LONG time to load, and then after selecting the login link, it eventually 500s out.

I'm now wondering if anybody else has 1.22 working, fresh install or update to an existing wiki, on a similar configuration: apache 2.2.26, php 5.4.22, running suphp?? I'm aware of the general state of suphp support, but it's still popular and every CMS running on our servers is still working except mediawiki 1.22.

--- original post ---

This server (RHEL5) has mysql Ver 14.14 Distrib 5.1.70 and PHP 5.4.22. After upgrading from mediawiki 1.21.3 to 1.22, the main wiki page displays, but the login page (after clicking on "login") does not. This wiki requires a login to view.

These are the only messages appearing in the error log:

[13-Dec-2013 10:57:29 America/Chicago] PHP Notice: Uncommitted DB writes (transaction from DatabaseBase::query (LCStore_DB::get)). in /home/.../wiki/includes/db/Database.php on line 3944

While searching for this error, we found a recent mention of setting $wgCommandLineMode = true to work around the problem, although we're not sure exactly where to do that, or if there is a pending fix for this in a future release.

This problem occurs for two completely separate wikis installed on two different servers (the other server is configured similarly but with RHEL6.)

Thanks for any suggestions.

Here is additional debugging info from when "login" is selected, with "testsite" replacing the actual url:

Start request GET /index.php?title=Special:UserLogin&returnto=Special%3ASpecialPages
HTTP HEADERS:
USER-AGENT: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:25.0) Gecko/20100101 Firefox/25.0
HOST: wiki.testsite.net
CONNECTION: keep-alive
ACCEPT-LANGUAGE: en-US,en;q=0.5
REFERER: http://wiki.testsite.net//index.php?title=Special:SpecialPages
ACCEPT: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
ACCEPT-ENCODING: gzip, deflate
COOKIE: __utma=132645968.1105903451.1371837585.1377636307.1384794043.4; __utmz=132645968.1371837585.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)
CACHES: EmptyBagOStuff[main] SqlBagOStuff[message] SqlBagOStuff[parser]
LocalisationCache: using store LCStore_DB
Fully initialised
IP: 10.10.241.165
Connected to database 0 at localhost
[cookie] session_set_cookie_params: "0", "/", "", "", "1"
wfFixSessionID: PHP's built in entropy is disabled or not sufficient, overriding session id generation using our cryptrand source.
MWCryptRand::realGenerate: Generating cryptographic random bytes for wfFixSessionID/MWCryptRand::generateHex/MWCryptRand::realGenerateHex/MWCryptRand::generate/MWCryptRand::realGenerate
MWCryptRand::realGenerate: mcrypt_create_iv generated 16 bytes of randomness.
MWCryptRand::realGenerate: 0 bytes of randomness leftover in the buffer.
Unstubbing $wgAuth on call of $wgAuth::validDomain from LoginForm::load
Connected to database 0 at localhost
MessageCache::load: Loading en... got from global cache
Unstubbing $wgParser on call of $wgParser::firstCallInit from MessageCache::getParser
Parser: using preprocessor: Preprocessor_DOM
Unstubbing $wgLang on call of $wgLang::_unstub from ParserOptions::__construct
MWCryptRand::realGenerate: Generating cryptographic random bytes for LoginForm::setLoginToken/MWCryptRand::generateHex/MWCryptRand::realGenerateHex/MWCryptRand::generate/MWCryptRand::realGenerate
MWCryptRand::realGenerate: mcrypt_create_iv generated 16 bytes of randomness.
MWCryptRand::realGenerate: 0 bytes of randomness leftover in the buffer.
DatabaseBase::query: Writes done: INSERT IGNORE INTO `mw_msg_resource` (mr_lang,mr_resource,mr_blob,mr_timestamp) VALUES ('en','user.options','{}','20131213193735')

Approximately accompanied by:

[Fri Dec 13 13:47:34 2013] [error] [client 10.10.241.165] Script timed out before returning headers: index.php, referer: http://wiki.testsite.net//index.php?title=Special:SpecialPages

The installation also produces a huge number of processes running

maintenance/runJobs.php --maxjobs 1

We can load a fresh install of 1.22, connect it to the existing mysql db, and upgrade the mysql db to 1.22 using the command line script. At that point the login page is broken however. When we then revert the code (but not the db) to 1.21.3, the login page works again (with the 1.22 db updates intact.) Pbt~mediawikiwiki (talk) 17:52, 13 December 2013 (UTC)

Hi!

This is a known problem, I see that as well. A workaround might be to change PHPs error reporting to no longer show notices; this does not in any way fix the cause of the problem, but it only hides the symptoms. I think that this currently is the best solution.

This seems similar to https://bugzilla.wikimedia.org/show_bug.cgi?id=56269, which is visible after https://gerrit.wikimedia.org/r/#/c/79852/, but was already there before. Reason is that transactions in MediaWiki are broken.

As a workaround I have set $wgCommandLineMode = true;, however: I did that in a kind of maintenance script. This script is not executed each time a wiki page is called. You could set that by adding this line to LocalSettings.php, however, as the manual says: "Don't do it."

I personally also do not know, what else setting this variable changes and I think Manual:$wgCommandLineMode should really be extended with according information! 88.130.115.236 18:16, 13 December 2013 (UTC)

Thanks for the reply. We have php set to only log errors, not display them to users, if that's what you mean. The main wiki page loads and displays in the browser ("you must login in to view this wiki", etc.), but when the login link is clicked, nothing happens (except the errors are logged.) So there's no opportunity to attempt a login. Everything still works in the pre-upgrade wiki (we cloned it before attempting the upgrade.)

It's not clear if that uncommitted issue is definitely the cause of the login page not appearing, but it's the only entry in the error log, and doesn't appear in the 1.21.3 error log. Pbt (talk) 18:33, 13 December 2013 (UTC)

The message, which you posted only is a notice; basically the system should also run correctly with it. I think that the login page does not show up at all(!), is not caused by that one.

See blank page for some steps and ideas on how to debug that! 88.130.115.236 18:40, 13 December 2013 (UTC)

It did seem more like a warning vs. error, but that was still the only message after enabling the error display to the browser (as instructed in that link.) In the past (many versions ago) we've experienced the blank page problem, but it was always an out-of-memory error, and now we have a 512MB limit (confirmed with phpinfo().) Pbt (talk) 19:01, 13 December 2013 (UTC)

The "Uncommitted transaction" problem only is a PHP notice. As far as I can tell, a notice should not be able to produce a blank screen. When you see a blank screen, or - as you added above - a server error 500, then something else must be the cause.

Check the server error log to get information about the server error 500! 88.130.85.45 22:33, 17 December 2013 (UTC)

[Tue Dec 17 15:44:17 2013] [error] [client 10.10.241.232] Script timed out before returning headers: index.php, referer: http://testdomain/wiki/index.php?title=Special:UserLogin&returnto=Main+Page

Followed of course by the not-having-a-dedicated-500-page error, but there was a lot more debugging enabled for the run that I listed above, so I was assuming that would be more useful. Pbt (talk) 14:59, 18 December 2013 (UTC)

Hello,

I don't know if it's related but I encounter PHP Notice: Uncommitted DB writes error when trying to update database for Semantic Mediawiki (the Mediawiki is new, version 1.22, and semantic mediawiki also). Database upgrade (Postgresql 9.3) won't work at all with original files. If I disable index creation in database upgrade file (SMW_SQLStore3_SetupHandlers.php), the upgrade process will look like completed but ends with such php notice and tables are not created...

Many thanks if clear database access may be recovered with actual table creation, in my particular case (and others...).

Sorry for being anonymous, I didn't create an account... 82.65.247.29 01:08, 22 December 2013 (UTC)

Probably not related. The DB error message can be caused by a lot of things. Bawolff (talk) 05:32, 22 December 2013 (UTC)

OK, thank you for quick answer... Ynedelec3 (talk) 12:39, 22 December 2013 (UTC)

Hi,

I just installed fresh copy of Wiki for the first time and I get the same error. I tried to login but it loads long time and nothing happened, just loading. I have longer timeout set in PHP config, but this should not be a problem to login.

Any ideas how to use fresh installation of Wiki?

I will use it for private stuff if that helps.

Best regards

Gogy Gogy82 (talk) 01:08, 1 February 2014 (UTC)

This may be related to problems with the new handling of the Job queue on page requests. Try setting $wgJobRunRate = 0; to see if problem disappears. You may need to set $wgPhpCli to false to revert to the old handling system that doesn't have this problem, until it's fixed. Ciencia Al Poder (talk) 18:41, 1 February 2014 (UTC)

With JobRunRate set to 0 I was able to login. Notice exists but this is not what I care much in this moment, maybe later in new release, but I hope this will be solved later and upgrade should be made to handle this.

Ciencia, thank you very much for your answer and your time! Gogy82 (talk) 21:58, 1 February 2014 (UTC)

For the notice, you should disable error reporting for E_NOTICE. For example:

// Report simple running errors
error_reporting(E_ERROR | E_WARNING | E_PARSE);

Note that having $wgJobRunRate = 0; cause jobs to not being run, so you must manually run runJobs.php periodically to run them, needed to refresh links, etc. Ciencia Al Poder (talk) 18:20, 2 February 2014 (UTC)

I've problems after update to 1.22.2 with PHP Notice: Uncommitted DB writes (transaction from DatabaseBase::query (LCStore_DB::get)). in /home/.../wiki/includes/db/Database.php on line 3944

Is there a solution for this ? hollosch (talk) 21:12, 18 February 2014 (UTC)

Solved !!!

First i enabled SQL debug. Add in LocalSettings.php the following parameters:

$wgShowSQLErrors = true;

$wgDebugDumpSql = true;

$wgShowDBErrorBacktrace = true;

The error message show that the column iw_wikiid dont exist on table interwiki.

After I found the following patch <WIKI>/maintenance/archives/patch-iw_api_and_wikiid.sql

ALTER TABLE /*_*/interwiki

ADD iw_wikiid varchar(64) NOT NULL;

after i created this column, all works fine!

P.S.: remember to remove the debug parameters Ebasso (talk) 01:28, 19 February 2014 (UTC)

This should not happen if you properly upgrade your MediaWiki installation, as explained in Manual:Upgrading. Specially, the part that talks about Run the update script Ciencia Al Poder (talk) 10:18, 19 February 2014 (UTC)

Not solved!

Running .../maintenance/archives/patch-iw_api_and_wikiid.sql => #1060 - Duplicate column name 'iw_api'.

Happens on a fresh installation of 1.22.2 + semantic bundle; cant create/move categories without getting the error.

Do I have to run the update script after installing latest downloads?!? Collabet (talk) 11:10, 19 February 2014 (UTC)

enable SQL Debug. This is the best option to check in your environmnent.

In my case the problem was in table interwiki, that already have column name 'iw_api', but did not have column 'iw_wikiid'. Ebasso (talk) 11:48, 19 February 2014 (UTC)

These lines are added to LocalSettings.php:

$wgShowSQLErrors = true;

$wgDebugDumpSql = true;

$wgShowDBErrorBacktrace = true;

But all I get is:

Notice: Uncommitted DB writes (transaction from DatabaseBase::query (LCStore_DB::get)). in /home/[...]/html/includes/db/Database.php on line 3944

Where do I check for more hints or where's some error-log for the notice?

Setting $wgJobRunRate to 0 or 0.01 did not change anything.

This bug keeps me from using my MW at all. Collabet (talk) 15:32, 19 February 2014 (UTC)

First, add

 error_reporting( -1 );
 ini_set( 'display_errors', 1 );

to your LocalSettings.php file and see if any errors are displayed. If none are, try enabling debugging and see if the file shows you anything. ☠MarkAHershberger☢(talk)☣ 17:14, 19 February 2014 (UTC)

Thx alot, these 2 lines helped to get more output - more than I can digest.

• Abfrage: CREATE TEMPORARY TABLE `t2`( id INT UNSIGNED KEY ) ENGINE=MEMORY
• Funktion: SMW::executeHierarchyQuery
• Fehler: 1044 Access denied for user 'USER289985'@'%' to database 'db_289985_1' (mysql.lima-city.de)

Followed by 29 lines of backtrace.

Dead end for my level of knowledge. So far, I really liked SMW, more than any of its derivates, but it seems useless without IT degree. Collabet (talk) 18:06, 19 February 2014 (UTC)

The important bit there is this "Access denied for user ...". It looks like your permissions aren't set correctly for that user. Could you show the error to whoever hosts your site and see if they can help? ☠MarkAHershberger☢(talk)☣ 17:36, 20 February 2014 (UTC)

I also encountered the same problem, google-chrome-stable-33.0.1750.146-1.x86_64 can not log in, firefox, opera is no problem, the problem is chrome, or mediawiki problem?

mediawiki-1.22.3.tar.gz 218.241.171.220 02:01, 5 March 2014 (UTC)

A database error of "Access denied for user ..." is independent of the browser you're using. If that's not the same error, please open a new thread detailing what error message you get and doing what actions. Ciencia Al Poder (talk) 10:15, 5 March 2014 (UTC)

Upgrade to 1.22 - bad GU interface and login

The interface now has what looks like template placeholders for the titles and sidebar. example: the word 'navigation' overlays the actual navigation links. I also can no longer log in as Admin.

Version 1.20 was working just fine. 66.237.45.250 (talk) 23:21, 13 December 2013 (UTC)

After writing the above, I can no longer even open the wiki. Now I have to figure out how to revert back to 1.20 so I can have a working wiki. 66.237.45.250 23:25, 13 December 2013 (UTC)

Nope. Can't login or even get a 'forgot password' help. Browser is constantly waiting for the wiki to respond. 66.237.45.250 23:47, 13 December 2013 (UTC)

Hi!

I'll respond a bit differently than I normally do; I hope you won't mind:

When I report a problem, I never provide a URL for others to actually see it. I will not provide the versions I use; neither the old MediaWiki version, nor the MySQL and PHP versions!

If I were you I'd recommend the following steps: Do not check blank page, do not check the content of the Apache error log and do not see what is in the PHP error log. They are just terribly overrated. 88.130.115.236 00:07, 14 December 2013 (UTC)

How to Map a newly created template to the already existing content

How to Map a newly created template to the already existing content. For example I am having more than 1 lakh page. For all those pages, I need call a freshly created template. Is it possible, Please any one help in this. Regards, Maries Jayablan India 182.65.164.224 (talk) 08:19, 14 December 2013 (UTC)

This isn't really possible unless you use a bot. You should look at Pywikibot for ideas. ☠MarkAHershberger☢(talk)☣ 17:37, 20 February 2014 (UTC)

[Resolved] How to insert pages in bulk

Hello,

I have a wiki where I want to insert 100s of pages. How could I insert it? Is there any sql proc or commands that I can use or any program that can be used. Inserting page one by one is not the solution for these many pages. I am sure there is some method to do it programmatically. I couldn't find it in past discussions. Please help.

Thanks, Vikas

url: www.jainkosh.org MediaWiki 1.18.1 PHP 5.2.17 (cgi-fcgi) MySQL 5.0.96-log 113.193.106.133 (talk) 15:00, 14 December 2013 (UTC)

Hi!

Before I tell you about importing stuff, let me tell you this: MediaWiki 1.18 is outdated and no longer supported. It has known security holes. If you can update your PHP version to PHP 5.3, you should do so and then do an update to MediaWiki 1.22. If you cannot update PHP, update MediaWiki to version 1.19, which is also old, but at least still receives security fixes. There is a fine step-by-step guide through the upgrade here: Upgrade!

Without upgrading it's only a question of time when your wiki gets hacked. 88.130.74.3 16:36, 14 December 2013 (UTC)

Thanks for your input. I'll start upgrading it.

But I still need to find solution to insert pages. Can you help with that?

Thanks, 113.193.104.8 11:10, 15 December 2013 (UTC)

You can create/update pages directly from the server using edit.php, or from a remote machine using API:Edit Ciencia Al Poder (talk) 16:16, 15 December 2013 (UTC)

Thanks for your help. I'll check on how can I run these scripts. 113.193.104.33 15:29, 20 December 2013 (UTC)

remove tab's square

Is it possible to remove that little square for text like "page", "edit" for anonymous users? picture of what im talking about: https://yz3mzw.bn1304.livefilestore.com/y2pm_KKzaEOXwminqMTPDhwtJbjtgskKQp6Mu0pv1lIyefsRyMgppDqGzPu6gzn5FZN45U-rWkp-FGxm4n5UjZzx26Cr1u3ohCda2ra2qSyFc8/remo.jpg

i just want that little square gone since the "page" tab is the only thing anonymous user can see anyway. Cristal01 (talk) 16:38, 14 December 2013 (UTC)

Hi!

I understand you want to hide the tab "page" from display.

There basically are two possible options on how to solve this:

• By adding CSS rules to hide the tab (although it still is in the source code). For this solution I do not know how to make sure that the rules only apply to anonymous users.
• By modifying the navigation tabs with a hook. This will solve the problem in an even cleaner way.

Here someone already asked that:

http://www.mediawiki.org/wiki/Project%3ASupport%20desk/Flow/2012/04#h-%5BRESOLVED%5D_How_can_I_hide_tabs_for_users_not_logged_in%3F-2012-04-11T15%3A38%3A00.000Z

Note that the hook SkinTemplateSetupPageCss, which is used in the first example, is no longer present in current versions of MediaWiki. Instead of this using the hook SkinTemplateNavigation should work. 88.130.74.3 18:32, 14 December 2013 (UTC)

sadly this is not what I want. I just want to remove that one little square where is says "page" to make it look like this:

https://yz3mzw.bn1302.livefilestore.com/y2pkhh84j-r3tcNDaeeC5-GkJ1wP-M_-a_pDABAgtjPYrbnfxhtma_cUYNlsie5Tn0mHdcflTuK2IFPcfz_a6mEJiJJg6OyRIUgHbsGSx_QWEk/remo1.jpg

I still want people to see that page, I just dont want them to see that is the "page" tab Cristal01 (talk) 19:15, 14 December 2013 (UTC)

With the stuff in the linked thread you can modify the tabs, e.g. remove them. This will not change anything with the page content nor make the pages invisible. When you remove an entry with that hook, it will remove what you call "little square", this tab. Is that not what you want? 88.130.74.3 23:25, 14 December 2013 (UTC)

How to store images of Mediawiki on separate servers?

For example, currently I am using Linode VPS which is expensive and slow. I would like to store image to Amazon S3 or another cheaper VPS.

Now I am using

$wgUploadDirectory = "/wiki/image"; 
$wgUploadPath = "//static.mengniang.org"; 

to enable CDN from different domain.

However, the images still store at the same VPS with Mediawiki software. How to let mediawiki upload and load image to a separate servers? Deletedaccount4567435 (talk) 01:40, 15 December 2013 (UTC)

When you upload a file to MediaWiki, it stores it in $wgUploadDirectory, and when a page containing that image is rendered, the URL of the image points to $wgUploadPath. You need something to make MediaWiki upload that file to Amazon. See Extension:AWS or Extension:LocalS3Repo Ciencia Al Poder (talk) 16:06, 15 December 2013 (UTC)

Ok thank you. And how about different server? How can I store image on a different server? Zoglun (talk) 07:05, 16 December 2013 (UTC)

You could mount a remote filesystem on the local server using NFS, but that may not work on servers not placed on the same local network.

Another way would be to continue storing images locally, and have some sort of proxy cache (in $wgUploadPath address) for when a image is requested, if it doesn't exist, request the image to your wiki server and store it locally, so next requests for that image serve the saved image instead of requesting it again to your wiki. But that would be problematic if you upload a new version of the same image, since it would not notice the update, unless it's intelligent enough to periodically check if a new version of the file exists. Ciencia Al Poder (talk) 10:45, 16 December 2013 (UTC)

Thank you Ciencia Al Poder!

I tried the Network File System but the delay is toooooo large when using different location server. Now we are using multiple squid proxy which works good so far. However this does not solve the local storage problem, which means we still need to spend lots of money for Linode's disk space. Zoglun (talk) 07:25, 19 January 2014 (UTC)

I would also find it incredibly useful to store all user uploaded images on a different server. Is there anyway to do that besides mounting the remote file system using NFS? RainDelay (talk) 20:14, 21 April 2014 (UTC)

Wiki restriction help

Hi ,

How do I configure MediaWiki in such a way that users with 10 posts or more can see a page , which MediaWiki should automatically grant access when a user reaches 10 posts.

Is there any way to do this? Leaderboard (talk) 17:14, 15 December 2013 (UTC)

Hi!

Do you want that users can view all pages not before they reach 10 posts or do you want that they can view one certain page when they have 10 posts at least? 88.130.119.59 03:49, 16 December 2013 (UTC)

Hi ,

I want it to be in such a way that if a user reaches 10 edits(not posts , sorry) , they would have access to one additional page in addition to the access that they already have. Leaderboard (talk) 04:38, 16 December 2013 (UTC)

You should create a new group able to access those pages, and configure Manual:$wgAutopromote to add users to that group with the conditions you want. Ciencia Al Poder (talk) 10:52, 16 December 2013 (UTC)

So , I should create a group (eg group1) and set the permissions in such a way that only that group can access the specified page?

EdIT1 - How do I configure that only that page can that group read in addition to their usual user rights Leaderboard (talk) 13:58, 16 December 2013 (UTC)

MediaWiki doesn't provide page view restriction to specific pages or namespaces. You can use Extension:Lockdown to achieve this. Ciencia Al Poder (talk) 10:14, 17 December 2013 (UTC)

Partial page view restrictions when users can also edit some other pages is not secure. Be very careful setting such a thing up, it could probably be gotten around. (Common ways include transcluding the restricted page) Bawolff (talk) 21:02, 18 December 2013 (UTC)

[RESOLVED] How to change my Wiki font size?

Hi, My Wiki is 繁體中文, Need font size 14, i don't know how to change, can help me? :( Seonlive (talk) 06:07, 16 December 2013 (UTC)

Hi!

That is easy: I assume you use the Vector skin, right? Then on your wiki, go to the wiki page MediaWiki:Vector.css and add something like this:

/* Bring the text to 14px */

.mw-content-text {

font-size: 0.875em;

}

However, note that this might also change the size of other things inside the content. The original value is 0.8em, which comes down to 12.8px. 88.130.119.59 13:30, 16 December 2013 (UTC)

well, i try, but it not work :(

http://chelinpedia.twbbs.org/zh-tw/index.php/MediaWiki:Vector.css Seonlive (talk) 15:20, 16 December 2013 (UTC)

I've checked this again and in fact it seems like the font-size is defined by "bodyContent" in your wiki. So this rule should do:

/* Bring the text to 14px */

#mw-content-text {

font-size: 0.875em;

}

Note that I fixed a wrong sign in thiscode, which I had there by accident. :-(

/* Bring the text to 14px */

#bodyContent {

font-size: 0.875em;

}

Use one of the two, but not both, as I guess their changes add to each other. 88.130.119.59 15:29, 16 December 2013 (UTC)

he work！

Thanks you very much！

Have a Good Day:) Seonlive (talk) 15:37, 16 December 2013 (UTC)

Protecting Sysop and Admin Email Password Reset

Hi All@Mediawiki,

Can we setup Mediawiki to allow passord reset if conditions are :

- Admin User name asked for resetiing password,
- AND IP restrictions

If real terms, if a User supply an AdminUserName and his IP is not valid, Mediawiki will reply :

"Sorry, but you're not allowed to do this !!!" ONLY a valid IP adress/subnet is able to proceed :-)

Thanks a lot for help.

Produit Version MediaWiki 1.22.0 PHP 5.3.3 (apache2handler) MySQL 5.1.71 Neosa sa (talk) 13:04, 16 December 2013 (UTC)

Hi!

Do you want that any user can try to reset his password and if the user knows a username of an admin, then it works?

Or do you want that only admins can reset passwords (also passwords of other users), but only if the admin's IP comes from a certain range? 88.130.119.59 14:18, 16 December 2013 (UTC)

Hi,

Thanks for reply :-)

I want that only Users within a IP range able to perform passowrds reset, especially to protect admin accounts :-)

If a user named 'ACME' try to reset a password, 'ACME' is able to fill the field with a username identified as admin (let's call it 'Admin') => in a such case, user 'Admin' will receive an email telling him the password has been reset & has to be change.

Of course, I can also setup Wiki Users not to be able reseting their passwords, but I want to keep to the possibility for any Users to perform password reset BUT IF their own IP is not within a IP range AND they supply the username 'Admin', mediawiki will reply "You are not allowed to send a request for reseting the password for 'Admin'".

Of course, if 'Admin' is identified as a valid IP user, mediawiki will allow 'Admin' to receive a new password. May be that it is not possible to do this, I will understand if a such behavior is not possible at that time (V 1.22).

Regards. Neosa sa (talk) 17:21, 16 December 2013 (UTC)

Hi!

You might be interested in the hooks Manual:Hooks/User::mailPasswordInternal and especially Manual:Hooks/SpecialPasswordResetOnSubmit.

Let me get the logic straight:

• A user has forgotten his password (and so he is not logged in).
• He now "pretends" to be one certain user (maybe he is, maybe he is not) and asks MediaWiki to send out a new-password-mail to this user's e mail address.

Problem with that is that you don't know, if this user actually maybe even is this admin (so that you want him to get the new password for the admin account). So I would say you cannot differentiate between "This user is an admin; he is allowed to trigger the "send-admin-an-e-mail"-function and between "This user is no admin, he is not allowed to do so".

So it all boils down to the IP range. In the hook SpecialPasswordResetOnSubmit you have access to "User objects" (for which users?). And you have the user data, which was sent by the requesting user.

The information at that point should enable you to get the user's IP address (see the functions in includes/User.php) and to check it against the range you want. Should the user be outside of that range, you can use &$error to give back an error code, otherwise you can let the hook go on. This would block any user from outside the defined range to request a password-reset-mail; that might be a good start for the problem. 88.130.119.59 17:45, 16 December 2013 (UTC)

Upload Files, Error: mwstore://local-backend/local-public

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Hello,

had the problem with uploading files and getting the error above. After changing a lot of permissions and checking LocalSettings.php i found out the problem.

In the php.ini (file_uploads = on) i had to add o the basedir the folder which contains the uploaded files. So in the end i changed the following line to:

open_basedir = /srv/http/:/home/:/tmp/:/usr/share/pear/:/usr/share/webapps/:/var/lib/mediawiki

where u can see that adding the last entry: :/var/lib/mediawiki solved my Problem 89.207.120.69 (talk) 13:44, 16 December 2013 (UTC)

Glad to see that worked for you. In Manual:Configuring file uploads there's already a note about the open_basedir. Ciencia Al Poder (talk) 10:26, 17 December 2013 (UTC)

See also this topic for an alternative cause for the same error message. [[kgh]] (talk) 10:19, 30 June 2019 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Change media icon size

Hi. First of all I hope I am using the correct terminology, please excuse me if I'm not.

I would like to know how to change the icon size for file types mediawiki does not make previews of e.g. Excel spreadsheets and PDF files, both on the file page and on the list that is created by adding the files to a category. Currently they are 120 x 120px which is too large for a long list of files.

Thanks for your help. 217.146.106.11 (talk) 15:12, 16 December 2013 (UTC)

Hi!

I think the icons only are avaiable in that one size? Then I would not try to use another, a smaller icon, but I would render it smaller using CSS:

I assume you use the Vector skin, right? Then on your wiki, go to the wiki page MediaWiki:Vector.css and there add CSS rules, which make these icons show up a bit smaller. 88.130.119.59 15:14, 16 December 2013 (UTC)

My website all of a sudden is gone?

It was working fine, and now all of a sudden nothing loads?

http://creawiki.net/ 174.140.182.136 (talk) 03:56, 17 December 2013 (UTC)

See https://www.mediawiki.org/wiki/Manual:How_to_debug for how to start investigating. AKlapper (WMF) (talk) 08:59, 17 December 2013 (UTC)

Re upload your files to your website again meaning your version Mediawiki be downloaded again and uploaded to your website to see if that helped if you have Mediawiki 1.18 please upgrade to Mediawiki 1.19 or Mediawiki 1.21 or higher please 2.216.253.172 17:23, 17 December 2013 (UTC)

Andre is right: Follow the debugging steps on that page, also check the PHP error log and see what you got there. No need to upload thousands of files - possibly via FTP - only to realize that this does not help. 88.130.85.45 18:45, 17 December 2013 (UTC)

CSS won't load: mime/type is text/html ?

I've installed MW 1.22.0 in my public_html using a sqlite3 engine

php maintenance/install.php  --dbtype sqlite ...

.

I can see the Main_Page but the CSS won't load (I tried to reload the firefox cache using shift+reload)

The error in firefox is:

[12:26:27.138] The stylesheet http://localhost/~lindenb/mediawiki-1.22.0/wiki/load.php?debug=false&lang=en&modules=mediawiki.legacy.commonPrint%2Cshared%7Cskins.vector&only=styles&skin=vector&* was not loaded because its MIME type, "text/html", is not "text/css". @ http://localhost/~lindenb/mediawiki-1.22.0/wiki/index.php/Main_Page

The HTML source of the main page contains

(...)
<link rel="stylesheet" href="http://localhost/~lindenb/mediawiki-1.22.0/wiki/load.php?debug=false&lang=en&modules=mediawiki.legacy.commonPrint%2Cshared%7Cskins.vector&only=styles&skin=vector&*" />
(...)

A curl with this address returns a text/html page:

$ curl -D - 'http://localhost/~lindenb/mediawiki-1.22.0/wiki/load.php?debug=false&lang=en&modules=mediawiki.legacy.commonPrint%2Cshared%7Cskins.vector&only=styles&skin=vector&*' | more

Date: Tue, 17 Dec 2013 11:28:29 GMT
Server: Apache/2.2.22 (Ubuntu)
X-Powered-By: PHP/5.3.10-1ubuntu3.9
X-Content-Type-Options: nosniff
Content-language: en
Vary: Accept-Encoding,Cookie
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Cache-Control: private, must-revalidate, max-age=0
Last-Modified: Tue, 17 Dec 2013 11:18:33 GMT
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8

<!DOCTYPE html>
<html lang="en" dir="ltr" class="client-nojs">
<head>
<meta charset="UTF-8" /><title>lindenb</title>
<meta name="generator" content="MediaWiki 1.22.0" />
<link rel="alternate" type="application/x-wiki" title="Edit" href="/~lindenb/mediawiki-1.22.0/wiki/index.php?title=Main_Page&action=edit" 
/>
<link rel="edit" title="Edit" href="/~lindenb/mediawiki-1.22.0/wiki/index.php?title=Main_Page&action=edit" />
<link rel="shortcut icon" href="/favicon.ico" />
(...)

Using http://localhost/~lindenb/mediawiki-1.22.0/skins/modern/main.css returns a text/css page

How can I fix this ? Plindenbaum (talk) 11:41, 17 December 2013 (UTC)

Hi!

This is a common problem; see Manual:load.php for a fix. 88.130.85.45 12:39, 17 December 2013 (UTC)

Sorry I'm not a skilled sysadmin,

I put a .htaccess in the MW directory

~/public_html/mediawiki-1.22.0$ cat .htaccess 
RewriteEngine On
RewriteRule ^(api|load)\.php - [L]

I also set

AllowOverride All

in /etc/apache2/mods-enabled/userdir.conf and in /etc/apache2/sites-available/default

and restarted apache:

$ sudo /etc/init.d/apache2 restart
</syntaxhighlight>
::After reload the page(with shift to clear the cache), I still get the error <syntaxhighlight lang='text'>"[17:11:13.756] The stylesheet http://localhost/~lindenb/mediawiki-1.22.0/wiki/load.php?debug=false&lang=en&modules=mediawiki.legacy.commonPrint%2Cshared%7Cskins.vector&only=styles&skin=vector&* was not loaded because its MIME type, "text/html", is not "text/css". @ http://localhost/~lindenb/mediawiki-1.22.0/wiki/index.php/Azdazd"

Plindenbaum (talk) 16:40, 17 December 2013 (UTC)

It looks like that is caused by rewrite rules, try doing the instructions at Manual:Short_URLs instead of whatever you did. Bawolff (talk) 21:00, 18 December 2013 (UTC)

Loading pages from .csv with categories & properties.

There seems to be something that I'm not getting.

I'm wanting to upload pages, a line at a time, from .csv files into mediawiki. I've loaded the semantic extensions. I'm able to load the .csv file into a template, but it seems to ignore the properties, the categories and even text features like '\n' - simply treating it all as raw text. How do I change this behaviour?

The files I've used for testing are:

.csv:

Title,Import_template[namespace],Import_template[category],Import_template[policy_owner],Import_template[policy_name],Import_template[policy_description]

"sandpit:one","policy","[category:policy]\n[[status::active]]\n[[renewal
date::20/02/2014]]\n[[service::Administration]]\n[[speciality::all]]","My.Name","test_policy_name","==Policy
Description==\n\ntest_policy_description\n\nmore test policy
description"

What I get is:

title |
namespace | policy
category | [[category::[category:policy]\nactive\n20/02/2014\nAdministration\nall]]
policy_owner | My.Name
policy_name | test_policy_name
policy_description| =Policy
Description==\n\ntest_policy_description\n\nmore test policy
description
test_policy |

So it seems to be interpreting the input as if it was binary text, ignoring the categories, the [] and the '\n'. So, as you can see, I've tried to set properties and categories, but doesn't seem to recognise them.

The template I've set is:

<noinclude>
This is the "Import_template" template.
It should be called in the following format:
<pre>
{{Import_template
|title=
|namespace=
|category=
|policy_owner=
|policy_name=
|policy_description=
}}

Edit the page to see the template text.

Fustbariclation (talk)

Product Version MediaWiki 1.22.0 PHP 5.3.27 (cgi-fcgi) MySQL 5.5.32-cll Fustbariclation (talk) 12:24, 17 December 2013 (UTC)

What tool are you using to import csv files into MediaWiki? Ciencia Al Poder (talk) 10:23, 18 December 2013 (UTC)

The SMW csv import special page:

Special:ImportCSV - Extension:Data Transfer Last version 0.4.1 (June 2013)

https://www.mediawiki.org/wiki/Extension:Data_Transfer Fustbariclation (talk) 10:37, 18 December 2013 (UTC)

Would I do better using the multiple URL calls to the API instead? Fustbariclation (talk) 10:40, 18 December 2013 (UTC)

The support desk is for more general questions. Try posting your question to Extension talk:Data Transfer (or put a link there to this thread), since there may be more possibilities that other users, more familiar with that extension, can see the message if they have the talk page in their watchlist. Ciencia Al Poder (talk) 10:32, 19 December 2013 (UTC)

UTF-8 converted to latin1 on output?

Hello, I'm encountering a really confusing issue. Article text seems to be being converted from UTF-8 to latin1 during rendering of the wiki text, causing multibyte characters to display incorrectly. This also affects system messages appearing as part of the wiki content area. It does not affect the sidebar.

This is most perfectly illustrated on the Mediawiki:Sidebar page, where the sidebar is displayed on the left correctly in UTF-8, but in the content area it is converted to latin1, thus creating garbage where the multibyte characters should be.

http://wikiausland.de/bookshop/MediaWiki:Sidebar.

It affects both new and old pages. Tables are all BINARY collation.

Does anyone have any idea what's occurring here and what I can do to fix it? Andrujhon (talk) 19:57, 17 December 2013 (UTC)

I forgot to add that when editing a page, the text is once again correctly output as UTF-8 in the textarea. When saved, the page once again loads a garbled non-utf8 version. Andrujhon (talk) 20:01, 17 December 2013 (UTC)

Hi!

I do not directly have the solution, but some thoughts:

Binary tables are fine. MediaWiki internally always handles the data as UTF-8. You should make sure that all charset settings in MySQL are UTF-8 or binary: character_set_connection, character_set_client and character_set_results. They all can also be set with $wgDBmysql5, but you might not need to set it at all, if they are configured properly anyway. Then make sure that inside your database the following objects use the right encoding: the DB itself, the single tables and those columns, which do have an encoding. They should all be binary in your case, except a few tables, which need to be UTF-8, because they need a full text search (I think that affected two tables, one of them the search index).

You are currently using MW1.21rc4. You might want to update that to MW1.21.3 (but I do not expect that to solve the problem). When you say that you updated - and that before the update everything worked correctly -, from which version did you update? 88.130.85.45 22:25, 17 December 2013 (UTC)

Hi, Thanks for the suggestions.

I have previously tried setting $wgDBmysql5 to true, but it had no effect.

The most confusing thing about this is that it is not an old upgraded installation - it is a fresh installation with new tables.

The only irregularity I can conjecture is that it is sharing the user tables of a wiki which has been upgraded from an older version, and so may have some historic anomalies, although it would be strange if the shared user tables caused the new wiki installation to expect non-utf8?

Unless anyone has any ideas on where to dig, I think the next course of action will be an export and total reinstall. Please save me from that ;) Andrujhon (talk) 16:18, 18 December 2013 (UTC)

The user table should not change stuff with the content. If you think it might do, just create yourself a new user account (which does not have historic anomalies) and test with that one to see.

I am pretty sure that the problem is somewhere in your (MySQL) configuration. At least one of the charset settings I mentioned in my above post must be wrong. What are they set to? 88.130.117.159 17:15, 18 December 2013 (UTC)

I do not think its your db. If it was the db, I would expect the textareas to also have the bad character, as well as the api to output the bad characters, where both are fine.

I believe it is the utf_decode line in the MoveToSkin.php extension that is causing your issue.

-----

p.s. You currently have $wgScriptPath set to '/w-bookshop/', it should actually be '/w-bookshop'. This doesn't make much of a difference, but will prevent some urls from having a double // in them (e.g. http://wikiausland.de/w-bookshop//index.php?title=Wikiausland:Administratoren&action=edit&redlink=1 )

p.p.s. I really like your skin. Its one of the better mediawiki skinning jobs I've seen. Bawolff (talk) 20:13, 18 December 2013 (UTC)

Thanks Bawolff, I'll look into that now. The MoveToSkin extension is actually one I wrote, so I'm totally responsible if it turns out to be the problem!

Thanks for the Skin complements. It's based on an open source Twitter Bootstrap skin I created here: https://github.com/andru/mediawiki-bootstrap -- which I extracted from the custom skin I made for http://practicalplants.org -- it's still basically a base skin from which to build a custom skin, but I hope to gradually improve it with each project which I utilise it for, until it's a decent option as a modern, responsive skin for MW. Andrujhon (talk) 14:05, 20 December 2013 (UTC)

Too many notifications sent by the Translate extension without any actual modification, to my mailbox

I receive really too many of these notifications (by mails sent from: MediaWiki Mail <wiki@wikimedia.org>), even when there are actually NO modifications at all :

Dear $username,

The Meta page Translations:$pagename/$id/$lang has been changed on $date by $user, see http://meta.wikimedia.org/wiki/Translations:$pagename/$id/$lang for the current revision.

Editor's summary: -

Contact the editor: mail: http://meta.wikimedia.org/wiki/Special:EmailUser/$user wiki: http://meta.wikimedia.org/wiki/User:$user

There will be no other notifications in case of further activity unless you visit this page while logged in. You could also reset the notification flags for all your watched pages on your watchlist.

Your friendly Meta notification system

(I have replaced the variable parts by $placeholders)

This notification says that there will be no other notifications, until I visit the site, but is is plain wrong, these notifications come into large batches of dozens of emails (one email for each notification). This is clearly excessive. In fact these notifications are not only sent if someone changes a translation, but only votes on a translation for reviewing it without any change. This is clearly not necessary to submit a notification by mail for this (then we also do not receive notifications online on the wiki website).

Can someone investigate this bug (one of the many bugs that are plagging the Translate extension for MediaWiki)? Verdy p (talk) 22:18, 17 December 2013 (UTC)

This has nothing to do with Translate, it's bugzilla:14901's friends i.e. how enotifwatchlist work. I agree that it's sad that enotif in core is not being worked on at all (since the last patch by Benny for 14901). Nemo 22:39, 17 December 2013 (UTC)

This bug 14901 is said to be "resolved, fixed". Still this correction is not working as it should, and the bug persists (or it's unrelated to bug 14901 and is another bug, or the patch has not been applied on Meta; bit I see also the same effect with translations on other wikis). The bug does not occur however on translatewiki.net (may be it has applied the patch, but not Wikimedia sites).

It is a fact that the Translate extension creates these notifications even when they are absolutely not needed (no change at all in the wiki text, only a vote by someone else for approving a translation).

And a fact as well that these notifications should be bucketed instead of being sent in batches every few seconds when someone reviews a list of translations and accepts them.

That's clearly someting that the Translate extension must rework, by delaying them, or by informing the Notification system to delay the delivery, so that the Translate interface can produce a summary.

For now it is just spamming in mass to my mailbox, really too frequently (including with messages saying that I have *myself* created or modified a translation).

There's certainly something to develop in a better cooperating API between the Translate extension, the Notifications extension and the MEdiaWiki mail interface, but which could as well be used between LiquidThread's extension (for "new messages") and the Mediawiki mail interface: we need more tunings for these messages, even if the associated pages are part of a watchlist (which is not enough categorized by types of interactions). Verdy p (talk) 23:20, 17 December 2013 (UTC)

The core logging system does not allow me 1) to change wording of the emails it sends 2) preventing the emails it sends. In fact, I've patched core on some translation sites I run to exactly to avoid these emails. Building an emailing system as you describe is definitely out of scope for Translate and I wouldn't have time for doing that either. Nikerabbit (talk) 06:50, 18 December 2013 (UTC)

Again, this has nothing to do with Translate, stop accusing stuff and people randomly. It also has nothing to do with Echo (I assume you just meant that you'd like the team members of Echo to give a look at this).

That specific core bug has been fixed because we reduced its scope to get some progress, but the underlying issue is that enotifwatchlist doesn't "understand" logs. The current main open bugs are bugzilla:42457 and bugzilla:42458; the part about following notifications not being suppressed even though you don't visit the page is not known, please look for steps to reproduce and file a bug (remember that "until I visit the site" is wrong, you have to visit the page; if you're using "site" to mean "page" as the Germans usually do, ok). Nemo 07:02, 18 December 2013 (UTC)

Stop pretending that I accuse someone or some designated parts of the code of doing something wrong. In fact I was not designating any one, but this is still a bug and the fact it was triaged to bug 14901 is ONLY from you Nemo, when now I see that you have already created bug 34153 which is definitely NOT fixed, but given "low" priority now.

I absolutely don't care if this bug is from Echo or anny other part of the system. This is a bug, wherever it is.

But YOU, Nemo, confused it by misredirecting me to the wrong bug 14901, then again two other (possibly unrelated) bug 42457 and bug 42258.

Clearly this is not a problem of history log because these mails are sent even when there are aboslutely *nothing* recorded in the hisotry log of pages (for example when someone just votes for an existing translation without performingany change, the mail is sent for a watched translation, when in fact we are not watching votes that are recorded elsewhere).

I maintain then this message here in the support desk, where it was appropriately placed, if you had not just confused things more. Initially I DID NOT wrote to the Bugzilla reports, it's YOU, Nemo, that brought me there.

For now every one wants to pretend that this is not a bug in their module, they "throw the baby" to the next developer, and nobody cares, and this is not acceptable. And people like you, Nemo, are even aggressive against those that signal something that is a legitimate bug.

Please reread my initiual request. I accused abolutely NOBODY. Verdy p (talk) 10:06, 18 December 2013 (UTC)

Read better, I said «it's bugzilla:14901's friends» (bold added). Nemo 17:11, 18 December 2013 (UTC)

This email is not sent by Echo notification Bsitu (talk) 23:39, 17 December 2013 (UTC)

Did I pretend it? No. I was only looking for direction on this helpdesk, if Nemo had not confused everything and pretended I was accusing someone, when he was the only one to designate bugs randomly here. Verdy p (talk) 10:15, 18 December 2013 (UTC)

Nemo did not accuse anyone and even if he did, it will not solve your problem. Please adjust your tone and come back to the topic! I think you want this bug fixed as well. 88.130.117.159 13:06, 18 December 2013 (UTC)

Problems after upgrading to 1.22

I previously reported that I was getting an error 500 on Special:SpecialPages after upgrading to 1.22. After a while I reported that the error appeared to have gone away. However I am still getting occasional errors on this page. Everything else appears to work correctly but I haven't tested every single piece of functionality so I cannot guarantee this - if anyone wants to give it a go (without corrupting content!) you can find my wiki at http://www.festipedia.org. Checking the Apache error log I am getting three different errors:

• Seg fault
• zend_mm_heap corrupted
• Allowed memory size of 134217728 bytes exhausted (tried to allocate <very large number> bytes) in includes/context/RequestContext.php on line 350 (the very large number is typically in the range 8Gb - 20 Gb - I can provide the actual numbers if it would help)

Looking at RequestContext.php it doesn't look like it should be allocating any memory on line 350 so I'm guessing this is some kind of corruption.

Details for my setup are:

MediaWiki 1.22.0 PHP 5.3.6 (apache2handler) MySQL 5.1.56

I have a lot of extensions installed (a subset of those on the English Wikipedia) but I have tried commenting them all out in LocalSettings.php and it doesn't make any difference so I don't think it is related to any of those. Just in case it is relevant, my current LocalSettings.php was copied from my 1.21 setup. All I have done to it is remove some extensions that are now part of core.

Any thoughts? Prh47bridge (talk) 10:10, 18 December 2013 (UTC)

Correction - the URL for my wiki is http://www.festipedia.org.uk. Sorry. Prh47bridge (talk) 10:25, 18 December 2013 (UTC)

Allocating 8-20 GB (!) I have no idea what could cause that, but maybe something wrong with your version of PHP (shot in the dark) Bawolff (talk) 20:57, 18 December 2013 (UTC)

Just to clarify, the error happens only when viewing Special:SpecialPages? Or does it appear at random page requests? Or always on the same page? Ciencia Al Poder (talk) 10:44, 19 December 2013 (UTC)

I have only seen it when viewing Special:SpecialPages. I cannot rule out the possibility that it also happens on other pages but I haven't seen it. When I first upgraded to 1.22.0 it would fail on Special:SpecialPages every time. After a few hours it started working properly, then it failed consistently for several hours, then it started working again. Now it works more often than it fails and when it does fail it usually starts working again on the second or third attempt to view Special:SpecialPages.

I'm not ruling anything out but I would be surprised if it is my version of PHP. It is a supported version and hasn't given a problem before. At one point I thought it my be due to APC but disabling that had no effect.

I note that some other people have reported problems immediately after upgrading but the issues have gone away (or the poster has stopped responding!) without any fix being applied. I don't know if the problem I'm seeing is a symptom of the same issue or something different. If it is something I've done I'd like to fix it! If it is a problem in 1.22.0 I'd like to help debug it, so happy to provide any information that would help to get to the bottom of this. Prh47bridge (talk) 12:34, 19 December 2013 (UTC)

Googling around I could find some possible causes:

• Bad session manager [1]
• I've seen various errors related to this when using some opcode cache, e-accelerator, apc, etc. Probably not the opcode fault
• Not enough memory (that would explain when you get "Allowed memory size of NNNNN bytes exhausted")
• Some say increasing PHP's output_buffering sometimes solves the problem [2]

But nothing conclusive :( Ciencia Al Poder (talk) 14:14, 21 December 2013 (UTC)

Thanks for the ideas. Unfortunately they haven't helped.

Checking the log shows that this does occasionally happen on other pages but it seems to reproduce most reliably on Special:SpecialPages.

Checking the figures for the large memory allocations, the most common one is 0x400000000 which looks suspicious. The second most common figure is 0xd04845e7 which looks a bit more random. Prh47bridge (talk) 12:09, 1 January 2014 (UTC)

I have exactly the same problem too. The memory limit is set to memory_limit = 128M and output_buffering = 4096. I also tried the update script and update special pages script. Fireflyt (talk) 12:48, 9 January 2014 (UTC)

Turns out my issue is being caused by the multiupload extension, simply commenting it out in localsettings.php fixes the issue. I am assuming that it must reference the old Vector extension somewhere. Fireflyt (talk) 13:50, 9 January 2014 (UTC)

[RESOLVED] MediaWiki don't work with PCRE 8.34

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

I was running MediaWiki 1.20.8 with no problems. Then after upgrading PCRE from version 8.33 to 8.34, the content on most of the pages in my MediaWiki site does not display, only empty pages without content. Then I upgraded to MediaWIki 1.22.0, but the same problem still exist there.

The Apache Error Log shows many lines like this (note there is different line numbers in the errors, so its not only line number 902 like in this example) (I have changed the domain name and user name and ip from the error):

[Wed Dec 18 14:07:46.351691 2013] [:error] [pid 8193] [client 12.12.12.12:53455] PHP Warning: preg_match(): Compilation failed: group name must start with a non-digit at offset 8 in /home/xxx/domains/xxx.com/public_html/w/includes/MagicWord.php on line 907, referer: http:// xxx.no/w/index.php/Hovedside

Then I look at PCRE 8.34 changelog at pcre.org/news.txt wich says this:

"Perl no longer allows group names to start with digits, so I have made this change also in PCRE."

Please look into this and make MediaWiki compatible with newest PCRE 8.34

Also, please help me about what changes I need to do in order to patch this problem manually in MagicWord.php, so that I don't have to downgrade PCRE, please help. 87.252.72.81 (talk) 13:15, 18 December 2013 (UTC)

Thanks for the very good problem description!

I have just checked the bugtracker and here already is an issue about this problem:

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

Please add your findings there, especially this:

Then I look at PCRE 8.34 changelog at pcre.org/news.txt wich says this:

"Perl no longer allows group names to start with digits, so I have made this change also in PCRE." 88.130.117.159 13:34, 18 December 2013 (UTC)

The patch on the link above and running php update.php fixed this issue for me. Thanks for directing us to the correct place. LTech (talk) 08:09, 20 October 2014 (UTC)

Thanks for the patch Bennylin (talk) 10:34, 2 September 2015 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

[RESOLVED] SideBar menu opens then automatically collapses

MediaWiki 1.22.0 PHP 5.3.28 (cgi-fcgi) MySQL 5.1.70-cll

Clicking on a sidebar drop down menu causes the menu to expand then automatically collapse. One menu is stuck open. 76.19.144.178 (talk) 15:24, 18 December 2013 (UTC)

If this wiki is publicly accessible, a link to it would really help.

This looks like scripts are being included twice, so the collapse event is attached twice, with one click it uncollapses and then the second event runs again, collapsing the element. Are you using a custom skin? Did you have any customization to MediaWiki files? Ciencia Al Poder (talk) 10:39, 19 December 2013 (UTC)

Hello all,

yesterday I updated my Wiki to 1.22 and I am facing exactly the same problem: A klick on one of the sidebar menu items drops down the related sub menu and immediately closes it again. No chance to click one of the sub menu items.

I did not yet update all my extensions to the latest releases so far, but I can't imagine that an older extension version could cause this problem.

Mediawiki: 1.22.2

PHP Version: 5.3.18-nmm1 (apache2handler)

MySQL Version: 5.1.73-nmm1-log

Has there been any progress regarding this investigation?

Many thanks to all involved! Sochin67 (talk) 09:51, 11 February 2014 (UTC)

Sadly, without a public wiki where this happens, to check what JavaScript events are bound to the menu and where they come from, is impossible to find the cause.

I'd recommend disabling all extensions and see if the problem remains. Ciencia Al Poder (talk) 10:19, 11 February 2014 (UTC)

Many thanks for your quick response!

Do you think you could have a look at it? I will grant you access to the wiki anyway for your verification:

URL: http://hvg-wiki.heimatverein-gymnich.de

user: hvg

pw: hvg2013wiki

It's a german wiki, but I think this is irrelevant for bugfixing, right?

Please let me know when you finished your investigations, then I'll change the login data again.

Many thanks again! Sochin67 (talk) 10:45, 11 February 2014 (UTC)

I see the problem in the heimatverein-gymnich wiki as well. The wiki uses the Vector skin. No code concerning that part of MediaWiki on Common.js and on Vector.js.

In earlier versions the collapsing was part of the extension (not the skin!) of the extension Vector. In MediaWiki 1.22 this extension has been merged into the MediaWiki core. Now the extension is superfluous. However, your Special:Version page shows that you still have the Vector extension activated. You should remove the Vector extension from LocalSettings.php and the files from the extensions/ folder!

I am pretty sure this improves, if not solves the problem! 88.130.105.207 11:58, 11 February 2014 (UTC)

Whoever you are - you're a star!!

It seems to work fine now - many thanks indeed!!! Sochin67 (talk) 12:14, 11 February 2014 (UTC)

Store Calculated Variable History

I get external data, run some queries and calculations and produce a metric. When the data changes, so does the metric. I'd like to store that calculation so I can have a history that is not dependent on the data. Ideally, the metric would be stored with the next or Friday as the date. Wednesday would overwrite Tuesdays' data, but come Saturday would make a have a new entry to the next Friday. I can then see how the metric changes by week and how it's tracking for the current week.

on 12/18 Metric is 10 -> store as 12/20, 10 on 12/19 Metric is 11 -> store as 12/20, 11 on 12/20 Metric is 9 -> store as 12/20, 9 on 12/21 Metric is 9 -> store as 12/27, 12

The data source prevents me from running a calculation to get past data so I need to store these as a sort of snapshot. Can I do this without running a SQL server to write data to? I'd like to write it to a page or a storage place within my mediawiki. 192.206.89.4 (talk) 20:03, 18 December 2013 (UTC)

Product Version

MediaWiki 1.21.2

PHP 5.3.17 (apache2handler)

MySQL 5.5.31

Lua 5.1.5

Forgot to paste this. 192.206.89.4 20:04, 18 December 2013 (UTC)

MediaWiki stores everything in a mediawiki server, so storing it in mediawiki is storing it in an sql server. Depending on what level you are talking about, you might just want a Bot that just edits page, or have an extension with custom tables (Manual:Database_access and Manual:Hooks/LoadExtensionSchemaUpdates) Bawolff (talk) 20:53, 18 December 2013 (UTC)

Creating a partial fork of Wikipedia

I've had a plan for a long time about making a history encyclopedia that is reliable, yet less intense than Citizendium. I think it would be good to start by forking and attributing content from Wikipedia. Is there a way that attribution notices can be automatically added to articles? I'm thinking some sort of extension or JavaScript that adds a notice to the bottom of a page if it's older than a certain date.

I suspect that there might also be extensions, CSS, templates, and JavaScript that would also need to be imported. Lieutenant Aleksandr Reznov 23:09, 18 December 2013 (UTC)

Maybe https://www.mediawiki.org/wiki/Extension:CreditsSource might be close to adding such information to articles. Haven't tried myself. AKlapper (WMF) (talk) 23:37, 18 December 2013 (UTC)

MySQL upgrade

Hi MediaWiki users,

we have several MediaWiki instances, versions 1.15, 1.16, 1.17, and 1.20, running on our server. Currently, the databases are hosted at a dedicated database server using MySQL 5.0.96. We are planning to upgrade this database server to MySQL 5.5. I searched this support desk for similar posts, and found, e.g., [1,2]. In particular, [2] suggests that there will be problems due to a bug in "update.php" script in MW 17, which uses MySQL TYPE.

I have a couple of questions, maybe someone has some insights: 1.) Can anybody confirm this bug in [2]? Is this bug also in 1.15, 1.16, or 1.20? 2.) Are there any best practices and/or tips for our planned MySQL upgrade? 3.) I assume I do not (!) have to run need to run any MW maintance scripts - right?

Any pointers would be very much appreciated ;)

Kind regards Andreas

[1] http://www.mediawiki.org/wiki/Project%3ASupport%20desk/Flow/2010/10#h-%28RESOLVED%29_Mediawiki_MySQL_upgrade-2010-10-27T19%3A50%3A00.000Z [2] http://www.mediawiki.org/wiki/Project%3ASupport%20desk/Flow/2011/08#h-MySQL_5.5_and_MW_17_-_ENGINE_vs_TYPE-2011-08-16T09%3A11%3A00.000Z 95.113.50.172 (talk) 00:55, 19 December 2013 (UTC)

Hi Andreas!

To 1): Newer versions like 1.20 should be fine, maybe 1.17 received an according patch after [2] was asked, but I don't know for older ones (1.15 is from 2009...). Download a copy of the MediaWiki versions, which you are using, and check the file maintenance/tables.sql. This file contains the MySQL table definitions. When there is no TYPE option in it, you should be fine.

To 2): Best practices are the ones, which the MySQL guys give you; e.g. to always create a backup before starting and to run the upgrade scripts, which MySQL provides. But as far as the MediaWiki side is concerned: Not that I know of. I have updated a MySQL 5.0 to 5.1 some time ago and inside MediaWiki I had to change nothing at all.

To 3): Correct; especially this script upgrade1.5_php, which is mentioned as problemtic in [2] is not needed in your case. It would only be used when you updated MediaWiki to version 1.5, which in your case will not happen. 88.130.117.159 02:13, 19 December 2013 (UTC)

The TYPE vs ENGINE thing in older mediawiki should be able to be worked around by specifying $wgDBTableOptions in LocalSettings.php with an appropriate value. (If its wrong in tables.sql, it should still be fine, as that file is only used during install, and I assume you are not re-installing mediawiki on the new db) Bawolff (talk) 03:40, 19 December 2013 (UTC)

Mediawiki Support on Windows 2012 server and Hardware Requirements

Hi,

We need to install mediawiki on Windows 2012 server and when we search in Mediawikis installation guide there is information about windows 2003 and 2008 servers but we couldnt find any info weather mediawiki supports windows 2012 server or not.

Below is our mediawiki configuration:

• Mediawiki version: 1.20.3-0
• PHP: 3.01
• MySQL: 5.5

Please also let me know hardware requirements for windows 2012 server to run mediawiki if it supports..

Thanks. 14.140.124.69 (talk) 10:23, 19 December 2013 (UTC)

It should work in Windows 2012 server. In fact, system requirements talk about the webserver (IIS, Apache, etc), PHP and SQL server. The underlying system shouldn't matter, although Linux is preferred over Windows, since Windows may have some issues with filesystem for file storage, like invalid characters in filenames and such. Ciencia Al Poder (talk) 10:49, 19 December 2013 (UTC)

The biggest issue with windows (Other then what Ciencia Al Poder mentioned, that there is a bug in php preventing non-ascii characters in uploaded files) is that certain features don't work unless you install certain utilities that are commonly present on linux. For example GNU diff3 (and configured via $wgDiff3) Without diff3 you will have constant edit conflicts. Windows also gets significantly less testing than linux, however it should definitely work. Bawolff (talk) 08:57, 20 December 2013 (UTC)

Maybe that should be noted in Manual:Installation requirements Ciencia Al Poder (talk) 10:03, 20 December 2013 (UTC)

Display of only a particular category

Possible to display only the category of music?

http://en.wikipedia.org/w/api.php?action=parse&prop=text&page=queen&format=xml http://en.wikipedia.org/w/api.php?action=query&prop=revisions&rvprop=content&titles=queen&format=xml Hashian (talk) 10:59, 19 December 2013 (UTC)

I'm not sure I exactly understand your question, but the answer is probably sort of.

You can do something like:

• https://en.wikipedia.org/w/api.php?action=query&prop=revisions&titles=queen&rvprop=content&rvsection=2
• https://en.wikipedia.org/w/api.php?action=query&prop=revisions&titles=queen&rvprop=content&rvsection=2&rvparse
• https://en.wikipedia.org/w/api.php?action=parse&page=queen&section=2
• And also to get a list of sections https://en.wikipedia.org/w/api.php?action=parse&page=queen&prop=sections Bawolff (talk) 08:54, 20 December 2013 (UTC)

Hide sidebar and tabs on URL extension?

How do I configure MediaWiki(if it's possible) to hide the sidebar and tabs on a URL extension.

For example , on the main page , I should be able to hide the sidebar/tabs by simply adding ?hide or such in addition to the normal URL.

Is there any way for this to happen? Leaderboard (talk) 12:39, 19 December 2013 (UTC)

Hi!

Maybe the easiest solution is to use jQuery for that. I would not use ?hide as parameter, as it might also be appended after other parameters are already there making it an &hide (where your "?hide" would no longer match). When the URL contains the parameter "hide", then add some CSS styles to the according elements to make them display: none;.

I don't know how that works exactly, but it's classical jQuery stuff; once you found anything, please also post that here; I am interested in that as well. :-) 88.130.81.165 18:31, 19 December 2013 (UTC)

As an aside, you can hide all the skin by doing ?action=render (probably not what you want, but thought I'd mention just in case) Bawolff (talk) 08:49, 20 December 2013 (UTC)

It seems to work , but font goes bad. Leaderboard (talk) 14:09, 21 December 2013 (UTC)

What code are you using? 88.130.123.192 14:18, 21 December 2013 (UTC)

The code suggested by Balwolff above.

I replaced ?title=Main_Page with ?action=render and got such a screen.

'The font goes bad' means here that the font goes to Times New Roman - I want to preserve all the formatting instead but with the navbar and tabs disabled.

Is there any way for this? Leaderboard (talk) 16:30, 22 December 2013 (UTC)

action=render is only supposed to output the div with the content in it. You will not have any stylesheets or such included, all styles you see are browser defaults. Go for jQuery! 88.130.85.177 20:17, 22 December 2013 (UTC)

What jQuery code should I use and how do I insert it? Leaderboard (talk) 04:12, 23 December 2013 (UTC)

I don't know how that works exactly, but it's classical jQuery stuff; once you found anything, please also post that here; I am interested in that as well. :-)

You can insert JavaScript in your wiki on the page MediaWiki:Common.js. 88.130.111.116 12:30, 23 December 2013 (UTC)

Still not sure , I don't know what jQuery code to add. Leaderboard (talk) 08:55, 5 January 2014 (UTC)

 04:12, 23 December 2013 (UTC)
 16:30, 22 December 2013 (UTC)

Top menu

Hey all,

How do you add something to the top menu? Everything always turns to the side bar, but I want the server time (just a simple echo date("j f Y, H:i"); would do) next to the user name.

MediaWiki: 1.22 PHP: 5.3.27 MySQL: 5.5

Thanks in advance! 94.212.146.227 (talk) 19:44, 19 December 2013 (UTC)

Hi!

Yes, that is possible! Use the hook PersonalUrls to add an entry to the personal tools menu! 88.130.81.165 22:12, 19 December 2013 (UTC)

Thank you! Is there any karma, upvotes, rating I can give you, somehow somewhere? 94.212.146.227 00:07, 20 December 2013 (UTC)

user tool suggestions

1. easy to find user suggestion box on each page and (maybe with auto or prompting tags to classify use distribute the suggestion) for action - bet you'd get a ton of great ideas!

2. optional floating subject (page name) header bar to avoid user having to scroll back up to recall what page one is at - sometimes I have so many pages open or the page is long I get lost. Scrolling is a time and distraction-time loss.

love the site!

kind regards Brian 75.157.45.7 (talk) 23:00, 19 December 2013 (UTC)

For 1 - see extension:ArticleFeedback. Was on Wikipedia (I assume you meant suggestions for the wiki, as opposed to suggestions for new mediawiki features), but the Wikipedians found the suggestions not very useful (Lots of non-sensical suggestions) and sorting all the suggestions represented more work then the benefit gotten out of it. (I think. I didn't entirely follow the debate).

For 2. I think some people are experimenting with something along those lines. See Vector_Navigation_Modification Bawolff (talk) 08:47, 20 December 2013 (UTC)

Maintain tree view state in sidebar

Hi,

I have added tree view of categories to sidebar using CategoryTree extension and when i expand tree and navigate to any of page then the tree view is going to its collapsed state. How can i maintain trees state after clicking on it. It should work like Support/Development menu which maintains its state in mediawiki page: http://www.mediawiki.org/wiki/MediaWiki

plz help... 14.140.124.69 (talk) 06:34, 20 December 2013 (UTC)

Modify my Wiki Edit-Page

Hello everybody,

i hope you can help me with my Mediawiki problem. First of all, i hope you can understand my english, i'm not a native speaker.

I run a personal Wiki on my work pc, so i cannot give you an URL :/. But i will show you a screenshot of the problem area.

MediaWiki 1.22.0 PHP 5.4.16 (cgi-fcgi) Database 5.5.31-MariaDB

I want to implant a little header pic in the Edit-menu. So if somebody want to create or edit a page on the wiki, he will get only in this menu a picture above the headline of the edit site (Screenshot will show the spot. The picture should not be shown at any other site or place of the wiki.

I hope you can help me :/.

The Screenshot (The red surrounded space shows the spot): http://s1.directupload.net/images/131220/2548o44f.jpg 134.91.10.143 (talk) 10:22, 20 December 2013 (UTC)

You can add a css rule like body.action-edit h1#firstHeading {background: url( 'http://foo.com/image.jpg' ) no-repeat; padding-top:50px } to the page MediaWiki:Common.css on your wiki. (You may have to adjust the rule slightly, particularly the amount of padding to get what your want) Bawolff (talk) 06:50, 21 December 2013 (UTC)

Thank you very much, it works great :). And sorry for the late respond, i wasn't at home the last two weeks :(.

Maybe you could help me again?

Instead of a picture, would it be possible to insert a chart/table at the same position? 134.91.10.143 09:33, 6 January 2014 (UTC)

How to change math background color?

I want to change formula background color but the method that described in https://meta.wikimedia.org/wiki/Help:Formula#Color either doesn't work and outdated. Omidh (talk) 10:45, 20 December 2013 (UTC)

The page on meta doesn't even do what it suggests.

Try:

<div style="background-color:orange; float:left;"><math>f^{x_1}(y^{2}_{1})</math></div><br style="clear:both">

Which makes:

$f^{x_1}(y_1^2)$

(Note there is also: $wgTexvcBackgroundColor, but you probably want to keep that at its default of Transparent) Bawolff (talk) 06:38, 21 December 2013 (UTC)

Sighting-Settings?

Hello, where i can change, that i must first sight, before public the text.

Sorry for my english, i hope u can read it. 88.74.71.246 (talk) 10:52, 20 December 2013 (UTC)

Extension:FlaggedRevs Nemo 14:23, 20 December 2013 (UTC)

192.44.63.165 14:48, 20 December 2013 (UTC)

Editing issue on apache webserver. works on xampp

Hi I keep getting the following error when doing a simple edit after installing can anyone point out what I am doing wrong:

 [f7e6e4e8] /wiki/index.php?title=Main_Page&action=submit Exception from line 773 of /usr/local/pem/vhosts/235501/webspace/httpdocs/half12.com/wiki/includes/HttpFunctions.php:
Error setting curl options.
Backtrace: #0 /usr/local/pem/vhosts/235501/webspace/httpdocs/half12.com/wiki/includes/HttpFunctions.php(74): CurlHttpRequest->execute()
#1 /usr/local/pem/vhosts/235501/webspace/httpdocs/half12.com/wiki/includes/HttpFunctions.php(95): Http::request(string, string, array) 
#2 /usr/local/pem/vhosts/235501/webspace/httpdocs/half12.com/wiki/extensions/SpamBlacklist/BaseBlacklist.php(308): Http::get(string) 
#3 /usr/local/pem/vhosts/235501/webspace/httpdocs/half12.com/wiki/extensions/SpamBlacklist/BaseBlacklist.php(271): BaseBlacklist->getHttpText(string)
#4 /usr/local/pem/vhosts/235501/webspace/httpdocs/half12.com/wiki/extensions/SpamBlacklist/BaseBlacklist.php(247): BaseBlacklist->buildSharedBlacklists() 
#5 /usr/local/pem/vhosts/235501/webspace/httpdocs/half12.com/wiki/extensions/SpamBlacklist/BaseBlacklist.php(196): BaseBlacklist->getSharedBlacklists() 
#6 /usr/local/pem/vhosts/235501/webspace/httpdocs/half12.com/wiki/extensions/SpamBlacklist/SpamBlacklist_body.php(44): BaseBlacklist->getBlacklists()
 #7 /usr/local/pem/vhosts/235501/webspace/httpdocs/half12.com/wiki/extensions/SpamBlacklist/SpamBlacklistHooks.php(37): SpamBlacklist->filter(array, Title)
 #8 [internal function]: SpamBlacklistHooks::filterMergedContent(RequestContext, WikitextContent, Status, string, User, boolean) 
#9 /usr/local/pem/vhosts/235501/webspace/httpdocs/half12.com/wiki/includes/Hooks.php(199): call_user_func_array(string, array) 
#10 /usr/local/pem/vhosts/235501/webspace/httpdocs/half12.com/wiki/includes/GlobalFunctions.php(3877): Hooks::run(string, array) 
#11 /usr/local/pem/vhosts/235501/webspace/httpdocs/half12.com/wiki/includes/EditPage.php(1331): wfRunHooks(string, array) 
#12 /usr/local/pem/vhosts/235501/webspace/httpdocs/half12.com/wiki/includes/EditPage.php(1676): EditPage->runPostMergeFilters(WikitextContent, Status, User)
 #13 /usr/local/pem/vhosts/235501/webspace/httpdocs/half12.com/wiki/includes/EditPage.php(1213): EditPage->internalAttemptSave(boolean, boolean)
#14 /usr/local/pem/vhosts/235501/webspace/httpdocs/half12.com/wiki/includes/EditPage.php(416): EditPage->attemptSave()
 #15 /usr/local/pem/vhosts/235501/webspace/httpdocs/half12.com/wiki/includes/actions/EditAction.php(50): EditPage->edit()
 #16 /usr/local/pem/vhosts/235501/webspace/httpdocs/half12.com/wiki/includes/actions/EditAction.php(76): EditAction->show() 
#17 /usr/local/pem/vhosts/235501/webspace/httpdocs/half12.com/wiki/includes/Wiki.php(448): SubmitAction->show() 
#18 /usr/local/pem/vhosts/235501/webspace/httpdocs/half12.com/wiki/includes/Wiki.php(312): MediaWiki->performAction(Article, Title) 
#19 /usr/local/pem/vhosts/235501/webspace/httpdocs/half12.com/wiki/includes/Wiki.php(602): MediaWiki->performRequest()
 #20 /usr/local/pem/vhosts/235501/webspace/httpdocs/half12.com/wiki/includes/Wiki.php(467): MediaWiki->main()
 #21 /usr/local/pem/vhosts/235501/webspace/httpdocs/half12.com/wiki/index.php(49): MediaWiki->run() 
#22 {main}

86.45.176.214 (talk) 11:38, 20 December 2013 (UTC)

What version of PHP curl extension do you have installed (you can find this out via phpinfo()) Bawolff (talk) 06:32, 21 December 2013 (UTC)

I have same "includes/HttpFunctions.php: Error setting curl options." error during installation of new mw 1.22 with curl 7.15.5 Umarzuki (talk) 15:32, 31 December 2013 (UTC)

Changing the edit link in the pages

Hello,

Following a specific need, I would add a second link nearby links "edit" on body content

___[edit][otherlink]

But I didn't find where this link was generated in Wiki sources.

Can someone tell me it?

Thank you in advance. 192.44.63.165 (talk) 14:08, 20 December 2013 (UTC)

Hi!

It doesn't really matter where this link is generated in the MediaWiki source code; changing the source code is BAD. Instead, use a hook. You should be able to change the HTML code of the section edit links using the hook DoEditSectionLink. 88.130.102.228 16:06, 20 December 2013 (UTC)

[RESOLVED] Database error in upgrading from 1.18 to 1.22

Hi, I am trying to upgrade wiki 1.18 to 1.22. I uploaded wiki-22 files, copied Localsettings.php to the folder, ran mw-config/index.php from web browser, then got this error:

"A database query error has occurred. This may indicate a bug in the software."

How should I fix this error? Your help is much appreciated.

My current version: MediaWiki 1.18.0 PHP 5.3.24 (cgi-fcgi) MySQL 5.0.96-log

Thanks, Vikas 113.193.104.33 (talk) 15:27, 20 December 2013 (UTC)

Hi Vikas,

at the end of your LocalSettings.php file add

$wgShowSQLErrors = 1;

and run the update script again. What error message do you get? 88.130.102.228 16:01, 20 December 2013 (UTC)

Thanks for reply.

This says:

A database query error has occurred. This may indicate a bug in the software.

Query:

SELECT page_id,page_namespace,page_title,page_restrictions,page_counter,page_is_redirect,page_is_new,page_random,page_touched,page_latest,page_len,page_content_model FROM `jainwikipage` WHERE page_namespace = '0' AND page_title = 'Mw-config/index.php' LIMIT 1

Function: WikiPage::pageData

Error: 1054 Unknown column 'page_content_model' in 'field list' (jainwikiuser.db.7394013.hostedresource.com) 113.193.104.33 16:47, 20 December 2013 (UTC)

The interesting part in that message is:

Function: WikiPage::pageData Error: 1054 Unknown column 'page_content_model' in 'field list' (jainwikiuser.db.7394013.hostedresource.com)

The updater obviously expects the column "page_content_model" to be in your database, but it is not. As afirst step, I would take a backup of the database and just try the update again.

If that does not help, have a look at this thread, where the same problem has been discussed. Basically some hack to add and remove the column at the start of the update... This is actually not the same problem, sorry. 88.130.102.228 18:06, 20 December 2013 (UTC)

The database query indicates you are not running the web configurations script, but actually going to the page "Mw-config/index.php" on your wiki. Possibly you have rewrite rules set up that prevent you from accessing mw-config/index.php properly. If possible try running update.php from the command line, otherwise investigate getting to the actual web updater. Bawolff (talk) 06:26, 21 December 2013 (UTC)

I had write permission rules in LocalSettings.php which I removed, but still had the same error.

My SSH doesn't allow me to run PHP commands. It says command not found. How can I get that running? 1.23.179.84 10:47, 21 December 2013 (UTC)

I read that page before too, but couldn't follow much. But again read that, inserted a column that was missing in page table. Then ran mw-config/index.php from Web, I get this error.

Mw-config/index.php

There is currently no text in this page. You can search for this page title in other pages, search the related logs, or edit this page.

When I go to main page, it doesn't show data. Clicking on recent changes, it shows recent changes in pages. However trying to open any of the page, it gives this error:

A database query error has occurred. This may indicate a bug in the software.

Query:

SELECT rev_id,rev_page,rev_text_id,rev_timestamp,rev_comment,rev_user_text,rev_user,rev_minor_edit,rev_deleted,rev_len,rev_parent_id,rev_sha1,rev_content_format,rev_content_model,page_namespace,page_title,page_id,page_latest,page_is_redirect,page_len,user_name FROM `jainwikirevision` INNER JOIN `jainwikipage` ON ((page_id = rev_page)) LEFT JOIN `jainwikiuser` ON ((rev_user != 0) AND (user_id = rev_user)) WHERE page_id = '4232' AND rev_id = '8256' LIMIT 1

Function: Revision::fetchFromConds

Error: 1054 Unknown column 'rev_sha1' in 'field list' (jainwikiuser.db.7394013.hostedresource.com)

What should I do to update? 1.23.179.84 11:14, 21 December 2013 (UTC)

When you actually end up on the page Mw-config/... with capital "M", then you have RewriteRules, which interfere with the update script. For the time of the upgrade you can try renaming the file .htaccess to something else. This will break the output of your wiki, but it should allow you to run the web updater.

I have added hints on what to do when you cannot run php update.php from the shell to the page Upgrade. 88.130.123.192 12:23, 21 December 2013 (UTC)

Thanks a lot for helping with this. I renamed .htaccess and then followed the instructions. It is working well now. I somehow don't remember renaming .htaccess when I last upgrade to .18 version. I'll keep this in mind next time.

Thanks again,

Vikas 1.23.179.237 13:54, 21 December 2013 (UTC)

Always follow the information on page Upgrade. This is the most up to date upgrade guide and it contains all the things you need to know. I have just added the information about interfering RewriteRules there as well. 88.130.123.192 14:29, 21 December 2013 (UTC)

A database query error has occurred. This may indicate a bug in the software.

Query:

SELECT user_claim FROM `user` WHERE user_id=

Function: SkinTemplate::buildPersonalUrls

Error: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near at line 1 (localhost)

please help me 210.89.56.38 14:27, 3 March 2014 (UTC)

I can only guess as the MySQL error you posted does not contain information on the actual error, but maybe the column user_claim is not present in the DB? Run update.php to fix! 88.130.67.150 15:13, 3 March 2014 (UTC)

"CACHE_ACCEL requested but no suitable object cache is present."

Hi, My wiki is on a VPS on dreamhost and has xcache enabled. Today after logging in, it asked me to upgrade my php to 5.3 (which was long overdue on dreamhost). Anyway, after doing that I went to my wiki and I noticed I got a message:

CACHE_ACCEL requested but no suitable object cache is present. You may want to install APC.

Backtrace:

#0 [internal function]: ObjectCache::newAccelerator(Array)
#1 /home/kingkwon/koreanwikiproject.com/wiki/includes/objectcache/ObjectCache.php(62): call_user_func('ObjectCache::ne...', Array)
#2 /home/kingkwon/koreanwikiproject.com/wiki/includes/objectcache/ObjectCache.php(50): ObjectCache::newFromParams(Array)
#3 /home/kingkwon/koreanwikiproject.com/wiki/includes/objectcache/ObjectCache.php(23): ObjectCache::newFromId(3)
#4 /home/kingkwon/koreanwikiproject.com/wiki/includes/GlobalFunctions.php(3816): ObjectCache::getInstance(3)
#5 /home/kingkwon/koreanwikiproject.com/wiki/includes/Setup.php(439): wfGetMainCache()
#6 /home/kingkwon/koreanwikiproject.com/wiki/includes/WebStart.php(157): require_once('/home/kingkwon/...')
#7 /home/kingkwon/koreanwikiproject.com/wiki/index.php(54): require('/home/kingkwon/...')
#8 {main}

I don't know if upgrading the php broke it, or if it was broken beforehand. I've tried changing the php back to 5.2 and tried 5.4 as well and no luck so far. I have no idea how to proceed. Any help would be appreciated. Thanks Bluesoju (talk) 14:51, 21 December 2013 (UTC)

Hi!

Try adjusting the vale of $wgMainCacheType in LocalSettings.php. 88.130.123.192 15:26, 21 December 2013 (UTC)

What should I adjust it to? Previously it had no problem picking up xcache automatically, why not now? Bluesoju (talk) 01:45, 22 December 2013 (UTC)

Make sure that XCache is installed with the new version of PHP. The most likely cause is the new version of PHP simply doesn't have xcache installed. You can do this by creating a php file with just the code <?php phpinfo(); and then viewing it in a web browser.

Setting $wgMainCacheType = CACHE_NONE; will disable all caching, which would prevent the error, but make things slow. Bawolff (talk) 05:29, 22 December 2013 (UTC)

I have the same problem using DreamHost VPS with MW 1.23. Also, when I try to install a new MediaWiki installation (v1.25), I get "Warning: Could not find APC, XCache or WinCache. Object caching is not enabled." Leucosticte (talk) 18:15, 3 November 2014 (UTC)

It's the same problem :) Without any object cache, you can not use object caches. You should try to install php with XCache or something similar, or just disable object caching like Bawolff said. Florianschmidtwelzow (talk) 09:54, 4 November 2014 (UTC)

Well, phpinfo() says XCache is present. DreamHost tech support writes:

This message is normal. The configuration we use for PHP is,

unfortunately, not compatible with using XCache as an object cache for

applications such as MediaWiki. Attempting to enable it will result in

unreliable behavior (e.g, users in MediaWiki not staying logged in, or

edits to pages sometimes not taking effect).

XCache does still work as a PHP opcode cache, though. This is sufficient

to speed up PHP applications (again, such as MediaWiki) by quite a bit;

the object cache functionality is not crucial.

Thanks!

Andrew F Leucosticte (talk) 15:07, 4 November 2014 (UTC)

One thing to check is that you have a valid config for xcache in php.ini (or the appropriate alternative config file). I was having the same problem and it was because I didn't have some of the following entries:

xcache.size = 60M
 xcache.var_size = 4M

Have a look at the xcache.ini that is shipped with xcache for the possible variables to define. Ralfthewise (talk) 18:10, 4 May 2016 (UTC)

[RESOLVED] How to restore a database backup from a very old version (1.8) to a current one (1.22)?

For al lot of years a used a closed mediawiki, my on wiki, for literature management. It was hosted on a virtual server (debian). A few days ago, this server was hacked, so I had to restart/new install the server from srcatch. Before I did, fortunaly I'm able to make a mysql-dump from the wiki, but not more. This mediawiki was version 1.8 and it works very fine all the years. Only with plain text, no pictures, no datas or anything else.

But now I'm forced to install not only a new server (debian 7 - squeeze) but also a new(er) mediawiki version. The installation itself isn't a problem, I done. But now the question is: how can I restore the database backup/dump from the old version (1.8) to the current one (1.22)? The manual page "Manual:Restoring a wiki from backup" says:"Particularly, avoid restoring a database backup from an older version of the software into a newer version; this will not work." Okay, but I think it isn't meaningful (and also possible) to install mediawiki Version 1.8.

So, what can I do?

I'm very happy about every help! 87.161.244.34 (talk) 18:33, 21 December 2013 (UTC)

If you have your old 1.8 database downloaded all you need to do is upload it to your MySQL or another sql databases and then run update.php in Mediawiki 1.22 and it should update the tables in your MySQL database or your other sql database. 86.135.255.245 19:29, 21 December 2013 (UTC)

Yes, take the old database and put it in the new MySQL server. Together with the files of the new MediaWiki version you then have the same situation as you would have when you updated from MediaWiki 1.8. Follow the steps on page Upgrade to complete the update; most importantly run update.php. 88.130.85.177 07:25, 22 December 2013 (UTC)

Thank you very much!! :-) This works, takes time, but works without any error! So a lot of hours and years of work (the content of my wiki) are saved.

Have a nice time at christmas (I'll ;-))! 79.197.209.223 08:01, 22 December 2013 (UTC)

mediawiki error

hi I have a problem in mediawiki it says this error [45d6fa8e] /mw-config/?page=ExistingWiki Exception from line 181 of /home/paladox/public_html/en/includes/Hooks.php: Invalid callback in hooks for ParserFirstCallInit

Backtrace:

1. 0 /home/paladox/public_html/en/includes/GlobalFunctions.php(4031): Hooks::run(string, array)

#1 /home/paladox/public_html/en/includes/parser/Parser.php(275): wfRunHooks(string, array)
#2 /home/paladox/public_html/en/includes/parser/Parser.php(287): Parser->firstCallInit()
#3 /home/paladox/public_html/en/includes/parser/Parser.php(4823): Parser->clearState()
#4 /home/paladox/public_html/en/includes/parser/Parser.php(367): Parser->startParse(Title, ParserOptions, integer, boolean)
#5 /home/paladox/public_html/en/includes/installer/Installer.php(591): Parser->parse(string, Title, ParserOptions, boolean)
#6 /home/paladox/public_html/en/includes/installer/WebInstaller.php(668): Installer->parse(string, boolean)
#7 /home/paladox/public_html/en/includes/installer/WebInstallerPage.php(358): WebInstaller->getInfoBox(string)
#8 /home/paladox/public_html/en/includes/installer/WebInstallerPage.php(346): WebInstaller_ExistingWiki->showKeyForm()
#9 /home/paladox/public_html/en/includes/installer/WebInstaller.php(275): WebInstaller_ExistingWiki->execute()
#10 /home/paladox/public_html/en/mw-config/index.php(61): WebInstaller->execute(array)
#11 /home/paladox/public_html/en/mw-config/index.php(29): wfInstallerMain()
#12 {main}

I am running mediawiki 1.23 wmf8 and php 5.3.8 86.135.255.245 (talk) 22:40, 21 December 2013 (UTC)

Looks like the same as Extension_talk:Math#fix_error_in_extension_math. Try running the latest stable MediaWiki version instead (1.22), or report the bug at bugzilla. Ciencia Al Poder (talk) 10:52, 23 December 2013 (UTC)

Non-developer's Guide to Git

I'm using Mediawiki software to maintain a couple private wikis. In the past I downloaded gz files and updated the sites manually. Now it seems that we're supposed to use git to keep things up to date. Installing new extensions any other way doesn't seem supported (unless I copy individual files manually, which can't be what anyone wants). Almost all the git related content here seems to be aimed at the developer, not the average site maintainer. I'm quite familiar with Linux and PHP but I'm new to git and I'm not quite getting it (or should that be gitting it?). Is there a non-developer's guide to git for Mediawiki? If not, there should be. I'm thinkin it would be something that walks through setting up and maintaining a mediawiki web site using git from the perspective of a site administrator?

Some specific questions:

I have installed git on my CentOS 6 machine and used "git clone https://gerrit.wikimedia.org/r/p/mediawiki/core.git" to download MediaWiki core. One thing that wasn't mentioned on the Download from Git page is what directory I should be in when that is done or whether it matters. Is that meant to be done so that the resulting ./core directory is the actual wikimedia installation (i.e. the web directory)? Or do files get copied from there to the web tree (and if so, by git or manually)? Also, I don't see what "git checkout" actually does. Is it meant to checkout a copy of the files and put them somewhere? If so, where? HenryHartley (talk) 03:54, 22 December 2013 (UTC)

Hi. I'm sorry to hear you are having trouble with the gz files. They are still supported, and are still the recommended way of getting MediaWiki for non-developers. What troubles specifically are you having with extensions?

Git is primarily aimed at developers. Some people do use it just for getting MediaWiki (It can be convenient for upgrading versions), however it is by no means required. To answer your question, the directory downloaded is the web directory. The checkout command is used to change versions. (By default it downloads "master" which is the experimental MediaWiki 1.23 alpha). You can use a command like git checkout origin/REL1_22 from inside the downloaded directory to switch to the stable MediaWiki 1.22 release Bawolff (talk) 05:26, 22 December 2013 (UTC)

That's good to hear. Perhaps I've missunderstood. What made me think gz files were no longer available (excpet for the core code) is that I went to get a few extensions (Extension:HighslideGallery and Extension:Maps specifically) and both of them only have links to github for their source. I don't see any gz tarballs of either. Am I missing something there? I suppose I could use git just for the extensions. HenryHartley (talk) 00:05, 23 December 2013 (UTC)

Both of those extensions are being developed by a different group then the people who are developing MediaWiki core (To be accurate, Maps is developed by someone who is also active in MW core, but he has for some reason chosen not to host that extension on wikimedia repos), and the people developing those extensions decided not to use Wikimedia's source control repositories.

You should still be able to download archive files for those extensions, the format however is zip instead of tar.gz (Most unix hosts have an unzip command, so you should still be able to upload then unzip in a similar way to a gz tarball). The link to download the zip archive on github, is on the sidebar on the right hand side, towards the bottom (It has the text "Download ZIP"). Bawolff (talk) 07:19, 23 December 2013 (UTC)

Sure enough. I didn't see that link and it's exactly what I was looking for. I have no problem using zip instead of gzip. Thanks for taking the time to help me out and show me what I'm missing. HenryHartley (talk) 12:45, 24 December 2013 (UTC)

Text to Speech extension?

Has anyone had any experience adding a text to speech extension to their wiki's?

I'm looking for an open source solution that's as simple as http://www.readspeaker.com. That product looks amazing, it highlights text and reads clearly. I'm wondering if something similar is developed for Wikipedia and the wikimedia platform.

I know there are client side solutions but I can't find an embedded solution that's open source and up and running anywhere. Any suggestions? MarkJurgens (talk) 05:01, 22 December 2013 (UTC)

Special:SpecialPages error

• MediaWiki 1.21.1
• PHP 5.3.27
• MySQL 5.5.33-31.1

Link to the site's Special pages www.everythingfoodanddrink.org/wiki/Special:SpecialPages

The following error has showed up on all three wikis in my farm, this error is generated when navigating to Special:SpecialPages

Warning: Illegal offset type in $IP/public_html/w/includes/specials/SpecialSpecialpages.php on line 69 (sometimes shows line 70)

ScreenShot of file in question can be seen here: SpecialSpecialpages.php on line 69. I have a feeling this error is caused by an extension, but have no idea which one or if at all.

Hoping this looks familiar to someone.

Thanx - FlightTime (open channel) 05:55, 22 December 2013 (UTC)

I am not sure if it has anything to do with groups you have your wiki but try updating your extension to 1.21 please or try updating to 1.22 in 1.22 vector is bult into the core now so when upgraded to 1.22 you no longer need the extension vector 86.135.255.245 12:29, 22 December 2013 (UTC)

I believe I've narrowed it down to Extension:TwoFactorAuthentication when active is generating the error, but I still don't know how to resolve the error.

Also I've just Upgraded to 1.22.0, the error is still present (except it's line 70 now)

Suggestions ? Mlpearc (powwow) 22:25, 22 December 2013 (UTC)

Does making the change to SpecialTwoFactoryAuth.php described at https://gerrit.wikimedia.org/r/#/c/103527/1/SpecialTwoFactorAuth.php fix the issue for you? (Edit: The patch is now in the master version of that extension, so you could also just re-download it). Bawolff (talk) 06:54, 24 December 2013 (UTC)

I'm such a rookie :P Working fine thank you Bawolff you saved me again Cheers Mlpearc (powwow) 00:06, 26 December 2013 (UTC)

Improving the effectiveness of regular expressions against vandalism

The current mechanism that identify vandalism is based on regular expression applied to "illegal" variations of words. This is not effective, it can be easily bypassed (as has been seen very often at least in the pt.* community).

I've proposed a solution to it here.

The translation to English resumes in: 1) provide a default (and a good) spell checking mechanism. Just allow save the wikitext if all words exists (using the dictionary, inflections, etc.). 2) After this process send this data to the layer that counters vandalism (anti vandalism tools).

1. A database of words that "exist", already exist, and its open: the wiktionary.
2. A set of libraries for a lot of programming languages exist that do inflections of words.
3. That is very good, because the side effect of it is: articles will be more correct!

What is missing?

There are any projects, extensions, looking this? Guiwp (talk) 18:52, 22 December 2013 (UTC)

Having a "very good" dictionary of possible words is difficult. In particular having an exhaustive list of proper nouns is pretty much impossible. Also some articles will presumably have words in foreign languages, so one has to allow valid words in any language. Bawolff (talk) 08:52, 23 December 2013 (UTC)

Yes, that's also what I thought: Creating a usable whitelist with allowed words will be pretty much impossible. 88.130.111.116 12:31, 23 December 2013 (UTC)

But this doesn't make sense. You think that the number of arbitrary words (illegal variations) are less than the known words that we consult in a simple dictionary? No they are much more, 1000x more, more, etc. Most people use few words. You can make a research and publish the word frequency used in the articles, you will see that the used words are very few compared to the whole lexicon that they could use.

The whitelist doesn't need to be perfect at the first time, words can be added as their use start appearing. And articles can be flagged to latter be published after someone personally check and possibly later add the word to whitelies database (or create a "inflexer" for a new variation).

The way vandalism its currently identified is much more "ridiculous" than trying something better. Man, I saw funny regular expressions just trying to catch a simple variation (illegal) of a word, and they failed, simply because its easy to bypass a system that accepts arbitrary combination of characters.

Usually the foreign languages are present through foreign terms in some articles, but we are not allowed to write an article using a foreign language. Thats another point making whitelist for category of articles, because if one present a term that has nothing to do with the subject, we known it is vandalism, or it its possibly a vandalism that can be notified.

I seriously believe that things wont get better with the current mechanism. If you believe, give me technical reasons please. Maybe in 20 or more years, things will be the same if they don't change this way to catch vandalism. Guiwp (talk) 15:08, 23 December 2013 (UTC)

Technical reasons? We already did -- it is impossible to make a dictionary sufficient enough to cover every possible word in every possible language, including every possible proper noun, intentional misspellings of words (e.g. "internet speak"), and code (among many other things). If such a dictionary was made, it would likely number in the millions of words and be impossible to scan every word of every submission for a match in the dictionary in a reasonable amount of time (especially of larger articles that average 20 KB of text or more).

This is way too limiting and even more arbitrary of a restriction than the current regex-based measures. Additionally, a sufficiently motivated vandal can and will get around any arbitrary restriction you impose, so in addition to not doing anything (except, I guess, making vandals vandalize pages using actual words), it harms the average user who may wish to type something that doesn't exist in the dictionary and finds that they are unable to do so ("I really wanted to write an article on Khenarthi's Roost, but it isn't in the dictionary so I can't!"). Skizzerz 00:09, 24 December 2013 (UTC)

Sorry, but I think that you didn't read what I wrote.

Let me again, try to make you read.

• You think that the number of arbitrary words (illegal variations) are less than the known words that we consult in a simple dictionary? You get to be kidding if you answer that arbitrary combinations are less than using known words. So no, the current system is much less effective. Its simple I wont rewrite it again.
• Most people use few words. Thats somthing globally very "known", you can read some books in the linguistics area, you will known.
• The whitelist doesn't need to be perfect at the first time. Where did I said to cover every possible word in every possible language? Please, read the text...

Now based on simple math that 2+2 is greater than 1, I can't completely understand what you say by This is way too limiting and even more arbitrary of a restriction than the current regex-based measures. Did you known what are arbitrary characters combination?

Other thing you said that proves you didn't read:

"I really wanted to write an article on Khenarthi's Roost, but it isn't in the dictionary so I can't!"

What I wrote before:

And articles can be flagged to latter be published after someone personally check and possibly later add the word to whitelies database (or create a "inflexer" for a new variation).

Anyway, thanks for you comments. I think I should look for people more optimistic. Bye. Guiwp (talk) 01:08, 24 December 2013 (UTC)

> Did you known what are arbitrary characters combination?

Skizzerz is right. Please stop becoming offensive and stay on topic!

It is true that trusted editors could flag all new revisions in every article. The article would then only be displayed after this check. This concept in fact has been introduced e.g. in the German Wikipedia and successfully is in use there since years. However, this has nothing to do with an automated check against a whitelist in which all words of the article have to be included as you want it. While aiming at the same problem, flagged revisions are technically a completely different cup of tea.

I also see the point that you can use various kinds of spelling to write one and the same illegal word. E.g. for the small blue pills you can use two slashes instead of the "V", a small "L" or a "1" instead of the "i" or some kind of unicode sign which looks like one of these letters, but is not one of them. You see that you will quickly have several thousand variations of the same illegal word. However, compared to the few illegal words, the number of legal words is way bigger: The Oxford English Dictionary lists around 170.000 words, around 50.000 obsolete words and nearly 10.000 derivate words. And all this does neither include technical terms nor flections nor composita. There is a vast number of legal words and it is just untrue to say they would not be used. Even if the same user only uses "a few" (how many ever that may be) different words a day, the sum of users, the sum of languages and the sum of all their different areas of expertise will create an immensely hugh number of legal words. And what should happen when a user adds a word not in that list? Should we then disallow saving the whole edit? There so often are articles with typing errors - or maybe only about a word, which you have not amongst your billions of words. Imagine you wrote your first article and you just would not be able to save it. How annoying! The number of editors is already stagnating today, but what would happen with that patronizing? Many more would turn away and never come back. It would do way more harm than good.

And I even go one step further when I dare to say: Not only is it personally impossible; it is also technically impossible to check every single edit, every single word against a dictionary with these billions of words, flections and derivations. Although hardware and also CPU cycles are becoming cheaper and cheaper, you will still have to throw an immense amount of money at this problem would you really want to check every single edit and every single word against such a list. And all this does not even take into account that languages are constantly changing: New words are created and meanings of old words change. What was accepted yesterday maybe has become an insult now. You would have to constantly update your huddle of words to stay up to date. Basically like a dictionary company; but even more blatant as they can leave words out (e.g. because they don't consider them tightened enough), while with a whitelist you cannot do so.

I am not pessimistic, but just realistic when I say:

What you want, technically as well as personally, just is impossible to be accomplished. 88.130.111.116 01:46, 24 December 2013 (UTC)

Did you known what are arbitrary characters combination?

This was a question, simply a question on the topic. There are some readers, volunteers that do not known "computing". They just try to help, I was thinking the Skizzerz was one. Sorry, didn't want offend Skizzerz. But he didn't said that he was offended, are you "Skizzerz"?

You wrote:

several thousand variations of the same illegal word.

Man... I could say that with arbitrary combination of characters you don't declare a "word" a "word", its simply millions/billions/etc. of combinations (that is, thousand times bigger than of all dictionaries that you could cite in this thread right now, sorry). I'm not telling you to make characters appear a word, as illegal variation, I'm telling you that fuzzy combinations with all available characters in unicode are much, but much more bigger than predefined set of words. And that is what I mean by arbitrary.

I can't make it more clear, I'll stop on this thread. Thank you for you comments. Guiwp (talk) 02:04, 24 December 2013 (UTC)

You're always welcome. :-)

Merry Christmas! 88.130.111.116 03:27, 24 December 2013 (UTC)

Thanks for this words. Now I see hope In your words. Now I'm more happy. =)

We'll find a way to improve all this "system"! Lets hope! =)

Merry Christmas to all people! Guiwp (talk) 03:59, 24 December 2013 (UTC)

I guess I'm late to the party here, but...

In your original post I assumed you meant that any edit containing a non-allowed word would be utterly rejected. In such a system, the room for error is pretty close to zero, as the inconvenience for a false positive is extremely high.

In regards to the number of bad words being larger than the number of good words. That is almost certainly true. There is a countably infinite number of bad words, and I believe only a finite number of good words. However just because the cardinality is higher on the bad word sign, does not necessarily make it a do-able task to do it in the other direction, since a number smaller then infinity can still be much to large to manage.

However, later on you talk about using this a system to trigger extra review, or tag an edit for futher review, etc. That's much more likely to be workable imo, although there would still be many questions to work out about how such a system would actually work, and what the review process would be like.

But if you do go in that direction, it might be better to go a more machine learning approach rather than spelling (lest the vandals and spammers learn to spell obligatory xkcd). You may be interested in reading up on w:User:ClueBot_NG.

Happy holidays, Bawolff (talk) 06:15, 24 December 2013 (UTC)

... and may also be interested on w:pt:Wikipédia Discussão:Projetos/AntiVandalismo#ClueBot NG. Helder 13:51, 24 December 2013 (UTC)

Problem uploading File.

Hello dear forum

I have the following problem. I have a local mediawiki

- running on MAMP - on osx 10.9 - version 1.22 - using the Push extension to push pages to a mediawiki on a server.

The pushing works fine for the page itself but I have problems pushing embedded files. The extension is a bit ouf of date so I adapted it to the changes php and mediawiki made meanwhile. That was only the usage of curl file and httpfunctions from mediawiki.

When I try to push a page with a file I get the following error;

couldn't open file "mwstore://local-backend/local-public/2/2f/Mold_and_sterile.jpg"

I chmoded and chowned the images folder to 777 and 755 and 744 and user www and myself and whatnot. Didn't help. Can anybody give me a hint in the right direction? 84.73.130.2 (talk) 22:03, 22 December 2013 (UTC)

First, add

 error_reporting( -1 );
 ini_set( 'display_errors', 1 );

to your LocalSettings.php file and see if any errors are displayed. If none are, try enabling debugging and see if the file shows you anything. ☠MarkAHershberger☢(talk)☣ 16:03, 5 February 2014 (UTC)

Um, why git?

Hello-

I see that MediaWiki is moving everything to git. That's great! For developers, but the rest of lowly admins really have hardly any clue on how to use this tool, and nearly all documentation for this tool is targeted towards developersl. If you are going to insist on using the tool for MediWiki and all of its extensions, I beg you, please, please, please write git instructions as if you are talking to someone who has never even heard the term before.

Thanks. MadenssContinued (talk) 03:25, 23 December 2013 (UTC)

We are only moving to git for developer stuff (which actually happened quite a while ago, around the release of 1.19) or if you for some reason want to use an alpha release of MediaWiki on your site. Non-developers are still welcome (and encouraged) to use the tarball releases. If you have any trouble using these tarballs, please let us know what the trouble is.

Non-developers can of course use git for installing their wikis if they want (Some people like it so they can do version control for any local changes they make [We of course recommend people don't make local changes, but some people still do]), but they by no means have to

See also Project:Support desk/Flow/2013/12#h-Non-developer's_Guide_to_Git-2013-12-22T03:54:00.000Z Bawolff (talk) 08:26, 23 December 2013 (UTC)

If there is something missing or unclear about https://www.mediawiki.org/wiki/Git/Tutorial I'd love to see specific feedback on its talk page. Thanks in advance for your help to improve the documentation! AKlapper (WMF) (talk) 16:46, 23 December 2013 (UTC)

Wiki's formatting disappeared. Turned into text only page

Have been having this issue off an on and can't seem to figure out why. Currently, when viewing the wiki the pages display without any formatting, just as simple text in a list. The links are still there but no images show. It is as if the css files disappeared. At first I noticed that this would happen only on one computer... others would show the page fine. Now it is all computers.

Any ideas? So far I've restarted the httpd service and reset the CentOS box it is installed on.

Thanks! 66.31.98.174 (talk) 13:49, 23 December 2013 (UTC)

Which MediaWiki version? When did this problem start and what did you do before? Also see https://www.mediawiki.org/wiki/Manual:How_to_debug AKlapper (WMF) (talk) 16:30, 23 December 2013 (UTC)

After messing around a bit I found it to be a DNS issue. When I am pointing at my company's DNS server, then everything comes up fine. If I use something different then it is no good. This will work great for people inside the domain but not when they are remote. I understand now that the references to elements in the site require name resolution on the browser side that only work if you are on the internal network / using the DNS server. Thoughts on how I go about fixing this? I inherited this wiki from a long gone employee and I'm trying to fix all the mistakes.

Thanks. 66.31.98.174 01:29, 24 December 2013 (UTC)

Hi!

In these cases, usually it's $wgServer. In fact, it's always $wgServer. Make sure that you are using the right base URL there! 88.130.111.116 01:58, 24 December 2013 (UTC)

Upgrade from 1.19 to 1.22 - doesn't appear to show

I just attempted at upgrade from 1.19 to 1.22. I thought I did everything right - download, replace files, run the web update (I had no idea how to do it using the Command Line/SSH). But when I ran the updated and checked my version on my wiki, it said updating to 1.19.2. What have I done wrong?

http://attwiki.org

Thanks! 94.6.38.172 (talk) 23:46, 23 December 2013 (UTC)

 23:52, 23 December 2013 (UTC)
 00:05, 24 December 2013 (UTC)
 00:05, 24 December 2013 (UTC)

Your wiki still shows version 1.19.2. This means that - where ever you have uploaded/extracted the files: It was not in the correct folder. Make sure that you are actually overwriting the files from the old source code.

See Upgrade for more information, also for information on how to access the shell. 88.130.111.116 00:42, 24 December 2013 (UTC)

I overwrote the files in the correct folder using my FTP client. They're listed under attwiki.org/wiki

I've got shortened URLs and in doing so have the files in a subfolder "wiki", but I assumed that shouldn't make a difference to the upgrade... 94.6.38.172 00:45, 24 December 2013 (UTC)

I guess I see the problem:

Short URLs and files in the folder wiki/ are fine. Please make sure that when you are upgrading you actually overwrite those files, which are inside the folder wiki/! You have not done that so far. As long as you see the old version on the page Special:Version, you have not done that yet! 88.130.111.116 00:51, 24 December 2013 (UTC)

Ah, I seem to have fixed it now, even though I managed to temporarily destroy my website in the process... 94.6.38.172 13:00, 24 December 2013 (UTC)

Yes, that may happen during update. Once you know what to look for when such errors occur, you will mostly be able to fix that rather easily.

Merry Christmas! 88.130.78.100 13:07, 24 December 2013 (UTC)

Cant login to existing wiki

So I have an existing wiki. I moved my google account to a new domain How can I reset my password from the wiki? It used to be Single sign on. It no longer is. I cant login. I have a screen to use An existing account on this wiki I don't even know what my existing account is or password, because I never created one Please hep Regaltopax (talk) 01:13, 24 December 2013 (UTC)

Hi!

I am missing some punctuation in your post. It is nearly not understandable.

You say you have a wiki. And you have a Google account? And how are these connected? Anyway: Ask the guys who changed the wiki so that you now can no longer log in. When they were the ones who changed away from SSO, they now also have to deal with the consequences! 88.130.111.116 02:02, 24 December 2013 (UTC)

Changes to sidebar don't show up

I've just installed Mediawiki version 1.22.0 with no changes other than configuration. I've edited the MediaWiki:Sidebar but the side bar on my site doesn't really look like what I'm editing and my changes have no effect. If I refresh and clear cache, I see briefly what might be the same as what I'm editing, but it gets covered up immediately by something else. Site is http://windangel.org. I've read the documentation for MediaWiki:Sidebar, didn't understand some of the more esoteric discussions and have no idea what "skin" I might be running. This may be way more complicated an app than I need, if changing the sidebar is this difficult. I may have to look elsewhere.

Thanks, Jim. K0lup (talk) 14:34, 24 December 2013 (UTC)

Hi Jim,

possibly. The skin you are using is called Vector; it is the MediaWiki default skin, which is also used on Wikipedia.

When I check your sidebar then it looks like what you have on the wiki page except that the link "photos" does not show up. A look at Manual:Interface/Sidebar showed me that you should obviously add the URL there but without square brackets around and with a pipe in the link. 88.130.78.100 00:00, 25 December 2013 (UTC)

Yes, you should replace the line:

** Photos

With the line

** http://windangel.org/cgi-bin/photo/index.cgi%7CPhotos

In http://windangel.org/mediawiki/index.php?title=MediaWiki:Sidebar&action=edit

If that doesn't fix it, please let use know. Bawolff (talk) 22:11, 26 December 2013 (UTC)

API search in mediawiki don't work

I downloaded mediawiki in order to have a local copy of wikipedia I want to make search with wikimedia API in my local mediawiki.

When I try this url on the wikipedia API online

http://en.wikipedia.org/w/api.php?action=query&list=search&srsearch=fran&srprop=timestamp

I get this

<?xml version="1.0"?>
<api>
  <query-continue>
    <search sroffset="10" />
  </query-continue>
  <query>
    <searchinfo totalhits="13454" />
    <search>
      <p ns="0" title="Fran" timestamp="2013-07-10T11:08:52Z" />
      <p ns="0" title="Hurricane Fran" timestamp="2013-10-27T17:30:58Z" />
      <p ns="0" title="Fran Drescher" timestamp="2013-12-10T01:10:38Z" />
      <p ns="0" title="Fran Walsh" timestamp="2013-11-19T04:12:29Z" />
      <p ns="0" title="List of The Nanny characters" timestamp="2013-11-29T17:26:10Z" />
      <p ns="0" title="Fran González" timestamp="2013-07-16T14:44:50Z" />
      <p ns="0" title="Fran Landesman" timestamp="2013-08-02T19:36:03Z" />
      <p ns="0" title="Fran Mérida" timestamp="2013-12-08T23:27:28Z" />
      <p ns="0" title="Tropical Storm Fran" timestamp="2012-11-11T18:44:02Z" />
      <p ns="0" title="Fran (film)" timestamp="2013-10-30T11:49:53Z" />
    </search>
  </query>
</api>

When I type the same url in my mediawiki API with dump of wikipedia:

http://www.mylocalhost.com/begoo/assets/mediawiki/api.php?action=query&list=search&srsearch=fran&srprop=timestamp

I get this

<?xml version="1.0"?>
<api>
  <query>
    <search />
  </query>
</api>

I correctly installed all dump of wikipedia and only the API OpenSearch Work fine,not the API Search.What is wrong? My wikipedia version is 1.21.3

All the order functions of the API work perfectly.I don't know if I must install an extension for it?

Tank's to all Yanstv (talk) 14:58, 24 December 2013 (UTC)

Maybe you need to run updateSearchIndex.php?

Actually, rebuildtextindex.php is the script to rebuild the search index. Ciencia Al Poder (talk) 16:43, 25 December 2013 (UTC)

Active math tag

Hi, Please I'm a newbie in command line,

What is the best and easy way to activate the math tag to mediawiki.

I'm use mediawiki version 1.21.3 Yanstv (talk) 15:27, 24 December 2013 (UTC)

Hi,

There's a guide for using math at Manual:Math. :)

You do have command line and FTP access to your wiki though, correct? The simplest way would be to download the Math Extension. Then add this to your LocalSettings.php file, updating directories listed accordingly:

require_once "$IP/extensions/Math/Math.php";
// Set this if you don't use MediaWiki Math's texvc:
$wgTexvc =  '/your/path/to/texvc';
 
// Be sure to have a math directory with writing
// permission and that these two variables are set or
// default to that directory:
$wgMathDirectory = 'filesystem/path/of/the/math/directory';
$wgMathPath = 'URL/path/of/the/math/directory';

After that's done, you're going to need command line access. Running the update script isn't too hard, depending on what your webserver runs. If it's Linux based, which it likely is, all you need to do is navigate to your MediaWiki installation's maintenance folder (for example "cd /var/www/wiki/maintenance" and then running php update.php. From there, it should be self-explanatory. Hopefully I explained it simply enough, but if you need further information, Manual:Math, Extension:Math, and Manual:Update.php would be good for you to look at. :)

Thanks, GeorgeBarnick (talk) 16:06, 24 December 2013 (UTC)

mediawiki database backup

what tables I need to do the backup data? i know that i don't need this two: - Objectcache table - Its content can be deleted and excluded from backups as it will be regenerated when needed - l10n_cache table - Its content can be deleted and excluded from backups as it will be regenerated when needed

There are other tables that can be excluded from the backup? (maybe: msg_resource, msg_resource_links, ecc...) 79.36.244.101 (talk) 16:53, 24 December 2013 (UTC)

You might think about leaving out the data (not the table definitions!) for the *_links tables, but I don't do that. I usually back up all and that works fine. 88.130.78.100 23:25, 24 December 2013 (UTC)

ok, but you have big database backup and when you restore PHPmyadmin return timeout errors

ok for table definition, but why we need to backup data that are regenerated everytime you use wiki 79.36.244.101 09:51, 25 December 2013 (UTC)

When you have big databases, you should use a system, which is capable of working with them.

When phpMyAdmin can no longer deal with that, you have two options: Adjust the PHP settings, so that it can again. That means: Set the maximum execution time and maybe the memory limit to something more suitable. Or use tools, which are really made for big databases, which are mysqldump and mysql on the shell. No PHP involved, no interface, just a oneliner as command and it will just work. As simple as that. I always prefer the oneliner.

mysqldump -u my-mysql-user -h my-mysql-host -pmy-password > backup-25.12.2013.sql

Run a command like this one as a cronjob and you are fine. 88.130.110.126 13:29, 25 December 2013 (UTC)

ok, but the original question was: There are tables that can be excluded from the backup? 79.36.244.101 08:37, 26 December 2013 (UTC)

As I said: You can exclude the content of some tables (objectcache, l10n_cache, externallinks, imagelinks, iwlinks, langlinks), but you cannot exclude the table definitions themselves. This will create some overhead for creating the DB dump with these modifications. And even if you decide to exclude the content of certain tables, you will have to do additional steps to get a running wiki again later; it will then not only be importing the DB and that's it.

This is not worth the hassle. 88.130.75.80 17:04, 26 December 2013 (UTC)

I'd just like to emphasize, regenerating link tables can take days on a moderately sized wiki. Be careful if you want to exclude them and your wiki is large.

Also you should test restoring from backup. Backups are pointless unless you are sure you can get back up based on them. Bawolff (talk) 21:58, 26 December 2013 (UTC)

ok

so the final answer is:

- you must non exclude table definitions

- content of cache table (objectcache, l10n_cache) can be excluded with no problem

- content of link table (externallinks, imagelinks, iwlinks, langlinks) can be excluded but regenerating can take days

is correct?

P.S.: "regenerating link tables" is an automated process after a backup? 79.3.242.132 14:10, 1 January 2014 (UTC)

Correct, but regenerating link data is not an automated process; you have to do that on your own. Basically run the maintenance script refreshLinks.php. This is then what might take days to complete - especially when - as it seems in your case - you only have very limited resources. You can try, but I would not expect it to work nicely... 88.130.110.25 18:03, 1 January 2014 (UTC)

Upgrade to 1.22.0 from 1.21.2 causes indefinite loading of pages. Possible problem with runJobs.php script and/or cookies?

Wiki: SystemLinks Wiki

I updated my Wiki from 1.21.2 to 1.22.0. Everything seemed to go fine during the installation: the server environment was found to be suitable, the database was updated successfully, and everything seemed to transfer over fine. However, from the very first time I tried to load the Wiki after updating, it would never load. Firefox would never pop up the message that the server timed out or the page couldn't load like it normally does when a website can't be loaded, it would just continually try to load for as long as I left the window up, but never would. When I checked the active processes on the server, it would show the page trying to be loaded along with the "w/maintenance/runJobs.php --maxjobs 1" script (one for each instance of a page trying to be loaded) and all of these processes would remain indefinitely (or until I manually killed them). I haven't made any changes to this script in the past or since the update, but when looking on the article for that script on this site, it sounded like this may not be normal behavior. Is it supposed to run with every page load?

I disabled all the extensions but it still continued to act the same (they are all still currently disabled). From getting a few friends to help test, I found that it seemed to be a problem with anyone who had already been logged in. I should note that I was able to get the main page to load after about 15 seconds or so while I was logged in once or twice, but 9 times out of 10 nothing would ever load. When I cleared my cookies, it seemed to start to load pages normally (perhaps a little slower than before I updated). However, if I went to the "Log In" page, and DIDN'T log in, a cookie would be installed, database_name_mwiki__session, (where database_name is the name of my MW database) and with just that cookie on my computer, the Wiki acted as before and no pages would load. If I deleted that cookie, pages would load again.

I did not make any changes to the 1.22.0 version files I downloaded except for moving over the Images and Extensions folders, the LocalSettings.php file, and the Vector folder. Lakster37 (talk) 17:27, 24 December 2013 (UTC)

Hi!

That exactly one job is executed with each page request is default behaviour. However, I have seen cases where the jobs are not executed in MediaWiki 1.22. However, for me the pages are still delivered normally.

Try running runJobs.php from the shell. Does that work?

I currently don't have an idea on the cookie issue you describe. 88.130.78.100 23:23, 24 December 2013 (UTC)

I don't really understand what runJobs.php does. From what you've said and what I've read in the Manual:runJobs.php article here, it makes sure that jobs are executed and so is run every time a job (e.g. loading a new page) is started? But, it seems like jobs can still be executed without the script? Unfortunately, I don't have shell access on my server (I just have a shared hosting Host Gator server), but what confuses me most is that it seems that when this script is executed manually, its to clear the job queue, and this sentence in the article particularly caught my attention: You may wish to use this script because your wiki's traffic is too slow to clear the queue, or there may be an exceptionally large number of jobs to clear. Be advised though that for many server configurations this can cause your wiki to become sluggish or even unresponsive until the script completes. But if its running all the time, it seems like it could take a very heavy burden on smaller servers like mine. Because of that, according to Manual:Job queue it seemed like the best thing to do was to decrease the Job Rate, so I did to $wgJobRunRate = 0.01; as in the example in that article. That seems to have fixed the loading issues of my pages, but I still don't really understand how/why. Would someone be able to explain or point me in the right direction to understand what the job queue is and how it works? Thanks! Lakster37 (talk) 04:32, 27 December 2013 (UTC)

No, runJobs.php is not started automatically during normal page requests. During normal page requests MediaWiki initializes a Job object and on average it runs the number of jobs defined by $wgJobRunRate, but this does not happen through runJobs.php. So by default MediaWiki renders the page, which was hit by the visitor and additionally one job, which is in the queue, is executed (most likely this will render a second page).

Let us assume with $wgJobRunRate = 1; you always had some jobs in the queue. So when you set $wgJobRunRate to something close to zero, then you take away a bit less than half of the rendering work. However, depending on the number of hits to your wiki and depending on the complexity of templates and the number of pages, it might now be that the job queue starts filling up without being emptied quickly enough. That will e.g. lead to outdated information on "What links here" pages and stuff like that. You can check to see, if you have that problem by looking at how many rows you have in the database table jobs. A high and constantly growing number is not good.

runJobs.php by default is only executed when you execute it manually on the shell. Then(!) it runs a number of 10.000 jobs - and because they have been run(!) it clears them, not all, only those which were run, from the queue. The 10.000 are only the default; you can adjust this number with the parameter --maxjobs. 88.130.75.135 05:58, 27 December 2013 (UTC)

Upgrade/migrate MediaWiki 1.12.0 to another server

Hello.

We want to both update & migrate (not necessarily in that order) our company's wiki. It is currently on CentOS 5.5, MediaWiki 1.12.0, PHP 5.1.6 (apache2handler), MySQL 5.0.77. We want to decommission that box and move the wiki to SLES 11 and to version 1.19+ - which requires PHP 5.2.3+. We are unsure of the proper order of steps since 1.12.0 doesn't necessarily support PHP 5.2.3 (as seen in the chart at http://www.mediawiki.org/wiki/Compatibility). Unfortunately since it is an internal wiki with no connection to the outside world I can't provide a URL to it. Any tips or words of advice as to how you would go about this move?

Thank you & Happy Holidays! Reznuh (talk) 19:06, 24 December 2013 (UTC)

Hi!

Hard to tell. When you only want to do the steps "Update server to one with the final PHP version" and "update MediaWiki" then you will inbetween have a state in which the wiki is not working.

If this is not allowed to happen, you can prevent this by doing one step inbetween: First update the PHP version on the old server and maybe also MediaWiki still on the old server. Then move the wiki to the new server (which should then at least not cause problems because of a wrong version of PHP). 88.130.78.100 23:17, 24 December 2013 (UTC)

You should copy your database from your old server to the new one (exporting and importing), while having on the new server your new MediaWiki installation, database and PHP versions. Then, basically, follow Manual:Upgrading.

Basically, on the new server:

• unpack the new MediaWiki installation files
• Download and unpack recent versions of Extensions you had in old MediaWiki (download extensions matching your new MediaWiki version, if you're going to use 1.19, download extensions for 1.19, not latest!)
• Copy your old LocalSettings.php to the new server, maybe disable some extensions if they became obsolete or if they may cause problems, and (if applicable) adapt the database connection settings
• run update.php from the command line. Ciencia Al Poder (talk) 17:29, 25 December 2013 (UTC)

Thank you guys very much. The person I'd be helping with this move is away for a bit but I think these comments provide a great game plan. I will check back with a status update when we get to it. Thanks again! Reznuh (talk) 17:02, 26 December 2013 (UTC)

One additional step - if your new server has a different host name, you may have to update $wgServer in your LocalSettings.php Bawolff (talk) 21:59, 26 December 2013 (UTC)

So first off thanks a ton to all of you. Just got the move completed and everything is working great!

In case anyone is using the same system (SLES 11 fresh install) sometime, we had two errors come up which were fixed:

1) During the maintenance/update.php process - PHP Fatal error: Class 'DOMDocument' not found in <wiki path>/includes/cache/LocalisationCache.php on line 587

- This was fixed by using yast to install the following php modules: xphp53-dom, xphp53-xmlreader, xphp53-xmlrpc, xphp53-xmlwriter

(Not all of these may be required, but they are what was installed)

2) After completing the update with no errors, the site would then return an internal server 500 error no matter what happened. HTML files would load fine. In Apache's error log we had various errors similar to this - PHP Notice: Use of undefined constant JSON_HEX_AMP - assumed 'JSON_HEX_AMP' in <wiki path>/includes/json/FormatJson.php on line 166

- This was fixed by then installing the php5-json module

Thanks again! Reznuh (talk) 16:59, 7 January 2014 (UTC)

Note that there's a known problem with PHP 5.3.8 on SLES11 sp2 that causes all uploads to fail (it's a bug with that PHP distribution). Refer to Manual:Errors and symptoms Ciencia Al Poder (talk) 10:17, 9 January 2014 (UTC)

m subdomain for mob version wiki with MobileFrontened

Please really need to know. I am installing mobilefrontend on shared hosting apache server. I want to use different domain for desktop and mobile version. By default the mob version appears at http://www.xserve.org/index.php?title=Main_Page&mobileaction=toggle_view_mobile but how to make at m.xserve.org. I want to know how to configure apache server. Do i need rewrite rule. and when i edit $mobileurltemplate: m.xserve.org. It does not work. How to make m.xserve.org use the content of http://www.xserve.org/index.php?title=Main_Page&mobileaction=toggle_view_mobile on apache server? 117.203.142.114 (talk) 13:43, 25 December 2013 (UTC)

If it requires rewrite rule , please write it. Still learning. 117.203.142.114 13:51, 25 December 2013 (UTC)

Wiki-portal can not been open after transferring on other server

Web server on which the wiki-site is located was hacked. After transferring I can not open site. The message is: MediaWiki internal error. Exception caught inside exception handler What is this error related to? How is the way to fix it? Thanks, YurNik Novikov 213.21.37.31 (talk) 15:52, 25 December 2013 (UTC)

Hi!

That is a generic error message, which is displayed when MediaWiki is configured to hide the actual error message. Add

error_reporting( -1 );

ini_set( 'display_errors', 1 );

to the bottom of LocalSettings.php and open your wiki again. What error do you see?

See blank page or how to debug for more information. 88.130.110.126 17:06, 25 December 2013 (UTC)

The error message isn't descriptive enough for us to tell what's happening. You should get a full stack trace from the apache error or PHP error log. See Manual:How to debug Ciencia Al Poder (talk) 17:34, 25 December 2013 (UTC)

wikitable style not working

Hi All,

I just installed the latest Ubuntu 12.04.3 LTS and latest mediawiki software. I went through all the configuration steps and the website works fine. The one little problem I have at the moment is that the style 'class="wikitable sortable"' does not seem to be working. After using the 'wikitable' class my table still shows up without any borders.

My table markup is simply:

header 1	header 2	header 3
row 1, cell 1	row 1, cell 2	row 1, cell 3
row 2, cell 1	row 2, cell 2	row 2, cell 3

But in my install it looks like above without shading and without borders and the sorting icons don't look right. What's going on here with my css??

I tried to use Chrome developer tools to debug and I could see that it's not working because the 'wikitable' style doesn't seem to be included anywhere.

Thanks,

O 124.149.95.179 (talk) 02:52, 26 December 2013 (UTC)

Ubuntu 12.04.3 LTS uses MediaWiki 1.15 which is now quite old and didn't include those styles. Also, that version is no longer supported.

You should download one of the supported MediaWiki versions from mediawiki.org and install it. If you have contents in your current version, see Manual:Upgrading

That, or manually add those styles on the page MediaWiki:Common.css of your wiki (see Manual:Interface/CSS) Ciencia Al Poder (talk) 15:41, 26 December 2013 (UTC)

Ubuntu 12.04.3 was only released last April and Mediawiki 1.15 was released sometime ago. But Ubuntu 13.10 is now the latest out. 86.135.255.241 18:50, 26 December 2013 (UTC)

You should either update MediaWiki to a current version or remove the old installation and create a new one. 88.130.75.80 18:57, 26 December 2013 (UTC)

You are all perfectly right. I reinstalled wiki from website download instead.

A small issue I'm having now is when I try to create an infobox template I use the class "infobox" but it makes no difference when I add this. I looked in the source and there is no infobox class anywhere...

Thanks! 220.233.216.157 05:59, 30 December 2013 (UTC)

You should probably import it from w:MediaWiki:Common.css (or the wiki you're trying to copy the templates/code from) Ciencia Al Poder (talk) 11:01, 30 December 2013 (UTC)

I'm sorry but I'm not sure what you mean by import ...

Are you saying there is some kind of import statement? Or do I need something in my LocalSettings.php?

Or do I need to copy and paste the CSS code into my template directly?

As an example I started editing a new page on my wiki and put in this:

{| class="infobox"
|-
| foo bar
|}

After clicking save or peview I just get "foo bar" written on the left as normal text. The above seems to work fine here...

Thanks 124.149.95.179 23:43, 30 December 2013 (UTC)

Since you mentioned there is no infobox class anywhere, I assumed you had basic knowledge of CSS and stylesheets. You should probably read Manual:Interface/Stylesheets then. Not all styles are specified inline. Basically, you must define the "infobox" class styles somewhere, as Wikipedia did in MediaWiki:Common.css Ciencia Al Poder (talk) 10:32, 31 December 2013 (UTC)

[Hooks Functions] Hooks function not work in other skin (work in default skin)

Dear all,

I am developing a special page and I need to add a page tab in navigation bar (top of the page). When I am doing my development, I am using default skin (Vector) and the codes work fine.

This is how I add a hook function:

$wgHooks['SkinTemplateNavigation'][] = 'addTab';


function addTab( $skin, &$links) {  

	$titleObj = Title::newFromText('Special:DiscussionAnalysis');

	$links['namespaces']['special'] = array(

		'class' => false,

		'text' => 'Analysis',

		'href' => $titleObj -> GetFullURL());


	return true;

}

But today when I changed other skin (for example:Monobook) in 'preferences' page, the tab disappear. But I change the default skin back, the tag appear again. So I think it's the problem about skin.

So I try to output some text in my hook function, such like: $wgOut -> addWikiText('Test');

The text will appear when I am using default skin (Vector)but not in other skin, thus I think the hooks function is not be loaded.

So is that possible to add a tab in navigation bar for all skins? if it's possible, is there's any problem in my code? (My mediawiki version:1.17.0)

Thanks in advance! Chongman~mediawikiwiki (talk) 06:09, 26 December 2013 (UTC)

html included stylesheet and script

I am using MediaWiki and I have designed a html webpage with its own JavaScript and CSS files. Using $wgRawHtml=true; in localsettings.php, I can use the html source but how can include my local javascript and css files into it. Is it even possible in anyway. Please Help and Please reply as soon as you can. I will be thankful. Thank You Mediawiki version = 1.22 Php version = 5.3 Mysql version = 6.0 125.63.64.56 (talk) 18:04, 26 December 2013 (UTC)

one more thing sir, where exactly are the pages saved on my local system. Does it even get saved on the local system in a document(.php or .htm). I will be thankful.

Thank You. 125.63.64.56 18:34, 26 December 2013 (UTC)

The actual document are stored in the database (As wikitext, converted to html on the fly [or possibly cached]).

In RawHTML mode you can add js using <script> tags. You can also add js to the page MediaWiki:Common.js on your wiki, which gets included in all pages. However you may want to consider if MediaWiki is right for your usecase here - its not really designed for custom html pages.

You may also want to look at Manual:Special_pages where you can entirely control what is being outputted. Bawolff (talk) 21:55, 26 December 2013 (UTC)

Hi!

If what you technically want is to actually use a wiki, then you are right with MediaWiki.

Do not use $wgRawHtml; this is unsecure as it allows any user with edit permission to add arbitrary HTML to your wiki pages. Instead, you can add JavaScript, which should be used for all the different MediaWiki skins, in your wiki on the wiki page MediaWiki:Common.js and you can add CSS on the page MediaWiki:Common.css. These pages are good to make smaller changes to the way how MediaWiki looks like.

MediaWiki can use custom HTML pages as templates and if what you want is to basically have a completely different design, then you should have a look at how to create MediaWiki skins. An own skin allows you to change the complete look and feel of your wiki (and amongst other things you can then include your JS and CSS stuff in files coming from the file system instead of in wiki pages as mentioned above). 88.130.75.80 00:20, 27 December 2013 (UTC)

Thanks, I am working on it and will post for any further problem or questions of mine.

Thank You. 125.63.64.36 10:35, 27 December 2013 (UTC)

To Bawolff, First of all, thank you for replying to my thread sir, it was really helpful and well, I am using mediawiki becuase it has the feature of editing documents written from the browser itself. If only I knew how is that possible that you can edit your files on the server from client site using web browser then I would not have to use it.

Does anyone knows how is that done, is so please tell me.

Thank You.

To 88.130.75.80, thanks to you too sir, you did a great help to me.

Thanks all. 125.63.64.36 11:57, 27 December 2013 (UTC)

125.63.64.36 12:08, 27 December 2013 (UTC)

@bawolff, also if I have css file and i do not want to give actual path instead a relative path. So, in this case, where should I put the css file js file inorder to use a relative path so that when I transfer the whole website from localhost to any web server, I do not have to make any changes.

Please help anybody, please, relly stuck in there.

Thank You. 125.63.107.148 16:15, 27 December 2013 (UTC)

you can add css to the page MediaWiki:Common.css on your wiki (create the page like any other page on your wiki) Bawolff (talk) 21:19, 3 February 2014 (UTC)

125.63.64.36 11:57, 27 December 2013 (UTC)
125.63.64.36 10:35, 27 December 2013 (UTC)

how to migrate existing wiki 1.10 to latest version with mysql database

HI,

Can you guide us, how to migrate older wikimedia to newer version with mysql database. wikimedia Current version is : 1.10 php - 5.2 postgresql - 8.2

Refer below special page information.

Version

   MediaWiki: 1.10.0rc1
   PHP: 5.2.0 (apache2handler)
   PostgreSQL: PostgreSQL 8.2.3 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.4.6 20060404 (Red Hat 3.4.6-11) 115.111.211.142 (talk) 09:28, 27 December 2013 (UTC)

Note: You're not running wikimedia, but mediawiki ;)

You should transfer your data from postgreSQL to mysql. See for example [3]

Then, set up your new MediaWiki installation following Manual:Upgrading Ciencia Al Poder (talk) 10:46, 27 December 2013 (UTC)

Hi!

Ciencia is right. However, when you do the first step, that is when you transfer the database to MySQL, you have to update the database data in LocalSettings.php including the database type you use. Important: The table with the page content is named differently in Oracle than in MySQL! That means that you will have to rename the table "pagecontent" to "text". See Manual:Text_table for details. 88.130.75.135 13:18, 27 December 2013 (UTC)

Mediawiki creates files

Since the update on 1.22.0 my MediaWiki starts to create files in the root folder of the wiki.

The files are named core.xxxxx (xxxxx is a running number) and the size is 16044kb. I have disabled all extensions and all variable without any change.

Does anyone have seen this before or know what part of the wiki is creating the file? Adzorn (talk) 15:21, 27 December 2013 (UTC)

Oh, i forgot the server facts:

MediaWiki: 1.22.0

Server: Apache/2.2.22 (Ubuntu)

PHP Version: 5.3.10-1ubuntu3.9

MySQL: 5.5.34-0ubuntu0.12.04.1 Adzorn (talk) 15:23, 27 December 2013 (UTC)

No, I have not seen this before. What is the content of these files? You say their size is identical - is it the content as well? 88.130.75.135 21:21, 27 December 2013 (UTC)

Those are core dumps, caused because your PHP process is crashing somehow during execution of your scripts. If you're the adventurous sort and have SSH access, you can analyze them with a program such as gdb. Otherwise, it might be worth poking your host about it as it could indicate a PHP misconfiguration. Skizzerz 05:39, 28 December 2013 (UTC)

SVG thumbnails displays corrupted.

MediaWiki 1.21.2
PHP 3.1.5
MySQL v.5

Does anyone have any idea why SVG thumbnails on my MediaWiki get corrupted (see examples), while the actual SVG file it self are displayed just fine?
I'm using ImageMagick that's installed on the server.

Examples of corrupt thumbnails

• http://wappenwiki.org/index.php/File:Rügen.svg
• http://wappenwiki.org/index.php/File:Vasa.svg
• http://wappenwiki.org/index.php/File:Trencavel.svg

Thanks in advance
Joakim 85.24.209.251 (talk) 17:48, 27 December 2013 (UTC)

Hi Joakim,

in the first image I see a grey dragon(?) behind stones in the lower half, the second shows kind of a golden pillar in front of blue, white, red background and the third is a coat of arms but completely in black. Anyway, for me the thumbnails look identical to the bigger pictures displayed at the top of the page.

The only thing that might be strange is that the thumbnails have the same size as the original images (1 pixel difference); that is not really what thumbnails are supposed to be there for. Is that what you mean when you say they are "corrupted"? 88.130.75.135 21:28, 27 December 2013 (UTC)

It's actually a lion. ;)

What I mean about corrupted thumbnails is that they get these "strokes/lines" on the sides but as soon as I click on a image to see it in it's full size the strokes disappear.

I've attached screenshots that shows what I mean.

www.wappenwiki.org/images/thumbnail.png

www.wappenwiki.org/images/preview.png

www.wappenwiki.org/images/full-image.png

Don't you see any "strokes/lines" on the thumbnails? 85.24.209.251 07:54, 28 December 2013 (UTC)

I see that in the thumbnails the black, curved borderline around the coat of arms does not have the same width at all places: In the lower half it is thinner than in the upper half.

Anyway, now I do see another, way more obvious corruption:

On http://wappenwiki.org/index.php/File:Rügen.svg the stones all are yellow.

When I click on the top image I see the original file: http://wappenwiki.org/images/d/df/R%C3%BCgen.svg and there the stones are red and blue. (And the border has the same thickness everywhere.)

The images, which you posted here are all SVG images. Do you also have this problem with file types other than SVG?

Which version of ImageMagick are you using? 88.130.117.154 12:47, 28 December 2013 (UTC)

I'm using ImageMagick 6.7.8-7 and other files works just fine, like PNG, GIF or JPG.

Did a little test using the same shape in Illustrator and created two different SVG files, one with a 5pt stroke, the other with 0pt stroke.

The 0pt stroke looks just as it should as a thumbnail while the 5pt stroke gets corrupted as a thumbnail.

Don't have any idea what's causing this since I didn't encounter this problem with my previous web host...

No stroke

http://wappenwiki.org/index.php/File:Nostroke.svg

5pt stroke

http://wappenwiki.org/index.php/File:Stroke.svg 85.24.209.251 17:07, 28 December 2013 (UTC)

I guess you could also check for this error by uploading e.g. the lion ;-) file to wikipedia and see what happens there. When the problem is not visible there, then I would guess it is most likely not caused by MediaWIki but by your version of ImageMagick.

Maybe it is a strange error in ImageMagick; I know of cases where ImageMagick had problems with SVG files. Maybe that is fixed in a newer version? Seems like 6.8.7-10 is current... 88.130.117.154 18:19, 28 December 2013 (UTC)

Which table are all of the pages stored in?

I had a hacker attack my server, so I had to reinstall MediaWiki, but for some reason restoring the database as a whole gives me an error.

I need to manually restore each table, but I am only worried about the pages for now.

the table "page" restores all of the links in Special:AllPages, but it doesn't restore the page contents itself.

Example; if I go to page "Clay", it says

"The revision #0 of the page named "Clay" does not exist. This is usually caused by following an outdated history link to a page that has been deleted. Details can be found in the deletion log." 174.140.182.136 (talk) 10:19, 28 December 2013 (UTC)

The tables "pages" and "text" contain ... well, you know. Both are connected through the table "revision".

I added some information on how the data is connected and retrieved to Manual:Page_table.

Only restoring parts of a database is a bad idea. You can restore the tables step by step, that is no problem, but you cannot leave tables out. 88.130.117.154 18:23, 28 December 2013 (UTC)

Try to run php maintenance/rebuildall.php GeorgeRu (talk) 20:25, 13 April 2014 (UTC)

The rebuildall maintenance script can rebuild links and indices used for searching the wiki. However, when page records, revisions or actual texts are missing, it is just useless - running the script cannot' fix these issues. 88.130.121.172 11:49, 14 April 2014 (UTC)

"The revision #0 of the page named "Page1" does not exist." After deleting page1 details manually from page,revision,text tables in mediawiki (1.20.5) and once again added the same page getting above issue how to resolve the above issue 15.219.169.72 09:30, 15 April 2014 (UTC)

The error message you get sounds like in the page table, the entry of the according page points to a non-existing revision. This might be fixable by running the maintenance script attachLatest.php. This should make the page point to the newest revision again. This would be what I would try first.

If that does not work and you in fact want to delete the page, I would try running the maintenance script nukePage.php. This script allows you to permanently(!) delete a page from the database. Afterwards you can use the script purgeOldText.php to delete unused rows from the text table.

However, note that your database currently is in an inconsistent state; although the scripts I mentioned were partly written for situations of brokenness, there is no guarantee that they can solve this. 88.130.121.172 10:31, 15 April 2014 (UTC)

It's also worth noting that you shouldn't fiddle directly with the database unless you know what are you doing. Ciencia Al Poder (talk) 09:29, 16 April 2014 (UTC)

 09:30, 15 April 2014 (UTC)

How does #ifeq evaluate in mediawiki?

I have the following code sample in my wikipage. I am not able to understand the flow of logic as it is giving me a different result than expected.

{{#vardefine:edition|1972}} The edition is {{#var:edition}} The result evaluated by the wiki is

The edition is 1983

But both the input strings are (1972) which are equal. Note: 1972 is within brackets. So its not an integer, but a string Could anyone explain why it is evaluating to 1983 and not 1972. I found the same issue using a {{#switch}} . Could anyone explain the flow of the logic here?

Mediawiki 1.15.1

Arnab 91.179.30.185 (talk) 15:13, 28 December 2013 (UTC)

It's due to you running such an old version of MediaWiki. Update it and your issue should be resolved (Note: ifeq does string comparison regardless of what the parameters actually are, because it is parsing wikitext, which is always a string). Alternatively, switch your order, e.g. {{#vardefine:edition|{{#ifeq:{{{input|}}}|(1972)|1972|1983}}}} {{#var:edition}} and it should work on your current mediawiki version. But you should upgrade anyway, as 1.15 is no longer receiving support and security updates, so your wiki could be quite vulnerable.

To elaborate, MediaWiki versions before 1.16 (I think that's the one, at least) always fully parsed both sides of the #ifeq (and similarly every condition of the #switch), although it only output the side that matched. This means parser functions with side effects such as #vardefine would behave incorrectly because they are actually getting called multiple times, and the very last call of #vardefine is what sets the value. As of 1.16, the only side that gets parsed is the branch that was taken. Skizzerz 17:04, 28 December 2013 (UTC)

Thank you, that was really very helpful. Yes we are about to upgrade now, since its been quite a while now.

Thanks

Arnab 91.179.30.185 17:33, 28 December 2013 (UTC)

Yes it worked. I updated the wiki. As well as updated the Parser functions. Now its good. Now the issue is resolved. That made my life much easier. Otherwise I would be banging my head on the table to figure out whats going on.. :D 91.179.30.185 10:37, 29 December 2013 (UTC)

Receive 404 (403) error when adding more than 3 links to URLs on a page.

Hello. Our problem is exactly like this one: http://www.mediawiki.org/wiki/Project%3ASupport%20desk/Flow/2012/12#h-%5BRESOLVED%5D_Receive_404_error_when_adding_more_than_3_links_to_URLs_on_a_page.-2012-12-08T17%3A38%3A00.000Z

I did not reply to the thread because it's almost a year old and marked as resolved.

The issue is, when we add more than 3 links per page, mod_security creates a 404 error (that is actually a 403 error). Given that this is a wiki, we have a news page that has more than 3 external links, as well as the front page having more than 3 external links. We disabled mod_security for a while, but that turned out to be a bad idea, so we need another solution.

I have heard of adding exceptions to mod_security, but other than the question linked above, I cannot determine what exactly we should be exempting. I think adding an except that allows certain user groups to post more than 3 links would work best, but I'm not sure how to go about that since mod_security isn't a wiki thing... 74.176.64.177 (talk) 19:06, 28 December 2013 (UTC)

Yes, I agree with your conclusions: Adding exceptions to mod_security is a mod_security problem. I don't think there are many mod_security experts around here. I would try getting more information on that in a forum specialized on mod_security... 88.130.117.154 02:34, 29 December 2013 (UTC)

[RESOLVED] Infoboxes - Including An Image Causes An Exception

I am creating a Wiki using MediaWiki, and I'm using InfoBoxes. However, for some reason, I can't seem to include images.

MediaWiki Version: 1.22

PHP Version: 5.3.3

SQLITE Version: 3.6.20

URL: http://corstekistan.usr.sh/wiki

My infobox code is below:

{{Infobox officeholder
| honorific-prefix = Chairman
| name             = Ian Duncan
| honorific-suffix =
| image            = IanDuncan.jpg
| alt              = Chairman Duncan's official portrait
| order            = 1st
| office           = Chairman of the Standing Committee of the Lawthing
| election         = 
| term_start       = December 13, 2013
| term_end         = 
| predecessor      = Office Established
| successor        = 
| order2           = 1st 
| office2          = Chairman of the General Council of the Republic of Corstekistan
| term_start2      = May 1, 2013
| term_end2        = December 13, 2013
| predecessor2     = Office Established
| successor2       = Office Abolished
| order3           = 2nd
| office3          = Chairman of the Wainist-Duncanist Republic of the Land of Derf
| term_start3      = April 11, 2013
| term_end3        = May 1, 2013
| predecessor3     = Fred L. Wain II
| successor3       = Office Abolished
| order4           = 1st
| office4          = General Secretary of the Wainist-Duncanist Republic of the Land of Derf
| term_start4      = April 1, 2013
| term_end4        = April 11, 2013
| predecessor4     = Office Established
| successor4       = Fred L. Wain II
| birth_date       = 
| birth_place      = 
| death_date       = 
| death_place      = 
| nationality      = Corsteki
| spouse           = 
| party            = Wainist-Duncanist Party of Corstekistan
| relations        = 
| children         =
| residence        =
| alma_mater       =
| occupation       =
| profession       = 
| religion         = 
| signature        =
| signature_alt    = 
| website          =
| footnotes        =
}}

The infobox renders fine when the image field is populated. However, when I tried to add an image (IanDuncan.jpg), upon saving I got this error message:

[0a348e3f] 2013-12-28 17:59:33: Fatal exception of type MWException

==> php/logs/error_log-20131228-000000-EST <==
[Sat Dec 28 13:01:35 2013] [error] [client 127.12.156.129] PHP Notice:  Uncommitted DB writes (transactio
n from DatabaseBase::query (DatabaseBase::query)). in /var/lib/openshift/529609ed5973cad8a7000001/app-roo
t/runtime/repo/php/wiki/includes/db/Database.php on line 3944, referer: http://corstekistan.usr.sh/wiki/i
ndex.php?title=Ian_Duncan&action=edit
[Sat Dec 28 13:01:35 2013] [error] [client 127.12.156.129] PHP Stack trace:, referer: http://corstekistan
.usr.sh/wiki/index.php?title=Ian_Duncan&action=edit
[Sat Dec 28 13:01:35 2013] [error] [client 127.12.156.129] PHP   1. {main}() /var/lib/openshift/529609ed5
973cad8a7000001/app-root/runtime/repo/php/wiki/index.php:0, referer: http://corstekistan.usr.sh/wiki/inde
x.php?title=Ian_Duncan&action=edit
[Sat Dec 28 13:01:35 2013] [error] [client 127.12.156.129] PHP   2. MediaWiki->run() /var/lib/openshift/5
29609ed5973cad8a7000001/app-root/runtime/repo/php/wiki/index.php:49, referer: http://corstekistan.usr.sh/
wiki/index.php?title=Ian_Duncan&action=edit
[Sat Dec 28 13:01:35 2013] [error] [client 127.12.156.129] PHP   3. MWExceptionHandler::handle() /var/lib
/openshift/529609ed5973cad8a7000001/app-root/runtime/repo/php/wiki/includes/Wiki.php:470, referer: http:/
/corstekistan.usr.sh/wiki/index.php?title=Ian_Duncan&action=edit
[Sat Dec 28 13:01:35 2013] [error] [client 127.12.156.129] PHP   4. DatabaseBase->__destruct() /var/lib/o
penshift/529609ed5973cad8a7000001/app-root/runtime/repo/php/wiki/includes/db/Database.php:0, referer: htt
p://corstekistan.usr.sh/wiki/index.php?title=Ian_Duncan&action=edit
[Sat Dec 28 13:01:35 2013] [error] [client 127.12.156.129] PHP   5. trigger_error() /var/lib/openshift/52
9609ed5973cad8a7000001/app-root/runtime/repo/php/wiki/includes/db/Database.php:3944, referer: http://cors
tekistan.usr.sh/wiki/index.php?title=Ian_Duncan&action=edit</pre>

What am I doing wrong? [[Special:Contributions/2604:6000:9FC0:1F:8D96:D3C0:4AC5:FAFE|2604:6000:9FC0:1F:8D96:D3C0:4AC5:FAFE]] ([[User talk:2604:6000:9FC0:1F:8D96:D3C0:4AC5:FAFE|talk]]) 20:39, 28 December 2013 (UTC)
:Nice that the log contains the info ''that'' something bad happened, but I do miss an actual error message...
:Add 
:<code> error_reporting( -1 );</code>
:<code> ini_set( 'display_errors', 1 );</code>
:to LocalSettings.php and cause the error again. What is the error message you get? [[Special:Contributions/88.130.117.154|88.130.117.154]] 23:25, 28 December 2013 (UTC)
::Ahh, I just read your text again:
::If that, what you posted, all belongs together, then it's all only about the uncommited DB transaction. This is a known issue in current versions and it is ''no'' exception. So this is ''not'' the error you want to have solved. [[Special:Contributions/88.130.117.154|88.130.117.154]] 23:52, 28 December 2013 (UTC)
:::By re-importing the template, things seem to have been fixed. [[Special:Contributions/2604:6000:9FC0:1F:8D96:D3C0:4AC5:FAFE|2604:6000:9FC0:1F:8D96:D3C0:4AC5:FAFE]] 01:12, 29 December 2013 (UTC)

== Loading pages from .csv with categories & properties. ==

There seems to be something that I'm not getting.
I'm wanting to upload pages, a line at a time, from .csv files into mediawiki. I've loaded the semantic extensions. I'm able to load the .csv file into a template, but it seems to ignore the properties, the categories and even text features like '\n' - simply treating it all as raw text. How do I change this behaviour?
The files I've used for testing are:

.csv:

Title,Import_template[namespace],Import_template[category],Import_template[policy_owner],Import_template[policy_name],Import_template[policy_description]

"sandpit:one","policy","[category:policy]\n[[status::active]]\n[[renewal
date::20/02/2014]]\n[[service::Administration]]\n[[speciality::all]]","My.Name","test_policy_name","==Policy
Description==\n\ntest_policy_description\n\nmore test policy
description"

What I get is:

title |

namespace | policy

category | [[category::[category:policy]\nactive\n20/02/2014\nAdministration\nall]]

policy_owner | My.Name

policy_name | test_policy_name

policy_description| =Policy

Description==\n\ntest_policy_description\n\nmore test policy

description

test_policy |

So it seems to be interpreting the input as if it was binary text, ignoring the categories, the [] and the '\n'. So, as you can see, I've tried to set properties and categories, but doesn't seem to recognise them.
The template I've set is:

<noinclude>

This is the "Import_template" template.

It should be called in the following format:

<pre>
{{Import_template

|title=

|namespace=

|category=

|policy_owner=

|policy_name=

|policy_description=

}}

Edit the page to see the template text.

Fustbariclation (talk) 10:59, 29 December 2013 (UTC)

Perhaps my description is too complicated.

All that I want to do is take a .csv file that says, for example:

TItle,import_template[description],import_template[category],import_template[category]

Test Line,This line is the first one\nThis is the second,[ [ Is a Test::Import ] ],[ [ Is multiline comment::Two_lines ] ]

and end up with a page called 'Test Line' that has:

This line is the first one

This is the second

[ [ Is a:Test::Import ] ] <<---- these are double square braces

[ [ Is multiline comment::Two_Lines ] ] <<---- these are double square braces

So that I now have a page with two semantic properties.

This doesn't seem to be working for me. Fustbariclation (talk) 23:54, 29 December 2013 (UTC)

Problem with image changing colour - different on logo & main page for same image

Problem with colours in pages vs in logo at top left

I'm using a .jpg file. When I have the file as the image as the logo at the top left the colours are correct.

When I have the same file in a wiki page, the colours are wrong.

What happens, particularly, is that, when it is set as an icon, main letters are dark green. You can see how it should be here:

logo the correct colour

When it is in a wiki page, the image becomes light- green - as it is here:

logo the wrong colour

Why the difference and how can I adjust it? Fustbariclation (talk) 12:59, 29 December 2013 (UTC)

Hi!

The version in the wiki page (http://service-ontology.info/images/thumb/TSF_Logo_medium_size.jpg/350px-TSF_Logo_medium_size.jpg) is a downscaled version of your original file. This downscaling is done by some image conversion software; and in your case this seems to create images with wrong colors. The software used to do that usually is ImageMagick (if that is available on your server and configured in LocalSettings.php). If you cannot change the image conversion software available, a workaround might be to upload the image in another file format, e.g. as png. 88.130.83.76 18:11, 29 December 2013 (UTC)

Thank you for that extremely helpful tip! Once you put me to thinking about ImageMagick, I found the answer quite quickly:

I took the image and used photoshop to change it from an 8-bit colour scheme to a 16-bit one. I also changed the colour coding from CMYK (I'm not sure why it was in that format in the first place, presumably somebody expected it to be printed out) into RGB.

Now it all works perfectly. Fustbariclation (talk) 23:45, 29 December 2013 (UTC)

[RESOLVED] no php_pdo_sqlite on debian 6 (squeeze)

Hi all,

Mediawiki 1.22.0
Debian    6.0.8
PHP PHP   5.3.3-7+squeeze18 with Suhosin-Patch
sqlite3   3.7.3-1

I am stuck with pdo and this time there seem to be no solution:
/etc/php5/conf.d/pdo_sqlite.ini contains the line extension=pdo_sqlite.so while Manual:SQLite#SQLite installation mentions php_pdo_sqlite and php_pdo – only, what I have are pdo_sqlite.so and pdo.so.
I have myTinyTodo installed, it works with SQLite3. And phpinfo() also finds it. But the Installer does not even give me a choice to use it, it only tries to connect to MySQL. All I get is this error:

[1257a372] /mediawiki-1.22.0/mw-config/index.php?page=DBConnect Exception from line 788 of /var/www/test/mediawiki-1.22.0/includes/db/Database.php: DatabaseBase::factory no viable database extension found for type 'mysql'
Backtrace:
#0 /var/www/test/mediawiki-1.22.0/includes/installer/WebInstallerPage.php(487): DatabaseBase::factory(string)
#1 /var/www/test/mediawiki-1.22.0/includes/installer/WebInstaller.php(275): WebInstaller_DBConnect->execute()
#2 /var/www/test/mediawiki-1.22.0/mw-config/index.php(61): WebInstaller->execute(array)
#3 /var/www/test/mediawiki-1.22.0/mw-config/index.php(29): wfInstallerMain()
#4 {main}

Since I only wanted to get it up and running with SQLite for this time, is there a quick'n'clean solution?

Thanks in advance

Edit: looks like a duplicate of Project:Support desk/Flow/2013/12#h-Newbie_Install-2013-12-10T00:58:00.000Z – oonly the answer there doesn't help. 149.172.51.26 (talk) 13:31, 29 December 2013 (UTC)

Getting the same error. All searching I do leads me back to here...or the duplicate mentioned which is not a helpful answer. I have both SQLite and PostgreSql installed and working...I even tried installing mysql and I still got the above error. Any suggestions on how to force the install to use SQLite or PostgreSql? There is no option to select the database type before getting to the 'Connect to Database' page...just 'Welcome to MediaWiki' -> Continue -> Error. 216.160.218.156 04:39, 3 January 2014 (UTC)

Could you try the patch in https://bugzilla.wikimedia.org/show_bug.cgi?id=58167#c5 ? If the patch works for you, a comment in that Bugzilla ticket is welcome. AKlapper (WMF) (talk) 10:54, 3 January 2014 (UTC)

I wasn't sure how to apply the patch. I ended up downloading that version of the WebInstaller.php file...replacing it with my original copy and now when I get to the 'mw-config/index.php' page, it is just a blank white screen. No error but no way to progress either.

After sleeping on it and reviewing the steps, the duplicate question (https://www.mediawiki.org/wiki/Project%3ASupport%20desk/Flow/2013/12#h-Newbie_Install-2013-12-10T00%3A58%3A00.000Z) actually does provide an answer. After I installed 'mysql-server' and 'php5-mysql' packages, I was able to get to the database selection screen. Last night, I only installed 'mysql-server'. So it looks like 'php5-mysql' is the real requirement here, after installation, I removed both packages and everything still works. 67.50.8.26 15:37, 3 January 2014 (UTC)

[RESOLVED] Problem with remote images

Hello, I using Mediawiki for technical docummentations. How Can I load remote image in mediawiki which doesnt have image suffix? This image is random generated from PHP and they have suffix .php, not jpg/png/gif/... .

Thanks. 81.89.58.44 (talk) 20:36, 29 December 2013 (UTC)

Have you tried it by simply inserting the URL into a wiki page? Provided you have fitting settings for $wgAllowExternalImages this might work. 88.130.83.76 20:47, 29 December 2013 (UTC)

Hi thank you. This resolved my problem :). 81.89.58.1 21:03, 29 December 2013 (UTC)

[RESOLVED] Infobox problems

Hey,

I've been trying all sorts of things but still can't get the infobox template the work.

I've copied all the information to Common.css, I've imported all the correct templates from Wikipedia (including changing all incidents of ‘text/plain’ with ‘CONTENT_FORMAT_TEXT’), I've installed Parserfunctions, then, after upgrading to 1.22, Scribunto, but I'm still getting a big red "Script Error" - when clicked "Lua error: Internal error: The interpreter exited with status 2."

See - http://attwiki.org/Infoboxtest

What exactly have I missed, or what has gone wrong?

Thanks! Ig1234 (talk) 22:48, 29 December 2013 (UTC)

Do you have command line access to the server? If you do, then what happens when you execute the lua binary in the Scribunto directory?

Otherwise, check the permissions on the lua binary. They need to be set to 755 or +x.

Finally, try the debug log. If you add

$wgScribuntoEngineConf['luastandalone']['errorFile'] = "$IP/images/temp/lua.log";

to your LocalSettings.php, does anything show up in the file? If so, what is the last bit? ☠MarkAHershberger☢(talk)☣ 20:19, 4 January 2014 (UTC)

Thanks Mark.

Sorry I only just noticed your reply, I'll look at what you said when I get back from work tomorrow and see what happens. Ig1234 (talk) 00:03, 6 January 2014 (UTC)

Hey,

You'll have to forgive my ignorance.

I can probably get command line access (I'm using Dreamhost) but I fear my ignorance will mess things up in trying to use Putty etc. so I may have to ignore that.

I remember changing the permissions on the lua binary before. I've changed them for everything within the standalone binaries folder but it doesn't appear to make a difference.

Again... ignorance - how do I access the debug log from that line in LocalSettings.php? Ig1234 (talk) 20:58, 6 January 2014 (UTC)

...bump. Ig1234 (talk) 20:31, 14 January 2014 (UTC)

See Manual:How_to_debug: Manual:$wgDebugLogFile and Manual:$wgDebugLogGroups.

If with debug log you in fact mean /images/temp/lua.log, then download it with FTP. 88.130.119.179 22:14, 14 January 2014 (UTC)

I'm an idiot. Thanks.

This is the output of the debug log:

/home/danlee68/attwiki.org/wiki/extensions/Scribunto/engines/LuaStandalone/lua_ulimit.sh: xrealloc: ../bash/parse.y:2228: cannot allocate 512 bytes (49152 bytes allocated)
/home/danlee68/attwiki.org/wiki/extensions/Scribunto/engines/LuaStandalone/lua_ulimit.sh: xrealloc: ../bash/parse.y:2228: cannot allocate 512 bytes (49152 bytes allocated)
/home/danlee68/attwiki.org/wiki/extensions/Scribunto/engines/LuaStandalone/lua_ulimit.sh: xmalloc: ../bash/subst.c:7606: cannot allocate 112 bytes (45056 bytes allocated)
/home/danlee68/attwiki.org/wiki/extensions/Scribunto/engines/LuaStandalone/lua_ulimit.sh: xrealloc: ../bash/print_cmd.c:1498: cannot allocate 256 bytes (53248 bytes allocated)
/home/danlee68/attwiki.org/wiki/extensions/Scribunto/engines/LuaStandalone/lua_ulimit.sh: xmalloc: ../bash/subst.c:3503: cannot allocate 519 bytes (49152 bytes allocated)
/home/danlee68/attwiki.org/wiki/extensions/Scribunto/engines/LuaStandalone/lua_ulimit.sh: xrealloc: ../bash/print_cmd.c:1498: cannot allocate 256 bytes (53248 bytes allocated)
/home/danlee68/attwiki.org/wiki/extensions/Scribunto/engines/LuaStandalone/lua_ulimit.sh: xmalloc: ../bash/subst.c:3503: cannot allocate 519 bytes (45056 bytes allocated)
/home/danlee68/attwiki.org/wiki/extensions/Scribunto/engines/LuaStandalone/lua_ulimit.sh: xmalloc: ../bash/subst.c:3503: cannot allocate 519 bytes (45056 bytes allocated)
/home/danlee68/attwiki.org/wiki/extensions/Scribunto/engines/LuaStandalone/lua_ulimit.sh: xmalloc: ../bash/subst.c:3503: cannot allocate 519 bytes (45056 bytes allocated)
/home/danlee68/attwiki.org/wiki/extensions/Scribunto/engines/LuaStandalone/lua_ulimit.sh: xrealloc: ../bash/print_cmd.c:1498: cannot allocate 256 bytes (53248 bytes allocated)
/home/danlee68/attwiki.org/wiki/extensions/Scribunto/engines/LuaStandalone/lua_ulimit.sh: xrealloc: ../bash/parse.y:2228: cannot allocate 512 bytes (49152 bytes allocated)
/home/danlee68/attwiki.org/wiki/extensions/Scribunto/engines/LuaStandalone/lua_ulimit.sh: xrealloc: ../bash/print_cmd.c:1498: cannot allocate 256 bytes (49152 bytes allocated)

Ig1234 (talk) 21:12, 16 January 2014 (UTC)

You probably need to increase $wgMaxShellMemory Ciencia Al Poder (talk) 11:52, 23 January 2014 (UTC)

I've set it to a higher value, but it doesn't appear to make a difference. Is there a particularly high value that it should be set to? Ig1234 (talk) 00:35, 26 January 2014 (UTC)

What's the size of bytes allocated in the error log now?

I'd try to increase it to 20MB for example, and if the error disappears you can adjust it to a more reasonable level if needed. Ciencia Al Poder (talk) 10:23, 28 January 2014 (UTC)

no value helps. same errors, over and over:

/home/bicyclesworkintheworld/bicyclesworkintheworld.com/extensions/Scribunto/engines/LuaStandalone/lua_ulimit.sh: xmalloc: ../bash/subst.c:3503: cannot allocate 663 bytes (45056 bytes allocated)

numbers change with change of bytes in LocalSettings for shellmemory, but otherwise does not work 109.230.45.242 01:34, 23 August 2014 (UTC)

this seems to fix the error: Extension talk:Scribunto/2014#c-Usakoi84-2014-06-21T03:37:00.000Z-Usakoi84-2014-06-21T02:23:00.000Z 109.230.45.242 01:38, 23 August 2014 (UTC)

$wgScribuntoEngineConf['luastandalone']['memoryLimit'] = 805306368;

$wgMaxShellTime = 0;

$wgMaxShellFileSize = 805306368; 109.230.45.242 01:39, 23 August 2014 (UTC)

Extension:Babel MediaWiki messages

For Extension:Babel, does reconfiguring the MediaWiki messages MediaWiki:babel-autocreate-text-levels and MediaWiki:babel-autocreate-text-main automatically send User:Babel AutoCreate to rename all the appropriate babel categories to match the new changed text? TeleComNasSprVen (talk) 23:59, 29 December 2013 (UTC)

I'm not sure how this works. If it works as a bot, then the answer is probably not. If it just uses those as templates, then yes. ☠MarkAHershberger☢(talk)☣ 18:00, 20 February 2014 (UTC)

What is Education Program Extension usage?

Hi, I've read the extensions's page but somehow I still don't know Education Program usage, Can someone explain what can I do with it? Omidh (talk) 15:32, 30 December 2013 (UTC)

From the page:

Facilitates educational programs by adding various interfaces to manage courses, students, institutions, mentors, etc, as well as improving workflow for everyone involved (enrollment, seeing changes of other students, article and reviewer association) and providing several analysis/statistics interfaces.

So, it sounds like you can manage students, courses, etc. for some sort of wiki-centric educational program. I imagine you know that already, though, so what more do you want to know? ☠MarkAHershberger☢(talk)☣ 22:44, 3 January 2014 (UTC)

I want to know the main purpose of using Education Program, What a student can do in a wiki? How the extensions manage students? the description is very general. Omidh (talk) 13:17, 9 January 2014 (UTC)

Best place to ask for information about the Education Program extension's purpose is on its talk page. ☠MarkAHershberger☢(talk)☣ 15:57, 5 February 2014 (UTC)

Upgrade (Mediawiki 1.15 XAMPP)

Hi. I need help from somebody smart. I have Mediawiki 1.15 install through XAMPP. After a lot of days I finally import my database to XAMPP (v3.2.1) (previosly I used MOWES). But I have very old MediaWiki (v 1.15) and I need to upgrade. But I'm completely lost in all the instructions and manuals. Please, please, can somebody help me step by step? Thanks. Zipacna1 (talk) 17:36, 30 December 2013 (UTC)

Hi!

The MediaWiki community is extremly proud to present you a document to fullfill your needs:

Upgrade!

This is the guide you are looking for! 88.130.127.24 23:27, 30 December 2013 (UTC)

[SOLVED] Category page does not refresh

MediaWiki 1.22.0 PHP 5.3.10-1ubuntu3.9 (apache2handler) MySQL 5.1.72-0ubuntu0.10.04.1

After upgrading to version 1.22, I have a problem getting category pages to refresh. I tried adding ?action=purge to the category page's url. And same for the changed 'to be categorized' page. I tried disabling pagecaching in LocalSettings.php. I waited over 24 hours (which used to help)

The problem occurs after changing the category on a page. The actual (correct) category shows in the footer of the page to be categorized, but the page keeps showing on the former category page.

I cannot share a link to the wiki as it is a closed usergroup wiki. BigBirdNL (talk) 10:51, 31 December 2013 (UTC)

Truncating the objectcache table in the database does not solve the problem eigther.

Removing and recreating the category page does not solve the problem. BigBirdNL (talk) 11:08, 31 December 2013 (UTC)

Hi!

Refresh the categories by running the maintenance script refreshLinks.php! 88.130.106.196 12:26, 31 December 2013 (UTC)

YES, that worked!

Thanks! BigBirdNL (talk) 17:14, 12 January 2014 (UTC)

html in mediawiki

how can I display an image on a mediawiki page using html <img> tag? 125.63.95.242 (talk) 11:24, 31 December 2013 (UTC)

Can we use multiple skins for a single wiki using mediawiki.

Just for example, suppose I have 10 pages on my mediawiki server and I want one skin to be applied on first five pages only whereas the second skin to be applied on the next five pages. Can we do that? I it even possible?

Thank You. 125.63.107.135 17:07, 31 December 2013 (UTC)

Hi!

As for the image there is an extension, which allows people to put HTML code into wiki pages (and that can also include image tags). However, using it is a security risk as people can basically enter any HTML code; also malicious stuff. Allowing raw HTML code in wiki pages is not recommended. If what you want to do is to allow external images, see $wgAllowExternalImages.

You can use the CSS classes, which are attached to the body tag in the HTML code to apply certain styles to certain pages. Maybe you want to use the classes, which are used for the different namespaces? That would allow you to differentiate by the page's namespace.

However, what you want sounds a bit strange. Maybe it would be better to use two separate wikis, if you want them to look differently? 88.130.106.196 03:35, 1 January 2014 (UTC)

So, we cannot use two skins on same wiki! Okay.

and Thank You Sir I will try if that works. 119.82.92.245 08:00, 1 January 2014 (UTC)

That's not what I said. In fact I think using two different skins in the same wiki would be possible, but I think it won't make sense. 88.130.94.158 13:16, 2 January 2014 (UTC)

Download audio file

Sorry, this is a very basic question, but I am a beginner at this. I want to download a Wikimedia file to my PC so that I can carry out acoustic analysis of the sound it contains. The file is voiceless palatal fricative.ogg and I can find that OK, but I have not been able to figure out how I can download this so that I have it as an audio file on my computer. 31.52.39.80 (talk) 14:29, 31 December 2013 (UTC)

You can download at media:voiceless palatal fricative.ogg.

There should also be download links from the menu option of the media player. The file description page also has a link to download the original file. Bawolff (talk) 05:11, 3 January 2014 (UTC)