View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0011763 | mantisbt | other | public | 2010-04-07 15:55 | 2016-10-15 20:37 |
Reporter | david_s_nl | Assigned To | |||
Priority | normal | Severity | feature | Reproducibility | N/A |
Status | new | Resolution | open | ||
Product Version | 1.2.0 | ||||
Summary | 0011763: Ability to escape bug linking | ||||
Description | Hi, When typing the hash character followed by a number in a text field Mantis automatically creates a link to the corresponding issue, for example: 0011763 However, every now and then i encounter a situation where i want to insert for example an error log containing hashes, without having Mantis convert it to a bug link, because this complicates reading the actual text. It would be convenient if there would be a way to prevent this by using an escape character. | ||||
Additional Information | I have tested this by changing line 371 in "string_process_bug_link" in string_api.php. By doing this, if i type a backslash before the hash, it will not get converted to a link, and the backslash will not be displayed. BEWARE, i have never written a single line of code in PHP and regular expressions give me headaches... so i recommend you do NOT use this :) #do not convert to bug link if hash is preceded by backslash | ||||
Tags | No tags attached. | ||||
Attached Files | |||||
related to | 0020503 | new | Consider not expanding issues and notes internal links in some places |
I would also like to see some improvement in this area. Not only is it confusing and irritating when it insists on auto-linking something you don't want, but in some cases it can actually break Mantis. For example, someone had sarcastically written the phrase 'attempt #938402394820928309482034' in a ticket, and now any time we try to update that ticket we get this error: Database query failed. Error received from database was #-1: ERROR: value "9223372036854775807" is out of range for type integer for the query: SELECT * FROM mantis_bug_table WHERE id=$1. Evidently Mantis tries to interpret any number following a hash, no matter how comically large, as a ticket number, and then tries to look it up in the database. I'd actually worked around the problem for the most part by replacing Mantis's default formatting plug-in with one that has a sort of pre-processor for escaping.... Probably i have Mantis configured not to use my pre-processor for e-mail notifications, so that's why i still get that error. The attached file contains the method i use in my formatting plug-in for handling back-slash-escaping of # and ~, as well as auto-escaping of #, ~, and @ inside code and pre elements. Not sure how performant it is — it works pretty well for our small installation, though it needs updated to use Mantis's facilities for getting the user-configured sigils instead of having them hard-coded in. If it would be in any way useful to anybody, you can consider this code to be released under the MIT and/or GPL 2+ licences. escapeSpecialChars.php (1,420 bytes)
<?php /** * Escapes special characters that Mantis might otherwise mangle. * * @param string $text The text to process. * * @return string The text after any escaping. */ protected function escapeSpecialChars($text) { // Escape all #/@/~ inside <pre> and <code> $text = preg_replace_callback( '%(<(pre|code)(?:\s[^>]*)?>)(.+?)(</\2\s*>)%ism', function ($matches) { $matches[3] = mb_encode_numericentity( $matches[3], [ // '#' 0x23, 0x23, 0, 0xff, // '@' 0x40, 0x40, 0, 0xff, // '~' 0x7e, 0x7e, 0, 0xff, ], 'UTF-8' ); return implode('', [ $matches[1], $matches[3], $matches[4], ]); }, $text ); // Escape all #/~ preceded by back-slashes $text = preg_replace_callback( '%(\\\\+)([#~])(\d)%', function ($matches) { $backslashes = $matches[1]; $char = $matches[2]; $number = $matches[3]; // Even number of back-slashes if ( ($len = strlen($backslashes)) && $len % 2 === 0 ) { $backslashes = substr($backslashes, floor($len / 2)); // Odd number of back-slashes } else { $backslashes = substr($backslashes, floor($len / 2) + 1); $char = mb_encode_numericentity($char, [ // '#' 0x23, 0x23, 0, 0xff, // '~' 0x7e, 0x7e, 0, 0xff, ], 'UTF-8'); } return implode('', [ $backslashes, $char, $number, ]); }, $text ); return $text; } |
|
The default text formatting plugin seems to respect hash character when it is immediately preceded by any other character than white space. Attaching a screenshot showing both cases. Mantis 2.0 Beta 3. |
|
That's about right, the pattern it uses to catch bug links is: '/(^|[^\w&])' . preg_quote( $t_tag, '/' ) . '(\d+)\b/' |
|
I can't reproduce that error. If you can, please report it with details, so it can be fixed |
|
Ideally, the bug/note replacement should not be performed within preformatted parts of text. For example: "pre" tags, or equivalent notation. But that is not feasible with current system, a proper parser is required to do that correctly. |
|