WordPress Trac: Ticket #18311: Support HTML in image captions.https://core.trac.wordpress.org/ticket/18311
<p>
The ability to add any HTML formatting to text in captions is very limited.
</p>
<ul><li>HTML markup can be added from the HTML editor as long as you don't switch to the visual editor and the markup does not contain any quotes.
</li><li>Currently the visual editor removes any HTML tags from captions.
</li></ul><p>
To do:
</p>
<ul><li>Handle HTML in the caption text escaping/encoding it to pass through the shortcode matching regex.
</li><li>Provide some way of adding HTML in the captions in the gallery -&gt; image properties. (This may be limited to links only as they seem most needed).
</li><li>Improve editing of caption text in the visual editor after inserting an image with caption or add third "popup button" to images that would add/remove captions directly without needing to open the uploader/gallery popup.
</li></ul>en-usWordPress Trachttps://core.trac.wordpress.org/chrome/site/your_project_logo.pnghttps://core.trac.wordpress.org/ticket/18311
Trac 1.0.1prettyboympMon, 01 Aug 2011 16:48:14 GMThttps://core.trac.wordpress.org/ticket/18311#comment:1
https://core.trac.wordpress.org/ticket/18311#comment:1
<p>
I toyed with using a shortcodes to implement the markup just to fix the problem, but found that having the ] in the caption also breaks the handling, see <a class="closed ticket" href="https://core.trac.wordpress.org/ticket/15694" title="defect (bug): Shortcode I/O Intolerant of &#34;]&#34;, &#34;&lt;&#34;, Quotes, etc. (closed: maybelater)">#15694</a>
</p>
TicketjaneSat, 10 Sep 2011 05:29:43 GMTcomponent changedhttps://core.trac.wordpress.org/ticket/18311#comment:2
https://core.trac.wordpress.org/ticket/18311#comment:2
<ul>
<li><strong>component</strong>
changed from <em>General</em> to <em>Media</em>
</li>
</ul>
Ticketh0tw1r3Thu, 29 Sep 2011 16:49:27 GMTattachment sethttps://core.trac.wordpress.org/ticket/18311
https://core.trac.wordpress.org/ticket/18311
<ul>
<li><strong>attachment</strong>
set to <em>my-patch.diff</em>
</li>
</ul>
<p>
use 'patch -p1 &lt; my-patch.diff' from the base wordpress folder
</p>
Ticketh0tw1r3Thu, 29 Sep 2011 16:50:13 GMTcomponent changedhttps://core.trac.wordpress.org/ticket/18311#comment:3
https://core.trac.wordpress.org/ticket/18311#comment:3
<ul>
<li><strong>component</strong>
changed from <em>Media</em> to <em>TinyMCE</em>
</li>
</ul>
<p>
This is related to how the wpeditimage plugin for TinyMCE currently works. It was originally written to support images, not other "stuff" in the media library or a generic for other things. I use it as a container for the flowplayer shorttag.
</p>
<p>
The first half of the problem is to stop the plugin from stripping the caption tag unnecessarily when switching from HTML to Visual mode.
</p>
<p>
"my-patch.diff" fixes that part of the issue.
</p>
TicketIpstenuTue, 18 Oct 2011 14:24:42 GMThttps://core.trac.wordpress.org/ticket/18311#comment:4
https://core.trac.wordpress.org/ticket/18311#comment:4
<p>
per <a class="ext-link" href="http://konstruktors.com/blog/wordpress/3203-how-to-automatically-add-image-credit-or-source-url-to-photo-captions-in-wordpress/"><span class="icon">​</span>http://konstruktors.com/blog/wordpress/3203-how-to-automatically-add-image-credit-or-source-url-to-photo-captions-in-wordpress/</a> the source URL might be a good alternative, though it borders on 'too many options'
</p>
TicketnavjotjsinghWed, 19 Oct 2011 09:40:39 GMTcc sethttps://core.trac.wordpress.org/ticket/18311#comment:5
https://core.trac.wordpress.org/ticket/18311#comment:5
<ul>
<li><strong>cc</strong>
<em>navjotjsingh@…</em> added
</li>
</ul>
TicketjeremyclarkeFri, 21 Oct 2011 18:58:42 GMThttps://core.trac.wordpress.org/ticket/18311#comment:6
https://core.trac.wordpress.org/ticket/18311#comment:6
<p>
I don't think the source_url method is the way to go. Definitely adds an unnecessarily confusing element to the UI and the whole system. I also don't think that just adding attribution in brackets like that is nearly universal enough.
</p>
<p>
What we need is to stop the caption system from stripping out light HTML from the caption field. There's no semantic justification for not having formatting and in fact there are MANY scenarios where having it is important, not the least of which is the attribution scenario which is vital for legal reasons.
</p>
<p>
WP IDEA with 55 supporters: <a class="ext-link" href="http://wordpress.org/extend/ideas/topic/fix-the-caption-system-to-allow-links-inside-captions"><span class="icon">​</span>http://wordpress.org/extend/ideas/topic/fix-the-caption-system-to-allow-links-inside-captions</a>
</p>
<p>
WP Tavern Post about it: <a class="ext-link" href="http://www.wptavern.com/how-to-insert-links-inside-of-image-captions"><span class="icon">​</span>http://www.wptavern.com/how-to-insert-links-inside-of-image-captions</a>
</p>
TicketnacinFri, 21 Oct 2011 19:18:40 GMThttps://core.trac.wordpress.org/ticket/18311#comment:7
https://core.trac.wordpress.org/ticket/18311#comment:7
<p>
Someone just needs to write the patch.
</p>
<p>
It's not a lack of support that is holding us back, it's the lack of code to implement this.
</p>
TicketnacinFri, 21 Oct 2011 19:19:05 GMTmilestone changed; keywords sethttps://core.trac.wordpress.org/ticket/18311#comment:8
https://core.trac.wordpress.org/ticket/18311#comment:8
<ul>
<li><strong>keywords</strong>
<em>needs-patch</em> added
</li>
<li><strong>milestone</strong>
changed from <em>Awaiting Review</em> to <em>Future Release</em>
</li>
</ul>
TicketjeremyclarkeFri, 21 Oct 2011 20:59:16 GMTcc changedhttps://core.trac.wordpress.org/ticket/18311#comment:9
https://core.trac.wordpress.org/ticket/18311#comment:9
<ul>
<li><strong>cc</strong>
<em>jer@…</em> added
</li>
</ul>
<p>
The first step of the problem is in <tt>image_add_caption()</tt>, which is attached to the <tt>image_send_to_editor</tt> filter and handles actually inserting the caption shortcode into post content. Notably, the <tt>image_add_caption()</tt> function is completely undocumented ( {@internal Missing Short Description}}) so it's hard to know what was intended by it's behavior, though clearly the idea was to simply remove anything that might be offensive inside a shortcode attribute without consideration for formatting that might be important to preserve.
</p>
<p>
Interestingly the upload manager popup correctly saves whatever HTML you insert in the caption without stripping it or showing an error. The problem is that when the shortcode is inserted into the post, <tt>image_add_caption()</tt> runs the following string replacement, which completely neutralises any HTML in the caption by replacing it with HTML entities:
</p>
<pre class="wiki">$caption = str_replace( array( '&gt;', '&lt;', '"', "'" ),
array( '&amp;gt;', '&amp;lt;', '&amp;quot;', '&amp;#039;' ),
$caption
);
</pre><p>
This is despite the fact that re-opening the image in the gallery shows you that the HTML is still saved correctly and unmolested in the caption field, which is very confusing. At a minimum the media uploader should not save any HTML in the caption field that will not ultimately function in the caption shortcode itself.
</p>
<p>
If the str_replace is removed then inserted HTML continues to not function because when the actual $caption content is output, addslashes() is run on it first( <tt>addslashes($caption)</tt>) which creates useless broken HTML.
</p>
<p>
The issue is further complicated by the fact that the caption text is stored in the <tt>caption=""</tt> attribute of the shortcode, so any double-quotes within the caption text truly don't make any sense and absolutely SHOULD be either escaped/slashed or replaced with single-quotes for storage inside the shortcode attribute.
</p>
<p>
<strong>THE CAPTION SHORTCODE IS FUNDAMENTALLY FLAWED, NUTS</strong>
</p>
<p>
Looking at it closely it seems like the architecture of the caption shortcode is fundamentally flawed because it uses an 'attribute' of the shortcode (caption="") to store the caption text, and attributes are rightly blocked from having the kind of formatting a useful caption needs. Since the shortcode has only one piece of content that can go between the two tags (i.e. between [caption] and <a href="https://core.trac.wordpress.org/caption">caption</a>) that content should have been the caption text itself (which could then take advantage of being regular post content), rather than the image html tag that is currently there (which could have been broken down into esc_attr()-safe attributes stored inside the initial [caption] shortcode and parsed into an img tag during shortcode execution).
</p>
<p>
Unfortunately re-architecting the caption shortcode now is probably off the table, and I doubt we can get traction for fully replacing it with a new more powerful shortcode in core. That is the problem we face though, the current architecture is just wrong for captions that are any more than another kind of alt label.
</p>
<p>
<strong>WE NEED SOME WAY TO ESCAPE HTML IN THE CAPTION TEXT ON SAVE, THEN UNESCAPE ON DISPLAY</strong>
</p>
<p>
So the trick we need to pull off is getting the system to somehow allow for at least a limited set of HTML (personally I'd settle for just links) inside the 'caption' attribute of the [caption] shortcode, then making the shortcode function <tt>img_caption_shortcode()</tt> display it correctly. If that worked, then it should be possible to get the visual editor to stop messing it up when you switch back and forth.
</p>
<p>
To me it seems like the best approach within the current shortcode would be to carefully account for particular HTML tags inside the 'caption' attribute by escaping them in a particular way while inserting them into the post, then when executing the shortcode carefully accounting for the escaped HTML and reverting it into an active state.
</p>
<p>
<strong>USING ADDSLASHES()/STRIPSLASHES() TO ESCAPE CAPTION TEXT: FAIL</strong>
</p>
<p>
The simplest version of that idea is to just remove the anti-html str_replace (quoted above) from <tt>image_add_caption()</tt> and instead depend on addslashes() to keep the content safe, then, in {{img_caption_shortcode()}} using stripslashes() to get the content back to it's original state.
</p>
<p>
Unfortunately we can't just stripslashes() in the current state of the codebase because a slash-escaped link tag inside the caption attribute causes the whole shortcode's $attr array to lose it's lunch and become broken, here's and example where the caption was "Testing a link" and the link was an a tag leading to test.com which used double-quotes around the URL:
</p>
<pre class="wiki"> [id] =&gt; attachment_74823
[align] =&gt; alignnone
[width] =&gt; 375
[0] =&gt; caption="Testing
[1] =&gt; a
[2] =&gt; href="http://test.com"&gt;link"
</pre><p>
That's the $attr array recieved by the shortcode function img_caption_shortcode(), so before we even have a chance to stripslashes($caption) the shortcode fails completely because the $caption attribute is mandatory for the shortcode and not present in $atts.
</p>
<p>
The culprit here is <tt>shortcode_parse_atts()</tt> which uses some intense regex voodoo I can't even begin to understand but is clearly not ready for a world where slash-escaped double-quotes are part of a shortcode attribute.
</p>
<p>
However, in this case switching to single-quotes actually fixes the problem, and results in the link showing correctly on the image. Maybe a final solution will involve enforcing single-quotes -only within caption text HTML, though that seems awkward, since it will be hard to distinguish between a double-quote used as part of a link and one used as part of regular text, and we don't want to replace text-quotes with a single-quote as that would be confusing for authors.
</p>
<p>
<strong>USING URLENCODE()/URLDECODE() TO ESCAPE CAPTION TEXT: UGLY</strong>
</p>
<p>
An alternate idea would be to use another escaping system entirely, to completely neutralize the caption text before sending it to the editor, then re-activate it when parsing the shortcode on display. I tried replacing addslashes/stripshashes with urlencode/urldecode and the results were very promising. In <tt>image_add_caption()</tt> I use urlencode($caption) before sending it to the editor, which sends things like this to the post:
</p>
<pre class="wiki">caption="TEsting+a+%3Ca+href%3D%22http%3A%2F%2Ftest.com%22%3Elink%3C%2Fa%3E+with+also+some+%3Cstrong%3Ebold%3C%2Fstrong%3E+text.+"
</pre><p>
Then in <tt>img_caption_shortcode()</tt> I run $caption = urldecode($caption), which reverts it back to it's original state and shows perfectly fine on the post preview.
</p>
<p>
This even avoids having the visual editor break the content when switching back and forth, but unfortunately it also looks AWFUL in the visual editor, because the urlencode() version of the caption is shown, which would probably confuse even users savvy enough to be adding HTML links in the caption field in the first place. This same awfulness applies to trying to read or edit the caption inside the HTML editor, which is infinitely more difficult then when the caption text is shown as plain text. Yet another place where the ugly urlencoded version shows is in the visual editor when you edit image settings.
</p>
<p>
<strong>WHAT OTHER FORMAT MIGHT WORK?</strong>
</p>
<p>
It seems like a big problem here is that any attempt to escape the HTML will need us to account for every single place where it is shown to users and unescape it for display in that space. Otherwise the escaping pattern would have to be simple/obvious enough that looking at the escaped version still made it clear what the HTML was for.
</p>
<p>
Maybe the solution is some kind of non-HTML code similar to shortcodes that could be used inside the caption attribute to identify links etc. This is not ideal as it creates yet another layer of syntax to learn and I would avoid that if at all possible, but it may be the only way to get around the problematic architecture that the caption shortcode currently suffers from. Maybe something that emulates mediawiki markup like this could work?
</p>
<pre class="wiki">[http://test.com/ test]
</pre><p>
<strong>OOF! THERE IS A REASON THIS HAS GONE SO LONG WITHOUT A FIX</strong>
</p>
<p>
Okay enough from me for today. Just wanted to dig into the code and do some research about the problem. I think that this probably needs more than just a patch, it needs thinking and decisions because so far there's still no solution that seems appropriate despite the obviousness of the need.
</p>
TicketkurtpayneFri, 21 Oct 2011 23:39:13 GMTattachment sethttps://core.trac.wordpress.org/ticket/18311
https://core.trac.wordpress.org/ticket/18311
<ul>
<li><strong>attachment</strong>
set to <em>18311.patch</em>
</li>
</ul>
<p>
Allow a subset of HTML in [caption] shortcode
</p>
TicketkurtpayneFri, 21 Oct 2011 23:52:09 GMTcc, keywords changedhttps://core.trac.wordpress.org/ticket/18311#comment:10
https://core.trac.wordpress.org/ticket/18311#comment:10
<ul>
<li><strong>cc</strong>
<em>kpayne@…</em> added
</li>
<li><strong>keywords</strong>
<em>has-patch</em> added
</li>
</ul>
<p>
Perhaps something like <a class="attachment" href="https://core.trac.wordpress.org/attachment/ticket/18311/18311.2.patch" title="Attachment '18311.2.patch' in Ticket #18311">18311.2.patch</a><a class="trac-rawlink" href="https://core.trac.wordpress.org/raw-attachment/ticket/18311/18311.2.patch" title="Download">​</a> would work?
</p>
<p>
This allows simple HTML (currently <tt>strong</tt>, <tt>em</tt>, and <tt>a</tt>) in the <tt>[caption]</tt> shortcode. It has to be turned on via the <tt>render_html=true</tt> attribute. It works with no modification to any other code, contained completely within <tt>img_caption_shortcode</tt>. It doesn't matter what encoded entities TinyMCE throws at it because it will decode it, keep good html, then re-encode it to sanitize bad html.
</p>
TicketkurtpayneFri, 21 Oct 2011 23:58:29 GMTattachment sethttps://core.trac.wordpress.org/ticket/18311
https://core.trac.wordpress.org/ticket/18311
<ul>
<li><strong>attachment</strong>
set to <em>18311.2.patch</em>
</li>
</ul>
<p>
Adding render_html attribute, default to false for backwards compatibility
</p>
TicketSergeyBiryukovTue, 10 Jan 2012 19:18:35 GMThttps://core.trac.wordpress.org/ticket/18311#comment:11
https://core.trac.wordpress.org/ticket/18311#comment:11
<p>
Related: <a class="closed ticket" href="https://core.trac.wordpress.org/ticket/12464" title="defect (bug): Text links are stripped from image captions (closed: duplicate)">#12464</a>
</p>
TicketazaozzWed, 11 Jan 2012 21:43:01 GMThttps://core.trac.wordpress.org/ticket/18311#comment:12
https://core.trac.wordpress.org/ticket/18311#comment:12
<p>
We need a more general approach both in the visual editor and in parsing the shortcode. Also this could involve an UI change (How to add a link in the caption in the image properties popup?) or explicitly moving editing of captions to the visual editor after the image has been inserted.
</p>
TicketDrewAPictureThu, 12 Jan 2012 08:19:01 GMTcc changedhttps://core.trac.wordpress.org/ticket/18311#comment:13
https://core.trac.wordpress.org/ticket/18311#comment:13
<ul>
<li><strong>cc</strong>
<em>xoodrew@…</em> added
</li>
</ul>
<p>
Replying to <a class="closed" href="https://core.trac.wordpress.org/ticket/18311#comment:12" title="Comment 12 for Ticket #18311">azaozz</a>:
</p>
<blockquote class="citation">
<p>
We need a more general approach both in the visual editor and in parsing the shortcode. Also this could involve an UI change (How to add a link in the caption in the image properties popup?) or explicitly moving editing of captions to the visual editor after the image has been inserted.
</p>
</blockquote>
<p>
Would moving the editing of captions to the visual editor affect the pulling of EXIF data (such as a caption) from those images?
</p>
TicketsushkovMon, 16 Jan 2012 12:02:08 GMTcc changedhttps://core.trac.wordpress.org/ticket/18311#comment:14
https://core.trac.wordpress.org/ticket/18311#comment:14
<ul>
<li><strong>cc</strong>
<em>sushkov</em> added
</li>
</ul>
<p>
@jeremyclarke has a point when says that image caption content should go between [caption] shortcode tags.
</p>
<p>
A fix could be achieved with minimum backcompat impact by separating the [caption] shortcode from <tt>img</tt> tag. To explain, we could move the [caption] before (makes more sense to me, or after) the <tt>img</tt> tag, so when the parser meets it, the context is not lost.
</p>
<p>
On the javascript side, that would mean little changes too.
</p>
<p>
Example:
<tt>[caption stuff=""]My awesome caption[/caption]&lt;img src="" alt=""/&gt;</tt>
</p>
<p>
The good part here, is that basically we do no make changes in the shortcode api (no overhead like mustaches <tt>{{}}</tt>) we just change the location of it inside the <tt>post_content</tt>.
</p>
TicketazaozzMon, 16 Jan 2012 20:35:32 GMThttps://core.trac.wordpress.org/ticket/18311#comment:15
https://core.trac.wordpress.org/ticket/18311#comment:15
<p>
Replying to <a class="closed" href="https://core.trac.wordpress.org/ticket/18311#comment:13" title="Comment 13 for Ticket #18311">DrewAPicture</a>:
</p>
<blockquote class="citation">
<p>
Would moving the editing of captions to the visual editor affect the pulling of EXIF data (such as a caption) from those images?
</p>
</blockquote>
<p>
No, we "read" the EXIF data in PHP after the image is uploaded and store it as meta. This is another enhancement (that has a ticket I think): using all relevant EXIF from the images and rotating them when needed after uploading and before making smaller sizes.
</p>
TicketazaozzMon, 16 Jan 2012 20:57:52 GMTstatus, description, component, summary, milestone, keywords, type changed; owner sethttps://core.trac.wordpress.org/ticket/18311#comment:16
https://core.trac.wordpress.org/ticket/18311#comment:16
<ul>
<li><strong>status</strong>
changed from <em>new</em> to <em>assigned</em>
</li>
<li><strong>description</strong>
modified (<a href="/ticket/18311?action=diff&amp;version=16">diff</a>)
</li>
<li><strong>component</strong>
changed from <em>TinyMCE</em> to <em>General</em>
</li>
<li><strong>summary</strong>
changed from <em>Caption shortcode doesn't support markup in the caption.</em> to <em>Support HTML in image captions.</em>
</li>
<li><strong>owner</strong>
set to <em>sushkov</em>
</li>
<li><strong>milestone</strong>
changed from <em>Future Release</em> to <em>3.4</em>
</li>
<li><strong>keywords</strong>
<em>has-patch</em> removed
</li>
<li><strong>type</strong>
changed from <em>enhancement</em> to <em>task (blessed)</em>
</li>
</ul>
<p>
Replying to <a class="closed" href="https://core.trac.wordpress.org/ticket/18311#comment:14" title="Comment 14 for Ticket #18311">sushkov</a>:
</p>
<blockquote class="citation">
<p>
@jeremyclarke has a point when says that image caption content should go between [caption] shortcode tags.
</p>
</blockquote>
<p>
Don't think changing the structure of the image caption shortcode is possible. This would break all plugins and themes that use it directly (we explicitly allow that in <tt>img_caption_shortcode()</tt> with the <tt>'img_caption_shortcode'</tt> filter).
</p>
<p>
I rather see that as escaping all quotes or encoding the html string in caption="...", whichever works better. If we need to encode it, we can decode before running the <tt>'img_caption_shortcode'</tt> filter to keep it back-compat.
</p>
TicketDrewAPictureMon, 16 Jan 2012 22:45:34 GMTkeywords changedhttps://core.trac.wordpress.org/ticket/18311#comment:17
https://core.trac.wordpress.org/ticket/18311#comment:17
<ul>
<li><strong>keywords</strong>
<em>ux-feedback</em> added
</li>
</ul>
<p>
How would moving the ability to edit captions/attachment meta into the Visual Editor affect UX when working outside the post/page editor in Media &gt; Library/Add New? My main concern is that the Visual Editor is not the only place where images (and their metadata) are used.
</p>
TicketjaneMon, 16 Jan 2012 22:48:30 GMThttps://core.trac.wordpress.org/ticket/18311#comment:18
https://core.trac.wordpress.org/ticket/18311#comment:18
<p>
I generally think of captions to be post/display-specific, while the library is just a file archive.
</p>
TicketDrewAPictureMon, 16 Jan 2012 22:55:20 GMThttps://core.trac.wordpress.org/ticket/18311#comment:19
https://core.trac.wordpress.org/ticket/18311#comment:19
<p>
Replying to <a class="closed" href="https://core.trac.wordpress.org/ticket/18311#comment:18" title="Comment 18 for Ticket #18311">jane</a>:
</p>
<blockquote class="citation">
<p>
I generally think of captions to be post/display-specific, while the library is just a file archive.
</p>
</blockquote>
<p>
Right, but you should still be able to edit the metadata (including the caption) even if it's just an archive.
</p>
TicketjaneMon, 16 Jan 2012 22:57:40 GMThttps://core.trac.wordpress.org/ticket/18311#comment:20
https://core.trac.wordpress.org/ticket/18311#comment:20
<p>
Replying to <a class="closed" href="https://core.trac.wordpress.org/ticket/18311#comment:19" title="Comment 19 for Ticket #18311">DrewAPicture</a>:
</p>
<blockquote class="citation">
<p>
Right, but you should still be able to edit the metadata (including the caption) even if it's just an archive.
</p>
</blockquote>
<p>
Maybe maybe not. If the metadata is use-specific, not file-specific, that would not be true. Linking to the use-specific editor makes sense, but say you have a logo or a headshot of someone that you caption differently every week. The file archive should have the single headshot, not hundreds of captions you have to wade through to find a file.
</p>
TicketDrewAPictureMon, 16 Jan 2012 23:22:57 GMThttps://core.trac.wordpress.org/ticket/18311#comment:21
https://core.trac.wordpress.org/ticket/18311#comment:21
<p>
Replying to <a class="closed" href="https://core.trac.wordpress.org/ticket/18311#comment:20" title="Comment 20 for Ticket #18311">jane</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="closed" href="https://core.trac.wordpress.org/ticket/18311#comment:19" title="Comment 19 for Ticket #18311">DrewAPicture</a>:
</p>
<blockquote class="citation">
<p>
Right, but you should still be able to edit the metadata (including the caption) even if it's just an archive.
</p>
</blockquote>
<p>
Maybe maybe not.
</p>
</blockquote>
<p>
That's kind of my point. I think it would behoove us to take into account a wider use-case for media, especially with a lot of the newer extensibility being tied to WordPress (App themes, CPTs, etc.). WordPress isn't just about blogging anymore, which means it's <em>also</em> not just about creating content in the editor. It seems counter intuitive to remove an option from where it always lives (media library) and move it to a place where it <em>sometimes</em> lives (visual editor).
</p>
<p>
Now, I understand the reasoning for moving it into the editor (shortcode parsing and all of that), but I don't think this is the right course to take.
</p>
TicketDrewAPictureThu, 19 Jan 2012 05:25:13 GMThttps://core.trac.wordpress.org/ticket/18311#comment:22
https://core.trac.wordpress.org/ticket/18311#comment:22
<p>
Related plugin? <a class="ext-link" href="http://wordpress.org/extend/plugins/rps-attach-caption-expand/"><span class="icon">​</span>RPS Attach Caption Expand</a>
</p>
TicketsushkovSat, 21 Jan 2012 18:36:15 GMThttps://core.trac.wordpress.org/ticket/18311#comment:23
https://core.trac.wordpress.org/ticket/18311#comment:23
<p>
I'm playing around with some escaping options, and the most elegant (chances are that it is not the most supported) solution is to use <tt>JSON.stringify()</tt> and <tt>JSON.parse()</tt>.
</p>
<p>
<tt>JSON</tt> is a native JSON encoding/decoding browser feature with IE6&gt; cross-browser support:
<a class="ext-link" href="http://en.wikipedia.org/wiki/JSON#Native_encoding_and_decoding_in_browsers"><span class="icon">​</span>http://en.wikipedia.org/wiki/JSON#Native_encoding_and_decoding_in_browsers</a>
</p>
<p>
Other ideas include <tt>encodeURIComponent()</tt> on JS side and <tt>urldecode()</tt>. We can't use <tt>escape()</tt> since there's no straight alternative to decode escaped strings on the PHP side (try this with languages like Tamil <a class="ext-link" href="http://en.wikipedia.org/wiki/Tamil_language"><span class="icon">​</span>http://en.wikipedia.org/wiki/Tamil_language</a>)
</p>
<p>
The biggest problem though, is that we will need to filter what tags are supported in the caption, where I would stick to basic <tt>span,a,em,strong,del,[insert markup tags here]</tt> (could not find a reason why would someone insert a <tt>&lt;table&gt;</tt> in a caption). For this we will definitely need a textarea instead of existing input type field and a UI markup editor, which is an unanswered question atm (both MCE and quicktags do not fit, unless we leave textarea use plain HTML).
</p>
<p>
Need some dev feedback.
</p>
TicketsushkovSat, 21 Jan 2012 18:37:12 GMTkeywords changedhttps://core.trac.wordpress.org/ticket/18311#comment:24
https://core.trac.wordpress.org/ticket/18311#comment:24
<ul>
<li><strong>keywords</strong>
<em>dev-feedback</em> added
</li>
</ul>
TicketazaozzMon, 23 Jan 2012 00:24:06 GMThttps://core.trac.wordpress.org/ticket/18311#comment:25
https://core.trac.wordpress.org/ticket/18311#comment:25
<p>
Replying to <a class="closed" href="https://core.trac.wordpress.org/ticket/18311#comment:23" title="Comment 23 for Ticket #18311">sushkov</a>:
</p>
<blockquote class="citation">
<p>
I'm playing around with some escaping options...
</p>
</blockquote>
<p>
Yes, JSON seems a good encoding solution for that. Was thinking we could try escapting only, i.e. escape the single and double quotes <tt>\'</tt>, <tt>\"</tt> and then unescape them after the shortcode is processed.
</p>
<blockquote class="citation">
<p>
The biggest problem though, is that we will need to filter what tags are supported in the caption, where I would stick to basic <tt>span,a,em,strong,del,[insert markup tags here]</tt>...
</p>
</blockquote>
<p>
When the visual editor is used it will allow only inline tags there (or the caption format breaks). When adding tags directly, it will be the UI that determines how we handle that. For now I imagine we would only support adding links directly (outside the visual editor) and of course entering HTML by hand. In the second case we should expect the users to "know what they are doing", same as when using the HTML editor.
</p>
<blockquote class="citation">
<p>
Need some dev feedback.
</p>
</blockquote>
<p>
You are one of the devs for this enhancement. That includes researching, testing and deciding what would be best there (you have the power!) :)
</p>
TicketsushkovMon, 23 Jan 2012 14:18:08 GMThttps://core.trac.wordpress.org/ticket/18311#comment:26
https://core.trac.wordpress.org/ticket/18311#comment:26
<p>
Added a diff that makes current editor allowing HTML. Though I still have to add some filtering on what HTML is allowed to be inserted.
File is not minimized!
</p>
TicketjeremyclarkeThu, 09 Feb 2012 18:15:15 GMThttps://core.trac.wordpress.org/ticket/18311#comment:27
https://core.trac.wordpress.org/ticket/18311#comment:27
<p>
Replying to <a class="closed" href="https://core.trac.wordpress.org/ticket/18311#comment:20" title="Comment 20 for Ticket #18311">jane</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="closed" href="https://core.trac.wordpress.org/ticket/18311#comment:19" title="Comment 19 for Ticket #18311">DrewAPicture</a>:
</p>
<blockquote class="citation">
<p>
Right, but you should still be able to edit the metadata (including the caption) even if it's just an archive.
</p>
</blockquote>
<p>
Maybe maybe not. If the metadata is use-specific, not file-specific, that would not be true. Linking to the use-specific editor makes sense, but say you have a logo or a headshot of someone that you caption differently every week. The file archive should have the single headshot, not hundreds of captions you have to wade through to find a file.
</p>
</blockquote>
<p>
Chiming in on this relatively old question, it's worth parsing out what each of these fields is used for in interpreting their relevance.
</p>
<p>
The caption is in fact used beyond the insertion of images into posts. At least in twenty-ten and twenty-eleven, if you use the [gallery] shortcode then on the thumbnail-list of images the text below each image is the caption as saved in the metadata. The caption is also used (albeit a bit strangely) on the single-image page when you click the thumbnail, between the image and the 'description' which is shown below.
</p>
<p>
Notably, any subsequent insertions of the image into that [gallery] post or in fact any other post (using the 'media library' tab in the uploader of other posts), will overwrite the caption text on the image, and thus change the behavior of the gallery. So if you carefully assemble a [gallery] with useful captions for each image in the context of the gallery then you need to never edit any of the captions on those images in the future or your gallery will become confusing. I actually didn't know that it would do this. I thought that the captions wouldn't be used in [gallery] but tested to make sure, glad I did!
</p>
<p>
To me the captions SHOULD be transient and insertion-specific, as Jane described. It's a logical thing to expect, especially compared to the 'description' and 'title' fields, which make much more sense as being official and linked to the image rather than the use. I'm pretty sure that the Link option actually does work like this, and isn't used anywhere other than in image insertions that happen while that link is visible in the field.
</p>
<p>
Despite what I might want though, captions are in fact a permanent part of each image attachment and thus on some level (at least for anyone who uses [gallery]) should be treated as directly linked with the image and permanent.
</p>
<p>
All that said, it doesn't really affect this ticket significantly unless we're seriously considering using the db-stored metadata to generate the [caption] shortcode at load time. As long as we stick with the current paradigm where the caption metadata parts ways with the caption text for a particular insertion at insertion time then we are fine. As an example, we should think about [gallery] and the stuff above if we are considering making the Visual Editor image settings editor capapable of editing the db-based metadata.
</p>
<p>
WHOOSH. I'm going to test the actual patch now.
</p>
TicketjeremyclarkeThu, 09 Feb 2012 22:06:12 GMThttps://core.trac.wordpress.org/ticket/18311#comment:28
https://core.trac.wordpress.org/ticket/18311#comment:28
<p>
Replying to <a class="closed" href="https://core.trac.wordpress.org/ticket/18311#comment:26" title="Comment 26 for Ticket #18311">sushkov</a>:
</p>
<blockquote class="citation">
<p>
Added a diff that makes current editor allowing HTML. Though I still have to add some filtering on what HTML is allowed to be inserted.
File is not minimized!
</p>
</blockquote>
<p>
Just tried this and it is a good partial solution! It does make links work if inserted with the media uploader, and gives a advanced-code-based solution for adding/editing links in captions from the visual and HTML editors.
</p>
<p>
Is there something unusual about this patch though? I tried <tt>patch -p0 FILENAME.diff</tt> and it totally didn't work. I just went in and aplied them by hand.
</p>
<p>
Anyone trying this patch should remember to set the <a class="ext-link" href="http://codex.wordpress.org/Debugging_in_WordPress#SCRIPT_DEBUG"><span class="icon">​</span>script debug constants</a> so your install uses the dev JS files which are modified by the patch:
</p>
<p>
Here's a rundown of things I tried and the results:
</p>
<ul><li><strong>Insert caption w/ link into post with uploader</strong>: works naturally. Links can be added with single or double quotes. Re-opening the media library and editing the link then re-inserting also works perfectly and is simple.
</li><li><strong>Switch back and forth between Visual and HTML</strong>: works, doesn't break the results of insert.
</li><li><strong>Visible in TinyMCE</strong>: Yes but confusing. Shows HTML code in caption box because the &lt; and &gt; tags are actually &amp;lt;, &amp;gt;, so the tags look like raw HTML when displayed. (see screenshot below)
</li><li><strong>Edit caption+link directly in TinyMCE</strong>: Works but awkward because you have to write HTML in the Visual editor. If you just type in &lt; and &gt; then they get saved as &amp;lt; which then gets the same treatment as links inserted by the media uploader.
</li><li><strong>Edit caption+link in "edit image" popup of TinyMCE</strong>: Works partially - link can be edited but "caption" field is populated with the entity-encoded version of the caption, which normal users and even HTML-aware-but-not-expert users will find very confusing to work with. (see screenshot below)
</li><li><strong>Editable in HTML editor</strong>: works but awkward - same problem as in Edit Image popup with entity-encoded HTML instead of ", ', &lt; and &gt;. Makes it very hard to edit. Obviously things like &amp;gt; are more reasonable in this context than TinyMCE.
</li><li><strong>Link works when viewing post/gallery</strong>: yes, looks right and behaves as expected.
</li></ul><p>
Personally I would be satisfied with the compromise that in HTML editor links-in-captions show up entity-encoded with &amp;gt;, &amp;39; etc. in their raw form. People using the HTML editor who really know HTML will understand what's happening and other types of users can be taught to simply delete and re-insert captions using the media uploader if they get something wrong. It even has decent WRITE-ability given that you can copy/paste from one caption into another to create links in captions by hand, and maybe some freaks will enjoy typing out &amp;39;'s themselves.
</p>
<p>
So the main thing this patch lacks is elegance when used inside the Visual editor. Having the links show up in the preview as raw HTML is probably not acceptable, and having them show up as HTML-encoded in the 'Edit Image' popup is definitely not acceptable.
</p>
<p>
<strong>Making caption-HTML show up as HTML in the Edit Image popup</strong>
</p>
<p>
Screenshot of the caption field from the Edit Image popup inside the Visual Editor:
</p>
<p>
<a class="ext-link" href="http://simianuprising.com/wp-content/uploads/2012/02/tinyMCE-link-in-caption-editimage-screenshot.png"><span class="icon">​</span>http://simianuprising.com/wp-content/uploads/2012/02/tinyMCE-link-in-caption-editimage-screenshot.png</a>
</p>
<p>
This strikes me as the easier problem. We need to filter the existing caption to entity-decode it as much as possible before sending it to the popup, and upon saving the popup we need to run the same encoding procedure used when inserting an image from the uploader popup. I took at stab at doing this and ended up on <tt>editimage.dev.js</tt> but I just can't figure out what does what.
</p>
<p>
It seems that when the Edit Image popup loads, it already has something to convert &amp;39; to ' and &amp;quot; to " because those show up normally. The problem in the popup is the &amp;lt; and &amp;gt; so wherever the quote un-encoding happens hopefully it won't be too hard to account for those as well.
</p>
<p>
Sushkov or Azaozz, do you know where this happens? What do you think is the best solution?
</p>
<p>
<strong>Showing HTML in captions properly in the WYSIYWG preview</strong>
</p>
<p>
This is a lot harder, and I don't even know where to start. Here's how it looks now:
</p>
<p>
<a class="ext-link" href="http://simianuprising.com/wp-content/uploads/2012/02/tinyMCE-link-in-caption-screenshot1.png"><span class="icon">​</span>http://simianuprising.com/wp-content/uploads/2012/02/tinyMCE-link-in-caption-screenshot1.png</a>
</p>
<p>
This is very logical behavior because the WYSIWYG is just showing us what the HTML would look like when viewed on a post. The thing is that when we actually show it on a post, the caption content will be run through the <tt>html_entity_decode()</tt> first, making the link active instead of encoded, so ideally we should incorporate that logic into the behavior of the editor, just like the shortcode is already parsed out to have the grey box.
</p>
<p>
What we need is to get TinyMCE, in whatever place it stores it's impression of the markup, to use a <tt>html_entity_decode()</tt>-style version of the caption text rather than the encoded version that is actually saved. Anyone have any idea how to make that happen? Is this likely to even be possible?
</p>
<p>
One move that might simplify the problem would be to completely lock editing of the caption in the WYSIWYG, and force people to use the Edit Image popup to do so. It would be annoying in some cases but it would also be clear and simple and probably not a huge pain most of the time. Really captions are very complicated and even without links, editing them inline causes weird results (what happened when I tried to delete a caption+image by starting with the caption was not at all what I expected). Again I have no idea what would be involved in taking this route, so anyone who knows please speak up.
</p>
<p>
Worst case scenario I'd accept if the answer is just "it looks wierd in the Visual editor if you have links in captions". It's still better than being unable to create links at all.
</p>
<p>
<strong>Thanks for reading, it will be great to have this issue resolved</strong>
</p>
<p>
Sushkov, please let me know if you think I got something wrong about your patch and what it does.
</p>
<p>
Others, please test it too!
</p>
TicketsushkovFri, 10 Feb 2012 14:36:53 GMTcomponent changedhttps://core.trac.wordpress.org/ticket/18311#comment:29
https://core.trac.wordpress.org/ticket/18311#comment:29
<ul>
<li><strong>component</strong>
changed from <em>General</em> to <em>Editor</em>
</li>
</ul>
<p>
Replying to <a class="closed" href="https://core.trac.wordpress.org/ticket/18311#comment:28" title="Comment 28 for Ticket #18311">jeremyclarke</a>:
</p>
<p>
Sorry for patch, my mistake. Should be fixed now.
Please make sure you are testing only after you replace the {{editor_plugin.js}} with the patched {{editor_plugin.dev.js}}.
</p>
<p>
Afaik, at this moment this issue needs dev-feedback and an UI decision.
</p>
<p>
Thanks.
</p>
TicketsushkovFri, 10 Feb 2012 14:37:31 GMTattachment sethttps://core.trac.wordpress.org/ticket/18311
https://core.trac.wordpress.org/ticket/18311
<ul>
<li><strong>attachment</strong>
set to <em>18311.diff</em>
</li>
</ul>
<p>
Fixed the git diff --no-prefix
</p>
TicketsushkovFri, 10 Feb 2012 14:38:41 GMTkeywords changedhttps://core.trac.wordpress.org/ticket/18311#comment:30
https://core.trac.wordpress.org/ticket/18311#comment:30
<ul>
<li><strong>keywords</strong>
<em>needs-patch</em> removed
</li>
</ul>
TicketazaozzFri, 10 Feb 2012 20:07:27 GMThttps://core.trac.wordpress.org/ticket/18311#comment:31
https://core.trac.wordpress.org/ticket/18311#comment:31
<p>
Been working on a patch for our 'wpeditimage' TinyMCE plugin for the last week or so. Don't think showing the raw HTML in the visual editor is acceptable (it is a <em>visual</em> editor). That would also prevent the user from editing or inserting any HTML there using MCE which is the main purpose if this improvement.
</p>
<p>
The problem is that whatever works in the visual editor looks pretty bad in the HTML editor and vice versa. Having a string with <tt>htmlspecialchars</tt> as entities in the HTML is highly undesirable and a lot harder to edit in the HTML editor.
</p>
<p>
The improvement on the TinyMCE side currently pulls all image captions "constructs" out of the DOM, serializes the nodes into HTML strings, creates the caption shortcode and then adds it back after the whole content has been serialized. Working on the DOM nodes instead of post-processing the HTML code with regex ensures that all tags in the captions are captured correctly.
</p>
<p>
As far as parsing the caption shortcode in PHP is concerned it seems to work well when using single quotes in the HTML in the caption attribute.
</p>
TicketazaozzFri, 10 Feb 2012 20:23:55 GMThttps://core.trac.wordpress.org/ticket/18311#comment:32
https://core.trac.wordpress.org/ticket/18311#comment:32
<p>
Replying to <a class="closed" href="https://core.trac.wordpress.org/ticket/18311#comment:20" title="Comment 20 for Ticket #18311">jane</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="closed" href="https://core.trac.wordpress.org/ticket/18311#comment:19" title="Comment 19 for Ticket #18311">DrewAPicture</a>:
</p>
<blockquote class="citation">
<p>
Right, but you should still be able to edit the metadata (including the caption)...
</p>
</blockquote>
<p>
Maybe maybe not. If the metadata is use-specific, not file-specific, that would not be true...
</p>
</blockquote>
<p>
Agree with Jane. Perhaps some of the confusion comes from the fact that we save the "caption" entered in the image properties popup into the attachment post's excerpt (and the image description is saved in post_content). Then the excerpt is shown in the default gallery and on individual image (attachment) pages, and is inserted together with the image in new posts/pages.
</p>
<p>
Perhaps we should rename the caption field in the image properties popup to "Default Caption" (as it is used as default in new posts).
</p>
TicketjeremyclarkeFri, 10 Feb 2012 21:40:24 GMThttps://core.trac.wordpress.org/ticket/18311#comment:33
https://core.trac.wordpress.org/ticket/18311#comment:33
<p>
Replying to <a class="closed" href="https://core.trac.wordpress.org/ticket/18311#comment:31" title="Comment 31 for Ticket #18311">azaozz</a>:
</p>
<blockquote class="citation">
<p>
That would also prevent the user from editing or inserting any HTML there using MCE which is the main purpose if this improvement.
</p>
</blockquote>
<p>
FWIW I think the main purpose of this improvement is to make it possible to add links in captions, not that it be easy to do so using the WYSIWYG tools. The bug is that it's impossible, whereas making it easy would be a more of a new feature request (just like it would be a feature request to give a way to add arbitrary CSS classes to HTML tags in the Visual editor, unlike the ability to do so in the HTML editor without it being destroyed when switching to Visual, which we already have).
</p>
<blockquote class="citation">
<p>
The problem is that whatever works in the visual editor looks pretty bad in the HTML editor and vice versa. Having a string with <tt>htmlspecialchars</tt> as entities in the HTML is highly undesirable and a lot harder to edit in the HTML editor.
</p>
</blockquote>
<p>
If we can make it work in the Visual editor then I think having some encoded characters in the HTML editor is harder but not insanely so. [caption] shortcodes are already hard to look at, this won't make it that much worse.
</p>
<blockquote class="citation">
<p>
As far as parsing the caption shortcode in PHP is concerned it seems to work well when using single quotes in the HTML in the caption attribute.
</p>
</blockquote>
<p>
Asking users to "only use single quotes" strikes me as unlikely to be successful and it also assumes the use of double-quotes throughout the shortcode, which is how it gets generated by the uploader UI, but not at all a prerequisite of the shortcode otherwise. In theory this could be a partial solution if we could stop the Visual editor from destroying such links (currently any links using single-quotes, as well as any subsequent text in the caption is removed when you switch to visual).
</p>
<p>
I think on some level despite the fact that &amp;39; is confusing it would also make it clear that "this is complicated and not just plain HTML". Using single quotes would make it look like any html could go in there, but if people wrote html that seemed the same but with double-quotes it would have very unpredictable effects (e.g, looking and working fine but getting destroyed if you ever switch to Visual editor).
</p>
<p>
It's great to hear you're also working on the wpeditimage plugin. I'm eager to try any patches you have that affect this situation. Thanks!
</p>
TicketmbijonSat, 11 Feb 2012 08:27:01 GMTcc changedhttps://core.trac.wordpress.org/ticket/18311#comment:34
https://core.trac.wordpress.org/ticket/18311#comment:34
<ul>
<li><strong>cc</strong>
<em>mike@…</em> added
</li>
</ul>
TicketazaozzSat, 11 Feb 2012 08:30:47 GMTattachment sethttps://core.trac.wordpress.org/ticket/18311
https://core.trac.wordpress.org/ticket/18311
<ul>
<li><strong>attachment</strong>
set to <em>18311-3.patch</em>
</li>
</ul>
<p>
Support for HTML in image captions - testing only
</p>
TicketazaozzSat, 11 Feb 2012 08:38:05 GMThttps://core.trac.wordpress.org/ticket/18311#comment:35
https://core.trac.wordpress.org/ticket/18311#comment:35
<p>
First run. Note that 18311-3.patch is for testing only, it replaces the minified wpeditimage/editor_plugin.js with the non-minified version to make it easier to test (still requires SCRIPT_DEBUG to be defined).
</p>
<p>
The patch doesn't include changes to the Edit Image popup in the visual editor or the image properties in the gallery (the two places where image captions can be typed in a text field).
</p>
TicketazaozzSat, 11 Feb 2012 09:05:29 GMThttps://core.trac.wordpress.org/ticket/18311#comment:36
https://core.trac.wordpress.org/ticket/18311#comment:36
<p>
Replying to <a class="closed" href="https://core.trac.wordpress.org/ticket/18311#comment:33" title="Comment 33 for Ticket #18311">jeremyclarke</a>:
</p>
<blockquote class="citation">
<p>
Asking users to "only use single quotes" strikes me as unlikely to be successful...
</p>
</blockquote>
<p>
You mean when the users type the whole caption shortcode in the HTML editor by hand, including HTML tags in the <tt>caption="..."</tt>? Doubt it anybody would do that. It's much easier to insert a shortcode then edit it in which case the user would simply follow the already set format (double quotes for shortcode attribs, single quotes for HTML in the <tt>caption="..."</tt>). Keep in mind the people that use the HTML editor "know what they are doing".
</p>
<p>
The alternative is to change the format of the shortcode. This would likely break some plugins that manipulate it directly in the DB or do other hacky things with it. Of course we can keep the <tt>'img_caption_shortcode'</tt> filter exactly the same but plugins that are "doing_it_wrong" and not using it would probably break.
</p>
<blockquote class="citation">
<p>
...if we could stop the Visual editor from destroying such links (currently any links using single-quotes, as well as any subsequent text in the caption is removed when you switch to visual).
</p>
</blockquote>
<p>
See the patch.
</p>
<blockquote class="citation">
<p>
It's great to hear you're also working on the wpeditimage plugin. I'm eager to try any patches you have that affect this situation.
</p>
</blockquote>
<p>
Yes, captions in the visual editor are handled there.
</p>
TicketazaozzTue, 14 Feb 2012 07:07:58 GMTattachment sethttps://core.trac.wordpress.org/ticket/18311
https://core.trac.wordpress.org/ticket/18311
<ul>
<li><strong>attachment</strong>
set to <em>18311-4.patch</em>
</li>
</ul>
<p>
Complete first run
</p>
TicketsushkovThu, 16 Feb 2012 20:42:35 GMThttps://core.trac.wordpress.org/ticket/18311#comment:37
https://core.trac.wordpress.org/ticket/18311#comment:37
<p>
Here's another approach we were proposing during last dev-chat, for handling caption text.
</p>
<p>
Right now the shortcode looks like this:
</p>
<p>
<tt> [caption id="attachment_7" align="alignleft" width="300" caption="Caption Text"]&lt;img src="pic.jpg" width="300" height="199" /&gt;[/caption] </tt>
</p>
<p>
Because changes to handle captions inside an attribute will result in less simple and clear code, we can move the caption text into its own shortcode:
</p>
<p>
<tt> [caption id="attachment_7" align="alignleft" width="300"]&lt;img src="pic.jpg" width="300" height="199" /&gt;[caption_text]Caption Text[/caption_text][/caption] </tt>
</p>
<p>
This basically saves us from handling input and escaping data from an attribute, and leaves space for all kind of formatting.
</p>
<p>
In fact, looking back, we can solve this simply by regexp-ing <tt>img</tt> tag and considering the rest <tt>caption text</tt> (problem here is that themes that hook into <tt>img_caption_shortcode</tt> will have no support for the new version of captions text).
</p>
<p>
This snippet more or less shows the current shortcode version changes it will require:
<a class="ext-link" href="https://gist.github.com/1847575"><span class="icon">​</span>https://gist.github.com/1847575</a>
</p>
<p>
The point of the above snippet, is to prove that backcompat can be preserved.
</p>
<p>
Once again, changes on the JS side, should be less and cleaner with an approach like this.
</p>
TicketnacinThu, 16 Feb 2012 20:59:02 GMThttps://core.trac.wordpress.org/ticket/18311#comment:38
https://core.trac.wordpress.org/ticket/18311#comment:38
<blockquote class="citation">
<p>
In fact, looking back, we can solve this simply by regexp-ing img tag and considering the rest caption text (problem here is that themes that hook into img_caption_shortcode will have no support for the new version of captions text).
</p>
</blockquote>
<p>
We're screwed there either way, though. Once we nest the content into caption_text, we're backwards incompatible for callbacks expecting an attribute.
</p>
<p>
So, we need to figure out how to be compatible here. What we can do is make img_caption_shortcode() reach into $content, remove the caption, and add it into <tt>$attr['caption']</tt>. Then pass the modified $attr and $content into the filter.
</p>
<p>
This would work best with a single [caption] shortcode, and no [caption_text]. The regex would need to account for &lt;a&gt; tags around the &lt;img&gt; tag as well.
</p>
TicketericlewisThu, 16 Feb 2012 21:49:58 GMTcc changedhttps://core.trac.wordpress.org/ticket/18311#comment:39
https://core.trac.wordpress.org/ticket/18311#comment:39
<ul>
<li><strong>cc</strong>
<em>eric.andrew.lewis@…</em> added
</li>
</ul>
TicketsushkovFri, 17 Feb 2012 15:55:02 GMThttps://core.trac.wordpress.org/ticket/18311#comment:40
https://core.trac.wordpress.org/ticket/18311#comment:40
<p>
You are right.
Perhaps something like this makes more sens:
<a class="ext-link" href="https://gist.github.com/1854115"><span class="icon">​</span>https://gist.github.com/1854115</a>
</p>
TicketazaozzFri, 17 Feb 2012 20:16:58 GMThttps://core.trac.wordpress.org/ticket/18311#comment:41
https://core.trac.wordpress.org/ticket/18311#comment:41
<p>
Replying to <a class="closed" href="https://core.trac.wordpress.org/ticket/18311#comment:38" title="Comment 38 for Ticket #18311">nacin</a>:
</p>
<blockquote class="citation">
<p>
We're screwed there either way... So, we need to figure out how to be compatible here.
</p>
</blockquote>
<p>
Not exactly. The current patch is backwards compatible. All it does is to force the quotes in the newly added HTML inside captions to be single. This works well and doesn't require any changes to the shortcode format or the handling/parsing of the shortcode in the back-end, including plugins.
</p>
<p>
Furthermore it accepts both quote formats when editing a post, so even if a plugin has added a caption shortcode using single quotes for the attributes (default is to use double quotes), it would handle it properly.
</p>
<p>
Agree with @sushkov that now would be a good time to tweak/improve the captions shortcode but don't see any way we can do that and keep it 100% backwards compatible.
</p>
TicketazaozzFri, 24 Feb 2012 01:58:19 GMThttps://core.trac.wordpress.org/ticket/18311#comment:42
https://core.trac.wordpress.org/ticket/18311#comment:42
<p>
In <a class="changeset" href="https://core.trac.wordpress.org/changeset/19982" title="HTML in image captions, first run, see #18311">[19982]</a>:
</p>
<div class="message"><p>
HTML in image captions, first run, see <a class="closed ticket" href="https://core.trac.wordpress.org/ticket/18311" title="task (blessed): Support HTML in image captions. (closed: fixed)">#18311</a><br />
</p>
</div>
TicketazaozzFri, 24 Feb 2012 20:42:36 GMThttps://core.trac.wordpress.org/ticket/18311#comment:43
https://core.trac.wordpress.org/ticket/18311#comment:43
<p>
In <a class="changeset" href="https://core.trac.wordpress.org/changeset/19986" title="Add new string to the proper i18n object, see #18311">[19986]</a>:
</p>
<div class="message"><p>
Add new string to the proper i18n object, see <a class="closed ticket" href="https://core.trac.wordpress.org/ticket/18311" title="task (blessed): Support HTML in image captions. (closed: fixed)">#18311</a><br />
</p>
</div>
TicketsushkovSun, 26 Feb 2012 01:57:44 GMThttps://core.trac.wordpress.org/ticket/18311#comment:44
https://core.trac.wordpress.org/ticket/18311#comment:44
<p>
UI/UX in wpeditimage.html is tricky stuff because <tt>ed.translate()</tt> replaces existing document.body with a new one, and old elements bindings die.
</p>
<p>
To get over it, I moved wysiwyg outside the components that require translation, after those are parsed, wysiwyg hides initial textarea, and updates its value in the background.
</p>
<p>
Looking back, I think we can just instantiate wysiwyg with the textarea name, since all this stuff depends on js and name attributes are irrelevant.
</p>
<p>
As for now, <tt>wpImage.enableWysiwyg()</tt> doesn't convert double-quotes into single-quotes, so using this from tinyMCE might srip formatting. Will take a look later.
</p>
<p>
Files are not minified.
</p>
TicketsushkovSun, 26 Feb 2012 01:59:23 GMThttps://core.trac.wordpress.org/ticket/18311#comment:45
https://core.trac.wordpress.org/ticket/18311#comment:45
<p>
A fast preview:
<a style="padding:0; border:none" href="http://i.imgur.com/2ZbGw.png"><img src="http://i.imgur.com/2ZbGw.png" alt="http://i.imgur.com/2ZbGw.png" title="http://i.imgur.com/2ZbGw.png" /></a>
</p>
TicketnacinSun, 26 Feb 2012 02:09:12 GMThttps://core.trac.wordpress.org/ticket/18311#comment:46
https://core.trac.wordpress.org/ticket/18311#comment:46
<p>
Is it possible to use wp_editor() (HTML editor only)? We implemented it on edit-comments.php and it turned out well.
</p>
TicketsushkovSun, 26 Feb 2012 03:46:21 GMThttps://core.trac.wordpress.org/ticket/18311#comment:47
https://core.trac.wordpress.org/ticket/18311#comment:47
<p>
Hmm, in <tt>wp-admin/media.php</tt> yes, already done.
</p>
<p>
In tinyMCE popup, sure, but it would require loading half of WordPress, and even more changes across codebase, so I'm not sure it's worth that.
</p>
<p>
A month ago I would never believe this ticket would require that many modifications. Right now the diff requires some more cleanup. But a nice working patch will be ready for upcoming meetup.
</p>
TickethidgwSun, 26 Feb 2012 04:46:23 GMTcc changedhttps://core.trac.wordpress.org/ticket/18311#comment:48
https://core.trac.wordpress.org/ticket/18311#comment:48
<ul>
<li><strong>cc</strong>
<em>hidgw</em> added
</li>
</ul>
TicketsushkovSun, 26 Feb 2012 12:50:00 GMTattachment sethttps://core.trac.wordpress.org/ticket/18311
https://core.trac.wordpress.org/ticket/18311
<ul>
<li><strong>attachment</strong>
set to <em>18311_qtags_ui.diff</em>
</li>
</ul>
<p>
Cleaned up a bit, added comments, fixed quotes compatiblity
</p>
TicketsushkovSun, 26 Feb 2012 12:52:50 GMTkeywords changedhttps://core.trac.wordpress.org/ticket/18311#comment:49
https://core.trac.wordpress.org/ticket/18311#comment:49
<ul>
<li><strong>keywords</strong>
<em>has-patch</em> added; <em>dev-feedback</em> removed
</li>
</ul>
TicketsushkovSun, 26 Feb 2012 13:07:11 GMTattachment sethttps://core.trac.wordpress.org/ticket/18311
https://core.trac.wordpress.org/ticket/18311
<ul>
<li><strong>attachment</strong>
set to <em>18311_qtags_ui.2.diff</em>
</li>
</ul>
TicketazaozzSun, 26 Feb 2012 23:13:11 GMThttps://core.trac.wordpress.org/ticket/18311#comment:50
https://core.trac.wordpress.org/ticket/18311#comment:50
<p>
Replying to <a class="closed" href="https://core.trac.wordpress.org/ticket/18311#comment:44" title="Comment 44 for Ticket #18311">sushkov</a>:
</p>
<blockquote class="citation">
<p>
...tricky stuff because <tt>ed.translate()</tt> replaces existing document.body with a new one, and old elements bindings die.
</p>
</blockquote>
<p>
Yes, unfortunately that's the way TinyMCE translates the iframe body in its popups. The way around it is to bind events after the translation is done.
</p>
<p>
Replying to <a class="closed" href="https://core.trac.wordpress.org/ticket/18311#comment:46" title="Comment 46 for Ticket #18311">nacin</a>:
</p>
<blockquote class="citation">
<p>
Is it possible to use wp_editor() (HTML editor only)?
</p>
</blockquote>
<p>
Currently there are five places where captions can be edited and only two use roughly the same code:
</p>
<ul><li>Media-&gt;Library screen (single image properties),
</li><li>"Media" tab in the uploader popup (single image properties),
</li><li>"From URL" tab in the uploader popup,
</li><li>"Edit Image" popup in TinyMCE,
</li><li>Editing directly in the visual editor.
</li></ul><p>
We can use wp_editor() in the first three as they are generated from PHP. The "Edit Image" popup in TinyMCE is all JS based, so Quicktags must be loaded directly there.
</p>
<p>
However the question here is mostly UX: by far the best place to edit captions is directly in the visual editor. It is WYSIWYG and the user has access to more tools (other inline tags, remove formatting, etc.).
</p>
<p>
Was thinking we can add third button that pops up when clicking on an image in the visual editor. Currently when users want to add a caption while composing a post they must:
</p>
<ol><li>Open the "Edit Image" popup,
</li><li>Add some text in the caption field,
</li><li>Click Update/close the popup,
</li><li>Edit the text they added in step 2 and add HTML elements to it.
</li></ol><p>
The new button would add (and remove?) the caption elements around the image directly without the need to open the "Edit Image" popup, i.e. the users would start directly at step 4.
</p>
TicketazaozzSun, 26 Feb 2012 23:27:23 GMThttps://core.trac.wordpress.org/ticket/18311#comment:51
https://core.trac.wordpress.org/ticket/18311#comment:51
<p>
Replying to <a class="closed" href="https://core.trac.wordpress.org/ticket/18311#comment:47" title="Comment 47 for Ticket #18311">sushkov</a>:
</p>
<blockquote class="citation">
<p>
Hmm, in <tt>wp-admin/media.php</tt> yes, already done.
</p>
</blockquote>
<p>
We should avoid using a buffer there. I know there's a "circular dependency" between media.php and wp_editor() in there but we should be able to work around it.
</p>
<blockquote class="citation">
<p>
In tinyMCE popup, sure, but it would require loading half of WordPress, and even more changes across codebase, so I'm not sure it's worth that.
</p>
</blockquote>
<p>
Not half, all of the admin as it would require wp-admin/includes/media.php. Not sure it's worth it either as it will make that popup (a lot) slower.
</p>
<blockquote class="citation">
<p>
A month ago I would never believe this ticket would require that many modifications...
</p>
</blockquote>
<p>
Nothing we can't handle :)
</p>
TicketsushkovMon, 27 Feb 2012 14:12:37 GMTattachment sethttps://core.trac.wordpress.org/ticket/18311
https://core.trac.wordpress.org/ticket/18311
<ul>
<li><strong>attachment</strong>
set to <em>18311_qtags_ui.3.diff</em>
</li>
</ul>
<p>
Tweaked for usage in <tt>From URL</tt> and <tt>Media-&gt;Library</tt> tabs
</p>
TicketsushkovMon, 27 Feb 2012 14:21:37 GMThttps://core.trac.wordpress.org/ticket/18311#comment:52
https://core.trac.wordpress.org/ticket/18311#comment:52
<p>
Hey @azaozz could you take a look at line 144 in <tt>wpeditimage/editor_plugin_src.js' in the context of </tt>From URL` tab (I'm asking because you already did some changes there).
Thanks.
</p>
<p>
Regarding <tt>ob_start()</tt>, I would leave it for later. To be honest, I don't see any reason why buffers should be avoided...
</p>
TicketazaozzMon, 27 Feb 2012 19:25:27 GMThttps://core.trac.wordpress.org/ticket/18311#comment:53
https://core.trac.wordpress.org/ticket/18311#comment:53
<p>
Replying to <a class="closed" href="https://core.trac.wordpress.org/ticket/18311#comment:52" title="Comment 52 for Ticket #18311">sushkov</a>:
</p>
<blockquote class="citation">
<p>
Regarding <tt>ob_start()</tt>, I would leave it for later. To be honest, I don't see any reason why buffers should be avoided...
</p>
</blockquote>
<p>
<tt>ob_start()</tt> is "evil" :) We've had problems with it in the past, seems some hosts run custom handlers that do all sorts of things with the buffers.
</p>
TicketazaozzTue, 28 Feb 2012 08:03:41 GMThttps://core.trac.wordpress.org/ticket/18311#comment:54
https://core.trac.wordpress.org/ticket/18311#comment:54
<p>
In <a class="changeset" href="https://core.trac.wordpress.org/changeset/20013" title="HTML in image captions: improve converting the caption html elements to a ...">[20013]</a>:
</p>
<div class="message"><p>
HTML in image captions: improve converting the caption html elements to a shortcode, catch some rare cases where image with a caption is pasted in the visual editor, see <a class="closed ticket" href="https://core.trac.wordpress.org/ticket/18311" title="task (blessed): Support HTML in image captions. (closed: fixed)">#18311</a><br />
</p>
</div>
TicketsushkovTue, 28 Feb 2012 14:03:59 GMTattachment sethttps://core.trac.wordpress.org/ticket/18311
https://core.trac.wordpress.org/ticket/18311
<ul>
<li><strong>attachment</strong>
set to <em>18311_qtags_ui.4.diff</em>
</li>
</ul>
<p>
Added wpLink back.
</p>
TicketsushkovTue, 28 Feb 2012 14:06:52 GMThttps://core.trac.wordpress.org/ticket/18311#comment:55
https://core.trac.wordpress.org/ticket/18311#comment:55
<p>
One reason I would disable <tt>wpLink</tt> in image popus, is because wpLink itself is a popup.
While its OK to have it inside single <tt>media.php</tt> item pages, in editor it results in some sort of <tt>Inception</tt> movie...
</p>
<p>
Static <tt>wpeditimage.html</tt> needs a bunch of js files in header to make it work, and a valid <tt>tinyMCEPopup</tt> object.
</p>
<p>
UI/UX feedback is welcome, please.
</p>
TicketjeremyclarkeTue, 28 Feb 2012 22:50:26 GMThttps://core.trac.wordpress.org/ticket/18311#comment:56
https://core.trac.wordpress.org/ticket/18311#comment:56
<p>
Hey guys it's come a long way!
</p>
<p>
<strong>TRUNK VERSION</strong>
</p>
<p>
The links work and I'm finding they persist well when switching back and forth between HTML and Visual. It's great that the caption can be edited in the Visual editor and in the popup.
</p>
<p>
One thing I noticed is it strips out any use of <tt>title=</tt> in links. Is that intentional/desirable? Link titles are important for accessibility as well as for SEO, if there's one attribute we should keep other than href it's probably title.
</p>
<p>
It's nice that if you type double quotes for caption links in the HTML editor then switching to VIsual editor makes them single quotes, but is there a way we could also do the same thing for people who only use the HTML editor? Right now saving the posts keeps the broken double-quotes-inside-double-quotes format and previewing it just makes the caption dissapear. It would be nice if people were protected from themselves even if they only use the HTML editor.
</p>
<p>
We aren't planning to stick with the "Add link" UI that's in trunk right now are we? I'm a bit confused but it sounds like Sushkov's patches to add quicktags is the right way to go.
</p>
<p>
<strong>PATCH VERSION</strong>
</p>
<p>
Unfortunately I can't seem to get the 18311_qtags_ui.4.diff patch to work. It patches successfully, but the result is very broken. In the uploader popup I can see a loose textarea at the bottom of the popup with the quicktags above it but looking unstyled.
</p>
<p>
Is there another patch from above that I need to get it working with trunk?
</p>
TicketazaozzTue, 28 Feb 2012 23:02:28 GMThttps://core.trac.wordpress.org/ticket/18311#comment:57
https://core.trac.wordpress.org/ticket/18311#comment:57
<p>
Replying to <a class="closed" href="https://core.trac.wordpress.org/ticket/18311#comment:55" title="Comment 55 for Ticket #18311">sushkov</a>:
</p>
<blockquote class="citation">
<p>
One reason I would disable <tt>wpLink</tt> in image popus, is because wpLink itself is a popup...
...Static <tt>wpeditimage.html</tt> needs a bunch of js files in header to make it work...
</p>
</blockquote>
<p>
The problem is that the default "link" in Quicktags is... quite bad. It opens a browser generated modal popup (for the url) which is most basic (and uglier) UI we can have (unfortunately there's no other way to do it in Quicktags). Also don't think we can use wp-link in some places and not use it in other. The UI needs to be consistent.
</p>
<p>
The current UX/UI questions are:
</p>
<ul><li>Shall we add Quicktags on the Image Caption fields.
<ul><li>With Quicktags we can have 2-3 more buttons that insert HTML tags but the "link" button opens an ugly modal popup.
</li><li>Without Quicktags we only have a "link" button but the UI/UX is better.
</li><li>It may be possible to tweak Quicktags' link button to use the current link UI. Would that be the best option.
</li></ul></li></ul><p>
</p>
<blockquote>
<p>
In both cases we would be showing the raw HTML code there.
</p>
</blockquote>
<p>
</p>
<blockquote>
<p>
Another inconsistency is that the "Caption" fields would have some sort of HTML editor but the "Description" fields would not. Description is actually the post_content and supports HTML.
</p>
</blockquote>
<ul><li>Shall we try to steer the users into editing captions directly into the visual editor. This is by far the best place to edit captions as all is wysiwyg, the image together with the caption usually looks exactly the same as on the front-end. An idea on how we can do that is to add a third button when clicking on an image in the visual editor. That button would be for adding (and removing) the caption "wrapper" on the image.
</li></ul>
TicketjeremyclarkeTue, 28 Feb 2012 23:33:30 GMThttps://core.trac.wordpress.org/ticket/18311#comment:58
https://core.trac.wordpress.org/ticket/18311#comment:58
<p>
FWIW I'd be satisfied with <strong>no</strong> UI for adding links in the popups. IMHO the bug was that it was impossible, so as long as me and my users can type in an &lt;a&gt; tag and have it work that's a huge step forward. The fact that people who don't know HTML can use the Visual editor is also very logical. While it may not be a perfect implementation, it's both pretty easy to figure out that the Visual editor can do it and dead-simple to explain to someone ("Oh, just use the WYSIWYG button after inserting the image"). Of course, having a UI would be good for promoting the fact that HTML works in captions now, but that doesn't seem like a huge priority to me especially while it's so new.
</p>
<p>
Overall, I'd say if we can't get at least the quicktags (if not the full visual/html editor) then we're better off without a link button complicating the UI. To me it's more confusing to have just that one button than to have the whole row, because the row is already familiar and has a clear relationship to the textarea.
</p>
<p>
Also, in the current 'add link' button hitting enter does not do what I'd expect. Instead of inserting the link it causes the whole popup to close and insert the image into the post. If we keep the 'add link' button (or integrate it into quicktags) it would be good to change that, as it was really confusing and I also lost my work on the link (not much work but still).
</p>
TicketazaozzTue, 28 Feb 2012 23:51:30 GMThttps://core.trac.wordpress.org/ticket/18311#comment:59
https://core.trac.wordpress.org/ticket/18311#comment:59
<p>
Replying to <a class="closed" href="https://core.trac.wordpress.org/ticket/18311#comment:56" title="Comment 56 for Ticket #18311">jeremyclarke</a>:
</p>
<blockquote class="citation">
<p>
One thing I noticed is it strips out any use of <tt>title=</tt> in links.
</p>
</blockquote>
<p>
Titles on links (or other tags) seem to work properly here. Could you try to trace where are they stripped.
</p>
<blockquote class="citation">
<p>
It's nice that if you type double quotes for caption links in the HTML editor then switching to VIsual editor makes them single quotes, but is there a way we could also do the same thing for people who only use the HTML editor?
</p>
</blockquote>
<p>
Don't think so. We aren't running any pre-save filters on the content of the HTML editor and I think most people that use it would insist on that. It's a simple case of using the right quotes, I mean <tt>$str = "single quote is ok here";</tt> and <tt>$str = 'double quote is ok here';</tt>, same as in any html tag. Also people that use the HTML editor usually "know what they are doing" :)
</p>
<blockquote class="citation">
<p>
We aren't planning to stick with the "Add link" UI that's in trunk right now are we? I'm a bit confused but it sounds like Sushkov's patches to add quicktags is the right way to go.
</p>
</blockquote>
<p>
Still undecided (see the above comment on that). Using Quicktags would make it better for people that use the HTML editor and have at least some basic understanding of HTML. For the big majority of users it wouldn't make any difference though.
</p>
<p>
Yes, the current "Add link" button and UI would need some polishing if we decide to keep it.
</p>
TicketaaroncampbellWed, 29 Feb 2012 21:30:15 GMThttps://core.trac.wordpress.org/ticket/18311#comment:60
https://core.trac.wordpress.org/ticket/18311#comment:60
<p>
I noticed that highlighting text in the caption in TinyMCE and using toolbar buttons works. However, in HTML it looks like doing the same works with everything but del. It seems that the del button in TinyMCE just ads the tags, but in HTML mode it adds tags AND a param for the date it was deleted. Do you think we could bring those buttons into sync with each other, standardize on no param, and let all the toolbar items in the HTML editor work? If so I can open another ticket.
</p>
TicketazaozzWed, 29 Feb 2012 22:59:58 GMThttps://core.trac.wordpress.org/ticket/18311#comment:61
https://core.trac.wordpress.org/ticket/18311#comment:61
<p>
Replying to <a class="closed" href="https://core.trac.wordpress.org/ticket/18311#comment:60" title="Comment 60 for Ticket #18311">aaroncampbell</a>:
</p>
<blockquote class="citation">
<p>
...It seems that the del button in TinyMCE just ads the tags, but in HTML mode it adds tags AND a param for the date it was deleted. Do you think we could bring those buttons into sync...
</p>
</blockquote>
<p>
Good idea. Yes, could you open another ticket for that.
</p>
TicketaaroncampbellThu, 01 Mar 2012 14:05:30 GMThttps://core.trac.wordpress.org/ticket/18311#comment:62
https://core.trac.wordpress.org/ticket/18311#comment:62
<p>
Replying to <a class="closed" href="https://core.trac.wordpress.org/ticket/18311#comment:61" title="Comment 61 for Ticket #18311">azaozz</a>:
</p>
<blockquote class="citation">
<p>
Good idea. Yes, could you open another ticket for that.
</p>
</blockquote>
<p>
<a class="closed ticket" href="https://core.trac.wordpress.org/ticket/20149" title="defect (bug): Del button should work the same in Visual &amp; HTML Editors (closed: invalid)">#20149</a> - If you can comment on how you'd like it to be fixed, I can probably get the patch written.
</p>
TicketazaozzMon, 05 Mar 2012 07:31:32 GMThttps://core.trac.wordpress.org/ticket/18311#comment:63
https://core.trac.wordpress.org/ticket/18311#comment:63
<p>
In <a class="changeset" href="https://core.trac.wordpress.org/changeset/20114" title="Based on the current UX feedback, remove the &#34;Insert Link&#34; UI from under ...">[20114]</a>:
</p>
<div class="message"><p>
Based on the current UX feedback, remove the "Insert Link" UI from under the caption fields, see <a class="closed ticket" href="https://core.trac.wordpress.org/ticket/18311" title="task (blessed): Support HTML in image captions. (closed: fixed)">#18311</a><br />
</p>
</div>
TicketwestiWed, 14 Mar 2012 12:00:55 GMThttps://core.trac.wordpress.org/ticket/18311#comment:64
https://core.trac.wordpress.org/ticket/18311#comment:64
<p>
I've done some simple testing with this and the change to a text area for entering the "Default Caption" allows the user to enter multi line data which then breaks the insert into post js:
</p>
<pre class="wiki">unterminated string literal
https://mytestsite/wp-admin/media-upload.php?type=file&amp;tab=library&amp;post_id=2509
Line 4
</pre><p>
for
</p>
<pre class="wiki">win.send_to_editor('[caption id=\"attachment_2375\" align=\"alignnone\" width=\"...
</pre>
TicketazaozzWed, 14 Mar 2012 21:53:12 GMThttps://core.trac.wordpress.org/ticket/18311#comment:65
https://core.trac.wordpress.org/ticket/18311#comment:65
<p>
In <a class="changeset" href="https://core.trac.wordpress.org/changeset/20174" title="Add support for line breaks to the caption textareas, see #18311">[20174]</a>:
</p>
<div class="message"><p>
Add support for line breaks to the caption textareas, see <a class="closed ticket" href="https://core.trac.wordpress.org/ticket/18311" title="task (blessed): Support HTML in image captions. (closed: fixed)">#18311</a><br />
</p>
</div>
TicketazaozzWed, 14 Mar 2012 21:57:57 GMThttps://core.trac.wordpress.org/ticket/18311#comment:66
https://core.trac.wordpress.org/ticket/18311#comment:66
<p>
Replying to <a class="closed" href="https://core.trac.wordpress.org/ticket/18311#comment:64" title="Comment 64 for Ticket #18311">westi</a>:
</p>
<p>
<a class="changeset" href="https://core.trac.wordpress.org/changeset/20174" title="Add support for line breaks to the caption textareas, see #18311">[20174]</a> fixes the error and converts line breaks to &lt;br&gt;. Currently it would convert multiple consecutive line breaks to one &lt;br&gt; as the HTML in the captions should contain inline tags only. Thinking that's the proper behavior there, may need another quick UX look.
</p>
TicketyoavfWed, 21 Mar 2012 11:23:48 GMTcc changedhttps://core.trac.wordpress.org/ticket/18311#comment:67
https://core.trac.wordpress.org/ticket/18311#comment:67
<ul>
<li><strong>cc</strong>
<em>yoav@…</em> added
</li>
</ul>
<p>
The textarea has the <tt>code</tt> class, which means it's automatically LTRd, even in RTL environments.
Since I presume most usage will still be with just text, it should be allowed to inherit the default text direction instead.
</p>
<p>
A few ways to do that:
</p>
<ul><li>Use Another class instead of <tt>code</tt>
</li><li>Have no class at all?
</li><li>An additional unique class that can be defined in the RTL css
</li><li>Use a wider selector for the RTL css, such as {{{.media-single textarea.code} maybe
</li></ul>
TicketazaozzWed, 21 Mar 2012 19:59:21 GMThttps://core.trac.wordpress.org/ticket/18311#comment:68
https://core.trac.wordpress.org/ticket/18311#comment:68
<p>
Replying to <a class="closed" href="https://core.trac.wordpress.org/ticket/18311#comment:67" title="Comment 67 for Ticket #18311">yoavf</a>:
</p>
<blockquote class="citation">
<p>
The textarea has the <tt>code</tt> class, which means it's automatically LTRd, even in RTL environments.
</p>
</blockquote>
<p>
Right, will remove the <tt>code</tt> class. Still thinking the textarea should have 'monospace' font as that improves readability for HTML tags.
</p>
TicketazaozzWed, 21 Mar 2012 22:48:37 GMThttps://core.trac.wordpress.org/ticket/18311#comment:69
https://core.trac.wordpress.org/ticket/18311#comment:69
<p>
In <a class="changeset" href="https://core.trac.wordpress.org/changeset/20247" title="Don't use class=&#34;code&#34; for the captions textareas as it resets RTL, see ...">[20247]</a>:
</p>
<div class="message"><p>
Don't use class="code" for the captions textareas as it resets RTL, see <a class="closed ticket" href="https://core.trac.wordpress.org/ticket/18311" title="task (blessed): Support HTML in image captions. (closed: fixed)">#18311</a><br />
</p>
</div>
TicketnacinSat, 24 Mar 2012 13:37:43 GMThttps://core.trac.wordpress.org/ticket/18311#comment:70
https://core.trac.wordpress.org/ticket/18311#comment:70
<p>
In <a class="changeset" href="https://core.trac.wordpress.org/changeset/20282" title="Revert UI for caption fields to pre-[19982], keeping textarea for the ...">[20282]</a>:
</p>
<div class="message"><p>
Revert UI for caption fields to pre-<a class="changeset" href="https://core.trac.wordpress.org/changeset/19982" title="HTML in image captions, first run, see #18311">[19982]</a>, keeping textarea for the caption field. No monospaced font, revert label. see <a class="closed ticket" href="https://core.trac.wordpress.org/ticket/18311" title="task (blessed): Support HTML in image captions. (closed: fixed)">#18311</a>.<br />
</p>
</div>
TicketnacinSat, 24 Mar 2012 13:38:38 GMThttps://core.trac.wordpress.org/ticket/18311#comment:71
https://core.trac.wordpress.org/ticket/18311#comment:71
<p>
I don't think a monospaced font is appropriate here. Reverted in <a class="changeset" href="https://core.trac.wordpress.org/changeset/20282" title="Revert UI for caption fields to pre-[19982], keeping textarea for the ...">[20282]</a>.
</p>
TicketazaozzSat, 24 Mar 2012 17:11:35 GMThttps://core.trac.wordpress.org/ticket/18311#comment:72
https://core.trac.wordpress.org/ticket/18311#comment:72
<p>
Replying to <a class="closed" href="https://core.trac.wordpress.org/ticket/18311#comment:71" title="Comment 71 for Ticket #18311">nacin</a>:
</p>
<blockquote class="citation">
<p>
I don't think a monospaced font is appropriate here.
</p>
</blockquote>
<p>
When using a variable width font the HTML tags are a bit harder to read. As the HTML editor has monospace font, added it here for consistency.
</p>
<p>
The change of the field's label from "Caption" to "Default Caption" was meant to distinguish between captions that are saved in the attachment post's excerpt vs. captions that are added after the image has been inserted in a post (discussed with Jane).
</p>
TicketnacinWed, 28 Mar 2012 20:32:02 GMTstatus changed; resolution sethttps://core.trac.wordpress.org/ticket/18311#comment:73
https://core.trac.wordpress.org/ticket/18311#comment:73
<ul>
<li><strong>status</strong>
changed from <em>assigned</em> to <em>closed</em>
</li>
<li><strong>resolution</strong>
set to <em>fixed</em>
</li>
</ul>
<p>
New bugs or enhancements on new tickets. Nice work, everyone.
</p>
TicketnacinWed, 28 Mar 2012 20:32:30 GMThttps://core.trac.wordpress.org/ticket/18311#comment:74
https://core.trac.wordpress.org/ticket/18311#comment:74
<p>
In <a class="changeset" href="https://core.trac.wordpress.org/changeset/20310" title="Revert label change in [20282]. see #18311.">[20310]</a>:
</p>
<div class="message"><p>
Revert label change in <a class="changeset" href="https://core.trac.wordpress.org/changeset/20282" title="Revert UI for caption fields to pre-[19982], keeping textarea for the ...">[20282]</a>. see <a class="closed ticket" href="https://core.trac.wordpress.org/ticket/18311" title="task (blessed): Support HTML in image captions. (closed: fixed)">#18311</a>.<br />
</p>
</div>
TicketaaroncampbellWed, 11 Apr 2012 20:49:44 GMTstatus changed; keywords, resolution deletedhttps://core.trac.wordpress.org/ticket/18311#comment:75
https://core.trac.wordpress.org/ticket/18311#comment:75
<ul>
<li><strong>keywords</strong>
<em>ux-feedback</em> <em>has-patch</em> removed
</li>
<li><strong>status</strong>
changed from <em>closed</em> to <em>reopened</em>
</li>
<li><strong>resolution</strong>
<em>fixed</em> deleted
</li>
</ul>
<p>
Quotes cause a lot of problems when used in shortcode parameters (like the quotes on html attributes). Let's try putting captions as part of the content instead. (see <a class="ext-link" href="https://irclogs.wordpress.org/chanlog.php?channel=wordpress-dev&amp;day=2012-04-11&amp;sort=asc#m384099"><span class="icon">​</span>IRC discussion</a>)
</p>
TicketnacinWed, 25 Apr 2012 19:54:05 GMThttps://core.trac.wordpress.org/ticket/18311#comment:76
https://core.trac.wordpress.org/ticket/18311#comment:76
<p>
In <a class="changeset" href="https://core.trac.wordpress.org/changeset/20593" title="Remove monospace from TinyMCE caption/alignment image edit popup. see ...">[20593]</a>:
</p>
<div class="message"><p>
Remove monospace from TinyMCE caption/alignment image edit popup. see <a class="closed ticket" href="https://core.trac.wordpress.org/ticket/18311" title="task (blessed): Support HTML in image captions. (closed: fixed)">#18311</a>.<br />
</p>
</div>
TicketnacinWed, 25 Apr 2012 20:01:17 GMTattachment sethttps://core.trac.wordpress.org/ticket/18311
https://core.trac.wordpress.org/ticket/18311
<ul>
<li><strong>attachment</strong>
set to <em>18311.php.diff</em>
</li>
</ul>
TicketazaozzThu, 26 Apr 2012 03:34:09 GMTattachment sethttps://core.trac.wordpress.org/ticket/18311
https://core.trac.wordpress.org/ticket/18311
<ul>
<li><strong>attachment</strong>
set to <em>18311-5.patch</em>
</li>
</ul>
TicketazaozzThu, 26 Apr 2012 03:40:01 GMThttps://core.trac.wordpress.org/ticket/18311#comment:77
https://core.trac.wordpress.org/ticket/18311#comment:77
<p>
18311-5.patch is support for a new style of caprions shortcode (contains 18311.php.diff):
</p>
<pre class="wiki">[caption id="" align="" width=""]&lt;a&gt;&lt;img /&gt;&lt;/a&gt;Caption Text and HTML[/caption]
</pre>
TicketsushkovThu, 26 Apr 2012 23:50:13 GMTattachment sethttps://core.trac.wordpress.org/ticket/18311
https://core.trac.wordpress.org/ticket/18311
<ul>
<li><strong>attachment</strong>
set to <em>0001-Added-tests-for-new-image-shortcode-handler.patch</em>
</li>
</ul>
TicketsushkovThu, 26 Apr 2012 23:51:46 GMTkeywords sethttps://core.trac.wordpress.org/ticket/18311#comment:78
https://core.trac.wordpress.org/ticket/18311#comment:78
<ul>
<li><strong>keywords</strong>
<em>has-patch</em> added
</li>
</ul>
<p>
Looks ok.
One note, I found this regex a bit shorter:
</p>
<pre class="wiki">preg_match( '~((?i:&lt;a\s.*&lt;img\s.*?&gt;.*?&lt;/a|&lt;img\s.*?)&gt;)(.*)~is', $content, $matches );
</pre><p>
I attached some tests you might want to take a look at and also come with some feedback.
</p>
TicketazaozzFri, 27 Apr 2012 00:46:04 GMTattachment sethttps://core.trac.wordpress.org/ticket/18311
https://core.trac.wordpress.org/ticket/18311
<ul>
<li><strong>attachment</strong>
set to <em>18311-6.patch</em>
</li>
</ul>
TicketazaozzFri, 27 Apr 2012 00:47:43 GMThttps://core.trac.wordpress.org/ticket/18311#comment:79
https://core.trac.wordpress.org/ticket/18311#comment:79
<p>
18311-6.patch is the same as 18311-5.patch except it adds a space between the &lt;img /&gt; tag and the caption text to make it a bit more readable. The space is trimmed when separating the caption from the image.
</p>
TicketnacinTue, 01 May 2012 01:20:31 GMTpriority, severity changedhttps://core.trac.wordpress.org/ticket/18311#comment:80
https://core.trac.wordpress.org/ticket/18311#comment:80
<ul>
<li><strong>priority</strong>
changed from <em>normal</em> to <em>highest omg bbq</em>
</li>
<li><strong>severity</strong>
changed from <em>normal</em> to <em>blocker</em>
</li>
</ul>
<p>
This needs to land prior to Beta 4.
</p>
TicketazaozzWed, 02 May 2012 00:38:03 GMThttps://core.trac.wordpress.org/ticket/18311#comment:81
https://core.trac.wordpress.org/ticket/18311#comment:81
<p>
Did some quick testing and seems the caption separating regex can be optimized a bit:
</p>
<pre class="wiki">preg_match( '#((?:&lt;a [^&gt;]+&gt;\s*)?&lt;img [^&gt;]+&gt;(?:\s*&lt;/a&gt;)?)(.*)#is', $content, $matches );
</pre><p>
seems to be twice as fast (as there's no back tracking from the <tt>.*?</tt>). The image tag + link + caption are generally not very long string but this runs on the front-end and any speedup is good.
</p>
TicketazaozzWed, 02 May 2012 01:14:52 GMTstatus changed; resolution sethttps://core.trac.wordpress.org/ticket/18311#comment:82
https://core.trac.wordpress.org/ticket/18311#comment:82
<ul>
<li><strong>status</strong>
changed from <em>reopened</em> to <em>closed</em>
</li>
<li><strong>resolution</strong>
set to <em>fixed</em>
</li>
</ul>
<p>
In <a class="changeset" href="https://core.trac.wordpress.org/changeset/20679" title="Change the image caption shortcode format to [caption ...]&lt;a&gt;&lt;img /&gt;&lt;/a&gt; ...">[20679]</a>:
</p>
<div class="message"><p>
Change the image caption shortcode format to [caption ...]&lt;a&gt;&lt;img /&gt;&lt;/a&gt; caption text + html<a href="https://core.trac.wordpress.org/caption">caption</a>. That way HTML tags in captions are better supported and the shortcode wouldn't break when using the wrong quotes. Props sushkov, nacin, fixes <a class="closed ticket" href="https://core.trac.wordpress.org/ticket/18311" title="task (blessed): Support HTML in image captions. (closed: fixed)">#18311</a><br />
</p>
</div>
TicketsushkovWed, 02 May 2012 06:18:21 GMThttps://core.trac.wordpress.org/ticket/18311#comment:83
https://core.trac.wordpress.org/ticket/18311#comment:83
<p>
Tests are still left aside, any chances we get those merged?
</p>
TicketazaozzFri, 18 May 2012 02:48:12 GMTstatus changed; resolution deletedhttps://core.trac.wordpress.org/ticket/18311#comment:84
https://core.trac.wordpress.org/ticket/18311#comment:84
<ul>
<li><strong>status</strong>
changed from <em>closed</em> to <em>reopened</em>
</li>
<li><strong>resolution</strong>
<em>fixed</em> deleted
</li>
</ul>
<p>
Got some UX feedback that the label change to "Default Caption" is not better, @nacin was right to revert it :)
</p>
TicketazaozzFri, 18 May 2012 02:50:06 GMTstatus changed; resolution sethttps://core.trac.wordpress.org/ticket/18311#comment:85
https://core.trac.wordpress.org/ticket/18311#comment:85
<ul>
<li><strong>status</strong>
changed from <em>reopened</em> to <em>closed</em>
</li>
<li><strong>resolution</strong>
set to <em>fixed</em>
</li>
</ul>
<p>
In <a class="changeset" href="https://core.trac.wordpress.org/changeset/20826" title="Image captions: revert label change back to &#34;Caption&#34;, fixes #18311">[20826]</a>:
</p>
<div class="message"><p>
Image captions: revert label change back to "Caption", fixes <a class="closed ticket" href="https://core.trac.wordpress.org/ticket/18311" title="task (blessed): Support HTML in image captions. (closed: fixed)">#18311</a><br />
</p>
</div>
TicketazaozzFri, 18 May 2012 23:10:00 GMThttps://core.trac.wordpress.org/ticket/18311#comment:86
https://core.trac.wordpress.org/ticket/18311#comment:86
<p>
In <a class="changeset" href="https://core.trac.wordpress.org/changeset/20831" title="Image captions: change query arg in the Edit Image iframe HTML to refresh ...">[20831]</a>:
</p>
<div class="message"><p>
Image captions: change query arg in the Edit Image iframe HTML to refresh browser cache, see <a class="closed ticket" href="https://core.trac.wordpress.org/ticket/18311" title="task (blessed): Support HTML in image captions. (closed: fixed)">#18311</a><br />
</p>
</div>
TicketazaozzFri, 18 May 2012 23:34:21 GMThttps://core.trac.wordpress.org/ticket/18311#comment:87
https://core.trac.wordpress.org/ticket/18311#comment:87
<p>
Replying to <a class="closed" href="https://core.trac.wordpress.org/ticket/18311#comment:83" title="Comment 83 for Ticket #18311">sushkov</a>:
</p>
<blockquote class="citation">
<p>
Tests are still left aside, any chances we get those merged?
</p>
</blockquote>
<p>
Looking through the tests: wouldn't it be simpler/more robust to feed them a shortcode string and compare the HTML string that comes out to what it should be? Using <tt>assertEquals( 1, preg_match_all( "~...*{$content_preg}~", $result, $_r ) );</tt> seems like a complicated way to do it.
</p>
TicketsushkovSat, 19 May 2012 11:56:51 GMThttps://core.trac.wordpress.org/ticket/18311#comment:88
https://core.trac.wordpress.org/ticket/18311#comment:88
<p>
I don't see how that is different with what is already done.
</p>
<p>
Maybe you can file a patch, or just update the unit-tests svn, I pushed it already some time ago.
</p>
TicketircbotTue, 17 Jun 2014 16:00:02 GMThttps://core.trac.wordpress.org/ticket/18311#comment:89
https://core.trac.wordpress.org/ticket/18311#comment:89
<p>
<em>This ticket was mentioned in IRC in #wordpress-dev by SergeyBiryukov. <a class="ext-link" href="http://irclogs.wordpress.org/chanlog.php?channel=wordpress-dev&amp;day=2014-06-17&amp;sort=asc#m870675"><span class="icon">​</span>View the logs</a>.</em>
</p>
TicketslackbotWed, 22 Apr 2015 14:48:30 GMThttps://core.trac.wordpress.org/ticket/18311#comment:90
https://core.trac.wordpress.org/ticket/18311#comment:90
<p>
<em>This ticket was mentioned in <a class="ext-link" href="https://make.wordpress.org/chat/"><span class="icon">​</span>Slack</a> in #core by paulschreiber. <a class="ext-link" href="https://wordpress.slack.com/archives/core/p1429714108005980"><span class="icon">​</span>View the logs</a>.</em>
</p>
Ticket