-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Since people seem to think the bugs have been pretty well shaken out so
far on test.wikipedia.org, I've gone ahead and turned on
$wgEnableWriteAPI on all public Wikimedia wikis.
Let's see how well stuff works! :D
- -- brion
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkizOpUACgkQwRnhpk1wk46pMgCfRRkjRY4vUGAr3OGDzrAgyYN7
G70AoJwZr8RocLqVPiKVKztACTTYpKQ3
=GWoW
-----END PGP SIGNATURE-----
On Mon, Aug 25, 2008 at 2:50 AM, <dantman(a)svn.wikimedia.org> wrote:
> Revision: 39938
> Author: dantman
> Date: 2008-08-25 06:50:31 +0000 (Mon, 25 Aug 2008)
>
> Log Message:
> -----------
> Revert 39936 and 39935;
> This 'fix' is merely a bad workaround and creates more issues rather than simply fixing.
> A) Part of the Title class is being /duplicated/ meaning more bugs are going to show up when someone improves stuff inside Title and doesn't know stuff is duplicated here.
> B) This change breaks cases as $wgCaptialLinks is now a per-namespace array, not a boolean.
No it isn't, that patch hasn't been committed. The correct function call
(once it's committed) will be MWNamespace::isCapitalized( $index ).
Fwiw: running a title through Title::newFromText() eventually runs it
through $title->secureAndSplit(), which does all kinds of fun normalization
(including forced first-letter capitalization). Personally, I'd rather
see _more_
of the logic for first-letter-case-sensitivity go there, rather than have
$wgCapitalLinks floating around everywhere.
As to the original bug: I say "invalid" myself. Trailing spaces and leading
spaces are _always_ trimmed. Thoughts on this?
-Chad
or in some other wise breaking the rules, as it feels like to me?
http://www.nationmaster.com/encyclopedia/Nuclear-Football
Cheers,
-- jra
--
Jay R. Ashworth Baylink jra(a)baylink.com
Designer The Things I Think RFC 2100
Ashworth & Associates http://baylink.pitas.com '87 e24
St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
Those who cast the vote decide nothing.
Those who count the vote decide everything.
-- (Josef Stalin)
aaron(a)svn.wikimedia.org wrote:
> Revision: 39675
> Author: aaron
> Date: 2008-08-20 01:03:01 +0000 (Wed, 20 Aug 2008)
>
> Log Message:
> -----------
> Remark static functions for performance. Same 15 test failures as before this change.
>
> Modified Paths:
> --------------
> trunk/phase3/includes/parser/Parser.php
>
>
[...]
> * @param string &$after set to everything after the ':'
> * return string the position of the ':', or false if none found
> */
> - function findColonNoLinks($str, &$before, &$after) {
> + static function findColonNoLinks($str, &$before, &$after) {
>
There are several problems with this.
First, the performance gain. I measured a performance difference of only
150ns per call, on my laptop. This is extremely small. I could only
reliably detect it with a tight unrolled loop of function calls. For
comparison, this baseline loop took 120ns per iteration:
for ( $i = 0; $i < 10000000; $i++ ) {
}
Suffice to say that anything at all that you do in a practical PHP
program will swamp the effect of replacing object calls with static calls.
So it has no significant performance benefit, but it also makes
maintaining the code difficult. If you later decide that it would be
convenient for the functions in question to access elements of $this, a
quite reasonable expectation given that the parser is an object for
storing memoized results, then all calls will have to be changed to
access an object. Any calls using the static syntax will become fatal
errors -- including in unmaintained extensions that aren't in our
repository.
Not only that, but static functions in classes such as Parser derail our
attempts to implement a runtime-extensible object model. We now have the
ability to plug in alternate parsers at runtime, such as Parser_OldPP
and Parser_DiffTest. This is only possible when you never name the
parser class in code external to that class. If an extension makes a
call like this:
$pos = Parser::findColonNoLinks($s, $before, $after);
then they have broken the object model, made differential unit testing
more difficult, and possibly introduced bugs. In theory, the correct
call would be:
$class = get_class( $wgParser );
$pos = call_user_func_array( array( $class, 'findColonNoLinks' ),
array( $s, &$before, &$after) );
But who's going to bother with that, right? This is simpler and faster:
$pos = $wgParser->findColonNoLinks($s, $before, $after);
The third problem is that PHP (before 5.3) doesn't resolve static calls
to self:: using the object context, instead it uses the lexical context.
If an extension creates a plug-in parser called ParserChild which
extends Parser, then when Parser calls self::foo(), it will resolve to
Parser::foo(), instead of ParserChild::foo(). This denies the child
class the ability to override that functionality.
I think classes such as Parser should not use static functions at all,
except for certain well-defined administrative roles, such as factory
functions. This applies not only to the classes which already have
dynamic names at runtime (Database, Parser, File, Article), but also to
classes which would benefit from this kind of architecture in the future
(User, OutputPage, SiteConfiguration).
-- Tim Starling
Hi,
Every release of MW since 1.10 I've been making a tweak to the
rebuildtextindex.php to replace line 60 with the following code:
if($s->page_namespace != NS_MAIN)
{
global $wgContLang;
$title = $wgContLang->getNsText( $s->page_namespace ) . ':'
. $s->page_title;
}
else
{
$title = $s->page_title;
}
$u = new SearchUpdate( $s->page_id, $title, $revtext );
I have no idea how the best way to get this into the main code base is, but
I'm pretty sure as it stands its wrong in everyone's eyes - since the
namespace information is currently lost. Ideally SearchUpdate would be
refactored to take a namespace parameter, but this at least allows it to be
retrieved intact. I found this problem when adding an extension to index the
other namespaces. Or should I be using something else to rebuild the text
search?
Kind regards,
Alex
--
Alex Powell
Exscien Training Ltd
Tel: +44 (0) 1865 876562
Mob: +44 (0) 7717 765210
skype: alexp700
mailto:alexp@exscien.com
http://www.exscien.com
Registered in England and Wales 05927635, Unit 10 Wheatley Business Centre,
Old London Road, Wheatley, OX33 1XW, England
i'm trying to add content to the body of my wiki documents. the requirements
are the following:
1. do not display content in edit window
2. cache content as normal
so far the closest hook to this seems like ParserAfterTidy, but the content
seems to disappear on edits and remains gone until the cache is flushed.
what technique should I use?
thanks in advance
--
View this message in context: http://www.nabble.com/what%27s-the-proper-hook-to-append-content-within-the…
Sent from the Wikipedia Developers mailing list archive at Nabble.com.
On Fri, Aug 22, 2008 at 12:56 AM, <brion(a)svn.wikimedia.org> wrote:
> Revision: 39799
> Author: brion
> Date: 2008-08-21 22:56:45 +0000 (Thu, 21 Aug 2008)
>
> Log Message:
> -----------
> Revert r39793 "* (bug 13879) Special:EmailUser shows a form in case no user was specified" for the moment
> * Recipient name seems to be output raw into HTML form; this is insecure
There was an htmlspecialchars around it:
> - $recipient = $this->target instanceof User ?
> - htmlspecialchars( $this->target->getName() ) :
> - '';
> * We've lost the link to the target's user page in the primary use case (followed 'email this user' link)
You suggest that we only show the input box in case no target or an
invalid target is specified and else the current behaviour with a link
to the receipent?
Bryan
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
greg(a)svn.wikimedia.org wrote:
> Force inserted bools to be ints, per Tim's suggestion on bug 15148.
> This should be fine for now as Postgres uses SMALLINTs for BOOLs, to
> match MySQLs BOOL/TINYINT aliasing and subsequent MW coding assumptions.
> It's possible this will cause bad effects if inserted values are called
> in a boolean context when they are going into a non-SMALLINT column, but we can handle
> those as they come up.
[snip]
> function addQuotes( $s ) {
> if ( is_null( $s ) ) {
> return 'NULL';
> + } else if ( is_bool( $s ) ) {
> + return intval( $s );
It probably wouldn't hurt to do this on general principle in the base
class. Some quick background:
PHP's boolean type interpolates to string as:
true -> "1"
false -> ""
MySQL's "bool" column type is an alias to "tinyint" (which we use, as
"bool" didn't exist in earlier MySQL versions), where you generally
store 1 or 0. However if you stick '' in there it gets automatically
interpreted as 0... (does this happen in MySQL's strict mode, though?)
PostgreSQL has a "bool" data type also, which seems to accept a variety
of values:
http://www.postgresql.org/docs/8.1/static/datatype-boolean.html
none of which are "". ;)
It's also much whingier about its numeric types, and won't let us insert
an empty string, which is what a boolean false interpolates to.
Now, most of the time we explicitly use 1 and 0 when storing boolean
values in MediaWiki, like:
'page_is_new' => ($lastRevision === 0) ? 1 : 0,
'page_is_redirect' => $rt !== NULL ? 1 : 0,
But it'd be nice not to break if people forget and use a genuine bool...
for that matter it'd be nice to be able to do that as a matter of course. ;)
- -- brion
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkit6J0ACgkQwRnhpk1wk45XUgCgy2BL/ggyfKmHMXbauzXGPq3Q
pwAAoI2tKNJKhuU7o90pbFG9w5S/IEfR
=NrDM
-----END PGP SIGNATURE-----
$wgCentralAuthAutoNew is now enabled, which means new accounts created in
the usual way automatically become global accounts, they don't need to
manually merge.
-- Tim Starling