Hi all
François wrote:
....
> Fatal error: mime_magic could not be initialized, magic file (null) is
> not avaliable in C:\apache2\htdocs\mediawiki15\includes\MimeMagic.php on
> line 476
This is a PHP issue - mime_content_type seems to be buggy under windows.
Possible solutions:
1) See http://www.php.net/manual/en/function.mime-content-type.php,
about half way down the page:
The function mime_content_type only worked for me on Microsoft Windows
after I added the directive "mime_magic.debug" to my php.ini with the
value of "On". The default value appears to be "Off". Exampe:
[mime_magic]
mime_magic.debug = On
mime_magic.magicfile = "c:\php\extras\magic.mime"
2) Install PHP with the fileinfo extension enabled (see
http://pecl.php.net/package/fileinfo). MediaWiki will use it instead of
mime_content_type, if it's available. Note that this probably also uses
a mime.magic file somewhere, somehow...
If (and only if!) you install fileinfo as a shared library, also set
$wgLoadFileinfoExtension= true; in LocalSettings.php.
3) Use an external program for mime detection by setting
$wgMimeDetectorCommand (in LocalSettings.php) to a command that will
return the mime type of a file. Under linux, "file -bi" works fine, but
that is not available under windows without a little fiddling. You might
get it to work via cygwin.
I hope this helps - please give feedback which solution works for you,
so other people running 1.5 under windows have an idea how to solve this
problem.
Thanks for giving feedback!
-- Duesentrieb
Using Mediawiki 1.411-1 (Debian testing) on a small intranet.
We had the wiki on a machine called tmccs2. The $wgScriptPath setting
in LocalSettings.php was "/techwiki".
We've moved the wiki to another machine called appstage1. I've left
the LocalSettings.php alone.
Now, whenever we try to open the wiki from appstage1, e.g., using
"http://appstage1/techwiki/" the url is rewritten as "tmccs2/techwiki/
index.php" immediately.
If I correct the url by hand, I can open up pages -- but I can't edit
them; the redirect after the edit always references tmccs2.
I've tried running rebuildall in /maintenance; I've cleared out my
object cache, I've reset $wgGlobalCache (as per this thread http://
mail.wikipedia.org/pipermail/mediawiki-l/2005-July/006108.html), all
to no avail.
How do I fix the pages themselves so that they don't refer to the old
server. I could rename the server for this, but it seems a bit
ridiculous.
Any help would be greatly appreciated.
######################################################################
This e-mail is confidential and should not be redistributed or
forwarded by the recipient. The information contained in this e-mail
message is intended only for the use of the individual or entity named
above. If the reader of this message is not the intended recipient or
you have received this communication in error, please immediately
notify us by telephone. Receipt by anyone other than the intended
recipient is not a waiver of any work-product or, if applicable,
attorney-client privilege.
This e-mail does not constitute an offering of any security. Such an
offering may only be made by means of a private placement memorandum
or other disclosure document. Nothing in this e-mail constitutes
investment advice. Past performance is not indicative of future
results. All e-mail to and from Millburn Ridgefield Corporation and
its affiliates is monitored, stored and made available to regulators
if requested.
######################################################################
In case anyone's following this thread, the conclusion was that both
problems are already in Bugzilla as known defects:
http://bugzilla.wikimedia.org/show_bug.cgi?id=3424http://bugzilla.wikimedia.org/show_bug.cgi?id=3805
Ben
-----Original Message-----
From: mediawiki-l-bounces(a)Wikimedia.org
[mailto:mediawiki-l-bounces@Wikimedia.org] On Behalf Of Ben Arnold
(DSLWN)
Sent: Tuesday, 25 October 2005 4:38 p.m.
To: mediawiki-l(a)Wikimedia.org
Subject: [Mediawiki-l] Category caching & "new messages" problems
I am running MediaWiki 1.5beta4 on the Saint WAMP 3.3.4 and I have two
problems. It's possible that both problems have the same root cause. Any
help would be much appreciated!
Problem 1: Category caching
The first problem I have involves the server-side caching of categories
at the bottom of an article page. If I edit an article and give it a
brand-new category, then save the article, the category name is
displayed in red (because the category doesn't yet exist). This is what
I expect. So I click on the category name to bring up the edit page,
enter some text and save the category.
When I return to the original article the category name still appears in
red and still uses "action=edit". I want the category name to be blue
and to link to the article without editing it.
Additional information:
- If I control-refresh my browser the category still appears in red with
action=edit
- If a user who's never been to the article browses the article the
category still appears in red with action=edit
- If I view the article through a redirect the category appears in blue
- If I add new articles to the category, they appear in blue
- If I add action=purge, this fixes the problem --- but since the
problem occurs every time I create a category, this is not a solution!
- I have made some manual changes to LocalSettings.php and httpd.conf
(see below)
Problem 2: "New messages"
If a user leaves a message for another user on their talk page they get
a "new messages" banner. This banner never disappears.
I searched around on the web a while and found a solution: get the user
to watch and unwatch their talk page. Again, this solves the immediate
problem but isn't a permanent solution.
Customisation
I have made a few manual changes to my LocalSettings.php:
# Must be logged in to edit
$wgGroupPermissions['*']['edit'] = false;
# Must be a Sysop to create accounts
$wgGroupPermissions['*']['createaccount'] = false;
# Enables uploading of all file types
$wgStrictFileExtensions = false;
$wgCheckFileExtensions = false;
$wgEnableUploads = true;
# Short article paths
$wgArticlePath = "/w/$1";
# Timezone NZDT
$wgLocalTZoffset = 13;
And two changes to httpd.conf:
Alias /w /web/root/wiki/index.php
LoadModule rewrite_module modules/mod_rewrite.so
Thanks for your help,
Ben Arnold
_______________________________________________
MediaWiki-l mailing list
MediaWiki-l(a)Wikimedia.org
http://mail.wikipedia.org/mailman/listinfo/mediawiki-l
Nope, not using templates on the category or the article. But Brion
Vibber has pointed me to a bug report about this (3424) so I'll wait to
see how that turns out.
-----Original Message-----
From: mediawiki-l-bounces(a)Wikimedia.org
[mailto:mediawiki-l-bounces@Wikimedia.org] On Behalf Of MHart
Sent: Saturday, 29 October 2005 6:36 a.m.
To: MediaWiki announcements and site admin list
Subject: Re: [Mediawiki-l] Category caching & "new messages" problems
Are you using templates on that page? We had a similar problem with
TaxAlmanac, and it turned out to be a problem in our template code that
wasn't particularly "visible", but resulted in and Edit link to a page
with content. We had main article pages with a stub and a discussion
page with lots of text, but the discussion link from the main article
was a red "edit"
link.
So it is, sort of a bug in MediaWiki, but the cause is a user error in
the template code.
- MHart
----- Original Message -----
From: "Ben Arnold (DSLWN)" <BenA(a)datacom.co.nz>
To: <mediawiki-l(a)Wikimedia.org>
Sent: Monday, October 24, 2005 11:38 PM
Subject: [Mediawiki-l] Category caching & "new messages" problems
I am running MediaWiki 1.5beta4 on the Saint WAMP 3.3.4 and I have two
problems. It's possible that both problems have the same root cause. Any
help would be much appreciated!
Problem 1: Category caching
The first problem I have involves the server-side caching of categories
at the bottom of an article page. If I edit an article and give it a
brand-new category, then save the article, the category name is
displayed in red (because the category doesn't yet exist). This is what
I expect. So I click on the category name to bring up the edit page,
enter some text and save the category.
When I return to the original article the category name still appears in
red and still uses "action=edit". I want the category name to be blue
and to link to the article without editing it.
Additional information:
- If I control-refresh my browser the category still appears in red with
action=edit
- If a user who's never been to the article browses the article the
category still appears in red with action=edit
- If I view the article through a redirect the category appears in blue
- If I add new articles to the category, they appear in blue
- If I add action=purge, this fixes the problem --- but since the
problem occurs every time I create a category, this is not a solution!
- I have made some manual changes to LocalSettings.php and httpd.conf
(see below)
Problem 2: "New messages"
If a user leaves a message for another user on their talk page they get
a "new messages" banner. This banner never disappears.
I searched around on the web a while and found a solution: get the user
to watch and unwatch their talk page. Again, this solves the immediate
problem but isn't a permanent solution.
Customisation
I have made a few manual changes to my LocalSettings.php:
# Must be logged in to edit
$wgGroupPermissions['*']['edit'] = false;
# Must be a Sysop to create accounts
$wgGroupPermissions['*']['createaccount'] = false;
# Enables uploading of all file types
$wgStrictFileExtensions = false;
$wgCheckFileExtensions = false;
$wgEnableUploads = true;
# Short article paths
$wgArticlePath = "/w/$1";
# Timezone NZDT
$wgLocalTZoffset = 13;
And two changes to httpd.conf:
Alias /w /web/root/wiki/index.php
LoadModule rewrite_module modules/mod_rewrite.so
Thanks for your help,
Ben Arnold
_______________________________________________
MediaWiki-l mailing list
MediaWiki-l(a)Wikimedia.org
http://mail.wikipedia.org/mailman/listinfo/mediawiki-l
_______________________________________________
MediaWiki-l mailing list
MediaWiki-l(a)Wikimedia.org
http://mail.wikipedia.org/mailman/listinfo/mediawiki-l
Hi All,
after some more experimenting I finally got LdapAuthentication.php
working, although with some adjustments: I only could get wgLDAPWriterDN
to work with "cn=priviledged user,dc=example...", it didn't work with
"uid=priviledged user,dc=example..." as stated in the example at
http://meta.wikimedia.org/wiki/LDAP#Summary_of_Extension Same for
wgLDAPWriterPassword: was not able to get it to work with "{SSHA}abcdef..."
or "{crypt}ghijkl..." only with "clearpassword".
Are this known problems or could this be a problem with my LDAP?
Sincerely,
Jan.
environment :
Debian GNU/Linux 3.1 Sarge,
LdapAuthentication.php Version 1.0a / 07.10.2005,
MediaWiki: 1.5.0,
PHP: 4.3.10-16 (apache2handler),
MySQL: 4.0.24_Debian-10sarge1-log,
slapd 2.2.23-8
----
This message is confidential and may be privileged. Any review, retransmission, dissemination or other use of, or taking any action with reference to this information by persons other than the intended recipient is prohibited. If you received this message in error, please notify the sender by reply e-mail and delete this message from all computers. Please note that e-mails are susceptible to change. The sender will not accept liability for the improper or incomplete transmission of the information contained in this message.
I'm trying to get this straight in my head. I couldn't find anything
about it in the MediaWiki handbook, so I'll update it once I get a
clearer picture.
I think what you're saying is that it's normal to have to purge after
making certain kinds of changes -- unless you're using the sophisticated
caching that the Wikimedia servers use.
In other words it's a known "feature" and not something I've done wrong
in my configuration.
Or are you saying that I've got my configuration in some messy half-way
stage where it thinks it's got sophisticated caching but it hasn't...
and that's why I'm having caching issues.
How should I solve the problem? Can I turn off caching? Or is it a
matter of teaching the users how to manually purge the cache after
certain kinds of changes?
Sorry for all the questions, but thanks for the answers. I'll make sure
it gets in the handbook!
Ben
-----Original Message-----
From: mediawiki-l-bounces(a)Wikimedia.org
[mailto:mediawiki-l-bounces@Wikimedia.org] On Behalf Of Rob Church
Sent: Friday, 28 October 2005 4:48 a.m.
To: MediaWiki announcements and site admin list
Subject: Re: [Mediawiki-l] Category links still not being regenerated
This is down to caching. Wikimedia web sites use a weird and wonderful
caching system, but your local machine or server likely doesn't. The
action=purge part causes the cache to be cleared for that particular
page. Try also a hard-refresh.
Incidentally, Wikimedia web sites all run 1.6-cvs, which is
pre-pre-pre-alpha. When the development team works for you, you can
afford to live dangerously. :-)
Rob Church
On 27/10/05, Ben Arnold (DSLWN) <BenA(a)datacom.co.nz> wrote:
> Hi, does anyone have some suggestions to offer? I'm quite stuck with
> this!
>
> I have succesfully upgraded to MediaWiki 1.5.1 on the off-chance that
> it was a bug that has been fixed in the latest version. No luck. I'm
> still having the problem. I notice that it doesn't happen at
> en.wikipedia which is at 1.6alpha.
>
> To summarise:
> - add a new category link to an article (e.g. [[Category:New
> category]]) & save
> - category appears in red (because it's a link to an edit page)
> - follow the link & save a description of the category
> - go back to the original article
> - link still appears in red and you have to use action=purge to fix it
>
> I'm now using MediaWiki 1.5.1, PHP 4.3.8, MySQL 4.0.20a-debug.
>
> Anyone else had this problem? Something like this? Know how to work
> around it?
>
> Thanks in advance,
>
>
> Ben
>
> _______________________________________________
> MediaWiki-l mailing list
> MediaWiki-l(a)Wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/mediawiki-l
>
_______________________________________________
MediaWiki-l mailing list
MediaWiki-l(a)Wikimedia.org
http://mail.wikipedia.org/mailman/listinfo/mediawiki-l
Hi all,
I'm proud to announce the first release of Electowidget (v0.1.0), a
plugin for MediaWiki:
http://electorama.com/electowidget
Electowidget is designed to be an extremely flexible framework for
implementing many different web-based ballot designs, election tallying
methods, and output formats, including Approval, Copeland, Definite
Majority Choice, Instant Runoff, Minmax (margins and wv), Plurality,
Range, Schulze (margins, wv and wv-mod [Debian]), and Smith set, and
allows chaining these together.
You can see Electowidget in action by looking at the examples listed
here:
http://wiki.electorama.com/wiki/Electowidget
Electowidget is useful for both conducting online polls, and for
documenting and comparing sample sets of ballots.
My implementation strategy may not have been the best, and is something
I'm willing to change around. In particular, it requires a small patch
to MediaWiki 1.5.1, because I'm overriding a couple of key classes in
MediaWiki (Article and EditPage), and I needed a way of hooking the
instantiation of those classes. Since I overrode those classes, that
means that any changes to the function calls in these classes affects
compatibility with Electowidget.
For MediaWiki 1.6 (or 2.0 or whatever), I plan to rewrite the glue layer
between MediaWiki and Electowidget, hopefully with some guidance from
people on this list. I'd like to make sure that Electowidget plugs in
cleanly into the next version of MediaWiki (no patch). If I'm really
lucky, it'll even plug into 1.5.2, but I'm not counting on that.
The biggest problem that I need to address is performance. In
particular, nothing gets cached right now. That means every reload
results in a retallying of a possibly really complicated election. This
is bad. I know this. ;-) That's one of the biggest reasons for
rewriting the glue layer.
Anyway, if you have some time, please mess around with it and let me
know what you think.
Thanks
Rob
hi
I've mediawiki 1.5
I translate some tags to spanich and it always appear in English.
I try to force with rebuildMessages.php but nothing :(
For example "Edit" dont changes
Any ideas?
Tks a lot
Cris
______________________________________________
Renovamos el Correo Yahoo!
Nuevos servicios, m�s seguridad
http://correo.yahoo.es
I've set up two different wiki's and evidently am not the bureaucrat of either.
When installing the wiki I changed the Sysop name to a my user name--assuming
I'd have Sysop and Bureaucrat status. Does that mean I'm logging in as the
bureaucrat and simply don't know it? How does one know if they have bureaucrat
or sysop status?
Which file would I look in to see how the bureaucrat was setup?
MikeT
I just wrote an alternative syndicated feed generator for MediaWiki,
tentatively named WikiFeeds.
With WikiFeeds, you can view the following feeds:
*User watchlist (finally)
*New pages
*Recent page changes
*Newest articles by user
*Recent page changes by user
*Recent page changes in a category
The script has ATOM 1.0 and RSS2.0 output, although other outputs are
trivial to make. I designed this script primarily for ATOM 1.0, so the
RSS2.0 mode isn't as mature, but whatever.
The code is located at
http://opensource.case.edu/svn/MediaWikiHacks/plugins/WikiFeeds/trunk/
I've also included a parser extension hook that allows you to embed
links to feeds made by this script in pages. For example, a category
page will link to the recent category changes feed and a user page will
link to the recent user changes feed, etc.
This script could consume a large amount of resources, so if you want to
deploy this on a heavy-use site, I recommend integrating it with the
MediaWiki cache or with PEAR::Cache.
If you find any bugs with the software (I'm sure the SQL queries could
use some fine-tuning), please post them at
http://opensource.case.edu/projects/MediaWikiHacks/ .
Happy Syndicating,
Gregory Szorc
gregory.szorc(a)case.edu