Opened 10 years ago
Last modified 8 years ago
#28607 new enhancement
Make wpautop()'s $allblocks variable filterable
Reported by: | walkinonwat3r | Owned by: | |
---|---|---|---|
Milestone: | Awaiting Review | Priority: | normal |
Severity: | normal | Version: | |
Component: | Formatting | Keywords: | has-patch wpautop needs-refresh |
Focuses: | administration, template | Cc: |
Description
The problem: I'd like <img> tags to not be wrapped by <p> in the_content().
I used to use a regex filter on the_content to achieve this, but looking at the source for wpautop(), I think it would be much cleaner to prevent <img>s from being wrapped in the first place by making $allblocks filterable.
The <p><img /></p> issue commonly causes formatting issues, and making the block list filterable would let theme/plugin authors change this without and other blocks without breaking stylesheets configured for images in paragraphs.
Additionally, I think it's semantically cleaner for a standalone image, since "The HTML <p> element (or HTML Paragraph Element) represents a paragraph of text." https://developer.mozilla.org/en-US/docs/Web/HTML/Element/p
Attachments (1)
Change History (11)
#3
follow-ups:
↓ 4
↓ 10
@
10 years ago
I don't find a filter on allblocks to be particularly compelling (something I've stated in previous wpautop tickets). Specifying that certain elements are blocks and others aren't seems like a bad idea. It encourages bad behavior and might make it more difficult for us to adjust wpautop() behavior in the future.
If you don't want paragraph tags around your images, then attach your own filter to the_content to remove them.
It's worth noting that block v. inline is an HTML4 construct, and the concept has grown much more complex in HTML5. Us putting a filter on this could make it more difficult for us from doing more fine-grained behavior in the future.
#4
in reply to:
↑ 3
@
10 years ago
Replying to nacin:
If you don't want paragraph tags around your images, then attach your own filter to the_content to remove them.
If all you need is that change, a custom filter replicating the rest of wpautop
would be close to 100 lines of code. Would renaming $allblocks
to something else make sense?
#5
@
10 years ago
I can see sense in renaming $allblocks, as I'm not sure that accurately describes the purpose of the variable. Something along the lines of $exclude_from_paragraph_wrap might be a closer to what it's doing here.
The filter could also pass an array of HTML tag names, which would allow for easier unset() and conditionals. (Then implode the array to form the regex string.)
Is there something in the HTML spec that says non-block elements should be wrapped in paragraph tags? If not, then I think that makes the list in $allblock a bit of an arbitrary setting, especially in an HTML5 context.
Removing the tags after the fact isn't simple. You could regex them out... but then you have to account for links around images, bad HTML, and other possible edge cases. I've also always read that you shouldn't use regex on HTML. I suppose you could hook into the_content and fire up DOMDocument every time, but that seems like overkill (and overhead) when the tags can be prevented from being added in the first place.
#9
@
8 years ago
Any info when will this be sorted out? The current 'hacks' ( this or this ) kinda work (not ideally tho). And not on existing content.
I don't even think that the auto p wrapping isn't as big a problem, as the lack of <figure>
tag around the image that has no caption. At least add the wrapper around the image. This gives the developers some kind of control over the image placement at the very least.
#10
in reply to:
↑ 3
@
8 years ago
Replying to nacin:
I apologize for the bump. However, I am really surprised that $allblocks has not been converted to a filter. I appreciate the strict nature of the idea; adhering to HTML5 block elements. HTML5 is intended to allow more flexibility and control. Good, conditional, css style sheets require some of the inline elements to be displayed as block elements. '$allblocks' does not need to be literal in the sense of HTML5 specs, but should be 'allbocks', as the theme-author intends. This should be a simple filter addition, as I think 99% of the cases, we are looking to add elements, not remove. Am I missing something else here? Do you think we could consider making this change?
There is also a JavaScript version of that list: tags/3.9.1/src/wp-admin/js/editor.js#L199 (related: #18534).