Skip Navigation

[Resolved] In wysiwg form field, link brocken after modification and update

This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.

Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.

Our next available supporter will start replying to tickets in about 1.62 hours from now. Thank you for your understanding.

Sun Mon Tue Wed Thu Fri Sat
- 9:00 – 13:00 9:00 – 13:00 9:00 – 13:00 9:00 – 13:00 9:00 – 13:00 -
- 14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 -

Supporter timezone: Asia/Karachi (GMT+05:00)

Author
Posts
#2611627

Hi,

The WYSIWYG field in my forms has a strange behavior when updating the form. All the <a> links are broken after the update. For example, a link like:
<a href="https//acve.asso.fr/sejours-organises/"> during input, becomes <a href=”https//acve.asso.fr/sejours-organises/”> after saving, and then during the next update, it becomes <a href=””https//acve.asso.fr/sejours-organises/””>, and during the subsequent update, it becomes <a href=”””https//acve.asso.fr/sejours-organises/”””>, and so on.

Thanks

Jean

#2611833

Can any one help me to solve this issue ?

#2611837

Waqar
Supporter

Languages: English (English )

Timezone: Asia/Karachi (GMT+05:00)

Hi Jean,

Thank you for contacting us and I'd be happy to assist.

Looks like some of the HTML code that you included in your message was stripped. Are you experiencing this only in a particular form or is it happening in all of them?

Can you please share the exact steps and the code to reproduce the issue on your website? Some screenshots or a screencast would make it even more clear.

regards,
Waqar

#2611907
after second update text mode.jpg
after first update text mode.jpg
before first update text mode.jpg
before first update visual mode.jpg

Yes here are the screen shots :

First I added a new link in the wysiwyg field from my front end editing form (see before first update in text and visual mode)
Then I've updated the form clicking on the publish button, and if I go back on this same form I can see that the link has been changed some curved quotation marks has been added to the double quotation marks ( see after first update text mode) and if I click again on the publish button (changing nothing or something else in the form) it adds other curved quotation marks to the link, and every time the form is submitted, it adds other double quotation marks to all the links (see all the links in my screenshots).

#2611945

This was my first message :

The WYSIWYG field in my forms has a strange behavior when updating the form. All the <a> links are broken after the update. For example, a link like:

<a href="https//acve.asso.fr/sejours-organises/"> 

during input, becomes

 <a href="https//acve.asso.fr/sejours-organises/">

after saving, and then during the next update, it becomes

<a href=""https//acve.asso.fr/sejours-organises/"">

and during the subsequent update, it becomes

 <a href="""https//acve.asso.fr/sejours-organises/""">

and so on.

first after the first submit double quotes are transformed in curved quotation marks, and then it ads new curved quotation marks after every submit...

Thanks

Jean

#2612117

And ?

#2612125

Waqar
Supporter

Languages: English (English )

Timezone: Asia/Karachi (GMT+05:00)

Thank you for sharing these details.

I've been performing some tests with a similar form and content on my test websites but couldn't reproduce this behavior. This suggests that something specific to your website is involved.

Do I have your permission to download a clone/snapshot of your website? This will help in investigating this on a test server without affecting the actual website.

#2612127

Hi,
Yes you can take a clone.

#2612813

Waqar
Supporter

Languages: English (English )

Timezone: Asia/Karachi (GMT+05:00)

Thank you for waiting as this investigation turned out to be more complicated than initially expected.

I've been running some tests on your website's clone and here are the findings.

It is not recommended to assign a Toolset content template to a post type if Elementor's theme builder is being used for it too.
( ref: https://toolset.com/course-lesson/using-toolset-with-elementor-page-builder/#Limitations-when-using-Elementor )

On your website, a Toolset content template 'Loop item in carte des maisons protestantes en France' is assigned to the post type 'Hébergements' ( screenshot: hidden link ).

But, if you'll go to WP Admin -> Templates -> Theme Builder, you'll see that the template 'Post Hébergement' is also set for the same post type's single post pages. This template from Elementor is what is actually being used for those posts and Toolset's content template has no control and is not visible, so it is better to unassign it.

As for the main concern of the character's conversion in the WYSIWYG form field, it is only happening when the edit form is rendered inside the Elementor's theme builder template. If you'll test the same form on a regular page or a post with only the Toolset content template, the links and other HTML characters are preserved as normal.

To avoid this overprocessing of characters by the Elementor, here are some workarounds:

1. You can create a new static page e.g. 'Hébergements Edit' and without assigning any Elementor template to it, you can place the edit post form on this page.

On each single Hébergements post page, you can add an edit post link that will take the user to this new page for editing, with a target post's ID in a URL parameter.

OR

2. In case, you'd prefer to keep the users on the same Hébergements post page for editing, you can unassign the Elementor's theme builder template from this post type and instead use the Toolset's content template, as the main controller.

The form can be added inside this Toolset's template directly and any Elementor elements can be loaded through Elementor templates, using their respective shortcodes.

I hope this helps and please let me know if you have any follow-up questions.

#2613093

Ok, fine... I'll try the second solution. However, if you happen to find an easier way to accomplish this on your end, it would be greatly appreciated.

#2613485

Waqar
Supporter

Languages: English (English )

Timezone: Asia/Karachi (GMT+05:00)

Please let me know if you need any help in implementing the second solution or if you have any follow-up questions.

I've spent quite some time on this and I'm afraid, these are the only two options that I could come up with.

#2615333

I finally found a faster solution in JS.
I'm sharing it here in case others have the same issue as me:

It is necessary to ensure that the script is called on the page or post containing the form.

 
document.addEventListener("DOMContentLoaded", () =>
    document.querySelectorAll('.wpt-wysiwyg').forEach(textarea =>
        textarea.value = textarea.value.replace(/"/g, '"').replace(/"/g, '"')
    )
);

This solution saved me from changing everything... and from now on, I will know that it's better to place editing or creation forms in a separate toolset template .

#2615337

My issue is resolved now. Thank you!

This ticket is now closed. If you're a WPML client and need related help, please open a new support ticket.