Alex, I have had problems in the past with thumbnails and resized images.
The problem can appear to be intermittent or affect images that in their
compressed form are smaller than images which seem to resize fine. I am
on a shared hosting service that limits the amount of memory I can access.
At least in the versions of MediaWiki that I am familiar with, the 'stock'
code uncompressed JPGs before resizing them - this dramatically increased
the image size. The solution that worked for me was to switch to
ImageMagick (instructions at
http://www.mediawiki.org/wiki/Manual:Installing_third-party_tools). In my
case, I ended up installing ImageMagick myself, only to later find that my
hosting provider already provided a useable (if not the most current)
version.
Regards, Norbert
> After upgrading to 1.14, I found a problem when previewing a page. The
server
> reported this:
> Fatal error: Allowed memory size of 20971520 bytes exhausted (tried to
> allocate 491520 bytes) in /var/www/alex/disperso.net/includes/Exif.php
on
> line 1020
Hi.
After upgrading to 1.14, I found a problem when previewing a page. The server
reported this:
Fatal error: Allowed memory size of 20971520 bytes exhausted (tried to
allocate 491520 bytes) in /var/www/alex/disperso.net/includes/Exif.php on
line 1020
I fixed it changing this line in LocalSettings.php:
# If PHP's memory limit is very low, some operations may fail.
ini_set( 'memory_limit', '30M' );
It was set to 20M first, so I just bumped the number. Is this expected
behaviour, or am I having a problem with my setup?
The page in question is really simple (e.g.
http://disperso.net/index.php?title=Albert&action=edit), and larger pages
without images don't have the problem, so I guess it can be a problem with
the program that MediaWiki is invoking.
However, I have to note one thing: I was trying to change the text in that
page and just the text, so MediaWiki should not invoke any image manipulation
program, because the image should be already scaled and on the cache. Am I
right?
Thanks in advance.
Cheers.
--
Alex
>5. Upload it, using the same File:xxxxx name as the original document
>(assuming you remember it) 6. Panic, when you realize someone else
>uploaded the same document a few minutes before you did, and you just
>wiped out their changes without realizing.
Now, wait just a second here, correct me if I'm wrong, but if the"someone
else" of whom you write did indeed upload the same document a few minutes
before you did, then their changes are not "wiped out" but, are nicely
captured in a previous version of the same file, under the same file name.
Agree, it's not a good solution for heavy traffic, but if you have just a
few users who are mostly downloading... I just recently created a Semantic
MediaWiki installation for a customer who wanted a shared calendar (Semantic
Results Formats) and a Document Repository for a quick set up that would
only last a few months.
I think we did a nice job-- we took the 'upload file' out of the Monobook
skin and added a tool bar to upload documents to certain "portal" pages.
Using Semantic MediaWiki and Semantic Forms, we created forms & templates
that allowed uploads (with filename auto completion from existing filenames)
that tagged the file with the right properties to make the 'Image:' pages
show up on the "portal" pages where the files are listed. I'm feeding the
query results to templates using the collapsable tables css from
en.wikipedia/wiki/MediaWiki:Common.css to create a microsofty folder-type
view that seems to resonate with the users.
Agree, it's not ideal and it's not a CMS. But, I run a wiki farm, not a web
hosting service. All things considered, I'm pretty happy with the result.
I can't do the inverse with a CMS-farm. ...I can't also use it as a wiki.
The magic combination for all the enterprise 2.0 needs seems to be the
combination of MediaWiki and Semantic MediaWiki (+Semantic Forms and
Semantic Results Formats).
I appreciate the links to o3spaces, alfresca, and opencms, tho. Those look
like long-term solutions for customers that need solutions that persist.
-CW
> Date: Sat, 18 Apr 2009 15:07:42 +0200
> From: Platonides <Platonides(a)gmail.com>
>
> Paul Wakfer wrote:
>
>> To satisfy this concern (about the JOIN command - which I really need to
>> do before I start trying to make the necessary coding changes), I would
>> really like to know if there is a mediawiki installation which currently
>> used shared tables on one dd with the other tables of at least one of
>> the wikis using this shared table being on an entirely separate db.
>>
>> --Paul
>>
>
> Mysql allows JOINing tables from different dbs.
>
Thanks a lot. I am quite new to mysql and it was not clear to me, from a
quick read, that this would be so and how it would work.
> The problem I see with your setup is that I don't think you can join
> them if the user is not able to read both tables.
>
At this point I don't see why I cannot put in an extra configuration
setting LocalSettings.php, for a shared db username (say
$wgSharedDBuser) and then change the mediawiki db accessing code to use
it, rather than the wiki's specified db username ($wgDBuser) whenever
the shared tables are accessed. At least, that is what I plan to try.
While I am at it I also plan to create configuration settings
$wgSharedDBserver and $wgSharedDBpassword to make it more complete and
flexible to situations. It would be nice if at some time in the future
this change would become a planned and implemented modification to the
standard mediawiki software to increase its site configuration flexibility.
--Paul Wakfer
Buongiorno,
Il 4/5/2009 10:05:09 AM, Alessandra Bialrdi vi ha chiesto di fare parte della sua rubrica Unyk per avere un accesso costante alle vostre coordinate e perché voi possiate fare altrettanto con quelle della Unyk.
Per accettare, cliccate qui.
http://www.unyk.com/ml/69/5/?i=3343304455fb40b890de5f7d639eddcd
Unyk è un sistema semplice ed intelligente per gestire i vostri contatti senza perderli mai.
Non dovete più preoccuparvi delle coordinate dei vostri contatti. Adesso, sono direttamente i contatti che le gestiscono per voi. Se modificano le loro coordinate nella Unyk.com, la vostra rubrica è aggiornata automaticamente. E viceversa, cioè se voi modificate le vostre coordinate nella Unyk.com, la loro rubrica Unyk sarà aggiornata.
È veramente semplice e gratuito... già 10 milioni di utenti vi aderiscono.
Se non desiderate più ricevere alcun invito all?utilizzo di UNYK da parte dei vostri contatti, cliccate qui!
http://www.unyk.com/ml/69/6/unsubscribe.asp?i=3343304455fb40b890de5f7d639ed…
UNYK, la prima rubrica intelligente che si aggiorna da sola!
On Thu, 16 Apr 2009 00:50:46 +0200, Platonides wrote:
> I don't really know about this, but perhaps you can do a GRANT ALL/GRANT
> SELECT as Bar to user Foo for Bar's db? Although as GRANT OPTION is not
> included by GRANT ALL it might not be available, but it's worth trying.
>
Thanks for replying. However, I did already try various mysql commands
to circumvent my shared host's limitations on my db names and usernames,
including GRANT. It appears that they have made the mysql installation
options such that shared host users do not have any permission to use
the GRANT command at all. Other than changing the user passwords (only
through a host supplied interface, not by use of mysql itself) all that
I am given when the db is created are three usernames: xxx, xxx_w and
xxx_r (where xxx is my account username with the host) with separate
passwords for each, which enable respectively create, delete, change,
write tables; just writing and reading; or merely reading. Everything
works fine with any one wiki and I have already easily successfully
exported and imported individual tables.
At the moment I see no solution but to change the code so that the
username (at least) is also changed to the common one whenever the
shared tables are accessed. While I am doing this I figure I might as
well make the change to also enable a different db host (the common one)
to also be used. However, my biggest concern at this point is that I do
not see how the JOIN mysql command can work if the tables are not in a
common db (which appears to be allowed by the mediawiki LocalSettings
parameters) unless perhaps the tables that one would normal want to
share (mainly "user" and "usergroups" are never used with a JOIN command
(something that is not at all clear from the mediawiki code).
To satisfy this concern (about the JOIN command - which I really need to
do before I start trying to make the necessary coding changes), I would
really like to know if there is a mediawiki installation which currently
used shared tables on one dd with the other tables of at least one of
the wikis using this shared table being on an entirely separate db.
--Paul
The names for namespaces of MediaWiki have been only partially translated into Japanese. To be concrete, Media, Special, File, Image, and Talks have been translated respectively as メディア, 特別, ファイル, 画像, and ノート or 会話 (see below), but MediaWiki, Template, Help, and Category remain in English
In addition, the Japanese translations given to the talk namespaces have been rather unpopular mainly for using a hyphen in the middle, which is not necessarily easy to type when using Japanese inputting systems, and also confusing for there are many similar characters (-, ―, ー, etc.).
Another rather controversial point is that, while most of the talk namespaces were translated as ノート (note, or rather notebook) by the early Japanese Wikipedia users, the translation of the User talk namespace remained 利用者‐会話 (User-talk, or User-conversation). Some think that we should keep a different translation for the user talk namespace, while others think the talk namespaces should all have the same translation.
There are also people who think "note" is not a very good choice, though it has been difficult to find an alternative that many can agree with.
These points have been repeatedly brought up, but never reached consensus, not least due to objection that such change will cause enormous amount of dead links.
Yet, since it has been recently made possible to set an alias for a namespace, and therefore possible to change the translation of the names of namespaces without breaking existing links, it seems to me, that finally we have a chance to settle them. (We are on the presumption that once we reach a consensus, the developers will kindly make the necessary amendments.)
Consequently, thanks to user aokomoriuta, some of the MediaWiki users using Japanese as a main language have recently started a discussion on these topics.
We understand that these changes may cause some confusion among wikis using Japanese as their site language, and also that the number of such changes should be as small as possible.
Therefore I would like to invite those who are interested in to the ongoing discussion at http://translatewiki.net/wiki/Portal_talk:Ja .
Since this is a discussion related to Japanese translation, the discussion is made in Japanese, but we appreciate suggestions from non-Japanese speakers as well.
We also appreciate if you can spread this notification to admins of MediaWiki wiki using Japanese as the site language.
Thank you for your cooperation.
Aotake
(http://translatewiki.net/wiki/User:Aotake )
Below, I repeat the same content in Japanese.
現在、MediaWiki の名前空間名は部分的にのみ日本語化されています。具体的にはMedia, Special, File, Image, および各Talk 名前空間は、それぞれメディア、特別、ファイル、画像、およびノートまたは会話（下記参照）と訳されていますが、MediaWiki, Template, Help, および Category は英語表記のままとなっています。
加えて、talk 名前空間の日本語訳は以前から使いにくいという声があります。これは主に区切りとしてハイフンを使用しているためで、日本語入力システムでは打ち込みにくい場合があったり、‐、―、ー など類似の記号が多く、混乱しやすくなっています。
更に、これは意見の分かれる点ですが、日本語版ウィキペディアの初期の利用者たちによって、大部分の talk 名前空間は「ノート」と訳されましたが、User talk だけは「利用者-会話」と訳されていることがあります。これについて、利用者名前空間はこのまま別の訳をあてておくほうがよいと考える方もいらっしゃれば、talk 名前空間の訳は統一されている方がよいと考える方もいらっしゃいます。
そして「ノート」という訳そのものがふさわしくないというご意見の方もいらっしゃいますが、これについてはいまのところ決定打となる代替案は提出されていない状況です。
上記の各点は、繰り返し指摘されてきたことですが、いままでは、名前空間名の変更は膨大なリンク切れを生むということもあり、変更の合意に至ることはありませんでした。
しかし、最近になって、名前空間にエイリアスを設定することが可能となり、リンク切れを起こさずに名前空間名の翻訳を変更することが可能となりました。したがって、今ならば、この問題に決着をつけることが可能だと思われます（もちろん、合意に至った場合には開発者が必要な変更を行ってくれるであろうという前提にたってのことですが）。
このような状況の中で、青子守歌 (aokomoriuta) さんの発議があり、現在、日本語話者のMediaWiki利用者の一部でこれらの点についての議論が行われています。
名前空間名の変更はサイト言語に日本語を使用していらっしゃるウィキに影響を与えると予想されますし、また変更の回数は最小限にとどめられるべきです。
そこで、この問題に関心のある方々に広く議論への参加をお願いいたします。議論場所は http://translatewiki.net/wiki/Portal_talk:Ja です。
日本語化に関連する話題であるため、議論は日本語で行っています。
また、もし日本語をサイト言語としているMediaWikiウィキをご存知でしたら、この議論について広くお知らせいただければ幸いです。
ご協力ありがとうございます。
Aotake
(http://translatewiki.net/wiki/User:Aotake )
--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/
Hi,
I want to restore a Mediawiki 1.13 database to a Mediawiki 1.14
database.
Is this possible?
If not, what are quick steps to realize this?
Peter Verhoeven
This message and attachment(s) are intended solely for use by the addressee and may contain information that is privileged, confidential or otherwise exempt from disclosure under applicable law.
If you are not the intended recipient or agent thereof responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited.
If you have received this communication in error, please notify the sender immediately by telephone and with a 'reply' message.
Thank you for your co-operation.
Hey,
I run a members-only forum. I'm in the process of adding a Wiki to the
site, and I'd like to restrict the wiki to only members logged into
the forum. Would there be any problems to adding session_start() to
the top of the wiki's index.php (as well as some checks to validate
the session cookie from the forum)?
What would be the best way to restrict this? I don't want non-members
to be able to view, edit, or register an account on the wiki at all,
so I don't see how I would be able to do this using the Wiki settings.
Thanks for all suggestions.
Dear all,
A friend of mine, working on a lawyer firm, asked me if MediaWiki is
suitable for knowledge management. I instantly said YES :)
He then asked me if there's any sample of MW implementation for a lot
of document (doc, xls, etc) uploads/repository. So, could anyone help
me to answer his question? Is there any sample for this kind of
requirement?
Thanks,
--
Ivan Lanin