Hi,
I'm running multiple language wikis and one pool wiki. The problem is
that no file descriptions are fetched in the language wikis although
$wgFetchCommonsDescriptions is set to true.
LocalSettings.php of the language wikis:
$wgUseSharedUploads = true;
$wgSharedUploadPath = 'http://pool.example.com/w/images';
$wgSharedUploadDirectory = '/path/to/pool/w/images/';
$wgHashedSharedUploadDirectory = true;
$wgFetchCommonsDescriptions = true;
$wgSharedUploadDBname = 'poolwiki'; # DB-Name of PoolWiki
#$wgSharedUploadDBprefix = 'wiki_'; # Table name prefix for PoolWiki
$wgRepositoryBaseUrl = "http://pool.example.com/wiki/Image:";
ForeignAPIRepo used to work fine before, but since I switched from
Apache to Nginx, no images show up anymore in the language wikis. This
is how my LocalSettings.php used to look like:
$wgForeignFileRepos[] = array(
'class' => 'ForeignAPIRepo',
'name' => 'pool',
'apibase' => 'http://pool.example.com/w/api.php',
'fetchDescription' => true, // Optional
'descriptionCacheExpiry' => 43200, // 12 hours, optional (values are
seconds)
'apiThumbCacheExpiry' => 0, // required for local thumb caching
);
I also tried to set 'name' => 'poolwiki', (name of the pool database)
but that doesn't work either.
I also re-started Memcached and I even deleted a file description page
from the CloudFlare cache, but still no file description can be seen :/
My software: MediaWiki: 1.22.0
PHP: 5.3.27 (fpm-fcgi)
MySQL: 5.1.70-log
Any help would be über-cool.
Thanks and cheers,
Till
> From: "Scheid, Bernhard" <Bernhard.Scheid(a)oeaw.ac.at>
>
> For unknown reasons, google sometimes refers to my wiki-pages by using https instead of http. The result is that the page is displayed, but without css. Any advice how to prevent this?
I doubt Google is making this up.
That means that there are links out there that refer to your site with https. Hunt them down and kill them.
Otherwise, if you have control of your server, you can simply enable https as well as http. It isn't terribly difficult.
:::: I suggest you locate your hot tub outside your house, so it won't do too much damage if it catches fire or explodes. First you decide which direction your hot tub should face for maximum solar energy. After much trial and error, I have found that the best direction for a hot tub to face is up. -- Dave Barry
:::: Jan Steinman, EcoReality Co-op ::::
Still getting error messages from the Special:UpLoad page shown below:
> Error creating thumbnail: convert.im6: no decode delegate for this
> image format `/tmp/magick-2bvC6VML' @
> error/constitute.c/ReadImage/544.
> convert.im6: no images defined `PNG:/tmp/transform_c5506caa9662-1.png'
> @ error/convert.c/ConvertImageCom
>
This is my images stuff from LocalSettings.php
> ## To enable image uploads, make sure the 'images' directory
> ## is writable, then set this to true:
> $wgEnableUploads = true;
> $wgUseImageMagick = true;
> $wgUseImageResize = true;
> $wgImageMagickConvertCommand = "/usr/bin/convert";
> $wgSVGConverter = 'ImageMagick';
> $wgTmpDirectory = "$IP/images/temp";
> $wgUploadPath = "$wgScriptPath/images";
> $wgUploadDirectory = "$IP/images";
> # InstantCommons allows wiki to use images from http://commons.wikimedia.org
> $wgUseInstantCommons = true;
>
> ## If you use ImageMagick (or any other shell command) on a
> ## Linux server, this will need to be set to the name of an
> ## available UTF-8 locale
> $wgShellLocale = "en_US.utf8";
>
I don't know if all the $wgXXXxxx settings are correct. Seem to be no examples available. Also I have tried just using the defaults & that doesn't work either.
Hello all,
I would like to announce the release of MediaWiki Language Extension
Bundle 2014.03. This bundle is compatible with MediaWiki 1.22.4 and
MediaWiki 1.21.7 releases.
* Download: https://translatewiki.net/mleb/MediaWikiLanguageExtensionBundle-2014.03.tar…
* sha256sum: f3a253e05f6b7c4f451882a1a78a138a1dcaecd2777237d0c2b8af7c3ecced70
Quick links:
* Installation instructions are at: https://www.mediawiki.org/wiki/MLEB
* Announcements of new releases will be posted to a mailing list:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-i18n
* Report bugs to: https://bugzilla.wikimedia.org
* Talk with us at: #mediawiki-i18n @ Freenode
Release notes for each extension are below.
-- Kartik Mistry
== Babel, CleanChanges ==
* Only localisation updates.
== CLDR ==
* Updated to CLDR 25.
* Localisation updates.
== LocalisationUpdate ==
LocalisationUpdate is rewritten for JSON file format support for
extensions. This is compatible with MediaWiki 1.19 and above.
* Extensions using JSON are fully supported and LocalisationUpdate
will pickup new languages as they appear.
* LocalisationUpdate will store translation using JSON file format. If
extension is not yet migrated to JSON, messages will be stored as PHP
file.
=== Configuration changes ===
==== Global Variables ====
====== $wgLocalisationUpdateRepository ======
Default repository source to fetch translation. MediaWiki's Github
mirror is set to default repository to fetch translations. This is
added with version 1.1.
===== $wgLocalisationUpdateRepositories =====
Array of repositories URLs from which to retrieve localisations for
core MediaWiki and extensions. Default is set to GitHub's MediaWiki
Git repositories and you should not change this unless you're using
this performance improvement or otherwise know what you're doing. This
is added with version 1.1.
==== Script parameters changes ====
With version 1.1,
--repoid: Fetch translations from repositories identified by this
==== Notes ====
* Once core MediaWiki switches to JSON format, all users must update
LU to keep receiving updates. They will need to update anyway because
older versions of LocalisationUpdate do not support JSON at all.
* If an extension switches to JSON, we will not be able to provide
updates until its local checkout is updated to such a version.
LocalisationUpdate does not know about the switch and will try to
fetch the PHP shim, which does not have translations any longer. This
is usually okay, as the PHP shims support old MediaWiki versions;
problems might appear if the extension has other incompatible changes
which prevent updating.
* For more details, also see:
https://www.mediawiki.org/wiki/Extension:LocalisationUpdate
== Translate ==
=== Noteworthy changes ===
* Added support for insertables with numbers in the end on translatable pages.
* Improvements in TUX shortcuts: Shortcut indicators are now more
visible. Fixed display in RTL. Added indicators for up/down arrows.
* characterEditStats.php: Mention the max age of recent changes
($wgRCMaxAge) limits.
* Added a notice about ULS extension dependency. On Special:Translate,
it will fail with MediaWiki error page if ULS is not installed.
== UniversalLanguageSelector ==
=== Noteworthy changes ===
* Compacting the interlanguage links with the ULS as new Beta feature.
Displays a shorter version of the language list with the languages
that are more relevant to you. More info at:
https://www.mediawiki.org/wiki/Universal_Language_Selector/Design/Interlang…
* Bug 56081: Reset webfonts where inline css style found upon reset.
This fixes broken live preview for content font.
=== Fonts ===
* Updated Lohit Oriya font to new upstream version and renamed to Lohit Odia.
--
Kartik Mistry/કાર્તિક મિસ્ત્રી | IRC: kart_
{kartikm, 0x1f1f}.wordpress.com
ProductVersion
MediaWiki1.22.5 (7266102)
PHP5.3.15 (apache2handler)
MySQL5.0.77
Lua5.1.5
I just noticed today that WikiEditor is no longer present when editing
a page on our wiki. Others seem to have experienced this as well. I
have a test version of the exact same wiki where WikiEditor is working
and the only difference between the two installations is the PHP
version. The working version is PHP 5.4.22.
Is there any known issues with WikiEditor and PHP 5.3?
Thanks
Bill
.gif images are not loading in my mediawiki. Even those that are from
$wgUseInstantCommons =true;
This is my image system settings from LocalSettings.php
> ## To enable image uploads, make sure the 'images' directory
> ## is writable, then set this to true:
> $wgEnableUploads = true;
> $wgUseImageMagick = true;
> $wgUseImageResize = true;
> $wgImageMagickConvertCommand = "/usr/bin/convert";
> $wgSVGConverter = 'ImageMagick';
> $wgTmpDirectory = "$IP/images/temp";
> $wgUploadPath = "$wgScriptPath/images";
> $wgUploadDirectory = "$IP/images";
> # InstantCommons allows wiki to use images from http://commons.wikimedia.org
> $wgUseInstantCommons = true;
>
> $wgFileExtensions = array( 'tex', 'png', 'eps', 'ps', 'gif', 'jpg', 'jpeg', 'svg', 'ppt', 'pdf', 'psd', 'mp3', 'xls', 'xlsx', 'swf', 'sty', 'doc','docx', 'odt', 'odc', 'odp', 'odg', 'mpp', 'tiff');
> $wgStrictFileExtensions = false;
>
I also am unable to use the Special:UploadFile page.
Both .jpeg & .svg seem to work. on the site others are shown as placeholders.
Notions or ideas??
Thanks
John
Hi, this project is geared towards third party MediaWikis, and this is why
it is becoming more difficult for us to find a mentor among the usual
suspects (WMF employees, usually focusing in features relevant to Wikimedia
projects). If anybody here familiar with development of extensions wants to
volunteer as mentor, let me know. Questons? Just ask.
It is urgent -- see
https://www.mediawiki.org/wiki/Google_Summer_of_Code_2014
Thank you.
---------- Forwarded message ----------
From: *Quim Gil* <qgil(a)wikimedia.org>
Date: Wednesday, March 26, 2014
Subject: [Wikitech-l] GSoC proposal "Frontend for Vector skin CSS
customizations" (Ioannis Protonotarios)
To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
Hi, we are still welcoming mentors for this interesting proposal
On Thu, Mar 20, 2014 at 6:58 PM, Ιωάννης Πρωτονοτάριος <
ioannis(a)protonotarios.eu> wrote:
> My proposal is the creation of a frontend that will help users with little
> or no experience at all to easily produce all the CSS needed to change
their
> wiki's layout.
>
> Full proposal wiki page:
https://www.mediawiki.org/wiki/User:Protnet/Frontend_for_Vector_skin_CSS_cu…
The implementation proposed consists in MediaWiki extension depending on
the Vector skin. The plan sounds sensible and fitting with the discssion of
finding ways for 3rd party MediaWikis to differentiate from plain MediaWiki
and Wikimedia sites. The proposal also shows a good amount of original
thought and work.
We *might* get a secondary mentor from the WMF Design team to support the
UI work and also the possibilities of CSS customization options that
MediaWiki admins might be interested about. We miss a developer familiar
with MediaWiki extension developer. I'm not an expert, but this extension
looks relatively simple in terms of backend? It is an interface to
manipulate MediaWiki:Common.css.
Ideas for related bugs that can be assigned to Ioannis as microtasks are
also welcome. Just name existing bug reports requiring skills relevant to
this project.
Thank you.
--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil