running shortcode in html field

Hi @filipnarcis

Sorry to hear you are having this issue.

Can you verify if your form is loading from Ajax on Form > Behaviour > Rendering mode?

When the form loads from Ajax the DOM will load the JS before the form renders, so in case the script is looking for the tags it wouldn’t work as tags don’t exist yet, so disabling the Ajax method can help.

Let us know the result you got.
Best Regards
Patrick Freitas

Thank you for your response.
Rendering mode was already unchecked using ajax. If I choose ajax the shortcode appears as shortcode format, it’s not rendering at all. The problem seems to be elsewhere.

I also tried this code but it’s not working:

// Render shortcode on HTML fields
add_filter( 'forminator_replace_variables', 'do_shortcode' );
// Include shortcode output to hidden field
add_filter( 'forminator_form_submit_field_data', function( $field_data_array ){
    
    $form = array(
        'field' => 'html-12', // Form html field
        'shortcode' => '[table id=1 /]' // Shortcode to be rendered
    );

    foreach( $field_data_array as &$field_single ){
        if( $field_single['name'] === $form['field'] ){
            $field_single['value'] = strip_tags( do_shortcode( $form['shortcode'] ) );
        }
    }

    return $field_data_array;

});

Hi @filipnarcis

In this snippet that you tested, only this one line is relevant to the case:

add_filter( 'forminator_replace_variables', 'do_shortcode' );

However, I don’t think it’s a matter of “shortcode execution”. It is execucted correctly as you can already see the table in the field. The shortcode output itself doesn’t include any JS scripts to handle table behavior.

JS is included in the page footer and it seems for some reason it’s not able to “find” relevant elements in DOM and that’d be more of Tablepress issue rather than Forminator.

However, the HTML field is not store in form submission and e-mail notification and it doesn’t “interact” with other fields – it’s purely informational. Even if this would work, it would only display it and that’s it.

Is there any specific reason for putting the table there rather than just including it on page right below the form?

Kind regards,
Adam

I want to display it that way because in this form (wich is not finished) will be almost 40 tables and they will appear one by one as the user slects a field (with rules) so they can identify some data in that tables for selecting the next one. That’s why i need it to be in the form. In this case means I have to find a workaround.
Thank you for your answear.

Hi @filipnarcis

Thank you for response!

This makes sense and I understand why you want to use it that way. However, I did some more testing and I’m afraid I don’t see a workaround here.

There are two main issues:

1. JS not working in the first place

As mentioned previously, it’s not really a matter of shortcode being processed correctly or not. If the table is showing up, shortcode is working. The problem is that the JS is not correctly handling the DOM and upon further checkup it turns out it’s directly related to the DataTables library. It’s actually a 3rd-party library used by Tablepress plugin (not even from Tablepress developers).

There seems to be no any obvious conflicts or errors with Forminator and there doesn’t seem to be anything on Forminator end that should/could be fixed. It requires some changes in either how DataTables library is initialized (by the TablePress plugin) or how it handles tables.

2. Conditional visibility

You mentioned that tables should be showing up when adding select fields. This is yet another issue because even if these tables start to work in current configuration, then making more HTML fields to show up on site conditionally means a lot of additional JS and dynamically handled (by JS) fields on front. This would cause further conflicts.

To sum it up, making it all work together would require a lot of complex custom development which is out of the scope of this forum (note that using anything JS-driven inside Forminator forms is a custom feature and not bug fixing as Forminator is not designed to handle this kind of input).

A workaround could be to use “static” tables. A 36 or so rows table isn’t super-long in my opinion so if you disable DataTables functions in table settings (when you edit table you can do so at the bottom of table settings) a full table should be showing up and while there’d be no paging and sorting, it would be displayed and those tables should work fine with conditionally visible HTML fields.

Kind regards,
Adam

Good idea to use static tables with all rows. It’s just a little more scrolling. it should be no problem. Thank you for your answer and testing. ?? Good plugin support for Forminator!