Last modified: 2012-06-08 11:10:40 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 T36013, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 34013 - ask/show "intro", "outro" and "default" parameter issues (1.7.1)
ask/show "intro", "outro" and "default" parameter issues (1.7.1)
Status: NEW
Product: MediaWiki extensions
Classification: Unclassified
Semantic MediaWiki (Other open bugs)
unspecified
All All
: Unprioritized normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-01-29 02:14 UTC by Daniel A. R. Werner
Modified: 2012-06-08 11:10 UTC (History)
3 users (show)

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


Attachments

Description Daniel A. R. Werner 2012-01-29 02:14:26 UTC
I think since Version 1.7 "intro", "outro" and "default" don't trim() their values anymore before applying them.
This makes the replacement of "_" against " " useless. So either they should trim() or the replacement should be omitted.
It would also be enough to just replace leading and tailing "_" but not those in the middle.
There is also a replacement of "_" happening for the 'default' parameter, I can't see why.

It might be worth re-thinking the whole concept of these parameters. On the other hand, they are in use for a long time already and it might break stuff changing their behavior more radically.

Anyway, there is also Bug 28075 which suggests to expand the 'default' only when needed. I suggest doing the same for 'intro' and 'outro' and perhaps moving the parameter handling to the parser functions instead of handling it within the SMWResultPrinter.

'Intro' and 'Outro' are getting handled twice right now it seems, for one in SMWQueryProcessor::getResultFromQuery() but also in SMWResultPrinter

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


Navigation
Links