Nick, thanks a lot.
Those two things were just what I was looking for - an api to get all the
interwiki links, and a way to get just the sizes... I will try to update my
scripts when I can. Of course, if someone wanted to include it in core, I'd
love it - but I cannot do php. The programming logic is dead simple though.
To the server admins, if I only did HEAD requests to get the size, would it
be considered acceptable usage to do five-six head requests everytime I used
my script to get a page (ie could I publicize my tool) or is that still too
much? Does it spend lot's of resources assembling each page each time, or
does it go straight from cache anyway?
Thanks
Stian
Hi Guys,
I have a site and want to plug wiki pages into the existing HTML pages. Is there a special wiki to do this... or I will have to install the standard wiki in www.mysite.com/wiki folder and then code in PHP to link wiki pages to the existing site?
I am a novice to both programing and wiki, so I need something that as easy as installing a software or plug in.
Cheers,
Sid
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
I'm writing a Mediawiki extension (http://mediawiki.pastey.net/28186)
that changes text like "[[X::R::Y]]" to "[[Y]]", and then displays X
and R at the bottom the page in a clever way (it's a semantic/RDF
extension, because I'm not crazy about the existing Semantic
Mediawiki).
To do this, I did:
$wgHooks['ParserBeforeStrip'][] = 'myInternalParseBeforeLinks';
where myInternalParseBeforeLinks(&$parser, &$text) appends "foo" to $text.
This works great for the main article, but "foo" also gets appended to
my page footer:
# This page was last modified 16:57, 6 May 2007.
This page has been accessed 56 times.
{whatever "foo" I added appears here too}
When I create or edit a page, it's even worse: "foo" appears all over
the place.
How do I get my hook to JUST add "foo" to the main article and nothing
else? As you can tell from the hook name, I originally tried to add
this as a InternalParseBeforeLinks hook, but that didn't work either.
Are these the correct lists to ask on?
--
We're just a Bunch Of Regular Guys, a collective group that's trying
to understand and assimilate technology. We feel that resistance to
new ideas and technology is unwise and ultimately futile.
An automated run of parserTests.php showed the following failures:
This is MediaWiki version 1.11alpha (r22218).
Reading tests from "maintenance/parserTests.txt"...
Reading tests from "extensions/Cite/citeParserTests.txt"...
Reading tests from "extensions/Poem/poemParserTests.txt"...
18 still FAILING test(s) :(
* URL-encoding in URL functions (single parameter) [Has never passed]
* URL-encoding in URL functions (multiple parameters) [Has never passed]
* Table security: embedded pipes (http://mail.wikipedia.org/pipermail/wikitech-l/2006-April/034637.html) [Has never passed]
* Link containing double-single-quotes '' (bug 4598) [Has never passed]
* message transform: <noinclude> in transcluded template (bug 4926) [Has never passed]
* message transform: <onlyinclude> in transcluded template (bug 4926) [Has never passed]
* BUG 1887, part 2: A <math> with a thumbnail- math enabled [Has never passed]
* HTML bullet list, unclosed tags (bug 5497) [Has never passed]
* HTML ordered list, unclosed tags (bug 5497) [Has never passed]
* HTML nested bullet list, open tags (bug 5497) [Has never passed]
* HTML nested ordered list, open tags (bug 5497) [Has never passed]
* Fuzz testing: image with bogus manual thumbnail [Introduced between 08-Apr-2007 07:15:22, 1.10alpha (r21099) and 25-Apr-2007 07:15:46, 1.10alpha (r21547)]
* Inline HTML vs wiki block nesting [Has never passed]
* Mixing markup for italics and bold [Has never passed]
* dt/dd/dl test [Has never passed]
* Images with the "|" character in the comment [Has never passed]
* Parents of subpages, two levels up, without trailing slash or name. [Has never passed]
* Parents of subpages, two levels up, with lots of extra trailing slashes. [Has never passed]
Passed 495 of 513 tests (96.49%)... 18 tests failed!
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Bugzilla 3.0 was released a couple days ago, with fixes for a lot of
longstanding annoyances:
* Allows uploading an attachment with initial bug report
* Detection of accidental multiple submissions
* Support for automatic send-all-mail-here, so we don't have to maintain
wikibugs-l
* and many more!
http://www.bugzilla.org/releases/3.0/release-notes.html
I've been testing the upgrade process offline. It looks like we'll have
to redo the skin and linking hacks to work with the new code, but that
shouldn't be a huge problem. I'll bring it online Monday if nothing else
goes awry.
- -- brion vibber (brion @ wikimedia.org)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGRNyVwRnhpk1wk44RAhbOAKCqHSq13SM4bIeYsM5D4qwLxl5iNgCgotAI
yJE9En+2pIHAmsEgd2WS5YA=
=qby8
-----END PGP SIGNATURE-----
An automated run of parserTests.php showed the following failures:
This is MediaWiki version 1.11alpha (r22200).
Reading tests from "maintenance/parserTests.txt"...
Reading tests from "extensions/Cite/citeParserTests.txt"...
Reading tests from "extensions/Poem/poemParserTests.txt"...
18 still FAILING test(s) :(
* URL-encoding in URL functions (single parameter) [Has never passed]
* URL-encoding in URL functions (multiple parameters) [Has never passed]
* Table security: embedded pipes (http://mail.wikipedia.org/pipermail/wikitech-l/2006-April/034637.html) [Has never passed]
* Link containing double-single-quotes '' (bug 4598) [Has never passed]
* message transform: <noinclude> in transcluded template (bug 4926) [Has never passed]
* message transform: <onlyinclude> in transcluded template (bug 4926) [Has never passed]
* BUG 1887, part 2: A <math> with a thumbnail- math enabled [Has never passed]
* HTML bullet list, unclosed tags (bug 5497) [Has never passed]
* HTML ordered list, unclosed tags (bug 5497) [Has never passed]
* HTML nested bullet list, open tags (bug 5497) [Has never passed]
* HTML nested ordered list, open tags (bug 5497) [Has never passed]
* Fuzz testing: image with bogus manual thumbnail [Introduced between 08-Apr-2007 07:15:22, 1.10alpha (r21099) and 25-Apr-2007 07:15:46, 1.10alpha (r21547)]
* Inline HTML vs wiki block nesting [Has never passed]
* Mixing markup for italics and bold [Has never passed]
* dt/dd/dl test [Has never passed]
* Images with the "|" character in the comment [Has never passed]
* Parents of subpages, two levels up, without trailing slash or name. [Has never passed]
* Parents of subpages, two levels up, with lots of extra trailing slashes. [Has never passed]
Passed 495 of 513 tests (96.49%)... 18 tests failed!
The infamous "secret number" beginning "09 F9" was being spammed to lots and
lots of unrelated articles, so someone added to the $wgSpamRegex blacklist.
Problem solved.
Unfortunately, this is causing problems at the article the describes the
controversy, which some editors and admins feel has a legitimate reason to cover
the key. The usual procedure would be to add that page to the whitelist, but
the admins who have attempted this say that it won't work, due to the
$wgSpamRegex issue. (and I should mention, there are some editors and admins
who feel the key should NOT be posted).
Jimbo and the foundation has issue a comment essentially leaving the decision up
to the community.
http://en.wikipedia.org/wiki/User_talk:Jimbo_Wales/Archive_24#Official_Offi…
Could a dev please remove the key from $wgSpamRegex and instead add it to the
usual spam blacklist? This should accomplish the same spam prevention, but
allow admins to whitelist pages if there is a consensus to do so.
Thanks!
Alec
hi,
I've been using the external tidy and it seems with the tidy.conf in
/extensions that a <body> tag is still generated and wrapped around the
generated HTML of the article. Is there any way to avoid this?
Thanks,
Travis
