[wp-trac] [WordPress Trac] #30644: "wpautop" Enhancements

[WordPress Trac]

#30644: "wpautop" Enhancements
---------------------------------+---------------------
 Reporter:  stefanrz             |       Owner:  (none)
     Type:  enhancement          |      Status:  new
 Priority:  normal               |   Milestone:
Component:  Formatting           |     Version:
 Severity:  normal               |  Resolution:
 Keywords:  wpautop 2nd-opinion  |     Focuses:
---------------------------------+---------------------

Comment (by azaozz):

 Replying to [comment:3 khag7]:
 > I recognize this is 6 years old. I recognize this is not as desirable
 now as it was prior to Gutenberg. I recognize that the 39 open tickets to
 fix wpautop are not a high priority. I recognize that any new version of
 wpautop needs to maintain back compat. But despite all that, I'd like to
 try to understand if there's a desire to fix this and if so, what steps
 need to be taken.

 Good question :)

 The main reason this didn't go ahead six years ago was that it needed a
 lot of unit tests, and also specific tests (and possibly fixes) for back-
 compat. Autop has always been... very temperamental. There are edge cases
 in it that the "surrounding code" has learned to expect. Over the years
 there were several attempts to "fix" some of these, but most failed as
 they either introduced new edge cases or by fixing a particular case broke
 the way something similar works. It's tough to use regex on HTML...

 Then, as you mention, autop went into "maintenance mode" couple of years
 ago with the release of the block editor in WP 5.0. The block editor
 doesn't use wpautop. It is used only as back-compat when there is only a
 single classic block (that doesn't get the block boundaries). Been looking
 into fixing that use case too.

 That means virtually all HTML coming from the block editor still has the
 `<p>` tags when saving it in the DB. The blocks "content HTML" is still
 run through wpautop on displaying, but there's no missing paragraph tags
 in there. This is still slow, and somewhat cumbersome, as there is no need
 to have the wpautop "display filter" on every front-end page load.

 In that terms I see the "future of wpautop" mainly in two directions:
 - Devise a way to not run the posts content through wpautop on every page
 load. This has to mostly look at "side effects", i.e. possible back-compat
 problems caused by white space changes added by wpautop to HTML that has
 all the `<p>` tags, etc.
 - Eventually fix and/or improve wpautop for HTML that has paragraph tags.
 This won't be needed if the above is implemented, and is more risky as
 wpautop still needs to work on older post content, and still needs it's
 old quirks to be backwards compatible.

 To answer your questions directly: don't think it's worth it fixing any
 edge cases in wpautop. The reasons are:
 1. Autop is in "maintenance mode" and on its way out.
 2. Fixing an edge case usually brings another, or brings some back-compat
 problems for code that is expecting the edge case.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/30644#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform