Custom protectedSource ruins content

[WayFarer]

When using custom protection for {tagname ...} elements (not for smarty here)

config.protectedSource = [/\{.*?\}/gi]; // { } tags.

(one protection pattern only)

editor sometimes selectively ruins {} tags, tested with latest FF and IE7/8
example:

{link page="test"}<p>
This Web site was created with you in mind. In your busy schedule at work or at home, you may not have the time to call, visit or schedule an appointment with us. We realize this and have created this helpful and informative Web site to meet your needs 24 hours a day. Detailed information has been provided regarding our <a href="{link page="services"}" target="_top">services</a>, <a href="{link page="merchandise"}" target="_top">merchandise</a>&nbsp;and&nbsp;<a href="{link page="prices"}">prices</a>, our <a href="{link page="grief-resources"}" target="_top">grief resources</a>, <a href="{link page="when-death-occurs"}">what to do when death occurs</a> and information on various other topics. 
{link page="test"}

become

{link page="test"}
<p>
	This Web site was created with you in mind. In your busy schedule at work or at home, you may not have the time to call, visit or schedule an appointment with us. We realize this and have created this helpful and informative Web site to meet your needs 24 hours a day. Detailed information has been provided regarding our <a href="&lt;!--{cke_protected}%7Blink%20page%3D%22services%22%7D--&gt;" target="_top">services</a>, <a href="&lt;!--{cke_protected}%7Blink%20page%3D%22merchandise%22%7D--&gt;" target="_top">merchandise</a>&nbsp;and&nbsp;<a href="&lt;!--{cke_protected}%7Blink%20page%3D%22prices%22%7D--&gt;">prices</a>, our <a href="&lt;!--{cke_protected}%7Blink%20page%3D%22grief-resources%22%7D--&gt;" target="_top">grief resources</a>, <a href="&lt;!--{cke_protected}%7Blink%20page%3D%22when-death-occurs%22%7D--&gt;">what to do when death occurs</a> and information on various other topics. {link page="test"}</p>

Please note, that not all {} tags ruined.

[Garry Yao]

Works for me, could you try to provide a sample page for reproducing? Note: protected source function doesn't support attribute value protection.

[WayFarer]

Replying to garry.yao:

Works for me, could you try to provide a sample page for reproducing? Note: protected source function doesn't support attribute value protection.

The shortest example which doesn't work for me is:

<a href="{link page="services"}">link text</a>

Paste it in HTML mode. It ruins protected tags inside attribute href. Content become the following after switching from HTML to WYSIWYG:

<p>
	<a href="&lt;!--{cke_protected}%7Blink%20page%3D%22services%22%7D--&gt;">link text</a></p>

More times I switching - much garbage it produces... after second switch:

<p>
	<a href="&lt;!--&lt;!--{cke_protected}%7Bcke_protected%7D--&gt;%7Blink%20page%3D%22services%22%7D--&gt;">link text</a></p>

etc...

As I understand if attrubute value protection is not supported - attribute value should stay untouched in WYSIWYG mode. But it became garbaged with {cke_protected} stuff.

It seems like only one way protection routine triggers (protection works), but "unprotection" doesn't catch what have been previously protected. -- Just my thoughts.

[fabio]

I'm having the same problem! Dou you know when it will be corrected?

[ecki]

Replying to WayFarer: Using

config.protectedSource.push( /<\?[\s\S]*?\?>/g );   // PHP Code

there is another example which doesn't work:

<a href="<?php print $url; ?>">link text</a>

Paste it in HTML mode, then switch to WYSIWYG and back again into HTML mode. It seems to have to do with php tags inside quotation marks inside tags.

(As a work-around you can use

<?php print '<a href="'.$url.'">link text</a>'; ?>

which is not very comfortable.)

[Alfonso Martínez de Lizarrondo]

The problem is similar to #4880, the protection isn't done in a symmetrical way: first is done using a regexp on a string, but then it's restored while parsing nodes.

The patch fixes both this bug and #4880

[Alfonso Martínez de Lizarrondo]

Proposed patch

[adam]

Replying to alfonsoml: Hello,

this patch works well for our sites, and solves a rather critical problem.

Can this fix be scheduled into the next release?

Happy to help in any way I can!

Regards,

Adam.

[Wiktor Walc]

I'm not sure if #6759 can be marked as duplicate of this ticket (didn't check whether patch attached here fixes issue described there), in any case I haven't seen a bug report regarding attributes.

[Alfonso Martínez de Lizarrondo]

yes, comments 2 and 7 state that issue

[Wiktor Walc]

(The proposed patch does not solve the problem with editing attributes containing protected source in dialogs - issue reported in #6759)

[Garry Yao]

Protect attribute value is an unnecessary feature, instead we should simply leave them intact.

[Garry Yao]

After some investigation as well as a discussion with Wiktor, it looks difficult to have other syntax live peacefully inside attribute value, as browser will likely to touch it a lot, so we can't really offer a DreamWeaver alike feature here, but considering that many existing application out there heavily relies on embedded syntax inside attribute, so we should at least provide the ability to keeping them intact (in source mode).

The patch is enhanced protected source feature that protect into placeholders text like {cke_protected_1}.

[Sa'ar Zac Elias]

Real values should be restored in dialogs.

[Garry Yao]

Replying to Saare:

Real values should be restored in dialogs.

This's by design, as achieving that requires much complexity when r/w attribute values.

[Garry Yao]

Fixed with [6457].