Talk:MediaWiki 1.18

Previous page history was archived for backup purposes at Talk:MediaWiki 1.18/LQT Archive 1 on 2015-06-10.

Recenetly, i upgrade 1.18 version from 1.17.x. And i met the error message when i upload a file. The message is "The file is a corrupt or otherwise unreadable ZIP file. It cannot be properly checked for security" The format are doc,xls.....not a zip... How can i solve this error.

I figured out that it tries to Unzip Doc file with ZipDirectoryReader::read and fails. Actually doc file is some kind of zip file but even standard zip program raises warnings: Archive: text.doc warning [text.doc]: 167526 extra bytes at beginning or within zipfile

 (attempting to process anyway)
 inflating: [Content_Types].xml     
 inflating: _rels/.rels             
 inflating: theme/theme/themeManager.xml  
 inflating: theme/theme/theme1.xml  

It is not much secure but I'm block this by: $wgAllowJavaUploads = true;

May be its help you

Ty it solved my problem.

Hi, I tried this and got an error 500, still trying to figure out exactly what the problem is. If I comment out $wgAllowJavaUploads = true; I get the message: The file is a corrupt or otherwise unreadable ZIP file. It cannot be properly checked for security.

Regards, Steve

[for Steve.Tarzon's issue] 500 error indicates php fatal error (aka bug in MediaWiki or an extension). If you enable php error reporting (See How to debug) it would be helpful in fixing the issue.

I'm having the same problem with version 1.18. I'm try to upload XLS, DOC, files. It is impossible. I've searched around the web and found no help.

You can now upgrade to MediaWiki 1.19 to see if that helps....

Upgrading did not help us. We are still unable to upload .doc files. This is a major bug, it must be fixed ASAP.

We urge you to file it in Bugzilla, our bug reporting system, with as many details as possible about your setup, the behavior, and anything else that might be relevant to tracking down and fixing the problem. Thanks!

Please file it in http://bugzilla.wikimedia.org which is our bug tracker, indicate how severe the problem is, and give us the information we need to fix it. Thanks!

I have done so.  :-)

Fyi, Sam's bug report is at https://bugzilla.wikimedia.org/show_bug.cgi?id=38432 .

test.

Setting $wgAllowJavaUploads = true fixed it for me too

For me (1.15, managed by debian squeeze) $wgAllowJavaUploads=true was not enough. I had to use $wgVerifyMimeType=false as well. Be warned though, this is bound to lead to some serious security issues.

Fixed it for me too.

M$ documents (doc, dot) generated with OOo or LOo are uploaded with success.

Solved my problem as well.
Thanks for the tip!

That solved my problem too in MW 1.23.6

Worked for me too in MW 1.27.1. I was encountering that error with certain .msg files (Outlook emails). Usually it was with the ones that had attachments. It may have only been with Excel/Word attachments. I believe .PDF files within .msg files worked okay.

I got same error but trying to attach a Draft email .msg

While inserting a .msg from completely received email worked...

I am using 1.22 tho :\

If I follow "RELEASE NOTES" of "You can consult the RELEASE NOTES" at the beginning of the page, I get URL https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/1.18.6/RELEASE-NOTES-1.18 which is ok (and https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+refs provides even all the releases).

If I follow "full release notes " of "see the full release notes for an exhaustive list." some lines below, I get a dummy page at URL https://phabricator.wikimedia.org/source/mediawiki/browse/REL1_18/RELEASE-NOTES-1.18

Ref "REL1_18" does not exist in this repository.

Can you correct leading to the same location. Thank you.

Christian Wia (talk) 17:42, 16 June 2019 (UTC)

Head content such as title, meta tags apper in body tag and not in head tag and this makes my skin messed in internet explore. can anyone give idea why is it so or how can i fix it.

Running update.php after replacing the Mediawiki 1.17.0 files with 1.18.2 ones, gives this:

Fatal error: Call to a member function getDbType() on a non-object in maintenance/doMaintenance.php on line 91

DB is corrupted after this happens. Is this a known bug/feature? The 1.17.0 is an original version, no custom corrections. Boyandin (talk) 01:31, 24 March 2012 (UTC)

I assure it is not a feature ;)

Make sure when upgrading that all the files got replaced by the new files. Maybe you have some files that are the 1.17 version, and some that are the 1.18 version, or something like that.

I am currently exploring possiblity of migrating to Oracle (Company need), I am required to provide an estimate for porting our existing wiki site (from MySQL) to oracle. I would like to know if anyone has succesfully managed to migrate mediawiki 1.18 on oracle and if yes, roughly how much effort was spent.

Thanks in advance.

I would be interested in an answer to this too

Hi, I guess this page is the better place to ask this. Cheers

Can we migrate mediawiki on wordpress..?

{{Special:NewImages/1}}

When never I change the number from 1 to 1000. It only show 50 newest image.

I can not use it on main page now.

I have opened bug 33037 for you :-)

thank you!

with new mediawiki on skin.php files (modern.php for example) there aren't head section, i need to add my javascript to it how i should do this?

We stopped using manually written heads and <body>s back in 1.16 and replaced them with the headelement.

To add styles define a `function setupSkinUserCss( OutputPage $out )` in the class you extend from SkinTemplate and make calls to $out there to (preferably) load a resource loader module with your styles. Or make addStyle calls. Likewise to add scripts do similar inside of a `function initPage( OutputPage $out )`.

If you're not writing your own skins, you should do things the normal way using the BeforePageDisplay hook and calls to output, or for analytics type scripts using SkinAfterBottomScripts.

Hi,

Google AdSense or DFP js-scripts need to be loaded on the head section of the page. How can I achieve this?

How is moving from a gender-neutral system to a binary gender system a feature? This is a bug!

Dear developers, you do realize that there are more gender identities than male and female, correct? By limiting this selection to only 'male' and 'female', you're taking a step backward. You were better off leaving it neutral. Please read this to understand: w:en:Gender_identity

"Leaving it neutral" is erroneous; previous to 1.18 many women got addressed as men in non-English languages. MediaWiki's developers are aware of the difficulties in addressing people respectfully and accurately with regards to gender; for example, see the discussion on https://bugzilla.wikimedia.org/show_bug.cgi?id=30442 and https://bugzilla.wikimedia.org/show_bug.cgi?id=27744, which you're welcome to join. Sumana Harihareswara, Wikimedia Foundation Volunteer Development Coordinator 03:37, 23 December 2011 (UTC)

These changes are mostly about support for grammatical genders, as far as I understand, and most languages that have grammatical gender differences that I know of use mainly two genders. Gender identity is of course more complex, and has always been, but as these changes make it possible to make grammatical correct translations in more places, I would at least not consider it a step backward. (Though maybe the settings field in the preferences page could be worded differently. I'm sure any suggestions on how to phrase it differently will be taken into account if you file a bug on it). rotsee 00:00, 1 January 2012 (UTC)

FWIW, for anyone who's wondering about the status of the 1.18 release, there's some info here:

• mailarchive:wikitech-l/2011-October/055963.html

It's a mail from October 26th where someone says they've been busy with other things this month but hope to push out a new 1.18 development release "this week", moving from alpha to beta. Ciaran 15:14, 30 October 2011 (UTC)

I know Mark Hershberger wants to get a beta out tomorrow (Thursday 3 November).

Hello,

I'm sorry for the bad English, this text is translated, I only speak French.

Since I moved from version 1.17 to version 1.18, when I put a tag <ref> in a template, I do not obtain, example, text^[1],

but something more like, example, text^{[UNIQ3e899f9b5c8f874-nowiki-00000002-QINU1UNIQ3e899f9b5c8f874-nowiki-00000003-QINU]}.

You can see an example on this page.

Where the source of that error?
This does not derive from templates or extensions. Thank you

I forgot in the message: the same page with the same models on a mediawiki 1.17 on this page