#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)
#3
in reply to:
↑ 2
@
13 years ago
Replying to SergeyBiryukov:
Wouldn't it be possible to just hook into
the_content
beforedo_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.
#4
follow-up:
↓ 5
@
13 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.
#5
in reply to:
↑ 4
@
13 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="bar" 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.
#6
@
13 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 " that's defautly on. you may want to switch it off.
#8
@
13 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.
#9
@
13 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.
Wouldn't it be possible to just hook into
the_content
beforedo_shortcode()
to make the replacement?