Heiya,
I would like to understand a bit better how thumbs are generated by MediaWiki with the help of ImageMagick. Basically what I want to achieve is that only 4 thumbs are generated per uploaded file.
I figured that "$wgThumbLimits" [0] is the setting to control this so I set:
$wgThumbLimits = array( 180, 200, 250, 300 );
I assumed that if the user can only select one of the given sizes I would MediaWiki would only generate thumbs in the sizes defined with the setting. What I however got is thumbs in up to 12 sizes ranging from 120px to 2880px depending on the size of the file uploaded. So this setting is not the one and I did not really find a setting allowing me to control thumb generation. I am kinda lost in thumbs now so any hint will be appreciated ...
Cheers Karsten
Other funny sizes probably come from the thumbnails shown on the file page itself. For example, for this random file:
https://commons.wikimedia.org/wiki/File:Bruxelles_%C3%A0_travers_les_%C3%A2g...
The main big thumbnail is 796×600 pixels, and the small thumbnail under "File history" is 120×90.
Additionally, for every thumbnail, thumbnails with 1.5× and 2× sizes are generated to be used on devices with high-resolution screens.
And additionally, you can set an arbitrary size for any thumbnail used in an article, and MediaWiki will dutifully generate a thumbnail of that size.
As far as I know there is currently no option to disallow generation of thumbnails of arbitrary sizes, and limit it to some preset list.
Thanks for your insight which verbosely matches the spartan 300. :)
And additionally, you can set an arbitrary size for any thumbnail
used in an article, and MediaWiki will dutifully generate a thumbnail of that size.
Yeah, this makes sense and is good to know.
As far as I know there is currently no option to disallow generation
of thumbnails of arbitrary sizes, and limit it to some preset list.
Good to know, too.
So the SSD-harddrive-with-not-enough-space-battle may continue. :) I will also try to find a nice place on the wiki to docu the info.
Thanks and cheers Karsten
Am 27.02.2017 um 17:54 schrieb Bartosz Dziewoński:
Other funny sizes probably come from the thumbnails shown on the file page itself. For example, for this random file:
https://commons.wikimedia.org/wiki/File:Bruxelles_%C3%A0_travers_les_%C3%A2g...
The main big thumbnail is 796×600 pixels, and the small thumbnail under "File history" is 120×90.
Additionally, for every thumbnail, thumbnails with 1.5× and 2× sizes are generated to be used on devices with high-resolution screens.
And additionally, you can set an arbitrary size for any thumbnail used in an article, and MediaWiki will dutifully generate a thumbnail of that size.
As far as I know there is currently no option to disallow generation of thumbnails of arbitrary sizes, and limit it to some preset list.
Heiya, it's me again about this. ;)
I found out that the default generation of thumbs is tied to the "$wgImageLimits" AND to the "$wgThumbLimits" configuration setting. If one for example sets the following for a minimum initial creation of thumbs:
$wgImageLimits = array( array( 320, 240 ) ); $wgThumbLimits = array( 320 );
Result: one gets in minimum five thumbs: 120 (default preview size on file pages), 180 (default preview size on "Special:ListFiles") as well as 320 (default size for thumbs), 480 (1.5x of default size for thumbs) and 640 (2x of default size for thumbs)
If one would change the setting for $wgImageLimits another three thumbs would be created. To be frank, thumb generation is indeed not controllable at all.
Cheers Karsten
Am 27.02.2017 um 17:54 schrieb Bartosz Dziewoński:
Other funny sizes probably come from the thumbnails shown on the file page itself. For example, for this random file:
https://commons.wikimedia.org/wiki/File:Bruxelles_%C3%A0_travers_les_%C3%A2g...
The main big thumbnail is 796×600 pixels, and the small thumbnail under "File history" is 120×90.
Additionally, for every thumbnail, thumbnails with 1.5× and 2× sizes are generated to be used on devices with high-resolution screens.
And additionally, you can set an arbitrary size for any thumbnail used in an article, and MediaWiki will dutifully generate a thumbnail of that size.
As far as I know there is currently no option to disallow generation of thumbnails of arbitrary sizes, and limit it to some preset list.
I think only the default value of wgImageLimits would actually do anything for this. The other limits Are only triggered for people with non default preferences.
If you dont care about things looking nice on high dpi displays (e.g. apple retina type things) you could set $wgResponsiveImages
You could disable thumbnailing outright and transfer the full sized image to the browser - $wgUseImageResize
Beyond that you could do something really complicated, like set up 404 thumb handling and then have a cron script use the find command to delete any thumbnails that havent been accessed recently or are non standard size.
Hope that helps. MW thumbnailing really is not optimized for the usecase of low hard disk space. -- bawolff
On Wednesday, March 1, 2017, [[kgh]] mediawiki@kghoffmeyer.de wrote:
Heiya, it's me again about this. ;)
I found out that the default generation of thumbs is tied to the
"$wgImageLimits" AND to the "$wgThumbLimits" configuration setting. If one for example sets the following for a minimum initial creation of thumbs:
$wgImageLimits = array( array( 320, 240 ) ); $wgThumbLimits = array( 320 );
Result: one gets in minimum five thumbs: 120 (default preview size on
file pages), 180 (default preview size on "Special:ListFiles") as well as 320 (default size for thumbs), 480 (1.5x of default size for thumbs) and 640 (2x of default size for thumbs)
If one would change the setting for $wgImageLimits another three thumbs
would be created. To be frank, thumb generation is indeed not controllable at all.
Cheers Karsten
Am 27.02.2017 um 17:54 schrieb Bartosz Dziewoński:
Other funny sizes probably come from the thumbnails shown on the file
page itself. For example, for this random file:
https://commons.wikimedia.org/wiki/File:Bruxelles_%C3%A0_travers_les_%C3%A2g...
The main big thumbnail is 796×600 pixels, and the small thumbnail under
"File history" is 120×90.
Additionally, for every thumbnail, thumbnails with 1.5× and 2× sizes are
generated to be used on devices with high-resolution screens.
And additionally, you can set an arbitrary size for any thumbnail used
in an article, and MediaWiki will dutifully generate a thumbnail of that size.
As far as I know there is currently no option to disallow generation of
thumbnails of arbitrary sizes, and limit it to some preset list.
MediaWiki-l mailing list To unsubscribe, go to: https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Dear Experts,
Could someone recommend the way of converting mediawiki to static website?
We have multiple installations of mediawiki for the needs of various projects. At some point when project ends, mediawiki just holds static unchanged material. It still needs to be there, however the need of maintenance, upgrade, migration to higher version of database backend suggests to convert wikis with static content just to static websites. I'm sure, many people do that, however a search on the web doesn't bring me on right track (which probably is due to my own inability to search well). Any pointers will be great.
Thanks a lot in advance for all your answers.
Valeri
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
You could make the wiki read only using $wgReadOnly. You can even add a nice message indicating that the project has completed, therefore the wiki is now read only.
On Thu, Mar 2, 2017 at 9:41 AM, Valeri Galtsev galtsev@kicp.uchicago.edu wrote:
Dear Experts,
Could someone recommend the way of converting mediawiki to static website?
We have multiple installations of mediawiki for the needs of various projects. At some point when project ends, mediawiki just holds static unchanged material. It still needs to be there, however the need of maintenance, upgrade, migration to higher version of database backend suggests to convert wikis with static content just to static websites. I'm sure, many people do that, however a search on the web doesn't bring me on right track (which probably is due to my own inability to search well). Any pointers will be great.
Thanks a lot in advance for all your answers.
Valeri
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
MediaWiki-l mailing list To unsubscribe, go to: https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
This is a use case worth covering for any CMS, in my opinion. Currently when one doesn't want to maintain a CMS any longer I'm forced to tell them to crawl with wget-warc/wpull (possibly via ArchiveTeam), submit to Internet Archive and then somehow redirect users. Few CMS seem to care about it though.
In practice the only "official" solutions we have are: * https://www.mediawiki.org/wiki/Extension:DumpHTML + any webserver * http://www.kiwix.org/ + kiwix-serve (mwoffliner via Parsoid)
From https://phabricator.wikimedia.org/T17017 and https://phabricator.wikimedia.org/T93396#1136904 , it seems WMF has no interest in providing a static HTML format which is directly usable.
Nemo
The HTML format dumps (not yet ready but soon, I promise!) may not be sufficient for stand-alone use, but a simple wrapper unrelated to MediaWiki ought to be able to serve them up with basic navigation; you'd still have to deal with searches somehow but that's true for any static HTML dump. Or am I misunderstanding folks' needs here?
Ariel
On Fri, Mar 10, 2017 at 10:24 AM, Federico Leva (Nemo) nemowiki@gmail.com wrote:
This is a use case worth covering for any CMS, in my opinion. Currently when one doesn't want to maintain a CMS any longer I'm forced to tell them to crawl with wget-warc/wpull (possibly via ArchiveTeam), submit to Internet Archive and then somehow redirect users. Few CMS seem to care about it though.
In practice the only "official" solutions we have are:
- https://www.mediawiki.org/wiki/Extension:DumpHTML + any webserver
- http://www.kiwix.org/ + kiwix-serve (mwoffliner via Parsoid)
From https://phabricator.wikimedia.org/T17017 and https://phabricator.wikimedia.org/T93396#1136904 , it seems WMF has no interest in providing a static HTML format which is directly usable.
Nemo
MediaWiki-l mailing list To unsubscribe, go to: https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
On Fri, March 10, 2017 3:05 am, Ariel Glenn WMF wrote:
The HTML format dumps (not yet ready but soon, I promise!) may not be sufficient for stand-alone use, but a simple wrapper unrelated to MediaWiki ought to be able to serve them up with basic navigation; you'd still have to deal with searches somehow but that's true for any static HTML dump. Or am I misunderstanding folks' needs here?
Thanks for the efforts. Our case was just to avoid maintaining/upgrading, and migration to later version of postgresql of what originally was set up as mediawiki, but at some point the content stopped being updated, thus wiki can be converted to static site (as whatever information is there still may be needed), allowing to avoid wiki maintenance efforts I mentioned above. Realizing that "you can not have everything" we accepted for ourselves the fact that it will not be searchable, at least not mediawiki way.
We did solve it for ourselves just by following someone's suggestion and using httrack site mirroring utility (luckily available on FreeBSD).
Thanks again, everybody, for all your help!
Valeri
Ariel
On Fri, Mar 10, 2017 at 10:24 AM, Federico Leva (Nemo) nemowiki@gmail.com wrote:
This is a use case worth covering for any CMS, in my opinion. Currently when one doesn't want to maintain a CMS any longer I'm forced to tell them to crawl with wget-warc/wpull (possibly via ArchiveTeam), submit to Internet Archive and then somehow redirect users. Few CMS seem to care about it though.
In practice the only "official" solutions we have are:
- https://www.mediawiki.org/wiki/Extension:DumpHTML + any webserver
- http://www.kiwix.org/ + kiwix-serve (mwoffliner via Parsoid)
From https://phabricator.wikimedia.org/T17017 and https://phabricator.wikimedia.org/T93396#1136904 , it seems WMF has no interest in providing a static HTML format which is directly usable.
Nemo
MediaWiki-l mailing list To unsubscribe, go to: https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
MediaWiki-l mailing list To unsubscribe, go to: https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
Heiya Valeri,
please use as new thread for new questions. Apart from that you may probably want to look into HTTrack [0].
Cheers Karsten
Am 02.03.2017 um 15:41 schrieb Valeri Galtsev:
Dear Experts,
Could someone recommend the way of converting mediawiki to static website?
We have multiple installations of mediawiki for the needs of various projects. At some point when project ends, mediawiki just holds static unchanged material. It still needs to be there, however the need of maintenance, upgrade, migration to higher version of database backend suggests to convert wikis with static content just to static websites. I'm sure, many people do that, however a search on the web doesn't bring me on right track (which probably is due to my own inability to search well). Any pointers will be great.
Thanks a lot in advance for all your answers.
Valeri
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
MediaWiki-l mailing list To unsubscribe, go to: https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Here's a script that converts a wiki to static HTML files:
http://www.connellybarnes.com/code/python/mw2html
http://barnesc.blogspot.ca/2005/10/mw2html-export-mediawiki-to-static.html
It probably would need some customization. The resulting HTML doesn't include a Search box, which your wiki may or may not need.
Tom
On Mar 2, 2017, at 9:47 AM, [[kgh]] mediawiki@kghoffmeyer.de wrote:
Heiya Valeri,
please use as new thread for new questions. Apart from that you may probably want to look into HTTrack [0].
Cheers Karsten
Am 02.03.2017 um 15:41 schrieb Valeri Galtsev:
Dear Experts,
Could someone recommend the way of converting mediawiki to static website?
We have multiple installations of mediawiki for the needs of various projects. At some point when project ends, mediawiki just holds static unchanged material. It still needs to be there, however the need of maintenance, upgrade, migration to higher version of database backend suggests to convert wikis with static content just to static websites. I'm sure, many people do that, however a search on the web doesn't bring me on right track (which probably is due to my own inability to search well). Any pointers will be great.
Thanks a lot in advance for all your answers.
Valeri
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
MediaWiki-l mailing list To unsubscribe, go to: https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
MediaWiki-l mailing list To unsubscribe, go to: https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Wenlin Institute, Inc. SPC (a Social Purpose Corporation) 文林研究所社会目的公司 Software for Learning Chinese E-mail: wenlin@wenlin.com Web: http://www.wenlin.com Telephone: 1-877-4-WENLIN (1-877-493-6546) ☯
mediawiki-l@lists.wikimedia.org