[Resolved] third party shortcode is not working in wysiwyg custom field

[Author]

Posts

[Suzan]

Tell us what you are trying to do?

I created many wysiwyg custom fields that are going to be used inside a CPT with content template and front-end form. When I enter third party shortcodes inside the wysiwyg of that custom field and save the custom post, I see after few minutes that the shortcode doesn't get executed and instead I see a script (the function) appearing in the wysiwyg and on the frontend.

This is an example of the shortcodes of the custom field I'm using
[types field='social-airline-index'][/types]

This is an example of one of the shortcodes I'm using in side the wysiwyg
[ff id="1"]

Inside the wysiwyg I have shortcodes from different third party plugins. I tested all of them and they all don't render after I save the CPT. I get to see a the function script instead.

See the screenshots of the wysiwyg with shortcode (first screenshot), then after I save the post (second screenshot) and finally the result on the front-end (third screenshot)

I

[Beda]

That is a JS Code snippet. Not a ShortCode, because those are written in PHP.

If your third party is printing JS with a ShortCode it is a wrong approach and should be corrected.
You will be able to see that all properly coded ShortCodes no matter the provider will work in a WYSIWYG field as well.

You can try that with a Toolset ShorCode or a custom shortcode like this:

function foobar_func( $atts ){
	return "foo and bar";
}
add_shortcode( 'foobar', 'foobar_func' );

This will create [foobar] shortcode that returns as: foo and bar
It will work nicely in a WYSIWYG

I think this is an issue with only some particular shortCodes of the third party you mention?
In this case, it needs to be reported there, but please first perform the above test to be sure it's not some other issue.

If the problem persists even with such correctly created ShortCodes, pleas let us know and if possible share a copy of the site (see https://toolset.com/faq/provide-supporters-copy-site/)

Thanks!

[Suzan]

Hi Beda

- The "shortcodes" or code snippets in questions used alway to work properly in those custom fields. I recently moved to using only toolset blooks and recreated all my templates using only the toolset blocks and the new wordpress editor

"You will be able to see that all properly coded ShortCodes no matter the provider will work in a WYSIWYG field as well"

I thought this too. I used to have the same shortcodes or snippets without problem printing...

"If your third party is printing JS with a ShortCode it is a wrong approach and should be corrected."

This is undoable Beda! Those shortcodes are from different plugins. As I said they were tested in custom fields created with toolset before and they worked just fine before.

- The custom shortcode you provided, where should I implement and test? can you kindly explain please?

[Christian Cox]

Hi, you can add the custom code Beda suggested in a child theme's functions.php file, or you can create a custom code snippet in Toolset > Settings > Custom Code.

[Suzan]

Hi Christian and Beda,

I tested submitting the front-end form to edit a CPT and followed your provided custom test code to be sure it's not some other issue.

These are the results:

BACKEND TEST (using the normal CPT backend editor)
---------------------

1- I go to the backend of my CPT (the regular backend clicking on edit the custom post)
2- I enter 3rd party shortcodes including test custom shortcode provided [foobar], text, featured image
3- I save/update the CPT and preview the frontend
4- Everything looks saved correctly. No matter how many times I update and save the CPT. The frontend looks having the featured image, the text and whatever the 3rd party shortcodes are supposed to display (table, chart, and so on). The Custom shortcode displays "foo and bar". In the backend, all the shortcodes, text and featured image are still correct and in place.

FRONTEND TEST (using the normal CPT backend editor)
---------------------

1- I go to the edit CPT using the edit link in the frontend of the post. (this link redirects me to editing the CPT using a "frontend" form)
2- I enter 3rd party shortcodes including test custom shortcode provided [foobar] , text, featured image and so on
3- I submit the form using the submit button and preview the frontend
4- Everything looks saved correctly the first time BUT when I go back to add more content and submit the frontend form, I see that all the shortcodes turned into code in the form fields and the featured image has again disappeared. On the frontend I see that form has echoed the code on the frontend too.

I expect the form fields to keep shortcodes in the form and to display what the shortcodes are supposed to output in the frontend of the CPT.

- I tried to test those 3rd party shortcodes on a normal wordpress page and they work fine. If I implement them in the backend and save the page, they show what they suppose to show in the frontend whether they are supposed to show a chart, a table or social media streams they work just fine. It is only when I implement them in a frontend form where they return a code after I refresh the page containing the form or when I add more content and submit the form

I look forward to your reply

[Shane]

Hi Suzan,

Christian is currently unavailable today but he will be back tomorrow to continue working through this issue with you.

Thank you for the continued patience.

[Christian Cox]

Hi, sorry for the delay. I have set up a test environment where we can collaborate on this issue. I have set up a scenario like you described, and I'm not able to reproduce the issue immediately. Please log in here: hidden link
Then you can create a new Book here:
hidden link
There are 4 WYSIWYG fields to test with, and the shortcode foobar is registered for use on the site. After you create a Book post, you will be redirected to the single Book post. There will be a link here to edit the post you just created, and in my tests so far I haven't been able to reproduce the issue. Please give it a test and let me know if you have different results.

If not, then there could be:
- a custom code, plugin or theme conflict
- some difference in our setups or field options in the block editor / shortcode attributes
- something else unpredictable

To rule out a conflict, please try the following troubleshooting steps:
- Make sure your Toolset plugins, theme, and WordPress installation are all up-to-date.
- Temporarily deactivate all plugins except Types, Forms, and Blocks/Views depending on which you have been using. Temporarily switch to a default theme like Twenty Twenty, and deactivate any custom code snippets you may have in Toolset > Settings > Custom Code.
- Test again. If the problem is resolved, reactivate your theme, other plugins, and custom code one by one, testing each time, until the problem returns. Let me know if you are able to pin down one theme or plugin responsible for the conflict.
- If the problem was not resolved, I'll need to take a closer look.

[Suzan]

Hi Christian,

I have recently been in touch with my host provider to exclude that the above issue I have been dealing with don't have anything to do with the settings of my site on the server side.

I have contacted my server and explained my issue what I have been discussing with you in this thread.

A cache path exclusion to the custom post type was enough to fix the issue.

I would really like to thank you for your effort in providing support for this issue in the last few days.

I want to issue something else for your information and knowledge base:

I discovered that if I create a taxonomy called: "status" wordpress refuse to save my custom post and returns an parameter error and doesn't save and change the status of the post. I run into this accidentally and asked my host provider to help my with this issue. An attentive help desk person notified me about this taxonomy conflict created with the toolset plugin and the problem disappeared.

I hope this can be made clear in the taxonomy creation page so other users of the toolset don't run accidentally in making the same mistake

Best regards,

New threads created by Christian Cox and linked to this one are listed below:

https://toolset.com/forums/topic/warn-users-about-problems-with-status-used-as-taxonomy/

[Christian Cox]

Okay thank you for the update. Regarding the "status" taxonomy name, I see how confusing that can be. I know there is a list of reserved terms here: https://codex.wordpress.org/Reserved_Terms
I will split this issue into a separate ticket so we can discuss in more detail, and I will check to see if I can escalate this as a Usability issue. I will contact you from the new ticket shortly.

[Suzan]

My issue is resolved now. Thank you!