MediaWiki-l October 2005

mediawiki-l@lists.wikimedia.org

169 participants
229 discussions

Re: 1.5.0 mime_magic crash
by Daniel Kinzler 01 Nov '05

01 Nov '05

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

3 3

Using mediawiki 1.4.11-1, can't get main URL to change.
by Norman Yamada 31 Oct '05

31 Oct '05

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. ######################################################################

1 0

RE: [Mediawiki-l] Category caching & "new messages" problems
by Ben Arnold (DSLWN) 31 Oct '05

31 Oct '05

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=3424 http://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

1 0

RE: [Mediawiki-l] Category caching & "new messages" problems
by Ben Arnold (DSLWN) 30 Oct '05

30 Oct '05

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

1 0

minor LDAP problems
by Haan, Jan de 30 Oct '05

30 Oct '05

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.

1 0

RE: [Mediawiki-l] Category links still not being regenerated
by Ben Arnold (DSLWN) 30 Oct '05

30 Oct '05

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

3 2

Announcing Electowidget 0.1.0: a plugin for MediaWiki
by Rob Lanphier 30 Oct '05

30 Oct '05

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

1 0

translate tags
by Cristian (argentina) 30 Oct '05

30 Oct '05

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

3 3

Sysop - Bureaucrats and other rascals
by Mike Thomas 29 Oct '05

29 Oct '05

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

2 3

WikiFeeds - An Alternative Feed Generator for MediaWiki
by Gregory Szorc 29 Oct '05

29 Oct '05

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

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

MediaWiki-l October 2005