New to the community? Start here

[Forminator Pro] FSE and Gutenberg Blocks?

1

Did I miss another request? Now with WP 6, FSE, and Blocks all the rage, can we look forward to Forminator support for Gutenberg blocks?

I can’t believe this hasn’t been suggested yet…

– Drop a Form block on a Page.
– Set the form ID to load the block list with one block for each field in that form.
– Build the page like any other Gutenberg page, with patterns, template parts, groups, columns, etc.
– Drop the fields into the page.
– Drop in the submit button.
– Style everything as desired, selecting local configuration only, or saving reusable blocks.

Forminator doesn’t need the responsibility of managing control order. The layout in the plugin shouldn’t change, for when we drop in a shortcode or form block. But we should be able to move fields around as required in the FSE, and save our configurations as patterns.

The exact same concept applies to Poll and Quiz forms as well.

I checked the roadmap.

> Exciting things on the way

Give me a break. What’s on the roadmap for Forminator? If this isn’t on it, let’s get it in there! :)

Thanks!

Tue, 19 Jul 2022 19:12:37
More Forminator Pro discussions
Forminator Pro
  • Nebu John
    • FLS

    Hi Tony G ,

    Trust you are doing good, and thank you for reaching out to us.

    Forminator does support Gutengerg Blocks.

    [attachments are only viewable by logged-in members]

    But it is not possible to configure the form directly from the page builder. However, I passed your suggestion to our Forminator Team and let’s see how complex this will be and can we expect this feature in the near future.

    Kind Regards,
    Nebu John

  • Tony G
    • Mr. LetsFixTheWorld

    This should be on the radar for Marketing and Management. Blocks are the Buzz. It’s Gut-enberg to support Gutenberg. Competitors have already done this, some of them poorly. WPMU DEV should not (again, sorry) come late to the party and then need to back off due to competition.

    Despite the seeming complexity, I think this is one that can be done relatively soon, to great fanfare. I don’t think any changes need to be made in the Forminator UI, form/poll/quiz creation – not yet anyway.

    This is just one way that this could work without changes to the Forminator UI:

    Put a Form Field block in the block selector list.
    When a Forminator block is dropped on the UI and the form is selected, save the form in transient state or elsewhere.
    When a Form Field block is dropped on the UI, use the state to find all fields within the form and offer them up in a list, just like the other block. Add two artificial selections to the list of fields : StartForm and EndForm. These must be used if field blocks are used.

    Now at UI generation time, assume the Form block must be placed after all Form Field blocks.
    On each event to process a new Form Field, just insert a placeholder and add the placeholder to a list.
    When the Form block goes to process a field, generate the UI control but don’t render it. Check the list of placeholders, and save the UI control markup with the placeholder as a key/value pair. If there is no placeholder, just render the markup exactly as before (or add it to a block that will be rendered later, I dunno how that is coded).
    Prior to final rendering, use one of the final pass events to go through the list of saved placeholders, inclusing StartForm and EndForm, and render them in the page where the Form Fields are located.

    That allows multiple Forminator objects on a page, just like we have now.
    No Forminator settings UI changes are required.

    I have not looked in the Forminator code recently. Your developer might suggest this is possible with an external plugin/integration IF there are short-circuit hooks before and after the processing of UI field controls. That is, if we can already get Forminator to not render UI components directly, but to save them as they are generated and then avoid a final rendering, then we/I can create a separate Forminator Field block to do all of the rest of it.

    So, it’s possible that I’m just asking for maybe one or two lines of code!
    That could be a single “apply_filters(‘forminator_filtername’, $markup, $args…)” : If the $markup is non-null before this and null afterward, don’t render the null, just skip processing, we expect the filter handler to render it … and that would be the external Field Block. This must apply to the Form and /Form tags as well .. OK, so maybe three lines?

    Example of how this might already be (pseudo)coded, and with one new line:

    
function generateForm() {
   [ $start, $end ] = getStartEndTags();
   foreach($fields as $field) { $markup[$field['name']=$this->getMarkup($field); }
   $markup = apply_filters('forminator_pre_render_form',[$markup,$start,$end]);
   // use $markup if there is anything left as usual to render a single form
 }

    I’m really asking for some exchanges with a developer who is intimate with this because he might say the hook(s) is/are already there and that to do this as described no changes should be necessary.

    So the next question is, after review and exchanges by a developer here, if we really are just missing a line or two, can we get them in the next point-release update of Forminator? Or do we really need to wait for a few years for this to get processed?

    If a week goes by and we can’t even get a developer to talk to us, I’ll look at the code myself again. But I usually have just enough time for exchanges here and my time to dig into other people’s code is limited.

    Thanks as always.