Dear MediaWiki experts,
I cannot really figure out the behaviour of MediaWiki regarding thumbnailing. What I want to achieve is that my MediaWiki installation produces thumbnails in a specified size.
What I did after reading through several help pages is this:
---------------------------
# Images und Thumbnails
$wgThumbLimits = array( 80, 250, 390 );
$wgDefaultUserOptions['thumbsize'] = 1; // thumb size 250
$wgImageLimits = array( array( 80, 90 ), array( 800, 600 ), array( 1280, 1024 ) );
$wgDefaultUserOptions['imagesize'] = 2; // image size 800, 600
---------------------------
In my opinion this should guarantee that for every image uploaded, there is an 80, 250 and 390px sized thumbnail. In many cases this is true, but there are some cases were I can find a 100px thumbnail, but no 80px thumbnail.
If I understand it correctly, this can perfectly be the case if any user sets his/her preference to 100px. I don't mind so much extra sizes to be produced, but I want to make sure that a 80px thumbnail is there.
Maybe in the cases where it is not present the images were uploaded before the above mentioned setting was made? But how can I get the wiki to redo thumbnails in my desired size?
cheers,
Bernhard
Attention sysops of projects that usef the RelatedArticles extension [1]
The reading web team recently updated this extension to render articles in
the footer of wikis rather than the traditional sidebar (as in Vector).
All Wikimedia wikis that use this extension are rendering related pages in
the footer. As a result we are now considering the deprecation of the
traditional rendering to avoid the maintenance of two rendering modes.
I have no idea if any projects outside Wikimedia are using this, but please
consider this email your opportunity to get your voice heard.
See also:
https://www.mediawiki.org/wiki/Extension:RelatedArticles#Notice_of_deprecat…
Thank you for your input!
Jon
[1] https://www.mediawiki.org/wiki/Extension:RelatedArticles
--
Jon Robson
Senior Software Engineer
Hello all,
I would like to announce the release of MediaWiki Language Extension
Bundle 2017.07. This bundle is The bundle is compatible with MediaWiki
1.27 and 1.28 or above and requires PHP 5.5.9 or above.
Next MLEB is expected to be released in 3 months. If there are major
changes or important bug fixes, we will do intermediate release.
Please give us your feedback at
[[Talk:MLEB|https://www.mediawiki.org/wiki/Talk:MLEB]].
* Download: https://translatewiki.net/mleb/MediaWikiLanguageExtensionBundle-2017.07.tar…
* sha256sum: c050c326bfa56d326fece072bed5e4be3e3ad3289b0a449313a2e7dbc4514c55
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://phabricator.wikimedia.org/
* Talk with us at: #mediawiki-i18n @ Freenode
Release notes for each extension are below.
-- Kartik Mistry
== Highlights and upgrade notes ==
== Babel ==
* Information about the languages that the user knows is now cached to
improve performance. To load the data from the cache, use
getCachedUserLanguageInfo() instead of getUserLanguageInfo(), and
getCachedUserLanguages() instead of getUserLanguages().
* Language code are normalized when they are stored in the database.
So, for example, "ZH" and "zh" are now stored as the same code.
* It is now possible to load Babel information from a Babel box on a
global user page.
== CLDR, CleanChanges and LocalisationUpdate ==
* Localisation and maintenance updates only.
== Translate ==
* Translate extension no longer bundles spyc library. If you need
support for parsing and generating YAML files, and you don't have
phpyaml extensions installed (HHVM provides it in PHP compatibility
mode), then you can install spyc using composer update. (T75945)
* Niklas Laxström fixed a broken error propagation in translator
sandbox user creation in case of an invalid password. (T164912)
* User TerraCodes removed redundant dialog title from the message
group selector. (T165241)
* Niklas Laxström added informative warning message that warns about
non-existent message groups.
* Niklas Laxström fixed a bug that could cause translation completion
statistics to not update in some situations (e.g. translatable pages
within an aggregate message group).
== UniversalLanguageSelector ==
* Amir Aharoni added to Compact Language Links the ability to show
languages that logged-in users specified in the Babel box. (T135371)
* Amir Aharoni improved the language database by making sure all
language autonyms are unique.
* Amir Aharoni fixed misaligned icons in the jquery.ime selector in
RTL. (T164474)
* Amir Aharoni added five African languages and one Asian language to
the language database.
* Amir Aharoni added five language of Taiwan to the language database.
* Amir Aharoni added Rangi language to the language database.
* Federico Leva added four new languages for translatewiki.net to the
language database.
* Federico Leva added variants for Hakka language to the language database.
=== Input methods ===
* Amir Aharoni added an input method for the Fula, Wolof language and
improved the keyboard for the Dagbani language.
* Amir Aharoni added input methods for Dinka, Bambara and Dagbani languages.
* Amir Aharoni renamed Akan keyboard and made it usable also for Twi.
* Kartik Mistry and Amir Aharoni merged numerous pull requests from volunteers:
** Kannada language input methods now also work for the Tulu language.
** Added Tarandine language keyboard by User:Joetaras
** Added Piedmontese language keyboard by User:GatoSelvadego
** Fixes to the Odia transliteration keyboard by User:Psubhashish
** Added the Tulalip input method for the Lushootseed language by
[https://github.com/jcrowgey jcrowgey].
** Added Sambhota input method for Tibetan language by
[https://github.com/eroux Elie Roux].
** Added a Gothic input method by User:Bokareis
** Added added mm3 input method for the Burmese language by User:Lionslayer.
** Added input methods for the Mongolian language by
[https://github.com/hfl Feilong Huang].
** Fixes to the Tamil 99 input method for the Tamil language by
User:Balajijagadesh
--
Kartik Mistry/કાર્તિક મિસ્ત્રી | IRC: kart_
{kartikm, 0x1f1f}.wordpress.com
Hello!
Today I've learned that an hidden category (using __HIDDENCAT__) is just
a page with a certain property in the `page_props` database table. To be
precise, it should have 'pp_propname' => 'hiddencat'.
https://doc.wikimedia.org/mediawiki-core/master/php/WikiPage_8php_source.ht…https://www.mediawiki.org/wiki/Manual:Page_props_table
Having said that:
1. Why the hell in my personal MediaWiki database I have
'68696464656e636174' as 'pp_propername' value (instead of the expected
'hiddencat' value)?
2. What does '68696464656e636174' mean?
3. Why does it work as expected?
3.1 Are there magic/obscure/evil lines of code behind the database
abstraction layer?
Yes, I admit that I'm using MediaWiki 1.27.3 but yes, my local
WikiPage.php looks exactly as the linked documentation.
Thanks for this clarification :D
--
Email sent from Ubuntu GNU/Linux GNOME using Mozilla Thunderbird
(Don't fight about it. I have to convert this client to Debian stable, like my laptop)
Valerio Bozzolan
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hello Everyone.
This is an advisory that the SimpleSecurity extension has unfixed
security issues, and that people relying on it should consider moving
to a different solution.
The extension does not take caching into consideration, and is not
secure when $wgMainCacheType is something other than CACHE_NONE. We
received a bug report about this quite a long time ago, however it
appears nobody is maintaining the extension, and we were unable to
find anyone to forward the report to who was interested in fixing
the issue. So instead we are making the issue public and issuing
this warning about it.
The issue in question is https://phabricator.wikimedia.org/T48843
The extension in question is
https://www.mediawiki.org/wiki/Extension:SimpleSecurity
Sincerely,
Brian Wolff
Wikimedia Security Team
P.S. This is the first time I've ever written a warning like this
for an extension. In the past, we've just put security alerts on
the extension page or sometimes just ignored them (which I consider bad).
I would like feedback from mediawiki-l if people on this list appreciate
getting a notice like this, or if you folks consider it off topic.
Any other feedback about how we handle security issues reported to
us for extensions we do not make or maintain is also appreciated.
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCAAGBQJZbtGsAAoJEDYflDsVwI3UGHIQAIWbmd1+xvbnCXLEV1gq1ZMm
3aAANm1SX8jbhanY93a28YnUyFULCuehlzrXTonZBvPy59W8GbOB5qW4Px1CHzRJ
hPewsxTObfnxEW5+JzSH9o4ApZgAjgGvBZP0fQTRgmZdiWGj+HM9m0vmP90lodzM
aCein3yneJVapNo2aONiQp1rVELJTWKqlRt0Wuraa8fUjPKfLydk0mfDfObejMYV
DUBuMWyif51m2EXZV1TisR4P3VzvyF3RNQXX4iKbVj+KOkI6+SLhGzrH/wFL3kE9
bCr5EQa6beRIs7sNCItvd+efFhATqxNZUi8WjDc3reylEKI4FMj+1NMHZYr4Mo7A
jO6KAoAWPUJtHu5v4Cqf2+YTT7zzqndPHZVdkp2PsfNs2ImmDHBCxdDGBfU/WkcA
2dsgnpqUmTeKsYnpwR1rH+/ZFkCGNhHqXRF9JrSYiqzE6K1BzTJo/nHIarEaL/TT
5R0JxP4WErZfBz7Ef7kTkp+hGPovH6Kdu7Fqu08VdgL+BIZomWDYpRmt1IfW5aET
fKUOUK4u84EQkv7Y8ue9RINB4tgodZr2hNXDjQBZVHun4IpNUJDyji136YYe23oe
ngPbwpXzQgJFwOkhzGEgslns1iIxITmc1dl8wuKisajT1XIhflNNOWEG0DlBqKbS
37gjoPxhoDjpIhD9ZgzS
=etRb
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hello everyone.
This is a security announcement for the CentralAuth
extension. There were 2 issues discovered in the
extension, and all users are strongly encouraged to
upgrade.
Issue 1: XSS in Special:GlobalGroupPermissions
Due to a lack of escaping in the
Special:GlobalGroupPermissions page, an attacker
would be able to inject arbitrary javascript into
the page, potentially leading to the take over
of other user's accounts.
The fix for this issue was accidentally included
in another patch - fadb367ad (February 1, 2017).
If you are using the master branch of the
extension, you need to ensure that your
copy is newer than February 1.
All versions of the REL1_29 branch have this
fix.
For REL1_28 please ensure that you have the
commit 1e9d612 (July 19, 2017)
For REL1_27 please ensure that you have the
commit aa3401503 (July 19, 2017)
This issue was discovered by Grunny.
For more information, please see:
https://phabricator.wikimedia.org/T134863
Issue 2: Open redirect in AutoLogin
An attacker can cause a user who is
globally logged in, but not logged in
on a specific wiki, to be redirected
to an arbitrary interwiki link, even
for interwiki prefixes without the
iw_local bit set.
To get the fix for this issue, please
ensure that your copy of CentralAuth
is from at least July 19, 2017
Associated git commits:
* Master: 6a84c0cb4e31
* REL1_29: 2a220af1e4ac
* REL1_28: 4acfa2865a05
(Now requires at least 1.28.1)
* REL1_27: 4db90e20808f
(Now requires at least 1.27.2)
Associated bug:
https://phabricator.wikimedia.org/T134931
Sincerely,
Brian Wolff
Wikimedia Security Team
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCAAGBQJZbudjAAoJEDYflDsVwI3Ux1AQAJXV2pcQicZzApo+WUbqD5aS
5GSEmNlLsS5E16r/tYU2Fhih2qxPJ/iNYCjQI0xZPDWPmi3r8aErEwMs4XS9bfjW
EG/uUsS0DPu9U7BJ+x2h3vOmUFyhyIWHhHMV+6OIAXWyb5Pzm0+oiE8Cw7wx7NId
ZsgTom0T0abXd597mzUomQbGLUPl4gWBbZYqclP9VS8S1xX6ci+UAo0D2hTe9bPN
r0K2C7cmYY0Ltpr2dy9lP3TeEOhsYK3/KQVLZkpTI6h2WZKZSnQKPJzF/qPJEdP8
Zni5zE7heMo+mgXBb6Vcl/+5CDgdxndbdAz9qrgRM51AbF/IfjQAahrs3uc+C7Le
2/zTNkUVxgCyWRrsDVjU8HJHeB/d26fZDNr8cGkXP6BZuTs3bKGG5gCZIVIRmoO8
cMJx0y0vCudDelIFXyE0NssKbKjyUeRZ9djw/kpIQ29CpR211lZuy5tPWB5Tr7/s
9CiwJUPyOjLV6N1icGC3pZfzwxPseJXSY+/J/PwPfwqn/z3IdTiKW9+NfFvp1Tvb
JIPt3ZUN/WbySdGlkTw0fNUo+ILSceDw7cdmRcm08UIV8Ce/xmLhHKF9uinXbAOU
Me0yjKLzHDIZBCCYdZJNPUzRZY+n63Sq0+22Ub4Tv348Pk8kIqtyY+gZuM6l7oMu
SW9yOQQSc5TxNLrPsCUP
=b2xq
-----END PGP SIGNATURE-----
This is now done and deployed in production! Thanks to everyone involved.
Special thanks to Tyler and Chad for their help with the rather
unexpectedly messy deployment.
https://phabricator.wikimedia.org/T171000
The resulting repos can be seen here:
https://github.com/wikimedia/mediawiki-skins-MinervaNeuehttps://github.com/wikimedia/mediawiki-extensions-MobileFrontend
The next step would be to break the MobileFrontend dependency on the
Minerva skin. I've setup an epic
https://phabricator.wikimedia.org/T171000 (subtasks
to be filed as I find them) and would appreciate help doing this if anyone
is looking for a fun side project and interested in improving our skin
ecosystem!
There is a milestone on the MinervaNeue project tracking all open bugs:
https://phabricator.wikimedia.org/project/board/2799/
Your help is welcomed and appreciated!!
On Tue, Jul 4, 2017 at 10:46 AM יגאל חיטרון <khitron(a)post.bgu.ac.il>
wrote:
> Hi. The link [5] is dead.
> IKhitron
>
>
> 2017-07-04 20:45 GMT+03:00 Gergo Tisza <gtisza(a)wikimedia.org>:
>
>> Nice! Thanks for working on this.
>>
>> On Mon, Jul 3, 2017 at 7:03 PM, Jon Robson <jrobson(a)wikimedia.org> wrote:
>>
>> > Dear all
>> > Back in 2014, Legoktm made the sensible suggestion [1] that we should
>> pull
>> > the skin portion of code from the MobileFrontend extension.
>> >
>> > I've spent the last few months making it possible and I now plan to make
>> > this a reality. I now plan to make this change on the 12th&13th July
>> with
>> > Chad (RainbowSprinkles) [2].
>> >
>> > I'm writing to give notice; answer questions and minimise the disruption
>> > that may cause. A while back when Vector was pulled out of MediaWiki
>> core,
>> > there was a little bit of pain so I'm keen to help people avoid this.
>> >
>>
> > *Developers:*
>
>
>> > Please make sure you update vagrant. Vagrant will install the new skin
>> as
>> > part of the MobileFrontend role and provided you do `vagrant git-update`
>> > you will not experience any breakage.
>> >
>> > If you are not using Vagrant, please install the new skin [3] and load
>> it
>> > using wfLoadSkin (after including MobileFrontend extension). When
>> > MobileFrontend stops working thats a sign you need to pull the latest
>> code
>> > from Master.
>> >
>>
> > *3rd parties who are using MobileFrontend in deployed wikis*
>
>
>> > Please be aware of this change when updating MobileFrontend. To be safe
>> > you should install the MinervaNeue skin [3] as part of your deploy
>> process
>> > and keep an eye on compatibility.
>> >
>> > The MinervaNeue skin and MobileFrontend are being kept backwards
>> > compatibility to ensure we do not break anything in Wikimedia's
>> production
>> > cluster, which is detailed in the Phabricator task [4].
>> >
>>
> > *Translators*
>
>
>> > As part of the migration I will be porting over translations to the new
>> > skin from MobileFrontend. There may be some changes to the message keys
>> > during this period of time so please bare this in mind when translating.
>> > The goal is to avoid unnecessary translations!
>> >
>>
> > *Why are you doing this?!!?*
>
>
>> > I've tried to write up this here [5]. Feel free to ask questions on the
>> > talk page there. It's a good conversation to have.
>> >
>>
> > *Can I just use MobileFrontend?*
>
>
>> > Sure. If you just have MobileFrontend it will give you a separate mobile
>> > site and you are free to use whatever skin you want there.
>> > https://www.mediawiki.org/wiki/Extension:MobileFrontend#Setup_a_skin
>> >
>>
> > *Can I just use the Minerva skin and throw away my mobile site?*
>
>
>> > Not quite. But that's the next step that this enables... :) More on that
>> > later.
>> >
>>
> > *Any questions?*
>
>
>> > Feel free to reply to this thread with any concerns or questions you
>> have
>> > or any way I can improve this migration.
>> >
>>
> > *Can I do nothing?*
>
>
>> > If you do not update sure, but if you are updating your instance it's
>> > going to break soon if you do not do anything.
>> >
>> > Let me know if any questions!
>> > Jon
>> >
>> > [1] https://phabricator.wikimedia.org/T71366
>> > [2] https://wikitech.wikimedia.org/wiki/Deployments#Week_of_July_10th
>> > [3] https://github.com/wikimedia/mediawiki-skins-MinervaNeue
>> > [4] https://phabricator.wikimedia.org/T166748
>> > [5] https://www.mediawiki.org/wiki/Reading/Web/
>> > MobileFrontend_and_Minerva#..._but_why_do_we_care_about_
>> > Minerva_as_a_desktop_skin.3F
>> >
>> >
>> > _______________________________________________
>> > Mobile-l mailing list
>> > Mobile-l(a)lists.wikimedia.org
>> > https://lists.wikimedia.org/mailman/listinfo/mobile-l
>> >
>> >
>>
> _______________________________________________
>> Wikitech-l mailing list
>> Wikitech-l(a)lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>
> --
Jon Robson
Senior Software Engineer
We're pleased to announce that the Html2Wiki extension [1] has been updated
to use the new Extension Registration system available since MediaWiki
REL1_25
This simply means that you can wfLoadExtension( 'Html2Wiki' ); in
LocalSettings.php
There are no new features, but the extension should still work in older
environments too because the stub entrypoint was retained for backward
compatibility. Html2Wiki can import vast collections of web content into
your wiki, including images. Or just a single page; e.g. Google Doc.
Contributions welcome.
[1] https://www.mediawiki.org/wiki/Extension:Html2Wiki
Greg Rundlett
https://eQuality-Tech.comhttps://freephile.org/wikireporthttps://QualityBox.us
We use a magic word/template to index one of our books we added to our wiki.
The book is a dictionary of terms, so we organized using letters. For
example, on the article page we've added {{#category_index:D|datum
correction}}. We are currently translating this book in multiple languages
and have started to see the index add multiple links to the same word -
http://wiki.seg.org/wiki/Dictionary:D:Index. In addition, we have one
article that has created multiple links with strange text (one example -
delta
UNIQ003571207dbef6cb-math-00000002-QINU,UNIQ003571207dbef6cb-math-0000000
3-QINU). I have removed all the html from the original article -
http://wiki.seg.org/wiki/Dictionary:Delta - but the index still lists the
links with the strange text.
Does anyone know how to remove the repeating words? What issue(s) might be
happening with the long, coded article? Is there a better way to organize
the articles by letters? Thanks.
Andrew
Andrew Geary | publications outreach editor
+1.918.497.4615 | ageary(a)seg.org
Society of Exploration Geophysicists (SEG)
8801 South Yale Ave, Ste. 500, Tulsa, OK 74137 USA