An automated run of parserTests.php showed the following failures:
Running test BUG 361: URL within URL, not bracketed... FAILED!
Running test External links: invalid character... FAILED!
Running test Bug 2702: Mismatched <i> and <a> tags are invalid... FAILED!
Running test A table with no data.... FAILED!
Running test A table with nothing but a caption... FAILED!
Running test Link containing "#<" and "#>" % as a hex sequences... FAILED!
Running test Template with thumb image (wiht link in description)... FAILED!
Running test Link to image page... FAILED!
Running test BUG 1887: A ISBN with a thumbnail... FAILED!
Running test BUG 1887: A <math> with a thumbnail... FAILED!
Running test BUG 561: {{/Subpage}}... FAILED!
Running test Simple category... FAILED!
Running test Basic section headings... FAILED!
Running test Section headings with TOC... FAILED!
Running test Handling of sections up to level 6 and beyond... FAILED!
Running test Resolving duplicate section names... FAILED!
Running test Template with sections, __NOTOC__... FAILED!
Running test Link inside a section heading... FAILED!
Running test Media link with nasty text... FAILED!
Running test Bug 2095: link with pipe and three closing brackets... FAILED!
Running test Parser hook: static parser hook inside a comment... FAILED!
Running test Sanitizer: Validating the contents of the id attribute (bug 4515)... FAILED!
Passed 266 of 288 tests (92.36%) FAILED!
For some lovely reason our new mail server has been blacklisted by SpamCop,
allegedly for sending mail to spamtrap addresses. (They provide no details by
policy, of course, so there's no way to verify it.)
Since there's a tiny possibility that the user-to-user email feature actually
could be abused, I've gone ahead and enabled the e-mail confirmation requirement
for using email features. This is a bit annoying for the moment since you have
to do it separately on each wiki.
I've disputed the listing, so hopefully we'll get it removed soonish and those
who aren't getting email will, uh, start getting it again.
-- brion vibber (brion @ pobox.com)
Dear developers,
Please create the following 13 wikipedia stated in
http://meta.wikimedia.org/wiki/Approved_requests_for_new_languages
* Dutch Low Saxon
* Vlax Romany
* Ligurian
* Samogitian
* Banyumasan
* Ripuarian
* Pennsylvania German (prototype)
* West Flemish
* Norman
* Franco-Provençal/Arpitan
* Cantonese
* Tetum
* Kalmyk
Best regards,
Henry Li
An automated run of parserTests.php showed the following failures:
Running test BUG 361: URL within URL, not bracketed... FAILED!
Running test External links: invalid character... FAILED!
Running test Bug 2702: Mismatched <i> and <a> tags are invalid... FAILED!
Running test A table with no data.... FAILED!
Running test A table with nothing but a caption... FAILED!
Running test Link containing "#<" and "#>" % as a hex sequences... FAILED!
Running test Template with thumb image (wiht link in description)... FAILED!
Running test Link to image page... FAILED!
Running test BUG 1887: A ISBN with a thumbnail... FAILED!
Running test BUG 1887: A <math> with a thumbnail... FAILED!
Running test BUG 561: {{/Subpage}}... FAILED!
Running test Simple category... FAILED!
Running test Basic section headings... FAILED!
Running test Section headings with TOC... FAILED!
Running test Handling of sections up to level 6 and beyond... FAILED!
Running test Resolving duplicate section names... FAILED!
Running test Template with sections, __NOTOC__... FAILED!
Running test Link inside a section heading... FAILED!
Running test Media link with nasty text... FAILED!
Running test Bug 2095: link with pipe and three closing brackets... FAILED!
Running test Parser hook: static parser hook inside a comment... FAILED!
Running test Sanitizer: Validating the contents of the id attribute (bug 4515)... FAILED!
Passed 266 of 288 tests (92.36%) FAILED!
I would like to know how i can hide Interwikilinks in Outputs?
When writing e.g. "[[en:lemna]]" the output is "en:lemna". i would like
to get just "lemna" (not showing the interwiki-link).
thx, heinz
Hi all
Is there a way to permanently assign skins to pages. I know I can do a
work-around using the attribute "useskin" in links but that's not what I
need.
Thanks in advance
Jorge
An automated run of parserTests.php showed the following failures:
Running test BUG 361: URL within URL, not bracketed... FAILED!
Running test External links: invalid character... FAILED!
Running test Bug 2702: Mismatched <i> and <a> tags are invalid... FAILED!
Running test A table with no data.... FAILED!
Running test A table with nothing but a caption... FAILED!
Running test Link containing "#<" and "#>" % as a hex sequences... FAILED!
Running test Template with thumb image (wiht link in description)... FAILED!
Running test Link to image page... FAILED!
Running test BUG 1887: A ISBN with a thumbnail... FAILED!
Running test BUG 1887: A <math> with a thumbnail... FAILED!
Running test BUG 561: {{/Subpage}}... FAILED!
Running test Simple category... FAILED!
Running test Section headings with TOC... FAILED!
Running test Media link with nasty text... FAILED!
Running test Bug 2095: link with pipe and three closing brackets... FAILED!
Running test Parser hook: static parser hook inside a comment... FAILED!
Running test Sanitizer: Validating the contents of the id attribute (bug 4515)... FAILED!
Passed 271 of 288 tests (94.1%) FAILED!
Hello,
I just created a simple form as a special page with in my wiki. This form is a simple data entry form and uses a mysql database. How can I link this database to the recent changes page. Or better yet, have a separate special page of recent changes for changes to this database only?
Any info will be greatly appreciated!
Thank you,
Victoria.
I've been trying to find a way to use Google Maps API to allow users
to identify the latitude and longitude of a business and then add it
to Yellowikis.
I asked a Google Maps "guru" about this idea and he told me:
"There's a fundamental problem trying to integrate Wikis, Google Maps and
Internet Explorer. If you can find a way past this one hurdle, then the
rest should be straight forward.
The problem is that IE refuses to allow Google Map API Javascript to be
placed inside a <div> or a <table>. Nobody really knows why, it's just
one of many bits of strange behaviour exhibited by IE. Wiki's don't like
pages to have custom content that's outside the "editsection" <div>.
The API code would like it to be possible to have a chunk of Javascript
that sits between these two lines
<!-- Served by truth in 0.14 secs. -->
</body>
(The map itself would appear in a "map" <div> within the "editsection"
<div>, it's just the associated Javascript code that must be moved.)
My understanding is that it's not easy for a Wiki page to contain custom
content there.
Possible workrounds are:
(1) Serve the map in an off-Wiki page within www.yellowikis.org. Write
the external page so that it looks something like a Wiki page. It might
then be tricky to get the user back to the Wiki page that he came from
in order to do something with the geocoded information.
(2) Serve the map in an <iframe>. Will a Wiki allow an <iframe> within
the "editsection"?
Here's a possible strategy:
A "create listing using a map" link takes the user to an off-Wikki page
www.yellowikis.org/map/map.html. The user sees a map of the world and a
set of instructions.
User zooms and pans until happy with the location, then clicks a button
that initiates the recording process. Once that button has been clicked,
a form is displayed at the side of the map, in which the user can enter
basic details like the company name, contact details and classification
codes. Clicking on the map in "record" mode causes a marker to be
displayed and the latitude and longitude to be inserted into the form.
Clicking on the map moves the marker and inserts the new latitude and
longitude into the form.
Clicking on the "Submit" button causes a few simple checks to be
performed (are the mandatory fields present?) then submits the data to
your server.
Somehow your server has to convert a wodge of data into something that's
suitable for the "editsection" of a Wiki page. Create the page if it's
not there already. Replace the stub contents if there's a stub. Do
something sensible if there already is a real entry. (You're on your own
with this section of the processing. I know nothing about PHP or the
server-side internals of wikis.)
Control then passes back to a page within the Wiki that tells the user
that the data has been accepted."
Does anyone have any thoughts on this?
Will I have to make an extension?
FYI Yellowikisis running:
* MediaWiki: 1.5.5
* PHP: 4.4.2-0.dotdeb.1 (apache)
* MySQL: 5.0-Debian_4sarge2-log
* Extensions:
o Parser hooks:
+ Inputbox by Erik Moeller
o Extension functions:
+ registerInputboxExtension
Any advice would be welcome.
Paul
--
Yellowikis is to Yellow Pages, as Wikipedia is to The Encyclopedia Britannica