-
Bug
-
Resolution: Fixed
-
Medium
-
4.0, 5.0
When using the Shift+Enter line break function in Confluence, the two words are indexed as if there is no whitespace between them and they are treated as one word by the indexer.
An example of this behaviour can be seen below:
Username: 123456
Password: abcdefg
The above content would result with the indexer seeing the strings '123456' and 'Password:', which have been separated by a Line Feed, (Shift+Enter), as one continuous string '123456Password:'.
Please see further illustration of this bug in the attached screenshots.
Workaround: Anyone impacted by this issue should add a space before using the Line Feed, (Shift+Enter), line break as this will ensure that the two strings are not seen as linked by the indexer
- is duplicated by
-
-
- Closed
-
-
-
- Closed
-
[CONFSERVER-26088] Line Feed, (Shift+Enter), line breaks cause the two surrounding words to be indexed as one word
Rhys Jones
added a comment - Thanks for re-opening Hi All
Thanks for the updates on this issue. Given the recent changes to the searching indexing (for Confluence 5.2) this issue should now be resolved. I'm going to close this issue out as Obsolete.
Regards
I have upgraded to Confluence 5.2 and this problem no longer exists for newly created pages or pages that have been edited. However, text in old pages after a <br /> tag is still not found until you rebuild the search index.
If you close the issue, please mention in the release notes that the search index should be rebuilt.
Actually, I may have spoken too soon. I hadn't yet upgraded to Confluence 5.2. From what I can tell, this bug no longer exists – I'm unable to reproduce it with either Shift+Enter or by cutting and pasting.
I blame the date (Friday the 13th) and subsequently retract my scathing complaint. Maybe I should lock the doors as well.
So, feel free to close this issue!
Atlassian! This is a onerous bug. Come on, folks. This stupid, stupid, stupid bug means I can't trust Confluence's search. It severely limits Confluence's ability as a wiki or, you know, a repository for data of any kind. Because of this bug, I have to rate UNIX grep as a more reliable and more useful tool than Confluence.
I see that this issue only has eight votes on it, but it's that way because of the subtle nature of the bug. The bug is so egregious that I'm going to comment on this issue weekly until I get a response out of the Confluence team.
I just confirmed that this problem still exists in Confluence 5.0.3 as well as Confluence 5.1. Please add these to affectedVersion – I would do so myself, but I don't have access.
This also happens when pasting content that contains breaks. We have a large amount of documentation that was pasted into Confluence that we cannot find via certain common keyword searches. Here's an example HTML document that you may use to reproduce the issue:
<!DOCTYPE html>
<html>
<head>
<title>test document</title>
</head>
<body>
<p>
This short block below, when pasted into the Confluence rich
text editor, will be indexed as a single word instead of two
separate words.
</p>
<code>banana</code><br />
<code>phone</code>
</body>
</html>
When pasted into Confluence, it appears as two separate lines, but the RTE indicates that the mode is Paragraph and not Preformatted, despite being monospaced. When searching, results appear for neither banana nor phone, but for bananaphone. I agree with Aaron that this problem should be escalated to critical. It impairs the search indexer and search is a very visible barometer for the usability of a content management system like Confluence.
As pointed out by mike.eldridge, this is fixed in Confluence 5.2. I tested it to confirm today - I'll attach screenshots of my test case.