tstarling(a)svn.wikimedia.org wrote:
> Revision: 40850
> Author: tstarling
> Date: 2008-09-15 07:10:40 +0000 (Mon, 15 Sep 2008)
>
> Log Message:
> -----------
> It's incorrect to use both Sanitizer::escapeHtmlAllowEntities() and Parser::recursiveTagParse(). Parser::recursiveTagParse() accepts plain wikitext as input, and will handle any invalid entities itself.
>
> Note that ideally, ImageMap would parse the image options in the same way as the parser does image links. This would mean replaceVariables(), removeHTMLtags(), doTableStuff(), <hr/>, doDoubleUnderscore(), doHeadings(), DateFormatter::reformat(), doAllQuotes(), replaceExternalLinks() and replaceInternalLinks2(). But recursiveTagParse() is almost the same anyway: only doMagicLinks() and formatHeadings() are added, and RIL/REL are done in the opposite order.
>
> Modified Paths:
> --------------
> trunk/extensions/ImageMap/ImageMap_body.php
>
> Modified: trunk/extensions/ImageMap/ImageMap_body.php
> ===================================================================
> --- trunk/extensions/ImageMap/ImageMap_body.php 2008-09-15 06:37:57 UTC (rev 40849)
> +++ trunk/extensions/ImageMap/ImageMap_body.php 2008-09-15 07:10:40 UTC (rev 40850)
> @@ -71,7 +71,7 @@
> return self::error( 'imagemap_bad_image' );
> }
> // Parse the options so we can use links and the like in the caption
> - $parsedoptions = $parser->recursiveTagParse( Sanitizer::escapeHtmlAllowEntities($options) );
> + $parsedoptions = $parser->recursiveTagParse( $options );
> $imageHTML = $parser->makeImage( $imageTitle, $parsedoptions );
> $parser->mOutput->addImage( $imageTitle->getDBkey() );
>
>
>
That's what I expected, but using Parser::recursiveTagParse() on
'thumb|right|250px|Area Codes 304 & 681' returns 'thumb|right|250px|Area
Codes 304 & 681', the & is not replaced with & and causes ImageMap
to return an 'imagemap_invalid_image' error (bug 15289). Is this a bug
with the parser, or the way ImageMap handles the output?
--
Alex (w:en:User:Mr.Z-man)
Hi,
Media Wiki is a great democratic tool, allowing anyone to
easily create beautiful content. But it has the potential to
also become an important tool *for* a democracy, by allowing
complex disputed cases to be closely argued and clearly
explained.
To best support this, it would appear that a new mode needs to
be added to Media Wiki that displays a pair of hierarchically-
expandable wiki streams side-by-side.
An example of what I'm suggesting can be seen at makethecase.net,
a site I created over five years ago using a now obsolete
system (and some rather primitive HTML skills). Though I'm now
a proficient Ruby on Rails programmer, I think it would be
better to create an updated system using Media Wiki, the premier
modern CMS. However I don't know much about PHP, so am looking
for anyone who would like to work alone, with me, or with others,
to make this a reality.
To this end, I've created a bug report for this enhancement:
https://bugzilla.wikimedia.org/show_bug.cgi?id=15423
I really think this would be a useful tool that would complement
Wikipedia, as I argued here: http://makethecase.net/why.html .
Regards,
Mark
Now that we can make our own robots.txt as a system message, wikis wanting
to start one will want to know what is already there (since it overrides the
"real" one), so we are not changing things which shouldn't be changed. Is
robots.txt available on noc or somewhere else?
As well, can we add a bare-bones robots.txt to SVN as a place to start?
(shouldn't take effect unless the system message exists though)
Mike
aaron(a)svn.wikimedia.org wrote:
> /**
> + * Additional functions to be performed with updateSpecialPages.
> + * Expensive Querypages are already updated.
> + */
> +$wgSpecialPageCacheUpdates = array(
> + 'Statistics' => 'SiteStatsUpdate::cacheUpdate'
> +);
>
This is the second time I've seen this, and I'm pretty sure it was from
two different authors.
DO NOT use a double-colon to specify calls to static functions!
Use an array instead: array( 'SiteStatsUpdate', 'cacheUpdate' )
Double-colons only work since 5.2.3, which means they may work during
development, but they will fail on some Wikimedia servers and on many
external installations.
The ONLY place where you should use a double-colon is in $wgHooks. We
had to use a double-colon in $wgHooks, with explode() to convert it to
an array, because arrays were already used for another purpose (passing
parameters).
-- Tim Starling
Hi everyone,
we use the Social Profile extension
(www.mediawiki.org/wiki/Extension:SocialProfile). Regular Mediawiki
behaviour is to make a hyperlink red when there is no article yet. As
SP hijacks the regular User:somename article and replaces it with the
social profile page, the link to the user's page always appears in
red, even when the user has completed their profile.
Where can I change the CSS to fix this? In Monobook, main.css contains
the element a.new with red color. How do I change the skin to not add
class="new" to "a href" if the link is to a User:somename article?
current link:
<a href="/w/index.php?title=User:First.Last&action=edit"
class="new" title="User:First.Last">First Last</a>
And CSS being:
a.new, #p-personal a.new {
color: #ba0000;
Makes it a redlink.
Thanks,
Andi
I don't want to complain but...
I submitted a patch to fix three imagemap bugs - 9126, 8718 and 8788.
The patch is attached to https://bugzilla.wikimedia.org/show_bug.cgi?id=9126
The first version of this patch was submitted on June 5, 2007 - over a
year ago. I have been updating it regularly for MW updates and other
imagemap patches since then so it now is compatible with 1.13 (but with
the current trunk version of the i18n file).
It needs to be reviewed and no one has reviewed it in all that time.
Should I continue to keep it up-to-date or is this going to be ignored?
Mike
mrzman(a)svn.wikimedia.org wrote:
> Revision: 40723
> Author: mrzman
> Date: 2008-09-11 03:50:53 +0000 (Thu, 11 Sep 2008)
>
> Log Message:
> -----------
> (bug 15551) Show deletion log excerpts when a user follows a redlink, even if they can't edit the page.
>
Note that the deletion log excerpt was removed from the article page in r22856 [1].
[1] http://svn.wikimedia.org/viewvc/mediawiki?view=rev&revision=22856