An automated run of parserTests.php showed the following failures:
This is MediaWiki version 1.10alpha (r19546).
Reading tests from "maintenance/parserTests.txt"...
Reading tests from "extensions/Cite/citeParserTests.txt"...
Reading tests from "extensions/Poem/poemParserTests.txt"...
2 new FAILING test(s) :(
* URL-encoding in URL functions (single parameter)
* URL-encoding in URL functions (multiple parameters)
16 still FAILING test(s) :(
* TODO: Table security: embedded pipes (http://mail.wikipedia.org/pipermail/wikitech-l/2006-April/034637.html)
* TODO: Link containing double-single-quotes '' (bug 4598)
* TODO: message transform: <noinclude> in transcluded template (bug 4926)
* TODO: message transform: <onlyinclude> in transcluded template (bug 4926)
* BUG 1887, part 2: A <math> with a thumbnail- math enabled
* TODO: HTML bullet list, unclosed tags (bug 5497)
* TODO: HTML ordered list, unclosed tags (bug 5497)
* TODO: HTML nested bullet list, open tags (bug 5497)
* TODO: HTML nested ordered list, open tags (bug 5497)
* TODO: Inline HTML vs wiki block nesting
* TODO: Mixing markup for italics and bold
* TODO: 5 quotes, code coverage +1 line
* TODO: dt/dd/dl test
* TODO: Images with the "|" character in the comment
* TODO: Parents of subpages, two levels up, without trailing slash or name.
* TODO: Parents of subpages, two levels up, with lots of extra trailing slashes.
Passed 489 of 507 tests (96.45%)... 18 tests failed!
HI,
I want get the search keyword and display something on search
result page, so, whether there are some hidden search hook there?
Thanks
--
---BiGreat---
www.Liang-Chen.com
Ligulem wrote:
> On 19.01.2007 10:27, Andrew Garrett wrote:
> > If you want something implemented in a pure programming language
> > (PHP is debatable in that regard), speak to developers, we will
> > implement it in PHP as part of MediaWiki. MediaWiki is a piece
> > of software, not an IDE.
>
> Would you move http://en.wikipedia.org/wiki/Template:Cite_book into
> MediaWiki then?
>
Taking this seriously, instead of as bait, if you are serious about
this, please post a bugzilla request, instead of hounding individual
developers.
That said, I think that a basic parameterised thing like that
needn't be reimplemented; although it would be perhaps helpful in
performance terms.
Andrew Garrett
(Werdna)
An automated run of parserTests.php showed the following failures:
This is MediaWiki version 1.10alpha (r19480).
Reading tests from "maintenance/parserTests.txt"...
Reading tests from "extensions/Cite/citeParserTests.txt"...
Reading tests from "extensions/Poem/poemParserTests.txt"...
16 still FAILING test(s) :(
* TODO: Table security: embedded pipes (http://mail.wikipedia.org/pipermail/wikitech-l/2006-April/034637.html)
* TODO: Link containing double-single-quotes '' (bug 4598)
* TODO: message transform: <noinclude> in transcluded template (bug 4926)
* TODO: message transform: <onlyinclude> in transcluded template (bug 4926)
* BUG 1887, part 2: A <math> with a thumbnail- math enabled
* TODO: HTML bullet list, unclosed tags (bug 5497)
* TODO: HTML ordered list, unclosed tags (bug 5497)
* TODO: HTML nested bullet list, open tags (bug 5497)
* TODO: HTML nested ordered list, open tags (bug 5497)
* TODO: Inline HTML vs wiki block nesting
* TODO: Mixing markup for italics and bold
* TODO: 5 quotes, code coverage +1 line
* TODO: dt/dd/dl test
* TODO: Images with the "|" character in the comment
* TODO: Parents of subpages, two levels up, without trailing slash or name.
* TODO: Parents of subpages, two levels up, with lots of extra trailing slashes.
Passed 489 of 505 tests (96.83%)... some tests failed!
On 19/01/07, Virgil Ierubino <virgil.ierubino(a)gmail.com> wrote:
> There's a solution here. How about we introduce another language ****that is
> only available in the Template namespace****, specifically for this
> function? Call it Wikisyntax. Wikisyntax is a pure (and simple) programming
> language, with no markup. Wikitext is a pure and simple markup language,
> with no code.
Oh yes please. Separate data and code!
MediaWiki is one of those really nice bits of technology that lets
geeks get really geeky, *but* is so simple to use that even people who
can't work computers can be fantastically productive with it. (c.f.
Firefox, LiveJournal, Mac OS X.)
It's hard to get across to some of the people pushing MediaWiki markup
to its limits just how intimidating the computer gobbledygook can be
to people who just hit "edit this page" and want to write about
something they know about the subject.
- d.
Is there any advantage or deteriment to using both eAccelerator AND memcached on the same single server Wikipedia mirror on a relatively low traffic site? The reason I ask is that eAccelerator is installed as a PHP plugin and memcached is also installed. MediaWiki is set to use memcached for caching, however eAccelerator picks up on the PHP script and caches them too. So I'm wondering if that's a good idea (possibly redudant) or should I disabled eAccel in favor of memcached? Far as I know memcached is set to use 128MB of RAM at the moment. eAccelerator appears to be set to use 32MB, if that matters for answering the question.
Mike O
--
_______________________________________________
Surf the Web in a faster, safer and easier way:
Download Opera 9 at http://www.opera.com
Powered by Outblaze
I'd like to reopen the discussion about whether we officially consider
MediaWiki a project of the Wikimedia Foundation. Currently, the
position of the Foundation on this issue appears somewhat ambiguous.
While we run the Subversion repository, the website, the mailing
lists, and pay the two lead developers, MediaWiki is listed, for
example, on:
http://wikimediafoundation.org/wiki/Our_projects
not as a Wikimedia project, but as a "related project." It is also not
part of our usual list of projects. On the other hand, mediawiki.org
carries the "A Wikimedia Project" button.
My view is that we should make this the consistent, official view and
consistently promote and list MediaWiki as a Wikimedia Foundation
project wherever other Wikimedia projects are listed. My hope is that,
in doing so, we will make MediaWiki more prominent and attract more
volunteers to work on it, just as on other Wikimedia Foundation
projects. I also believe that this will help in making MediaWiki
strategy a key part of the Foundation's general project strategy.
What are other people's thoughts? The only downside I can see is that
this might be seen as a move to exercise additional control over the
direction of development. But already, all major code changes to the
core have to be approved by Brion, who is a Foundation employee. I
actually think it will be easier to identify our responsibility
towards outside users if we consider MediaWiki to be a key part of the
free culture movement that the Wikimedia Foundation must support.
--
Peace & Love,
Erik
DISCLAIMER: This message does not represent an official position of
the Wikimedia Foundation or its Board of Trustees.
> Mike O wrote:
> > Is there any advantage or deteriment to using both eAccelerator AND
> > memcached on the same single server Wikipedia mirror on a relatively
> > low traffic site? The reason I ask is that eAccelerator is installed
> > as a PHP plugin and memcached is also installed. MediaWiki is set to
> > use memcached for caching, however eAccelerator picks up on the PHP
> > script and caches them too. So I'm wondering if that's a good idea
> > (possibly redudant) or should I disabled eAccel in favor of
> > memcached? Far as I know memcached is set to use 128MB of RAM at the
> > moment. eAccelerator appears to be set to use 32MB, if that matters
> > for answering the question.
>
> Well, try it both ways and see which way gives you better performance... :)
>
> - -- brion vibber (brion @ pobox.com)
I've been doing that, and just using a browser to view pages it's hard to tell. Thus my question. I figure since a few people here work on development they might have an answer...
Mike O
--
_______________________________________________
Surf the Web in a faster, safer and easier way:
Download Opera 9 at http://www.opera.com
Powered by Outblaze
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
== Summary ==
Full disk on the database master for non-en.wikipedia.org made most of
our wikis uneditable for about 2.5 hours, during Europe midday / US morning.
Immediate problem is repaired; some minor further cleanup needed;
procedural changes recommended.
== Disruption and data loss ==
The last edits to make it to the slave servers were at:
2007-01-19 11:50:29 UTC
A few more made it through on samuel before it stopped accepting more
data up to:
2007-01-19 11:51:03
(23 broken edits on de.wikipedia.)
After that point the database didn't accept more writes, leaving a
read-only state which didn't allow any further consistency problems to
develop.
There _may_ be some minor problems related to caching of revision data
where ID numbers overlap from the old server, but this is unclear.
== Inspection and repair ==
I was woken up around 13:50 to take a look, informed that samuel
(non-enwiki master) was out of disk space and wikis were read-only.
After a few minutes to check that the slaves were consistent and that
there wasn't _too_ bad a lag between them and the master, I decided to
go ahead with a master switch to adler, leaving samuel out of service
until it gets re-cloned.
By 14:26 the master switch was done, and read-write service restored.
== Further work: immediate ==
If really desired, we may be able to clone the small number of 'lost'
edits from samuel.
Once we no longer need samuel's data, it should have its database
re-cloned from one of the slaves consistent with the new state, and it
can be restored to slave service.
== Further work: long-term ==
Our procedure for monitoring disk space and cleaning up binlogs is terrible.
Low-disk warnings from Nagios are routinely ignored, in part because the
thresholds seem much too high.
Binlog cleanup appears to be entirely manual and ad-hoc; there is no set
schedule or assignment to do this.
The good news is this task is easy to automate.
Recommendation:
* automate cleanup of binlogs on the db masters.
* make low-disk warnings more reasonable and visible for the masters
specifically (where it really, really matters)
- -- brion vibber (brion @ pobox.com)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFsOS1wRnhpk1wk44RAjujAKDLga9UHrs9Z5o0E6DM24puZvkSMwCeO9N0
/TIoWOSKKdUMOO3Lu5Bdn0M=
=R6SD
-----END PGP SIGNATURE-----