Let me start by saying that MediaWiki is great wiki software and I have enjoyed
writing many extensions and plugins for it. The requirements of Wikipedia have
demanded features that are hard to come by in other wiki software, especially in
the areas of caching and optimization. However, this is a double-edged sword,
as development decisions in MediaWiki are often filtered through the question of
whether they are desired for Wikipedia. If this litmus test is not met,
features are abandoned and never see the light of day. If so, they are
implemented to the delight of Wikipedians. I don't mean to criticize this
methodology and I certainly don't wish to bad-mouth MediaWiki (after all,
someone was kind enough to make the product open source and kind enough to make
it generic that anyone could use), but I have a few questions that have been on
my mind.
My questions to the MediaWiki developers are as follows:
Will features perhaps never desirable for Wikipedia ever be considered for
MediaWiki? For example, wiki spaces (much like XWiki or Confluence) that either
exist as self-contained wikis or as areas that are more stand-alone (e.g.
attaching documents to individual pages). Another desirable feature is a
fine-grained permission system, although I argue this goes hand-in-hand with the
aforementioned concept of wiki spaces.
Will MediaWiki development ever take a significant step away from Wikipedia
so drastic overhauls to the core can be made? Right now, MediaWiki development
is mainly implementing features on a production site and spewing them back out
in the form of a new version release. Will this model ever change?
I see MediaWiki as much more than the software that powers Wikipedia. One
only has to look at the hundreds of independent wikis in existence that are
powered by MediaWiki. However, there is much ground that can be won. I argue
that because of Wikipedia's popularity, the MediaWiki wiki syntax is the most
recognized of any wiki syntax in existence. Combined with its proved track
record, MediaWiki is immediately a front-runner for anyone wishing to deploy a
wiki. However, we all know MediaWiki isn't ideal for some situations. Well,
basically it is ideal for only one simple use case: a wiki focusing on one
subject matter with blanket access control to all content therein. Any other
use is a stretch. In other words, there is a considerable market share in which
MediaWiki can't even compete.
MediaWiki is great software and will continue to be great software. In order
to take it to the next level, a slight departure from the Wikipedia-centric
development cycle will be required.
I kindly ask that the MediaWiki core developers lend their thoughts on
this matter.
Gregory Szorc
gregory.szorc(a)case.edu
Hello!
You are receiving this email because your project has been select to
take part in a new effort by the PHP QA Team to make sure that your
project still works with PHP versions to-be-released. With this we hope
to make sure that you are either aware of things that might break, or to
make sure we don't introduce any strange regressions. With this effort
we hope to build a better relation between the PHP Team and the major
projects.
If you do not want to receive these heads-up emails, please reply to me
personally and I will remove you from the list; but, we hope that you
want to actively help us making PHP a better and more stable scripting
language.
The final release candidate of PHP 5.1.3 can be found at
http://downloads.php.net/ilia/php-5.1.3RC2.tar.bz2. I would like to ask
you to test your application against this release and let us know about
any issues that you discover. We are particularly interested in
backwards compatibility breaks and new issues appeared in this release,
but were not present in prior 5.1 versions. If you find any issues,
please contact the PHP QA team at "php-qa(a)lists.php.net".
In case you think that other projects should also receive this kinds of
emails, please let me know privately, and I will add them to the list of
projects to contact.
regards,
Ilia Alshanetsky
5.1 Release Master
I am new to Wiki. I want to know if this Wiki method could be used on a Web
Site to edit text on a specfic page or pages ONLY by one person (via
password) I want only specific indaviduals to edit text and not use a web
editing software. Thank you Roger
> Please can you help with that ?
> I have read most of the online docs on this subject and still have no luck ..
> Also, can you tell me if the enhanced of enotif will be merge in a future
> version of mediawiki ?
E-mail notification _is_ built-in in MediaWiki. Please read
http://www.enotif.org about the common pitfalls.
For example, you'll never get an notification for your own changes. And:
try first to get a temporary password mailed.
If this doesn't work, something more basic in your installation need to
be fixed first.
Be aware: I only stopped the publication of the special version
"EnotifWiki", but not the support for e-mail notification as such.
Tom
A hierarchical navigation bar can be implemented by changing code in
monobook.php (
http://meta.wikimedia.org/wiki/Customization#How_do_I_add_an_editable_Left_…).
Unfortunately this only works in case $wgUseDatabaseMessages in
defaultsettings.php is set to "true".
In my case, this variable is set to false, in order to be able to use
another language (Dutch instead of English) in our wiki. BUT by
setting $wgUseDatabaseMessages=false,
the mediawiki-namespace (into which the navigation bar has to be changed) is
not read anymore.
To change the content of the navigation bar, I had to adapt the
language.phpfile:
'sidebar' => '
* navigation
** mainpage|mainpage
** portal-url|portal
** currentevents-url|currentevents
** recentchanges-url|recentchanges
** randompage-url|randompage
** helppage|help
* Cases
** Businesscase|Business
** Technicalcase|Technical
',
but i cannot implement a hierarchical menu by changing e.g. **
Technicalcase|Technical into *** Technicalcase|Technical. Does anyone know
how to solve this problem so that I can implement a hierarchical menu
while $wgUseDatabaseMessages=false?
Do I have to change code in the language.php file or in the monobook.phpfile?
Thanks in advance!
Birger
2006/3/24, Jama Poulsen <jama(a)debianlinux.net>:
>
> On Thu, Mar 23, 2006 at 10:05:57AM +0100, Birger wrote:
> > Does anyone know whether it is possible to implement a hierarchical
> > navigation bar in Mediawiki like e.g.:
> >
> > * CASES
> > ** BUSINESSCASES-URL | BUSINESSCASES
> > *** BCASE1-URL | CASE1
> > *** BCASE2-URL | CASE2
> > ** TECHNICALCASES-URL | TECHNICALCASES
> > *** TCASE1-URL | CASE1
> > *** TCASE2-URL | CASE2
>
> I think it would be easiest to just edit the skin files (eg.
> /wiki/skins/MonoBook.php) with some extra CSS and/or JS that implements
> such a structure.
>
> Doing this dynamically (from the Wiki text) isn't so easy in the MW
> interface.
>
> Jama Poulsen
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>
An automated run of parserTests.php showed the following failures:
Running test Magic Word: {{NUMBEROFFILES}}... FAILED!
Running test BUG 1887, part 2: A <math> with a thumbnail- math enabled... FAILED!
Passed 298 of 300 tests (99.33%) FAILED!
Neil Harris wrote:
> Ilmari Karonen wrote:
>
>> Tim Starling wrote:
>>
>>
>>> There's a simple, non-invasive way to determine the IP address of an AOL client, which I've been
>>> looking into recently: use SSL sign-on. Make the login links go to https://secure.wikimedia.org, and
>>> redirect them back when they're logged in. SSL requests skip the proxy cluster. We would store the
>>> IP address at login in the session, and then continue to use that IP address for the user after they
>>> return to the unsecured part of the site. And of course there are security benefits for all users.
>>>
>>>
>> If that really works, couldn't we just make AOL users _edit_ over SSL?
>> Have http links with action=edit (or action=submit) redirect to an https
>> URL if fetched from an AOL proxy.
>>
>> This would break talk message notification for unregistered AOL users,
>> but I suppose we could use a cookie for that. After all, talk pages are
>> public, so there's no security issue even if someone fakes the cookie.
>>
>>
>>
> Now, that's an *excellent* idea.
>
> 1 the SSL overhead will be low, because edits are a tiny fraction of the
> overall traffic
> 2 If we only SSL the form submission, this limits the SSL overhead even
> further.
> 3 AOL browsing will still be proxied, so page-view load will not increase
> 4 AOL _browsing_ will still be completely anonymous
> 5 AOL IP editors will still be as anonymous as any other IP editors
> 6 Dynamic IP assignment should not be any more or less of a problem than
> with other ISPs
>
> Are there any reasons why this should not work? Perhaps this could be
> the solution for all non-XFF-friendly ISPs?
>
> -- Neil
>
>
And, on re-reading, perhaps for AOL users only, the "my talk page" link
could be an SSL link which would then auto-redirect to the appropriate
IP address talk page, thus eliminating any need for a cookie.
A question: does the Foundation have a PKI certificate for the
wikipedia.org domain?
-- Neil
Forwarding to the technical list where this might get more attention
from the people who can help with this.
Angela
On 3/28/06, mingli yuan <mingli.yuan(a)gmail.com> wrote:
> Hi, buddies. The Chinese Wikimedia users need some technical help from
> the developers at the Foundation.
>
> As everyone here believes, the government of P.R. China has blocked
> access to all Wikimedia sites using its "Great Firewall"; Wikimedia
> contributors and users in Mainland China have to use proxies to visit
> Wikimedia sites. However, most of these proxies are unstable, so
> CNBlog.org (a famous and prominent advocacy of blogosphere in China
> operated by Social Brian Foundation, which hosted the First Chinese
> Blogger Conference last year) has setup a stable proxy for Chinese
> users.
>
> With this service, Mainland Chinese users can access Chinese Wikipedia
> using http://wikipedia.cnblog.org, and Chinese Wikinews using
> http://wikinews.cnblog.org. There are over 16,000 visits and over
> 110,000 page requests per day this month. CNBlog.org has been very
> helpful to Chinese users, and it is planning to expand its proxy
> service to cover all Chinese Wikimedia projects, which is really great
> news.
>
> Unfortunately, Chinese Wikimedia administrators are frowned upon an
> issue that came up recently: lots of vandalism is done using the
> CNBlog proxy. Currently, the IP of the CNBlog proxy is displayed and
> logged in edit history on Wikimedia. If an administrator blocks this
> IP (CNBlog proxy), all Mainland Chinese users who are using CNBlog
> proxy, either logged-in or not, will be blocked as well and not be
> able to contribute.
>
> Some Chinese Wikipedians discussed this issue with CNBlog.org, and we
> believe that a technical solution should be feasible. We also
> discussed some technical details, and I will send another e-mail to
> wikitech-l regarding the details. Basically, we would like to have
> users' real IP (IP used to access CNBlog proxy) displayed and logged
> at Wikimedia.
>
> We send this e-mail to here on behalf of many Chinese users. We hope
> to have kind attention and help from the Foundation. Thank you very
> much.
>
> [[User:Shizhao]]
> [[User:R.O.C]]
> [[User:Yongxinge]]
> [[User:Mountain]]