Bug #16217
closed
Leading and trailing blanks can't be edited
100%
Description
I will explain this issue by an example:
Following input ([blank] stands for a blank)
[blank]test[blank]
to an RTE field inserted and saved with "RTE disabled" or pasted into an htmlarea powered RTE field will render to the following HTML code inside the textarea tags delivered by htmlarea:
<p>[blank]test[blank]</p>
The two blanks are still there but can't be properly edited when the RTE is enabled (why?):
In IE, they are partially removed after saving (generally spoken, leading blanks seem to be removed somewhere, trailing blanks seem to be editable).
In Firefox, all leading and trailing blanks are still there after saving and never editable.
Under certain circumstances (eg if sorting in the backend is triggered by a RTE field and editors are supposed to always use the RTE and copy and paste from the outside world) this can be pretty bothering.
Suggestion for resolving the issue:
One possible fix would be to assure a consistent behaviour and trim all leading and trailing white-space from rte->db. That approach might not be acceptable for all circumstances although at this time, I can't imagine why one would like to have leading or trailing white-space in an RTE field which afterwards isn't properly editable anyways.
The suggested behaviour could be simply achieved by patching the core... hm... I'm fine with that and it's just a suggestion.
t3lib_parsehtml_proc::TS_transform_db in class.t3lib_parsehtml_proc.php
}
$this->TS_transform_db_safecounter++;return implode('',$blockSplit);
}
---
< }
< $this->TS_transform_db_safecounter++;
<
< return trim(implode('',$blockSplit));
< }
(issue imported from #M3632)
Files
Updated by 
Updated by 
Updated by 
Updated by 
Updated by 
Updated by 
Updated by