Make WordPress Core

Opened 11 years ago

Closed 9 years ago

#23778 closed defect (bug) (duplicate)

How do you keep WordPress from removing the non-breaking space?

Reported by: spherman's profile spherman Owned by: azaozz's profile azaozz
Milestone: Priority: normal
Severity: normal Version: 2.0
Component: TinyMCE Keywords:
Focuses: Cc:

Description

I am hoping you guys have a simple solution for me. I would really appreciate it.

I am doing a lot of porting existing sites to be wordpress sites and I have notived that every time there is a non-breaking space   it removes it fron the code when it is saved or when switching back and forth between visual and text mode.

I have combed google for a solution and come up with nothing but other people complaining about the same thing with no real solution.

Thoughts anyone?

Attachments (2)

23778.diff (528 bytes) - added by MikeHansenMe 11 years ago.
23778.2.diff (504 bytes) - added by MikeHansenMe 9 years ago.
Refreshed patch

Download all attachments as: .zip

Change History (14)

#1 @SergeyBiryukov
11 years ago

  • Component changed from Text Changes to TinyMCE
  • Version changed from 3.5.1 to 2.0

every time there is a non-breaking space   it removes it fron the code when it is saved or when switching back and forth between visual and text mode.

If you enter   in Text editor and save the post without switching to Visual editor, the non-breaking space will be preserved.

If you don't want to lose your non-breaking spaces by accidentally switching to Visual editor, the only workaround is to disable the Visual editor.

Closing as a duplicate of #2420.

#2 @SergeyBiryukov
11 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to duplicate
  • Status changed from new to closed

Duplicate of #2420.

#3 @SergeyBiryukov
11 years ago

Actually, this seems to work too:

function allow_nbsp_in_tinymce( $mceInit ) {
	$mceInit['entities'] = '160,nbsp,38,amp,60,lt,62,gt';	
	return $mceInit;
}
add_filter( 'tiny_mce_before_init', 'allow_nbsp_in_tinymce' );

#4 @SergeyBiryukov
11 years ago

  • Milestone set to Awaiting Review
  • Resolution duplicate deleted
  • Status changed from closed to reopened

The entities element was originally added in [4080].

Not sure why   is not there, we could probably add it.

#5 @spherman
11 years ago

Bless you!! I went searching for an answer to this once again and found your response. It worked!!!!

@MikeHansenMe
11 years ago

#6 @MikeHansenMe
11 years ago

  • Cc mdhansen@… added
  • Keywords has-patch added

#7 @jeremyclarke
10 years ago

  • Cc jer@… added
  • Keywords dev-feedback added

+1 for the importance of this issue. Our French authors are driven mad by the inability to add non-breaking spaces, it's like forcing them to use incorrect grammar (they have a lot of punctuation with spaces before the text like "« Salut Jeanne !").

Please lets make WP allow the proper usage of NBSP, especially since it's already allowed as a hack to fake empty paragraphs (it seems this bug doesn't affect NBSP that are on their own line, which is semantically crazy).

I tested the patch and it fixed the problem for me. Hopefully this can get into the next version of WP.

#8 @SergeyBiryukov
10 years ago

  • Keywords 3.8-early added
  • Milestone changed from Awaiting Review to Future Release

@MikeHansenMe
9 years ago

Refreshed patch

#10 @SergeyBiryukov
9 years ago

  • Milestone changed from Future Release to 4.4

#11 @wonderboymusic
9 years ago

  • Owner set to azaozz
  • Status changed from reopened to assigned

#12 @azaozz
9 years ago

  • Keywords has-patch dev-feedback 3.8-early removed
  • Milestone 4.4 deleted
  • Resolution set to duplicate
  • Status changed from assigned to closed

To clarify: the non-breaking spaces are not removed by TinyMCE. They are converted to the U+00A0 (UTF-8) character. This is not the default behavior but has been set in WordPress since version 2.

It is possible to stop converting the non-breaking spaces, but that will need changes in several other functions, mainly in wpautop and wptexturize, see #26842.

This ticket seems close enough to #26842 to close as a duplicate.

Note: See TracTickets for help on using tickets.