WordPress.org

Make WordPress Core

Opened 2 years ago

Closed 8 months ago

Last modified 8 months ago

#19639 closed enhancement (invalid)

Enhancement: request: filter support before shortcodes are parsed or convert " into "

Reported by: archon810 Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.3
Component: Shortcodes Keywords: close
Focuses: Cc:

Description

My team uses Windows Live Writer to do all posting, but we constantly have trouble using shortcodes because WLW, being as awesome as it is in other aspects, keeps converting the double quotes in shortcodes to

"

This breaks shortcode attributes, and while we're working around it using single quotes, we can't use shortcode attribute data that contains single quotes then.

So, is there a good fix for this?

One workaround would be to have a filter that runs before shortcodes are parsed that converts " back to ". However, in the shortcode API, I found no filters in use at all, so that's out without modifying WP source.

Alternatively, the API could just pre-process the data and take care of this case, which should be solved in WP core yet again.

Is there some way to resolve this without the above modifications to core?

Thanks.

Change History (11)

comment:1 archon8102 years ago

  • Cc admin@… added

comment:2 follow-up: SergeyBiryukov2 years ago

Wouldn't it be possible to just hook into the_content before do_shortcode() to make the replacement?

comment:3 in reply to: ↑ 2 archon8102 years ago

Replying to SergeyBiryukov:

Wouldn't it be possible to just hook into the_content before do_shortcode() to make the replacement?

I'd rather avoid doing something this involved and apply the fixes once each shortcode is being processed and the parameters have already been split up into a list. Ideally, changes to the whole $content should be avoided IMO, especially if regex is the only [sane] way to accomplish the task.

Last edited 2 years ago by archon810 (previous) (diff)

comment:4 follow-up: dd322 years ago

Can you post an example of the problem you're seeing? ie. The code in WLW and the code that you then see in the Visual Editor when editing that post?

This partially sounds like something that might need to be fixed in the shortcode parsing rather than a easier filter being added for you to fix it.

comment:5 in reply to: ↑ 4 archon8102 years ago

Replying to dd32:

Can you post an example of the problem you're seeing? ie. The code in WLW and the code that you then see in the Visual Editor when editing that post?

This partially sounds like something that might need to be fixed in the shortcode parsing rather than a easier filter being added for you to fix it.

Sure thing.

[test foo="bar" alpha='beta']

becomes this in source:

<p>[test foo=&quot;bar&quot; alpha='beta']</p>

I think if the parameter data is decode_entities'ed, it should be good to go, but it may be undesirable in case the data you're passing is supposed to be encoded. In that case, maybe treat it as a special case and be extra careful to just strip/decode these off the beginning and end only.

comment:6 dd322 years ago

Cheers. I'm just glad it's not curly quotes :) I'd classify this as a WLW bug myself, there's no need to encode the character in most cases.

It's been an issue for so long, that it looks like WLW has an option to turn off the character encoding:

http://social.microsoft.com/Forums/sk-SK/writergeneral/thread/c4d57a61-4a99-46f3-957d-43e15f4ed8de
the latest version 15.4 has an option replacing quotmarks with &quot that's defautly on. you may want to switch it off.

comment:7 archon8102 years ago

The problem is, there is no such option, and I have 15.4.

comment:8 dd322 years ago

I don't have a copy of WLW to test with right now, but the above forum suggests the option might be under Blog -> Edit Blog Settings -> Advanced - I'll test it out later if that doesn't help/isn't there.

comment:9 archon8102 years ago

OK, I found an option that makes this go away - it's called Markup language, and it's set to XHTML by default (even though the help hint says HTML should be default - yeah, not so). Changing it to HTML fixes the issue, though I'm not sure what other side effects it could bring.

So, there's no separate quote related option (there is one for smart quotes, but it's not relevant), but a fix is available. It'd still be great if Wordpress could handle this case for default WLW setups, but it's not necessary anymore.

Why not add a few pre-processor filters to shortcodes, however? Is there any harm to doing so? I remember wanting those before on some occasions, although they may all end up being because of this quote problem.

comment:10 c3mdigital8 months ago

  • Keywords close added
  • Resolution set to invalid
  • Status changed from new to closed
  • Type changed from defect (bug) to enhancement

comment:11 helen8 months ago

  • Milestone Awaiting Review deleted
Note: See TracTickets for help on using tickets.