Last modified: 2011-07-22 14:54:04 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T26555, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 24555 - Some parameters will not render when Semantic Maps shows queried data using a template for formatting
Some parameters will not render when Semantic Maps shows queried data using a...
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
SemanticMaps (Other open bugs)
unspecified
All All
: Normal minor (vote)
: ---
Assigned To: Jeroen De Dauw
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-07-27 11:46 UTC by Hans-Joerg Happel
Modified: 2011-07-22 14:54 UTC (History)
0 users

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Hans-Joerg Happel 2010-07-27 11:46:12 UTC
I encountered several problems when rendering a Semantic Maps marker using templates.

===========================
a) "=" in template parameter values considered harmful
===========================

When I tried to render three parameters in a simple template ({{{1}}} {{{2}}} {{{3}}}) it happened that some of the template variables were not replaced by actual parameters (which were actually queried correnctly, as tested by chekching format=table output of the same query).

Investigating the problem more deeply it appeared that especially parameters of annotation type URL and Email caused trouble. Looking into SM_MapPrinter.php (method addResultRow()) I found line 246 ($label[] = $object->getLongText( $outputmode, $skin );) being the tricky part.

This causes a plain input value "my@mail.xyz" to be transformed in a string "<a href="mailto:my@mail.xyz" class="external " title="mailto:my@mail.xyz">" which is then later ($text = preg_replace( '/\n+/m', '<br />', $wgParser->recursiveTagParse( '{{' . implode( '|', $segments ) . '}}' ) );) parsed as template code.

This ultimately fails (i.e. does not bind the value to the template variable) most probably due to the "=" sign (c.f. http://en.wikipedia.org/wiki/Help:Template#URL_problems).

A fix for this issue (as indicated in the text just referenced) is to explicitly prefix all template variables with their positon (i.e. "1=myvale"). The following code, inserted just before the line ("$segments = array_merge(") does the job for me:

// start
$n=0;
foreach($label as $l){
$label[$n] = ($n+1) . "=" . $label[$n]; // do explicit template numbering to avoid http://en.wikipedia.org/wiki/Help:Template#URL_problems
    $n++;
}
// end


===========================
b) Template parameters not available in raw form
===========================

A second, related concern is the fact that passing result values in a "rendered" style (e.g. "<a href="mailto:my@mail.xyz" class="external " title="mailto:my@mail.xyz">" instead of "my@mail.xyz") reduces flexibility in template design since the "raw" data can not be used.

Therefore I changed
  $label[] = $object->getLongText( $outputmode, $skin );
to
  $label[] =  $object->getWikiValue();
 
While this seems to work in the first, I can not rule out probable side-effects of this completely (due to lack of overview about the general code).

The same issue applies to the title as well:
* if ( $this->template ) $titleForTemplate = $object->getLongText( $outputmode, NULL );
* vs. if ( $this->template ) $titleForTemplate = $object->getWikiValue();

NOTE: although changes suggested in b) seem to resolve a) at a first glance, this is not completely true - especially if you have URLs with "=" as raw data ("http://www.myweb.com/index.php?var=1" -> will break while "1=http://www.myweb.com/index.php?var=1" works).



My system setup is:

MediaWiki  	1.15.4
PHP 	5.2.11-pl0-udmedia (apache)
MySQL 	5.0.83-log
Maps  (Version 0.6.5) (recent SVN head)
Semantic MediaWiki  (Version 1.5.1.1)
Semantic Maps (Version 0.6.5 rc1)
(plus various other extensions)
Comment 1 Jeroen De Dauw 2010-07-27 13:38:57 UTC
Thanks for bringing this issue and the one described in bug 24556 to my attention. These things used to work properly at some point in the past, so must somehow have broken. I will look into this when I have time, but that can take a while. Feel free to poke at it yourself and send a patch when fixing it though :)
Comment 2 Hans-Joerg Happel 2010-07-27 14:32:33 UTC
Sure I can prepare a patch. However, it would be great if you could give me some rough input regarding certain design decisions:

1) Backwards compability: changes proposed in part b) will create a slighly different behaviour and might break templates in use based on the current implementation. Is this OK? (Besides that, Bug 24556 needs to be resolved before doing so).

2) Side-effects: based on the code of SM_MapPrinter.php, I can not see many possible side-effects when modifying $this->locations['text'] for template mode. Do you agree on that, or is there anything else I should be aware of (I am used to MW extension development, but I did not yet dig deep into Maps/SemanticMaps except of for the issue described here).

3) Genericity: Without thinking too much about it I guess there might be further cases (special chars in page titles etc.) which might break the template rendering. Were there any past considerations of such issues and what is the philosophy you recommend for implementation (try to catch/avoid as many cases in the code vs. telling people how to avoid certain issues in the docs)?

4) Reuse: You said things used to work properly in the past. Could it be worthwhile to investigate/re-adapt the past solution? Do you have any kind of pointer (time/incident) regarding this?
Comment 3 Jeroen De Dauw 2011-07-22 14:54:04 UTC
This should have been fixed quite a while ago :)

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links