Talk:MediaWiki 1.21

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

Having issues with thumbnails on my wiki, ever since I enabled short URLs, everything has been working fine apart from thumbnails no longer show up

I have mediawiki installed in the root directory (shared hosting), and have set my shortURLs to be http://website.com/wiki

From searching this site and google I have gathered its most likely a problem with my htaccess files, I currently have it set to

RewriteEngine On

RewriteRule ^/?wiki(/.*)?$ %{DOCUMENT_ROOT}/index.php [L]

RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-f

RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-d

RewriteRule ^/?images/thumb/[0-9a-f]/[0-9a-f][0-9a-f]/([^/]+)/([0-9]+)px-.*$ %{DOCUMENT_ROOT}/thumb.php?f=$1&width=$2 [L,QSA,B]

RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-f

RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-d

RewriteRule ^/?images/thumb/archive/[0-9a-f]/[0-9a-f][0-9a-f]/([^/]+)/([0-9]+)px-.*$ %{DOCUMENT_ROOT}/thumb.php?f=$1&width=$2&archived=1 [L,QSA,B]

and the htaccess in my images directory is

# Protect against bug 28235

<IfModule rewrite_module>

RewriteEngine On

RewriteCond %{QUERY_STRING} \.[^\\/:*?\x22<>|%]+(#|\?|$) [nocase]

RewriteRule . - [forbidden]

# Fix for bug T64289

Options +FollowSymLinks

</IfModule>

my site seems to be looking in the correct place on my host for the files however any thumbnail files uploaded after the short URL change are not being created (I have the folder permissons set to 755)

Can anyone help with this please

Just a note for anyone who's wondering if the release is really going to happen or if the date will just be continually incremented... From reading the wikitech-l mailing list, it looks like the release really will happen and the delays are just minor issues. Here's the latest mail saying that there's a delay for logistical reasons (he later explains it's about organising multiple people):

http://lists.wikimedia.org/pipermail/wikitech-l/2013-May/069471.html

.Ciaran (talk) 09:15, 21 May 2013 (UTC)

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

Could we add a native mobile skin, or include such a extension with said skin, in the standard package?

There is no standard package yet, but the extension used by Wikipedia (Extension:MobileFrontend) is well on its way to becoming a generic (not Wikipedia specific) skin that can be used on any wiki, maybe even bundled by default one day.

Problem is that when 1.20 was stable, MobileFrontend required mw 1.21. Now that mw 1.21 is stable and 1.22 is in alpha stage, the extension requires 1.22!

Since mw 1.22 (stable) won't be on it's way anytime soon so could you please create a REL_1.21 branch for the MobileFrontend extension? I assume that up to some revision this extension can be used with mw 1.21.x.

The only infomarmation for the subject found on the internet about that is the following: https://www.mail-archive.com/mobile-l@lists.wikimedia.org/msg00576.html

Having a "mobile wiki" is vital! Thank in advance!

I'm using MobileFrontend in my own wiki and so far so good.

This post was posted by Qgil-WMF, but signed as Qgil.

MediaWiki 1.20 doesn't have mentions to the point releases. They can be only found at Release notes/1.20. Maybe in 1.21 we can do better?

Having a little section for each point release would allow us to keep linking to the (hopefully localized) MediaWiki 1.21 announcement. The release notes could stay as they are, in English only and all the details of bugs fixed.

This discussion started in the context of Template_talk:Current_versions#New proposal.

This post was posted by Qgil-WMF, but signed as Qgil.

1.x.y releases don't contain big new features etc. and in your example there's nothing about them on Release notes/1.20 that should go on MediaWiki 1.20. I'm adding {{MWReleases}} on the wiki release notes and we probably need {{MW quick download}} (or similar) on the 1.x pages.

You are right... But on the other hand is kind of weird to have point releases out there not mentioned at all in the main page of the release they relate to. A simple mention linking to the release notes would do e.g.

• YYYY/MM/DD - 1.x.y security release is out.

This post was posted by Qgil-WMF, but signed as Qgil.

Release checklist lists all the templates which are updated when a new release is produced; there's plenty of templates, those should be used for this.

How would you keep entries for 1.20.1 and 1.20.2 at MediaWiki 1.20 using those templates? They are updated every time a new release is available, isn't it. But thank you for the link to Release checklist. Should we move this thread there?

This post was posted by Qgil-WMF, but signed as Qgil.

I don't know. I've added more links to the two templates above.

It would be nice to have the 1.21 announcement localizable, with a few translations available by the release day. What do you think?

This post was posted by Qgil-WMF, but signed as Qgil.

(Reply moved from the other thread.) The real problem is that if we add information to the 1.XwmfY subpages then there's no easy way to transfer content and translation to the 1.X pages; perhaps sections like those should be transcluded from a central subpage for all wmf releases, which when the cycle is over would be either refactored and reused as MediaWiki 1.X page or partly transcluded in it, or whatever.

Er... sorry, I got lost. :) Do you agree with the idea of having the main page of each 1.x release translatable? The details of the point releases would go to a separate Release Notes page, in English only (which makes sense since more of the content of those notes are links to bugs in English only). I'm not sure what content you are proposing to transclude from Release Notes to main page, but if that is problematic for translations we can simply avoid transcluding?

This post was posted by Qgil-WMF, but signed as Qgil.

No, I don't propose any transclusion from release notes. I mean that translatable human-readable information on WMF releases, like MediaWiki_1.21/wmf6#Most_important_changes, should be reusable on the main release page.

Hello,

I am running v 1.21 on a Win 2k8 r2 (64 bit), it has been working fine since the installation.

I recently planned on getting thumbnails in it and so I got ImageMagick-7.0.0-Q16 on the same box. I set the variables of

$wgEnableUploads = true;
$wgUseImageMagick = true;
$wgImageMagickConvertCommand = "C:\Program Files\ImageMagick-7.0.0-Q16\convert.exe";

and I can see that under the folder ...wiki\images\thumb it is actually creating the thumbnails, I'm just having trouble displaying them on the website. Does anyone have the same issue?

Any information will be greatly appreciated. SF

Use double backslash in path - \\

Thanks,

I've tried using double backslash with no change, that gave me an idea and I also tried using the short names (PROGRA~1) and is all the same when loading the pages with thumbnails. I can still see the thumbs being created in the ...wiki\images\thumb folder but they are just not rendering in the website.

If I take the original "full size" image to an article it displays fine. Does anyone know of a specific configuration I should check?

SF

Just updated my Wiki to version 1.21.3, but the version number that's being displayed is 1.21.2. Is there an issue with the pack that's currently available or is there another update I need to apply?

Ever since we upgraded our site to MediaWiki 1.21 from 1.20 and our Apache server to 2.4 from 2.2, some of our pages return a Proxy Error saying it can't handle the request. This only occurs when the title of the page is >51 characters.

Has anyone else experienced this?

No, I only heard of issues with long load.php URLs (over 512 bytes or so). Please file a bug with as clear steps to reproduce as possible.

I'm a bit confused about the rename. We use the subpages of Release notes to host the wiki version of the RELEASE-NOTES-* files, are we going to drop them?

Could you weigh in on the mailing list thread?

Will release 1.21 include VisualEditor?

Probably not; VE is likely to continue to be (to some extent) experimental for a while, and 1.21 might well be ready to come out earlier than we can get it into a state that we'd recommend it to people, sorry.