I have been working with Wikipedia for a very long time and something
that has disturbed me very much is the lack of transparency after an
article has been deleted. I think the following issues should be
resolved:
1) [Logged in] users should be able to view the deleted article, if it
was not deleted due to copyright or legal issues. I believe there are
many articles that are being deleted that are still very educational
to the public, and I don't think it is in the educational best
interest of our public to ban someone's right to view a deleted
article.
2) There should be direct links on the deleted page to the discussion
(and previous discussion if it was put up for AfD before), so people
can more easily understand why an article was deleted. Today, if a
newbie to Wikipedia comes to a deleted article, they are basically
told that the article went through a process and was deleted. I
imagine it would be very shocking for someone to return after a two
week vacation and discover that one of their beloved articles has been
put to the AfD without them even being notified.
3) Email auto-notification of articles on someone's watchlist of being
proposed for AfD. Many people do not visit Wikipedia for a week, but
still care very deeply about articles on their watchlist and may have
put a lot of work into the article at hand and would like to have a
say in the debate about whether an article should be deleted. These
users should at least be notified by email when an article is put up
for AfD review.
I think with these three reforms in place, Wikipedia will become a
much better place. I know a few people who don't edit Wikipedia in
English anymore, because they are afraid that their work will just be
removed by a delete-happy admin, even if a vote has more Keep votes
than Remove (which I have seen in the past).
Best wishes,
Chuck Smith
Eo Wikipedia founder
On 22/06/07, aaron(a)svn.wikimedia.org <aaron(a)svn.wikimedia.org> wrote:
> Revision: 23265
> Author: aaron
> Date: 2007-06-22 22:38:11 +0000 (Fri, 22 Jun 2007)
>
> Log Message:
> -----------
> *Partial revert of r23253-23254, please add alternative UIs using a configurable global rather than replacing the current one, which is simply and likely fine for a lot of uses
Globals are evil, use hooks.
Rob Church
On 6/22/07, brion(a)svn.wikimedia.org <brion(a)svn.wikimedia.org> wrote:
>
> Revision: 23220
> Author: brion
> Date: 2007-06-22 14:25:23 +0000 (Fri, 22 Jun 2007)
>
> Log Message:
> -----------
> Revert r23197 -- while well-meaning, this would severely overrepresent
> minor content namespaces by selecting the namespaces with equal probability.
> A better solution would be to modify the RandomPage class to allow passing
> pages of multiple namespaces, and giving it the complete list of content
> namespaces; then the selection would be properly proportional.
<snip>
True -- my bad :). I was getting irritated by Randompage only returning one
or two pages in the mainspace on my wiki, rather than pulling from the
several other pages in other content namespaces, so did this as a quick
"fix". It would be quite nice to have Randompage select a random content
page, rather than just a random page in the mainspace, however, so I'll see
about implementing a more elegant and correct solution later on. Thanks for
catching that, Brion; I'll try to refrain from committing at 2am from now on
=D.
--
Daniel Cannon (AmiDaniel)
http://amidaniel.com
cannon.danielc(a)gmail.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ok, me and Tim finally got a chance to look over the LST extension...
Tim has some concerns about performance (there appear to be areas for
improvement) but thinks it shouldn't be a problem on Wikisource.
I've gone ahead and enabled it on *.wikisource.org and test.wikipedia.org.
For usage instructions, see:
http://www.mediawiki.org/wiki/Extension:Labeled_Section_Transclusion
- -- brion vibber (brion @ wikimedia.org)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGfChKwRnhpk1wk44RAhFpAJ94VvHO9oK8lKrLiVTLkJw3hVjRYQCeNW8W
0LBKldYN8DcE/SI/xVZN448=
=HPmK
-----END PGP SIGNATURE-----
I'm wrapping up my next version of Open Web Analytics for MediaWiki
(http://www.openwebanalytics.com) and wanted to inquire about plans
for creating an extension management special page where admins could
activate and deactivate extensions without modifying localSettings.php.
Something like this would greatly reduce the technical skill required
to add extensions into the mix but more importantly would provide
extension developers with a very handy "install" action hook that
could be used to do things like create dependent database tables,
etc. Right now one needs to run an extension install script to create
the necessary db tables and then link into localsettings.php.
Anyone thinking about this or working on something? I saw a thread a
while back but nothing since.
-P-
--
Peter Adams <peter(a)oncefuture.com>
Blog >> http://www.oncefuture.com/padams/weblog
Open Web Analytics >> http://www.openwebanalytics.com
A special thank you note from Hemen, a donator
-------
Hemen Mehta
For the Great work of Rob Church in getting FCKEditor to work with
MediaWiki 1.9.3 2007-06-13 13:03:27 USD 25.00 25.00
On 21/06/07, aaron(a)svn.wikimedia.org <aaron(a)svn.wikimedia.org> wrote:
> Revision: 23161
> Author: aaron
> Date: 2007-06-21 13:53:32 +0000 (Thu, 21 Jun 2007)
>
> Log Message:
> -----------
> *Return true for hooks
Er, not all hooks should return true, and these hooks relate to
authentication. Please be sure that the intended purpose of the hook
is understood before messing about with extension code in this manner.
Rob Church
After I found the cause of a specific extension interaction bug, brion
pointed out that this was a common error in extensions, that is functions
attached to hooks that do not return a value. Such functions previously
stopped all other functions attached to the hook from running - hence the
interaction issues.
Per r23133, any function that is called by a hook and does not return a
value will through a full stop error. This should encourage new extension
writers to use cleaner functions that avoid this, however, I noticed a lot
extension functions didn't return anything. I grepped through and tried to
fix them all, at least the ones on SVN, but someone else may want to
doublecheck, especially for the ones one WikiMedia sites (mainly
http://en.wikipedia.org/wiki/Special:Version).
--
View this message in context: http://www.nabble.com/Hooked-function-return-values-tf3955943.html#a11224995
Sent from the Wikipedia Developers mailing list archive at Nabble.com.
(Sorry if double posting but posted yesterday and didn't see my message)
on en.wikipedia.org :
http://en.wikipedia.org/wiki/Image:Newtroot_1_0_0_0_0_m1.png (actually it's
on commons :
http://commons.wikimedia.org/wiki/Image:Newtroot_1_0_0_0_0_m1.png) doesn't
display, instead the page shows a big gray square with "Error creating
thumbnail: Invalid thumbnail parameters"
I've tried on a local install and got the same error.
This image used to be smaller but was recently "upsized" so I've tried to
resize the image (5600x 5600 --> 1400 1400 : 5Mb --> 1 Mb) and upload it
locally and it worked fine (didn't tried on wp)
Could this be a problem linked either with the size (in bytes) or the size
(in pixels) of the image ?
Alexis
(BTW there are several others "Error creating thumbnail: Invalid thumbnail
parameters" on en.wp and commons)
--
View this message in context: http://www.nabble.com/thumbnails-problems-and-maximum-size-tf3956932.html#a…
Sent from the Wikipedia Developers mailing list archive at Nabble.com.
Hi All,
I am trying to customise the Special:Preferences page to remove tabs and
change certain form fields. My amendments are relatively simple to achieve
but editing includes/SpecialPreferences.php. However I would rather use an
extension and keep the core code intact. I have tried using the
SpecialPageExecuteBeforePage hook, but this seems not to work as expected
(see my extension code below). The following note in the core code,
includes/SpecialPage.php, stating that the SpecialPageExecuteBeforePage hook
needs to be fixed:
# FIXME: these hooks are broken for extensions and anything else that
subclasses SpecialPage.
If this hook is not due to be fixed soon will someone please offer another
way to amend the Special:Preferences page without hacking the core code?
My extension code:
$wgHooks['SpecialPageExecuteBeforePage'][] = 'CustomUserPreferencesPage';
function CustomUserPreferencesPage($specialpage, $par, $func) {
// Check if this hook has been called from the correct page
if ($specialpage->mName == 'Preferences') {
global $IP ;
$specialpage->file($IP .
"/extensions/CustomUserPreferencesPage/templates/CustomSpecialPreferences.php")
;
}
return true ;
}
Many thanks in advance,
Matthew
MediaWiki version 1.10.0
PHP version 5.2.2
