With WYSIWYG not set to activate editor, enter the following text into the body of a node:

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Fusce dolor. Sed eleifend rhoncus velit. Sed pellentesque turpis sed enim. Sed vulputate ultrices magna. Mauris ut pede. Vivamus sem urna, auctor nec, varius sed, porta aliquet, velit. Sed tincidunt quam id est. Nunc enim massa, ultrices sit amet, pharetra eu, egestas vitae, est. Fusce massa. Donec pretium tellus eget nunc. Quisque diam libero, vulputate sed, accumsan ac, tempus ut, quam. Cras posuere elementum urna. Sed facilisis nunc in diam.

Nullam malesuada, ligula vitae viverra mollis, nunc metus rutrum urna, eu elementum orci sem ut libero. Duis blandit velit ut arcu auctor scelerisque. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas. Proin convallis tellus ut pede. Nulla ac diam vitae ipsum adipiscing mollis. In eget justo vitae eros consequat porta. Phasellus fringilla ultricies tellus. Cras lorem dui, porttitor in, vestibulum a, ullamcorper cursus, tortor. Donec commodo mi. Etiam neque massa, imperdiet quis, gravida eu, gravida vel, sapien. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Curabitur fringilla diam dictum quam. Ut magna.

Cras a felis quis diam congue sagittis. Quisque vitae quam in purus eleifend condimentum. Aliquam erat volutpat. Proin non nulla. Donec at nisl. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Suspendisse enim mi, volutpat et, porttitor sed, pellentesque viverra, lacus. Fusce aliquet cursus tortor. Donec quis ligula a nibh convallis ultrices. Aliquam ullamcorper enim at mauris. Praesent viverra, purus vel tincidunt dignissim, quam urna dapibus nibh, vel dapibus est erat ut orci. Morbi ultrices odio non leo. Nullam faucibus. Aliquam aliquet mauris. Ut aliquam rhoncus urna. Integer commodo sem vel sapien.

Curabitur malesuada luctus diam. Phasellus non massa eu lectus cursus faucibus. Curabitur massa. Nullam nulla ipsum, varius sit amet, elementum semper, ornare eu, turpis. Duis non metus ut metus ullamcorper blandit. Integer non nisi sit amet metus elementum consectetur. Morbi ac orci vel ipsum varius aliquam. In lorem sapien, hendrerit sit amet, commodo vitae, pretium vitae, sapien. Donec eget turpis vel velit porttitor iaculis. Etiam laoreet dui eu dui. Nullam ante. Quisque sed diam eget tortor viverra tristique.

Fusce mauris nisl, commodo ut, vestibulum eu, sodales nec, lacus. Integer ultricies faucibus neque. Nullam eu mauris. Suspendisse in metus et est facilisis semper. Nam mollis vestibulum purus. Ut sed est eget dui ultrices convallis. Mauris sed tellus at orci congue tristique. Sed lobortis lorem a erat. Nunc enim turpis, laoreet vel, tempor vitae, feugiat vitae, eros. Duis fermentum. Nullam massa massa, dapibus eu, sollicitudin ultricies, lacinia et, metus. Suspendisse potenti. Nunc sodales leo eget turpis.

Leave it as Filtered HTML.

Then enable the WYSIWYG editor for TinyMCE for Filtered HTML. Edit the node you just created. You'll see that all the paragraphs have been munged together.

Furthermore, if you look at the code by clicking on TinyMCE's HTML button:

  • The HTML is now wrapped with <p> tags, which are not defined in Filtered HTML. In my case, allowed tags are <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <img>. (I think this is default?)
  • What were paragraph spaces earlier (two CRLFs) are now double spaces.

Here's the code in the editor:

<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Fusce dolor. Sed eleifend rhoncus velit. Sed pellentesque turpis sed enim. Sed vulputate ultrices magna. Mauris ut pede. Vivamus sem urna, auctor nec, varius sed, porta aliquet, velit. Sed tincidunt quam id est. Nunc enim massa, ultrices sit amet, pharetra eu, egestas vitae, est. Fusce massa. Donec pretium tellus eget nunc. Quisque diam libero, vulputate sed, accumsan ac, tempus ut, quam. Cras posuere elementum urna. Sed facilisis nunc in diam.  Nullam malesuada, ligula vitae viverra mollis, nunc metus rutrum urna, eu elementum orci sem ut libero. Duis blandit velit ut arcu auctor scelerisque. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas. Proin convallis tellus ut pede. Nulla ac diam vitae ipsum adipiscing mollis. In eget justo vitae eros consequat porta. Phasellus fringilla ultricies tellus. Cras lorem dui, porttitor in, vestibulum a, ullamcorper cursus, tortor. Donec commodo mi. Etiam neque massa, imperdiet quis, gravida eu, gravida vel, sapien. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Curabitur fringilla diam dictum quam. Ut magna.  Cras a felis quis diam congue sagittis. Quisque vitae quam in purus eleifend condimentum. Aliquam erat volutpat. Proin non nulla. Donec at nisl. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Suspendisse enim mi, volutpat et, porttitor sed, pellentesque viverra, lacus. Fusce aliquet cursus tortor. Donec quis ligula a nibh convallis ultrices. Aliquam ullamcorper enim at mauris. Praesent viverra, purus vel tincidunt dignissim, quam urna dapibus nibh, vel dapibus est erat ut orci. Morbi ultrices odio non leo. Nullam faucibus. Aliquam aliquet mauris. Ut aliquam rhoncus urna. Integer commodo sem vel sapien.  Curabitur malesuada luctus diam. Phasellus non massa eu lectus cursus faucibus. Curabitur massa. Nullam nulla ipsum, varius sit amet, elementum semper, ornare eu, turpis. Duis non metus ut metus ullamcorper blandit. Integer non nisi sit amet metus elementum consectetur. Morbi ac orci vel ipsum varius aliquam. In lorem sapien, hendrerit sit amet, commodo vitae, pretium vitae, sapien. Donec eget turpis vel velit porttitor iaculis. Etiam laoreet dui eu dui. Nullam ante. Quisque sed diam eget tortor viverra tristique.  Fusce mauris nisl, commodo ut, vestibulum eu, sodales nec, lacus. Integer ultricies faucibus neque. Nullam eu mauris. Suspendisse in metus et est facilisis semper. Nam mollis vestibulum purus. Ut sed est eget dui ultrices convallis. Mauris sed tellus at orci congue tristique. Sed lobortis lorem a erat. Nunc enim turpis, laoreet vel, tempor vitae, feugiat vitae, eros. Duis fermentum. Nullam massa massa, dapibus eu, sollicitudin ultricies, lacinia et, metus. Suspendisse potenti. Nunc sodales leo eget turpis.</p>

Comments

sun’s picture

sun
Primary language German
Location Karlsruhe
commented
Status: Active » Closed (works as designed)

This is a known issue. The paragraph filter that is enabled for "Filtered HTML" by default automatically replaces two newlines with HTML paragraphs. However, if you happen to switch to an editor, the editor will (and can) not apply the same logic to the content. In HTML, all white-space has absolutely no meaning at all.

As of now, I do not see a way how we could intercept this issue and automatically inject paragraphs, because we would apply this logic to all contents then - whether or not the logic was supposed to be applied.

Hence, I can only mark this issue as "by design".

aren cambre’s picture

aren cambre commented

So TinyMCE is incompatible with Filtered HTML?

sun’s picture

sun
Primary language German
Location Karlsruhe
commented

No. In general, every client-side editor is incompatible with the Paragraph and URL filters provided by Drupal core. You can enable/disable those filters for each input format.

aren cambre’s picture

aren cambre commented
Status: Closed (works as designed) » Active

Supposedly you can get TinyMCE to work with Drupal, but it appears not to be working as designed. I posted to their forum at http://tinymce.moxiecode.com/punbb/viewtopic.php?pid=47131#p47131.

aren cambre’s picture

aren cambre commented
Status: Active » Postponed (maintainer needs more info)

Putting this in "needs more info" until I get a satisfactory response from the TinyMCE forum.

sun’s picture

sun
Primary language German
Location Karlsruhe
commented

And I can already tell you the response of them: "We have no idea what Drupal is doing there, please consult Drupal's support."

As mentioned before, the input filters provided by Drupal core are *incompatible* with ANY client-side editor that expects HTML. Those input filters are CONVERTING plain-text into HTML, when a content is *rendered*, but not when a content is *edited*.

The only solution for this issue is to decide upfront whether you want to use an (HTML) editor - or not.

EDIT: If you want to use an (HTML-based) editor, then you need to disable those filters.

aren cambre’s picture

aren cambre commented
Status: Postponed (maintainer needs more info) » Closed (works as designed)

Not sure about that.

Atlassian uses TinyMCE for WYSIWYG in its Confluence wiki product. That TinyMCE produces a totally non-HTML wiki dialect that is strikingly different than HTML per http://confluence.atlassian.com/renderer/notationhelp.action?section=all.

I am not sure whether it's highly customized or if it's configured through options.

If I can tell TinyMCE to do what its documentation says it should do, then it can work "as is." Otherwise, you'll have to warn users that TinyMCE may screw up existing Filtered HTML content and get 2,492,231 annual support requests as opposed to 6,232,211 without the warning! :-)

aren cambre’s picture

aren cambre commented
Status: Closed (works as designed) » Postponed (maintainer needs more info)

BTW, can we keep this open until the TinyMCE folks give us a "for sure" response? I don't think the answer is clear enough to reject this yet.

sun’s picture

sun
Primary language German
Location Karlsruhe
commented
Status: Postponed (maintainer needs more info) » Closed (works as designed)

No. Sorry, I generally avoid such statements, but it seems you do not know to whom you are talking.

Please make yourself a bit more familiar with Drupal's APIs and filter system in particular.

aren cambre’s picture

aren cambre commented

I don't see where I errored. Drupal expects two vertical whitespaces to separate paragraphs in Filtered HTML. TinyMCE wants to make compliant XHTML and use P and BR instead.

A solution could be to convince TinyMCE to quit using BR and P tags and preserve whitespace. If you don't do this, then people will mess up Filtered HTML content created before they had TinyMCE because TinyMCE will screw up paragraph spacing.

Are the only options either A. full 100% XHTML or B. nothing at all? I don't think so, and that's what I am exploring with the TinyMCE folks.

sun’s picture

sun
Primary language German
Location Karlsruhe
commented

The point is not whether TinyMCE may support this or not. The point is that

a) this conversion from plain-text to HTML needs to be applied whenever an editor attaches to a textarea (an editor is loaded). Since Wysiwyg API supports more editors than TinyMCE, this needs to work independently from the editor. You should be aware of the fact that you can assign a different editor for each input format.

b) the reverse-conversion from HTML to plain-text needs to be applied whenever an editor detaches from a textarea. (an editor is removed)

c) the conversion must only happen if the new/target input format has the paragraph filter enabled, or the previous input format had it enabled and no (HTML-based) editor associated.

d) the conversion must happen in JavaScript, while the original conversion of the paragraph filter happens in PHP (which would mean duplicating code that is not easy to port to JavaScript).

e) there most probably must be an additional trigger that invokes this conversion, since it would obviously destroy your well-formed HTML from the editor otherwise.

aren cambre’s picture

aren cambre commented

this conversion from plain-text to HTML needs to be applied whenever an editor attaches to a textarea

the reverse-conversion from HTML to plain-text needs to be applied whenever an editor detaches from a textarea

If the editor can be adjusted to not require 100% pure (X)HTML, then we're OK. The biggest, maybe only (?) deal is the way paragraphs are done.

the conversion must only happen if the new/target input format has the paragraph filter enabled, or the previous input format had it enabled and no (HTML-based) editor associated.

Or if A. the editor can be adjusted per above and B. you can pass special settings to the editor instance on a per-filter basis (which I think you have already???), then no problem.

the conversion must happen in JavaScript, while the original conversion of the paragraph filter happens in PHP

there most probably must be an additional trigger that invokes this conversion, since it would obviously destroy your well-formed HTML from the editor otherwise.

No... again, if the editor can be adjusted to use Drupal's default paragraph format--vertical whitespace instead of P and BR--then we're fine. No need to emulate any PHP stuff.

sun’s picture

sun
Primary language German
Location Karlsruhe
commented

if the editor can be adjusted to use Drupal's default paragraph format--vertical whitespace instead of P and BR--then we're fine. No need to emulate any PHP stuff.

Good. Then please ensure this for all of the supported editors (including the ones that are about to be added) before wasting any more time on this issue. If you happen to find a solution that works for all editors, feel free to re-open this issue.

aren cambre’s picture

aren cambre commented

I'm scratching my head at that comment. You can have different configuration based on editor and filter. Why limit this module's usefulness to the lowest common denominator of editors?

sun’s picture

sun
Primary language German
Location Karlsruhe
commented
Title: WYSIWYG munges up paragraphs when editing pre-existing Filtered HTML content » Incompatible with paragraph/URL filters of Drupal core

See b), c), d), and e) from my previous list. A "simple setting to enable this feature in TinyMCE" (if that exists at all) does not buy us anything.

To re-open this issue, there has to be a proper and very solid concept. Just the concept will take weeks (if not months). The implementation will take even longer.

Better title.

aren cambre’s picture

aren cambre commented

Rereading your comments, I think you're confused. There is NO need for any conversions or "weeks (if not months)" of PHP work if the editor is able to use Drupal's whitespace convention instead of P and BR tags.

sun’s picture

sun
Primary language German
Location Karlsruhe
commented

Ok, here is my example flow:

1) Initial content (coming from the database):

What ever.

Foo bar.

2) Your converting editor is associated with the stored input format, it converts. Result:

<p>
What ever.
</p>

<p>
Foo bar.
</p>

3) You switch the input format to PHP code, Full HTML, or any other configured input format. Result:

<p>
What ever.
</p>

<p>
Foo bar.
</p>

4) You switch back to the input format with the converting editor associated. Result:

<p>
What ever.
</p>
<p>

</p>
<p>
Foo bar.
</p>
aren cambre’s picture

aren cambre commented

No. If TinyMCE's settings worked as they are documented, then step 2 would never happen. So if I can prevent step 2 from happening, then we've short-circuited the entire problem.

Step 4 should never happen with TinyMCE regardless of configuration.

aren cambre’s picture

aren cambre commented
Title: Incompatible with paragraph/URL filters of Drupal core » Required Drupal filter configuration not obvious
Version: 6.x-0.5 » 6.x-2.x-dev
Status: Closed (works as designed) » Active

The TinyMCE guys will not accommodate Drupal's default Filtered HTML format: http://tinymce.moxiecode.com/punbb/viewtopic.php?pid=50579. So it looks like the only practical options are either:

  1. Add the <p> tag to the default Filtered HTML filter.
  2. Use a different filter.

Without that, paragraphs get converted to <br /> tags.

This also happens with FCKEditor and presumably any editor that outputs valid XHTML.

Such an essential configuration need should be really obvious, even to someone who reads no documentation. Even if it's documented, it's buried.

I thought about asking Drupal core guys to add <p> to the default filter, but realized that may confuse the intent of the default Filtered HTML filter's handling.

sun’s picture

sun
Primary language German
Location Karlsruhe
commented
Status: Active » Closed (works as designed)

Sorry, but I already mentioned before that this is by design.

aren cambre’s picture

aren cambre commented
Status: Closed (works as designed) » Postponed (maintainer needs more info)

Note: I am not arguing the original point. I am simply asking you to be more clear about the required filter change.

I presume you intend the module to be intuitive. If that's true, the need for a filter setting change needs to be obvious.

sun’s picture

sun
Primary language German
Location Karlsruhe
commented
Component: Editor - TinyMCE » Documentation
Category: bug » support
Status: Postponed (maintainer needs more info) » Active

See #6 ?

aren cambre’s picture

aren cambre commented
Category: support » feature

All you need to make obvious is that users must either:

  1. Add the <p> tag to the default Filtered HTML filter or whatever filter(s) they use with WYSIWYG.
  2. Use a different filter that includes <p>.

Changed to "feature request" because I am pushing for a product change.

sun’s picture

sun
Primary language German
Location Karlsruhe
commented
Status: Active » Postponed (maintainer needs more info)

Sorry, but I cannot see a new "feature" in this issue. I'm open to review a patch if you provide one. Otherwise, I'll close this issue.

sun’s picture

sun
Primary language German
Location Karlsruhe
commented
Category: feature » support
Status: Postponed (maintainer needs more info) » Fixed

Go ahead and document it: http://drupal.org/node/417160

kevinquillen’s picture

kevinquillen commented

Along with that, it doesn't appear to be clear in the WYSIWYG what the end result will be.

Example, client enters in all their text. Hits enter to start a new paragraph, it looks like a single line, so they hit enter again to see a single line space. In reality, this inserts two empty p tags, or two p tags with a br (seems random). I had to edit the skin CSS file within to put decent padding between P tags so when you hit enter, its clear that what you are entering is a new paragraph (in the editor).

From that, we were able to more accurately match what the outcome would be on the rendered page vs whats in the editor.

Is there a way to prevent BR's being used at all?

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.