> I admire the work you've done there. I think it's very impressive.
> However, I also think it's far too complex for a site where the
> accesibility level should be low. The syntax should be *very* simple
> -- markup rather than programming.
The *article* syntax should be very simple. It's already way too
complicated for the type of person who is supposed to be contributing,
with pipe tables, HTML, visual style markup, and so on. Currently,
only those who aren't intimidated by code can contribute to the
encyclopedia, leading to significant systemic bias.
> Do you see the need? I don't. All I see is people wanting to use one
> template in all situations, where they could easily use multiple
> templates.
Using templates, especially templates with complex markup and
conditionals, makes *article markup* simpler and easier to edit.
There are still plenty of people who understand them and can make
changes when necessary.
> How about none of them, and play with templates how they were designed
> to be played with?
How exactly were they designed to be played with? If they were really
only designed for one specific purpose, is there a good reason for not
expanding their breadth? If they can be used as an intermediate step
between editors and developers, and make the wiki markup simpler and
easier to use for regular people, shouldn't it be done? The
developers don't have time to do everything we want, but if other
editors can do it with templates, and it's not hurting the servers,
and it's not hurting anything else, where's the problem?
Obviously it would be better if this functionality was present in the
Mediawiki itself, but until it is, what makes these templates so bad?
They make the encyclopedia better.
Hi,
Just want opinions if my hack is valid, secure, or if there are any
loop-holes you see, or if there are improvements you might suggest:
The objective is to require users to confirm their email addresses
before they can login. This may be useful in intranet settings, not
public ones.
So, here's a psuedo-code step-by-step if you're interested. I've
implemented it and it seems to work well.
Files to modify:
1. includes\SpecialUserlogin.php
A) function AddNewAccount()
The system will log you in automatically without confirming your email
address. Add code here to refuse logins and force a $wgUser->logout() call.
Example:
if (!$u->isEmailConfirmed())
...show error message
...log user out
B) function processLogin()
The other step to cover is when the user tries a regular login by
clicking the login button. Again, do the same check as you did in part
A, but remove the logout() since that is not necessary (user is not
logged in yet).
2. LocalSettings.php
Have the following:
$wgGroupPermissions['*' ]['createaccount'] = true;
$wgGroupPermissions['*' ]['read'] = false;
$wgGroupPermissions['*' ]['edit'] = false;
$wgEmailAuthentication = true;
This requires users to log-in first before they can read or write.
3. index.php
We need to modify index.php because when a confirmation link is sent to
your email to verify your address, the system wants you to login first
in order to validate it! But you can't since your login is now rejected
after our modifications.
Look for this in index.php
if ( !is_null( $wgTitle ) && !$wgTitle->userCanRead())
This is what's preventing you from confirming your email address. Your
email confirmation link is going to Special:Confirmemail. Write a
function that parses your $_GET[title] for the string
Special:Confirmemail and returns true if it finds it. You can stuff the
function somewhere to keep the code neat...I temporarily stuffed it in
localsettings.php.
Then add your function to the line:
if ( !is_null( $wgTitle ) && !$wgTitle->userCanRead() &&
!areYouConfirmingEmail())
That's all folks. Hope it's correct, and useful, and bug free.
Comments, criticisms welcome.
Hi,
I posted the same question already in the Mediawiki-Mailing group. But
it seems that
nobody has an idea.
So here is my problem:
I want to show thumbnails of my images. What I do:
* first upload an image
* to show the thumbnail enter [[Image:myPic.jpg|thumb|alternative text]]
Thats all, isn't it?
But no thumbnail is shown, only a frame an 'alternative text' and the
enlarge link!
No picture at all!
I thought that it could be a configuration problem.
In LocalSettings.php I have the following block:
## To enable image uploads, make sure the 'images' directory
## is writable, then uncomment this:
$wgEnableUploads = true;
$wgUseImageResize = true;
$wgUseImageMagick = true;
$wgImageMagickConvertCommand = "/usr/segment/bin/convert";
When I enter '/usr/segment/bin/convert' on the webserver I get the
following:
bash-3.1$ /usr/segment/bin/convert
Version: ImageMagick 6.1.8 01/18/05 Q16 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2005 ImageMagick Studio LLC
...
This seems to me to be correct. So I guess it is no configuration problem.
Any idea?
Can this be a PHP safe mode problem? Because I had some problems
activating image uploads.
I must run MediaWiki as cgi module. But I get no safe mode restriction
error or something like this.
Also the subdirectories in 'images' are existing and 777.
Thanks, MB
Spam Filter Project <http://meta.wikimedia.org/wiki/Spam_Filter>
*Purpose*
Address deficiences in existing SpamBlacklist
extension<http://meta.wikimedia.org/wiki/SpamBlacklist_extension>and
$wgSpamRegex filter.
*Scope*
Add new extension to enhance spam filtering with multiple regex patterns
and with maximum control at the local wiki.
*Benefits*
Empower small wikis. Leverage the spam patrol resources of large wikis.
Unbalance spammers by presenting them with multiple anti-spam strategies
instead of just one central strategy.
*Current status*
Proposal phase - reviewing requirements and seeking developers.
= John Walling
With increasing multilingualism in wikipedia, it is becoming harder to
find the interwiki link one is looking for in a list of dozens of languages.
I see two possibilities to solve this issue.
- English is the reference language for most topics. Therefore, English
interwiki links could be emphasized, typed bold or shown at the
beginning of the interwiki list.
- interwiki links could be customized. Nobody speaks all languages that
could possibly be linked. Every user could customize the set of
languages he is interested in in the preferences section. Then all other
links could be hidden for this user.
Looking forward to hear your opinion.
Dominik
Jama Poulsen wrote:
>I agree with this, but the solution isn't to not use
tags/labels/categories.
>The real solution lies in a combination of various meta-info systems and a
>powerful browse/search interface. For a project like Wikipedia a very
flexible
>solution is needed.
Semantic Mediawiki is very cool - I'll have to look at that some more.
Another approach relevant to what you're describing is to use multiple tags
for articles, and then search against those multiple categories (described
at http://meta.wikimedia.org/wiki/Category_math and other places) - one
example of this in action is at
http://www.wikidirectory.org/index.php?title=Special:Intersections&catlist=….
This gives you the more specific results from a combination of tags or
categories having less specific meaning.
Using an approach where you embrace tags/categories/labels/whatever that are
less specific, you begin to get an "average" kind of meaning. I've also
been thinking about how to combine this approach (category intersections)
with some kind of relevance rating (maybe using the article validation code
to rate the relevance of each tag).
Best Regards,
Aerik
Due to rising levels of spam on mediawiki-l and wikitech-l, I've set the lists
to automatically discard all non-subscriber posts, as has been previously done
on wikipedia-l and wikien-l.
With a ratio of something like 50 mortgage & viagara spams to each "forgot to
subscribe before asking a question" post, it's rather time-consuming. :(
As always, if you want to read through the web archives or news gateway, you can
disable direct mail delivery when you subscribe.
-- brion vibber (brion @ pobox.com)
On several mediawiki installations I run I have added the Google Analytics
code to the <head> of each page. I couldn't find any way to do this other
than directly inserting it into the code for includes/OutputPage.php
The code in question is to load an external .js file from Google's
servers, and then call a method on it.
Question 1: Is there some alternative to modifying this file that I've
missed? I know that there's the option for user-specific javascript, but
I'm looking for something similar, where I can edit a page to change the
JavaScript used by everyone.
Question 2: Assuming not, what would the consensus be on providing some
way of doing this? On one of my installations I forgot to re-modify this
file after an update, and lost a week's worth of tracking data. I'd
really like to find a way to factor this out so that I don't do that
again. I also suspect that other people would like this facility -
either for adding the Google code, or for other reasons.
My knowledge of the internals isn't good enough to do this myself yet,
but if it's deemed useful I'm willing to have a go at it if people could
give me a few pointers.
Thanks,
Tony
Hello devs,
Before submitting a vote on FR wikipedia and posting a request on bugzilla,
I would like to get an informal opinion about the feasibility of this new
function.
The principle is to add a "Proofread asked" flag to pages when submitting
changes, with a checkbox next to "Minor edit" and "Watch this page". Thus, a
hesitating contributor who would like his changes to be checked (for
spelling errors, wiki links, layout, etc.) could do it simply by one click.
This page would then appear in a list of special pages, for instance
"Special:PagesToProofread".
** This proposal is __not__ a validation issue : the flag is put by an
editor asking his own edits to be checked by someone else. The aim is to
easily improve global quality of articles by offering to users a tool which
helps them finding articles with potential minor errors.
The flag would be put up by default for IP changes, but the checkbox would
be clickable so as to allow them to uncheck the box. The flag would by put
down by default for registered users, but the checkbox would be clickable
too ; for registered users, default flag could be personalized via
"Special:Preferences" (for example for people who know they make a lot of
spelling or wiki mistakes). As long as edits are made with the box checked,
the flag stays up. The flag is set down with the first edit with an
unchecked box. The flag could also be put down easily, for example by
submitting the article unchanged but with the box unchecked.
Pages with the flag up would appear in "Special:Recentchanges" and
watchlists with a symbol like "N" for new pages and "m" for minor edits (for
instance a "p"). This symbol also needs to appear in the page history each
time it is set up or down, so as to keep a trace. Another possibility, which
is maybe more complicated, is to create a flag history for each page, to
prevent flag events from inflating the basic history.
This feature differs from "pages to verify" because changes needed in "pages
to proofread" are minor and don't refer to what is said in the article.
That's all folks. This feature would help us a lot to improve global quality
of articles by doing little work, so it would be a great tool for lazy
people like us :)
Could you please tell me if this feature is feasable ?
--
Guillom
"Je sers la science et c'est ma joie" - Basile le Disciple
http://fr.wikipedia.org/wiki/User:Guillom