Page 1 of 1
HTMLAREA editor - removed first blank line
Posted: Sat Apr 05, 2008 6:39 am
by Don Chambers
I have been annoyed by something for a long time.
Using the extended body, I have noticed that if you use the htmlarea editor and enter a few blank lines at the beginning of the extended body, the first blank line is removed when the entry is saved.
So, lets say I create an entry, using the html (non-wysiwyg) editor.... you are counting on the nl2br plugin to add <br /> markup for blank lines.
Continuing the example, I add a single blank line to the beginning of the extended body to provide separation from the entry body in detailed view. If I save the entry, this single blank line is removed.
If I enter 2 blank lines, the first is removed on save. If I continue to edit, then save again, the remaining blank line (originally the second) is now removed.
Can this behavior be changed so as not to remove the first blank line from the extended body?
Posted: Sat Apr 05, 2008 10:13 am
by kleinerChemiker
you could use css to seperate the extended body from the rest.
Re: HTMLAREA editor - removed first blank line
Posted: Sat Apr 05, 2008 1:20 pm
by garvinhicking
Hi!
Does that happen without WYSIWYG editor as well? I don't think so, right?
Regards,
Garvin
Posted: Sat Apr 05, 2008 3:30 pm
by Don Chambers
CSS is not the solution due to Garvin's next question.. it does not happen with the wysiwyg editor because wysiwyg wraps paragraphs in <p> tags.
The only reliable separator is a <br /> on the first line of extended body, but this can be very frustrating to those without html experience.
Posted: Sat Apr 05, 2008 7:48 pm
by garvinhicking
Hi!
This fix is required because in some browser the WYSIYWGT editor inserts a break or empty space into a body field, and then s9y will recognize it as "filled". Thus, in include/functions_entries.inc.php this can be found:
Code: Select all
/* WYSIWYG-editor inserts empty ' ' for extended body; this is reversed here */
if (isset($entry['extended']) && (trim($entry['extended']) == '' ||
trim($entry['extended']) == '<br />' || trim($entry['extended']) == '<p></p>' ||
str_replace(array("\r", "\n", "\t", "\0", "<br />", "<p>", "</p>", "<br>"), array('', '', '', '', '', '', '', ''), trim($entry['extended'])) == '')) {
$entry['extended'] = '';
}
However that only changed the extended entry, it should not be applied to the usual body. But if we change this, we will re-introduce the glitch that this portion fixes.
IMHO pre-seperation with newlines is bad and should not be done; CSS should be used for general distance, and in cases where you absolutely need it, manual <br>'s should do?
Regards,
Garvin
Posted: Sat Apr 05, 2008 8:06 pm
by Don Chambers
CSS is not really a solution unless the editor (wysiwyg or html) is known. The wysiwyg editor wraps all paragraphs in <p> tags, whereas the html editor does not. If the entry body is separated by, say a top margin on the extended body, it will look fine if an entry was created by the html editor, but will have too much space is both entry and extended have <p>aragraphs.
One "line" of height is also subject to css defined line height and font size, so setting that to exactly one line is also trial and error.
Leaving an extra line in the entry body is also a solution, but a visually unappealing one for a layout looking to minimize lines on an overview page.
Correct me if I am wrong here, but isn't this fix not really required as long as the user is not using the NL2BR plugin *AND* the wysiwyg editor?
Posted: Sun Apr 06, 2008 1:38 pm
by garvinhicking
Hi!
What about giving the <p> a top-margin of 0 and only work with bottom-margin? Then the spacing of the extended element will not vary if it contains a <p> and be the same like without.
Correct me if I am wrong here, but isn't this fix not really required as long as the user is not using the NL2BR plugin *AND* the wysiwyg editor?
I believe this problem is not related to nl2br (the code I pasted happens before nl2br is executed), but simply to what htmlarea sometimes gives you as first line/content even if it's empty...
Regards,
Garvin
Posted: Sun Apr 06, 2008 4:47 pm
by Don Chambers
Bottom-only margin on <p>'s would create an undesireable increase in length/height to an entry when only the entry body is showing...... this is why you really want the separation to be applied at the beginning of the extended body - it never shows without entry body.
I suppose, using smarty, one could test the extended body, and if the first 3 characters are NOT <p>, then print <br />.... but that sounds like a lot of overhead.... is it?
Posted: Sun Apr 06, 2008 5:40 pm
by garvinhicking
Hi!
You could use top-margin for the entry body, and only bottom-margin for the extended entry?
I suppose, using smarty, one could test the extended body, and if the first 3 characters are NOT <p>, then print <br />.... but that sounds like a lot of overhead.... is it?
True, that can be done, but it's also an overhead...
Maybe I'm not getting the whole picture, could you show an example of entries with undesirable margins so that I could understand why it's not solvable with CSS?
Regards,
Garvin