Hi all,
I got a bit perplexed about the order in which templates are expanded.
I tested a template - inside a ParserFunction - inside a parameter
(representing the |default}} value ), but, to my big surprise, the
template obviously expanded inside the parameter! That is, :
1. before ParserFunction (#if: evaluated "yes, a valid string")
2. which was returned as the default value for the parameter.
Simplified: In the simple parameter "{{{param|default}}}" I replaced
"default" by the slightly more complex expression :
{{{param|{{#if:{{GetSomeTitle}}|{{GetSomeTitle}}}}}}} which returned
= SomeTitle
or, more readable:
{{{param|
{{ #if: {{GetSomeTitle}} | {{GetSomeTitle}} }}
}}}
= SomeTitle
(the template GetSomeTitle returns the string "SomeTitle").
What surprised me was that the template (seemingly) were expanded
BEFORE the parameter, which I expected to be resolved before calling
any subsequent templates. Thus it seemd like a hen-or-egg-first
phenomenon... :)
Obviously I must have missed something.
Is there any documentation page which correctly describes the order in
which evaluation is performed of the following (on expand / parse) :
a. Strip for "no parse".
b. Magicwords
c. Parameters
d. Templates
e. Variables (StringFunctions)
f. ParserFunctions (#if:, #ifeq: etc.)
g. Unstrip
And also whether any of the above (forgot some?) are repeated before
and/or after any of the other in the list.
All shared insights on this topic would be much appreciated, TIA.
Regards,
// Rolf Lampa
An automated run of parserTests.php showed the following failures:
This is MediaWiki version 1.12alpha (r26677).
Reading tests from "maintenance/parserTests.txt"...
Reading tests from "extensions/Cite/citeParserTests.txt"...
Reading tests from "extensions/Poem/poemParserTests.txt"...
Reading tests from "extensions/LabeledSectionTransclusion/lstParserTests.txt"...
17 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://lists.wikimedia.org/mailman/htdig/wikitech-l/2006-April/022293.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]
* 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 527 of 544 tests (96.88%)... 17 tests failed!
Hello all,
The Liquid Threads extension needs several changes to core code in
order to function. None of them overtly mention Liquid Threads; most
of them are just new hooks. They currently live in the liquidthreads
branch, but we would like them to be merged into trunk so that Liquid
Threads can be a pure, easy-to-install extension.
Here's the patch:
http://wikixp.org/lqt-changes-to-trunk-as-of-r26530.txt
Here's a description of the changes, and what they're for. Again,
none of them should have any effect unless Liquid Threads is installed.
Linker.php:
Allow a hook to determine whether a page gets a red link or a blue one.
OutputPage.php:
Accessor method for mRedirect.
SpecialWatchlist.php:
Allow a hook to insert extra SQL into the watchlist query. (We use
this to exclude threads from the watchlist, since we show watched
threads on our own page).
Wiki.php:
Allow a hook to run at the beginning of Mediawiki::performAction().
This is our main entry-point, which we use to display threads and
talkpages specially.
ChangesList.php:
Allow a hook to add extra HTML to RC entries.
Title.php:
Allow a hook to override Title::getRestrictions().
SpecialPage.php:
Normally, the subpage part of a title is stripped out, but we make
this optional, so a special page can receive the information by
setting its mStripSubpages property to false.
EditPage.php:
Several changes:
Added $editFormTextBeforeContent, which works the same way as
$editFormTextTop, etc. It allows us to insert HTML into the edit form
at the appropriate place for a subject field.
Added $didSave, which is set to true when EditPage decides to save an
article, so that appropriate post-save action can be taken (such as
inserting the article into a thread table). Otherwise, there's no way
to see what happened after calling the monolithic edit().
Replaced some instances of $this->mTitle with $this->mArticle()-
>getTitle(). EditPage has been using the same mTitle object (and
occasionally wgTitle, but they're the same object) to refer to two
conceptually separate things: the title indicated by the request URL
(where forms should be posted), and the title of the article being
edited. MW assumes that these are the same title, but Liquid Threads
breaks that assumption, so we need to be able to treat with two
separate title objects. We use $this->mTitle anywhere the web
requests or user-interface is concerned, and $this->mArticle()-
>getTitle() when examining or modifying the database.
The value of mArticle and mTitle are both set by EditPage's
constructor: mArticle comes from the method argument, but mTitle is
copied from wgTitle. This means that the two can be set to separate
articles when EditPage is instantiated -- but under normal operation,
they are set to the same article. So EditPage behaves in exactly the
normal way, except when an extension uses this functionality by
passing a different article to the constructor.
That's it. Please review these changes. If I don't hear anything,
I'll commit them into the trunk on Friday. Thanks!
--
David McCabe
It is possible to display the _number_of_watching_users_ in the footer of every
page. However, as an admin of my wiki, I have received numerous requests to also
somehow dislay the WHO in addition to the HOW_MANY. Is there an existing
hook/extension/feature of the wiki to extract and display that information?
Thanks,
Paul.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
catrope(a)svn.wikimedia.org wrote:
> Revision: 26591
> Author: catrope
> Date: 2007-10-11 12:31:46 +0000 (Thu, 11 Oct 2007)
>
> Log Message:
> -----------
> (bug 11612) Days to show in recent changes cannot be larger than 7
Note that Special:Recentchanges and Special:Watchlist still happily
offer you up to 30 days, although the default value for $wgRCMaxAge is 7
days.
Additionally, inconsistent random application on smaller sites means
that you may often see many more than 7 days in the list, which is a bit
odd.
We could probably use some better consistency here:
* Apply the max age to the displayed limit links in RC, Watchlist, and
other tools using the recentchanges table as a base.
* Some better feedback on the prefs form as to what the available range is.
* Smaller, more frequent trimming of old data. On a heavily edited site,
rare trimming leads to intermittent replication lag as a lot of rows
have to get removed at once off the end; on a lightly edited site, a lot
of visible rows accumulate, then disappear randomly without explanation.
* A longer default which would be friendlier to lightly-edited sites.
- -- brion vibber (brion @ wikimedia.org)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHD9fZwRnhpk1wk44RAnjxAJ9lChtOo5tUe9TbKRPbBus9bg5vFQCeJHDd
wKIOh+yHNMGVXQhDeAhecRQ=
=64ud
-----END PGP SIGNATURE-----
An automated run of parserTests.php showed the following failures:
This is MediaWiki version 1.12alpha (r26623).
Reading tests from "maintenance/parserTests.txt"...
Reading tests from "extensions/Cite/citeParserTests.txt"...
Reading tests from "extensions/Poem/poemParserTests.txt"...
Reading tests from "extensions/LabeledSectionTransclusion/lstParserTests.txt"...
17 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://lists.wikimedia.org/mailman/htdig/wikitech-l/2006-April/022293.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]
* 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 527 of 544 tests (96.88%)... 17 tests failed!
On 10/11/07, nickj(a)svn.wikimedia.org <nickj(a)svn.wikimedia.org> wrote:
> * Bug 11629 - If $wgEmailConfirmToEdit is true, require people to supply an
> email address when registering.
Does this behavior make sense if users with unconfirmed e-mail
addresses aren't allowed to edit but are, for instance, allowed to
view pages that other users aren't? For that matter, users may want
to make an account just to set viewing preferences, say. I'm not sure
that an e-mail address should be required for registration just
because it's required for editing.
Incidentally, is there some reason we aren't using
$wgGroupPermissions['*']['edit'] = $wgGroupPermissions['user']['edit']
= false; $wgGroupPermissions['emailconfirmed']['edit'] = true;
instead of a dedicated option? Historical reasons, or something else?
Hi All,
I just joined the OTRS team a short time ago but I noticed a chronic problem
with the Arabic OTRS system, most of the messages in Arabic come to us
encoded as Windows-1256 and not UTF-8 unfortunately (probably because MS
Outlook, the prevalent client in Arab-speaking countries encodes them as
such) , therefore to read them, we have to switch to plain view then change
the encoding from the browser to read the mail, this is a minor
inconvenience, the big problem however is that when we send them back a
response through the system, users receive it as gibberish (I am guessing it
is UTF-8 encoded). I have seen a lot of users complain in the short time I
have been on OTRS that we are sending out unintelligible messages as
response to them. Does this have a solution? how does OTRS handles encoding
in general? do volunteers for other languages have the same problem?
--
Best Regards,
Muhammad Alsebaey
It has been discussed here before about the captchas which are too hard
to pass. However, without samples.
Today i found one of these captchas. I read ghooktrust but mediawiki
didn't agree. The first letter could be a 5, but we don't use numbers.
So i now finally noticed it might be an s
Anyone wishing to test its humaness?
http://upload.wikimedia.org/wikipedia/test/f/f5/WpCaptchaId_734931244.gif
