headers
Tim Starling | 1 Sep 2008 16:25
Picon

MySQL user variables (was Re: [MediaWiki-CVS] SVN: [40279] trunk/phase3)

aaron@... wrote:
> Added: trunk/phase3/maintenance/archives/patch-ss_active_users.sql
> ===================================================================
> --- trunk/phase3/maintenance/archives/patch-ss_active_users.sql	                        (rev 0)
> +++ trunk/phase3/maintenance/archives/patch-ss_active_users.sql	2008-08-31 19:29:37 UTC (rev 40279)
>  <at>  <at>  -0,0 +1,6  <at>  <at> 
> +-- More statistics, for version 1.14
> +
> +ALTER TABLE /*$wgDBprefix*/site_stats ADD ss_active_users bigint default '-1';
> +SELECT  <at> activeusers := COUNT( DISTINCT rc_user_text ) FROM /*$wgDBprefix*/recentchanges 
> +WHERE rc_user != 0 AND rc_bot = 0 AND rc_log_type != 'newusers';
> +UPDATE /*$wgDBprefix*/site_stats SET ss_active_users= <at> activeusers;
>   

User variables are not replication-safe, and should be avoided. It's
better to use a custom function in updaters.inc, and a schema-only
patch. Yes, I know I used a user variable too, back in 2006 for
ss_images, but I was young and naive.

-- Tim Starling
Permalink | Reply | 0 comments |
headers
Mark Reginald James | 1 Sep 2008 19:18
Picon
Gravatar

Anyone interested in developing a point-counterpoint mode?

Hi,

Media Wiki is a great democratic tool, allowing anyone to
easily create beautiful content. But it has the potential to
also become an important tool *for* a democracy, by allowing
complex disputed cases to be closely argued and clearly
explained.

To best support this, it would appear that a new mode needs to
be added to Media Wiki that displays a pair of hierarchically-
expandable wiki streams side-by-side.

An example of what I'm suggesting can be seen at makethecase.net,
a site I created over five years ago using a now obsolete
system (and some rather primitive HTML skills). Though I'm now
a proficient Ruby on Rails programmer, I think it would be
better to create an updated system using Media Wiki, the premier
modern CMS. However I don't know much about PHP, so am looking
for anyone who would like to work alone, with me, or with others,
to make this a reality.

To this end, I've created a bug report for this enhancement:
   https://bugzilla.wikimedia.org/show_bug.cgi?id=15423

I really think this would be a useful tool that would complement
Wikipedia, as I argued here: http://makethecase.net/why.html .

Regards,

Mark
(Continue reading)

Permalink | Reply | 10 comments |
headers
Daniel Friesen | 1 Sep 2008 19:53

Re: Anyone interested in developing a point-counterpoint mode?

You do have an interesting idea. However, it's not something that would 
work as a built in to MediaWiki.
MediaWiki internally has a hardwired one title, to one active revison, 
which contains one blob of text.

Though I do often get involved in alternative editing ideas. Typically 
this kind of thing is either done by creating a special interface (or 
altering the normal interface) to merge multiple pages together. Or 
using some syntax inside the page to break up the content.

What kind of features would the proposal offer.
Listing out the small features normally helps pick out the best method 
of implementation.

Firstly, should each point have an area where it can be discussed?
Should that be limited to a case point/rebutal pair?
Or should there only be one discussion for an entire full case?

~Daniel Friesen(Dantman, Nadir-Seen-Fire) of:
-The Nadir-Point Group (http://nadir-point.com)
--It's Wiki-Tools subgroup (http://wiki-tools.com)
--The ElectronicMe project (http://electronic-me.org)
--Games-G.P.S. (http://ggps.org)
-And Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG)
--Animepedia (http://anime.wikia.com)
--Narutopedia (http://naruto.wikia.com)

Mark Reginald James wrote:
> Hi,
>
(Continue reading)

Permalink | Reply | 9 comments |
headers
Mark Reginald James | 2 Sep 2008 11:38
Picon
Gravatar

Re: Anyone interested in developing a point-counterpoint mode?

Daniel Friesen wrote:
> You do have an interesting idea. However, it's not something that would 
> work as a built in to MediaWiki.
> MediaWiki internally has a hardwired one title, to one active revison, 
> which contains one blob of text.

Daniel, I'd assumed that some new core support would be required.
But my bug has now been re-classified as an extension request, so
perhaps it can instead be accommodated as an extension.

The concept may indeed be compatible with one title, one revision,
and one text. The only thing that may not be supported is the ability
to have separate permissions for changing the pro and con texts
on pages that are not freely editable. Perhaps this does in fact
require separate revisions, meaning that a single point-counterpoint
page would actually require the fusion of two wiki pages.

> Though I do often get involved in alternative editing ideas. Typically 
> this kind of thing is either done by creating a special interface (or 
> altering the normal interface) to merge multiple pages together. Or 
> using some syntax inside the page to break up the content.
> 
> What kind of features would the proposal offer.
> Listing out the small features normally helps pick out the best method 
> of implementation.
> 
> Firstly, should each point have an area where it can be discussed?
> Should that be limited to a case point/rebutal pair?
> Or should there only be one discussion for an entire full case?
(Continue reading)

Permalink | Reply | 8 comments |
headers
Daniel Friesen | 2 Sep 2008 12:40

Re: Anyone interested in developing a point-counterpoint mode?

Mark Reginald James wrote:
> Daniel Friesen wrote:
>   
>> You do have an interesting idea. However, it's not something that would 
>> work as a built in to MediaWiki.
>> MediaWiki internally has a hardwired one title, to one active revison, 
>> which contains one blob of text.
>>     
>
> Daniel, I'd assumed that some new core support would be required.
> But my bug has now been re-classified as an extension request, so
> perhaps it can instead be accommodated as an extension.
>
> The concept may indeed be compatible with one title, one revision,
> and one text. The only thing that may not be supported is the ability
> to have separate permissions for changing the pro and con texts
> on pages that are not freely editable. Perhaps this does in fact
> require separate revisions, meaning that a single point-counterpoint
> page would actually require the fusion of two wiki pages.
>   
MediaWiki is meant to be completely open, and so it really doesn't 
support per-page permissions for different groups. So the permissions 
part doesn't matter to much.
>> Though I do often get involved in alternative editing ideas. Typically 
>> this kind of thing is either done by creating a special interface (or 
>> altering the normal interface) to merge multiple pages together. Or 
>> using some syntax inside the page to break up the content.
>>
>> What kind of features would the proposal offer.
>> Listing out the small features normally helps pick out the best method
(Continue reading)

Permalink | Reply | 7 comments |
headers
Roan Kattouw | 2 Sep 2008 14:12
Picon
Favicon

Re: Anyone interested in developing a point-counterpoint mode?

Daniel Friesen schreef:
> Mark Reginald James wrote:
>   
>> Daniel Friesen wrote:
>>   
>>     
>>> You do have an interesting idea. However, it's not something that would 
>>> work as a built in to MediaWiki.
>>> MediaWiki internally has a hardwired one title, to one active revison, 
>>> which contains one blob of text.
>>>     
>>>       
>> Daniel, I'd assumed that some new core support would be required.
>> But my bug has now been re-classified as an extension request, so
>> perhaps it can instead be accommodated as an extension.
>>
>> The concept may indeed be compatible with one title, one revision,
>> and one text. The only thing that may not be supported is the ability
>> to have separate permissions for changing the pro and con texts
>> on pages that are not freely editable. Perhaps this does in fact
>> require separate revisions, meaning that a single point-counterpoint
>> page would actually require the fusion of two wiki pages.
>>   
>>     
> MediaWiki is meant to be completely open, and so it really doesn't 
> support per-page permissions for different groups. So the permissions 
> part doesn't matter to much.
>   
We do have per-page edit restrictions, though. Traditionally, you'd 
solve this by creating two pages (one with pros, one with cons), which
(Continue reading)

Permalink | Reply | 6 comments |
headers
Filipe Brandenburger | 2 Sep 2008 17:22

Extension to render Dia as a PNG

Hello,

I need an extension to render Dia files as PNGs. I was using this one:
http://www.mediawiki.org/wiki/Extension:Dia

However I saw many problems with it, one of them being the wrong way to
calculate the size of the image.

I tried to fix it, but I did not find a good way to do it.

The extension creates a new class that extends ImageHandler. In
"doTransform" it calls the "dia" binary with special arguments to
convert a .dia file to a .png file. Nothing wrong there.

The problem is that it implements a "getImageSize" method where it
implements a method that reads the XML file to try to "guess" the size
of the image that "dia" will produce in "doTransform", and the problem
is that it guesses wrong.

I think that the best way to do it would be actually to first generate
the PNG image by calling "dia", and then later returning the dimensions
of this PNG by using "getimagesize". The problem is that, as far as I
understood the source code, getImageSize will always be called before
doTransform. In fact, it seems to me that the name of the PNG image that
doTransform receives will start with the width of the image returned by
getImageSize itself.

I implemented a workaround^W^W a dirty hack to fix this issue. In
getImageSize, I am calling "dia" (without the size argument) saving it
to a tmpfile, then using "getimagesize" to get the dimensions of the PNG
(Continue reading)

Permalink | Reply | 0 comments |
headers
mike.lifeguard | 2 Sep 2008 17:36
Picon
Gravatar

Re: Moving pages

There is a script which handles this (and restores the page's original
protection levels in case your forget). One copy is at
http://commons.wikimedia.org/wiki/User:Animum/revdelete.js

Mike

-----Original Message-----
From: Ilmari Karonen [mailto:nospam@...] 
Sent: August 31, 2008 7:19 PM
To: Wikimedia developers
Subject: Re: [Wikitech-l] Moving pages

Victor Vasiliev wrote:
> ANTHONY APPLEYARD wrote:
>> I am an administrator in the English Wikipedia. It would be useful if
>> these could be made possible:-
>> * When deleting some edits in a page, to directly select them and
>> delete them, instead of having to delete everything and then undelete
>> the rest.
>>    
> We have rev_deleted feature implemented, but it is not reviewed yet.

While waiting for rev_deleted, even an UI for the current deletion 
system that allowed for selective deletion of revisions (rather than 
only wholesale deletion followed by selective undeletion) would be useful.

Something like that has been on my personal "to do" list for quite some 
time; who knows, maybe I'll even find the time to implement it before 
rev_deleted goes live.  (That one's only been implemented and "waiting 
for more testing" for, what, two years now?)
(Continue reading)

Permalink | Reply | 2 comments |
headers
Daniel Friesen | 2 Sep 2008 18:20

Re: SVN: [40323] trunk/phase3

Ummm... Isn't that a register_globals vulnerability since you removed 
$wgProxyKey from DefaultSettings.php?

~Daniel Friesen(Dantman, Nadir-Seen-Fire) of:
-The Nadir-Point Group (http://nadir-point.com)
--It's Wiki-Tools subgroup (http://wiki-tools.com)
--The ElectronicMe project (http://electronic-me.org)
--Games-G.P.S. (http://ggps.org)
-And Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG)
--Animepedia (http://anime.wikia.com)
--Narutopedia (http://naruto.wikia.com)

demon@... wrote:
> Revision: 40323
> Author:   demon
> Date:     2008-09-02 15:15:54 +0000 (Tue, 02 Sep 2008)
>
> Log Message:
> -----------
> Fully deprecate $wgProxyKey. Has been marked as deprecated since 1.4, but never seems to have been done.
Sites with $wgProxyKey set will continue to use the setting (added a fallback in Setup). Fixes bugs 9258
and 12089.
>
> Modified: trunk/phase3/includes/Setup.php
> ===================================================================
> --- trunk/phase3/includes/Setup.php	2008-09-02 02:11:50 UTC (rev 40322)
> +++ trunk/phase3/includes/Setup.php	2008-09-02 15:15:54 UTC (rev 40323)
>  <at>  <at>  -150,6 +150,10  <at>  <at> 
>  wfProfileOut( $fname.'-includes' );
>  wfProfileIn( $fname.'-misc1' );
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ilmari Karonen | 2 Sep 2008 18:47
Gravatar

Re: Moving pages

mike.lifeguard wrote:
> There is a script which handles this (and restores the page's original
> protection levels in case your forget). One copy is at
> http://commons.wikimedia.org/wiki/User:Animum/revdelete.js

Nice to know.  However, while the script certainly makes the whole 
process easier for the admin doing it, it doesn't actually make it any 
less laborious behind the scenes: it's still deleting all revisions of 
the page only to immediately restore all but one of them.

Also, while seemingly well written for a JavaScript workaround, it's not 
as robust as a server-side solution could be.  I suspect all sorts of 
unpleasant stuff may happen if you try it on a page with both a very 
long edit history and lots of previously deleted revisions.

--

-- 
Ilmari Karonen
Permalink | Reply | 1 comment |

Gmane