Patch (to be ported)
Project:
TableField
Version:
8.x-2.x-dev
Component:
User interface
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
19 Mar 2013 at 16:57 UTC
Updated:
11 Jun 2019 at 15:28 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
likewhoa commentedThis module seems to be ignoring "Text Formats" as using the default "Filtered HTML" as a test and pasting text with line breaks doesn't actually work as expected.
Comment #2
jenlamptonI'm unable to reproduce this issue. Would you please update to the latest 2.x dev and try again. Please comment here if the issue is resolved or not for you! :)
Comment #3
jenlamptonSince this was a fairly old issue I'm going to assume it has been fixed between now and when the issue was filed. If anyone has problems with text formats please reopen.
Comment #4
ishan.dikshit commentedI can't find a solution to this. I am unable to enter line breaks in the table field cells even after selecting 'Filtered Text' option. Kindly help.
Comment #5
lolandese commentedTablefield uses the form type text fields for the input instead of text areas. That probably explains why WYSIWYG editors are not applied.
Still all the allowed HTML tags that belong to a certain text format are retained and that is likely the intention of the option to apply them to the tablefield input fields. So to have multiple lines you should use the
<br />tag directly, like e.g.:<em>first line<br />second line</em>It's true that applying a WYSIWIG would allow for copy pasting line breaks correctly. This can be considered a feature request. If copying from another node's body field you can also Switch to plain text editor and use the HTML from there. You can also use an online text to HTML converter or use the body field of a temporary node for that.
I tend to go for a simpler solution where only line-breaks and paragraphs are converted to
<br />and<p></p>when pasting. See PHP: nl2br - Manual.Comment #6
lolandese commentedClosed #1878222: Show markup styling in edit view? as a duplicate of this issue.
Comment #7
lolandese commentedWork in progress.
Comment #8
lolandese commentedComment #9
lolandese commentedComment #10
lolandese commentedAlso JSON display mode should be tested on validity as line breaks should then be converted correctly.
Comment #11
lolandese commentedComment #12
lolandese commentedI guess double quotes should be escaped in Raw data (JSON) output.
Comment #13
lolandese commentedComment #14
lolandese commentedA start to get WYSIWYG would be:
Note
'text_format' => t('text_format (wysiwyg)'),. It would however need additional changes. Furthermore instead of storing only the value of the field it stores an array consisting of 'format' and 'value'. I then requires an is_array() condition throughout the code. Advantage is that the text_format can be set per cell.Above patch can still be reviewed but only implements a simple textarea, not a WYSIWYG. After implementing that a new issue should be opened specifically asking for the feature request WYSIWYG.
Also probably this existing snippet should be made optional:
Comment #15
lolandese commentedIn Raw data (JSON or XML) output we should strip all line breaks if a cell is used as an array key.
Comment #16
lolandese commentedComment #18
lolandese commentedNote that in some cases it is necessary to save content twice to get the line breaks applied correctly:
Opened #2869429: Text area: save content twice to get the line breaks applied correctly.
Comment #19
lolandese commentedAs follow up also opened #2869454: Text area: WYSIWYG support.
Comment #20
lolandese commentedNot sure why we used htmlspecialchars() on non plain text area but it results in undesired encoded stuff in out output.
Removing it.
Comment #23
lolandese commented