[wp-trac] [WordPress Trac] #13314: HTML is deleted when switched to visual editor

[WordPress Trac]

#13314: HTML is deleted when switched to visual editor
--------------------------+-----------------------
 Reporter:  BH8489        |       Owner:  azaozz
     Type:  defect (bug)  |      Status:  reopened
 Priority:  normal        |   Milestone:  3.5
Component:  Editor        |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  needs-patch   |
--------------------------+-----------------------

Comment (by MarcusPope):

 Since I know I have been interpreted as being harsh before, I really want
 to emphasize that there is no malice in this post.  It's just business to
 me, though if you are offended I'd really appreciate knowing by what so I
 can apologize-for/improve/rephrase it.

 That big ole warning is there because my plugin also disables wpautop.  I
 disable wpautop because I think it is an absolutely terrible and
 unnecessary notion.  But that is completely unrelated to the feature of
 preserving whitespace and newlines in html markup.  That feature could be
 used without any warning to the user.  It could even be implemented in
 conjunction with wpautop.

 But even if they were intertwined there are a dozen or more solutions to
 the warning.  It's odd to me that as a developer your first inclination is
 to say "it can't be done because of X" instead of "what could we do to fix
 X?". One solution would be to programmatically run the content through the
 fixit function on upgrade - something the core already does wrt schema
 updates.  Another option, for sites with millions of posts, would be to
 conditionally disable wpautop on posts created after activation and
 continue to use wpautop for posts created before activation, along with a
 hook to fix the content on individual post saves. Perhaps even simpler
 would be to just make the "preserve my html feature" a button on the
 toolbar of the html tab.  I'm confident you guys can think of solutions to
 these problems instead of just throwing up your hands.

 I didn't automatically call the conversion process (which is just an
 update to the post_content db field with the result of
 wpautop(post_content)), and instead put in that warning, because I'm a
 sole developer and don't have the time or QA resources to verify corner
 case issues that may or may not even exist.  That's where I'd expect the
 expertise of the core dev team to step in.  As a result of my limited time
 and focus, I gave a little more control to the end user just in case.

 If I was actually writing this as a core feature, or a commerical plugin
 I'd definitely polish it up.  For instance the Fix Posts feature doesn't
 even need to be a permanent change, I could easily run the content through
 a php version of unautop on plugin deactivation, or store a backup of the
 post as a special post_type that can be used to restore the posts in the
 result of a problem. Even though backing up data is a strict
 recommendation before updating the core or installing new plugins.

 The point was that preserving whitespace and newlines is completely
 possible, not impossible as stated by Azaozz.  If you read through my
 code, you'll see the approach I took. To make the task easier than reading
 ~600 lines of code, you don't even need to read past line 223 of the php
 file because the remainder is just admin settings / fix content stuff.
 For the js file just focus on logic after line 232.  And I'll be the first
 to say my approach isn't even 100% solid, there are namespace conflicts
 that could occur in the whitespace markers (however unlikely) and there is
 difinitely room for trying out a more fine-grained whitespace preservation
 technique.

 Ultimately, I've given you everything you need to solve the problem.  But
 I'm not going to do all of the work for you guys because it hasn't proven
 to be very useful in the past.  And in my eyes the likelihood that it will
 just go to waste and be untouched for another couple of years is just too
 strong for me to invest the amount of effort you are asking.  I'd love to
 find out that I'm wrong in that estimation, and with some consistency in
 that direction I'd make more contributions to the core.

 Though even if I was 100% convinced it would go to good use, I still
 wouldn't be able to help on that level today because my daughter is
 expected to be born in the next two to three weeks. I'm more than happy to
 be a consultant, if you will, on how to overcome specific hurdles you all
 discover along the way, but that's the best I can offer given the
 situation.

 Thanks again, for giving this issue some real consideration.  My email is
 anything at marcuspope.com and my twitter handle is marcuspope if you have
 any specific questions.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/13314#comment:27>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software