module FieldtypeFormSelect - A field for selecting forms built using the pro FormBuilder module

[FireWire]

FieldtypeFormSelect lets you create fields to select from forms created using the pro FormBuilder module.

Features:

• Create select fields that allow for choosing forms when editing pages
• Fully compatible with FormBuilder, render forms using native methods
• Choose which forms will be available to choose from, each field is configured individually
• Choose how form names will be presented in select elements
• Compatible with FormBuilderHtmx

FieldtypeFormSelect lets you create fields like this, configured as desired.

Choose which forms will be present.

Including forms where names start/end or contain a value allows you to create a form select field once then use form names to help group them together, or add/remove them from form selects without editing the field. This is also a pretty simple way to allow end users to create forms that will be selectable without having to edit a field configuration.

For example, this field will only allow you to choose forms having names ending with "request", so "customer-support-request" and "consultation-request" will be included, but where forms with names like "newsletter-signup" and "call-to-action" won't.

Choose how you would like the form names to be presented in the select element.

They can be shown as they are originally named, as spaced words, or as capitalized/spaced words.

Rendering in your templates is straightforward

<?php

$page->select_a_form; // => A form ID, or null if no form has been selected

// Render using the native FormBuilder method
echo $forms->render($page->select_a_form);

// Alternate method. Selected form will be rendered, if no form is selected output is null.
echo $page->render('select_a_form');

Form select fields store the ID of the selected form and FieldtypeFormSelect makes use of ProcessWire's built-in field rendering to keep things simple.

The fields you create will always be up-to-date with the forms as they currently exist. If a form is deleted that has been selected in one or more fields, those values will be set to null so you won't experience any issues with references to form IDs that no longer exist. Your templates and pages stay free from errors.

My primary use is to have a form select field available for blocks created in the RockPageBuilder module by @bernhard. I want each section on the page to contain an option to choose any form that will open in a modal to put the power of choosing forms in the hands of the user. RockPageBuilder is not required, but makes for a powerful example.

Contributions and issues are welcome on Github, or stop by here for some help!

Install as a ProcessWire module

Install via Composer

Download from the Github repository

Cheers!

[Macrura]

Thanks for this – I've been using FieldtypeForms for years, which was just a gist

https://gist.github.com/craigrodway/7515600

there may be another one here:

but much appreciated that you have made an official module for this, I use the form select module to allow site editors to select a form to show in a configurable page builder section.

[FireWire]

@Macrura I did take some inspiration from those conversations. Glad you find the module useful!

I've developed it on the fly and am using in a site that I'm building right now so any feedback or bugs you can report from your use will be helpful.

[Macrura]

Sure, well I don't know if/when I'll be able to use your version as I have mountains of infrastructure running on setups that I'm hesitant to change (if it ain't broke don't fix it), but probably on the next iteration of the main profile I use, I can see how the existing field could be replaced, and whether it will be a "drop in" replacement, or require some front end code adjustments...

[HMCB]

Great module. Thank you

[gornycreative]

For some reason this doesn't recall selections in repeaters for me. I see valid forms in the dropdown, select one and save, but the setting doesn't return to the form - the select element is stuck at the blank default.

On the backend, however, the selection is saved to the database.

[FireWire]

5 minutes ago, gornycreative said:

but the setting doesn't return to the form

Interesting. I'll take a look at that and see what I find.

Just to confirm, it's working in other places, just not repeater?

[gornycreative]

Just Repeater and RepeaterMatrix - like I said the value is still in the database so it doesn't break anything. Could be a fieldgroup context issue I just haven't had a chance to look at the code to see.

[FireWire]

3 hours ago, gornycreative said:

Could be a fieldgroup context issue

I tested in a repeater and didn't see the same issue so not sure. Let me know if you find something, interested in seeing what's up.

[gornycreative]

Okay... Doublechecking it was in RepeaterMatrix items only. Nested maybe 3 deep. I will play around with it later this week if it doesn't affect you and I'll let you know if I find anything related to the module.

I need to dig into how I can alter the pwimage selector in front-end editing to grab the imagefield from the item in a repeater field and not from the page where the repeater field is anyway so I will dig into that as well.

[FireWire]

Excellent. Looking forward to the results of your investigation, detective!

[Sanyaissues]

Hi! @FireWire! I'm using both FormBuilderHtmx and  FieldtypeFormSelect, so Thank you!

When I Submit a form with FormBuilderHtmx, the div where the form is, loads the whole page with the success message, and not only the success message as I was expecting.

Form before submission:

Spoiler

Form after submission:
 

Spoiler

This is how I'm rendering the form:

<?= $htmxForms->render(page()->form_selector, [], '#indicator') ?>

<div id="indicator" class="activity-indicator">
  <span class="loader"></span>
</div>

Do you have any clue why FormBuilderHtmx isn't extracting the content HTMX expects and is returning the full markup?
Thanks

[FireWire]

@Sanyaissues Indeed. It had been working in my use case, but this issue came up with another person using the module and I'm working on a fix.

So, fix and improvements are on the way.

[FireWire]

Hello all,

FieldtypeFormSelect has been added to the modules directory and is also now installable via Composer.

Thanks, and enjoy!

[gornycreative]

Nice to see it in the modules area! Thanks for putting it together!

I have two notes from working with it.

In my install it looks like the form id is stored in the field data as a string, not an integer, so the strict comparison on line 102 fails and I never get a selection for the dropdown from ___getFormOptions.

Dropping the === to a ==  fixes this for me, I suppose you could recast the stored value also.

There is no initial class set up for the inputfield - i.e. I'm using Admin themes and the UIKit class is not getting pulled into the initial load for the inputfield attributes.

Something like this could be used to get whatever admin theme classes exist:

  /**
   * {@inheritdoc}
   */
  public function ___render() {
    $attrs = $this->getAttributes();

	//ADD
	$adminTheme = $this->adminTheme;
    if($adminTheme && method_exists($adminTheme, 'getClass')) {
		$attrs['class'] = $adminTheme->getClass('select');
	}

    $value = $attrs['value'];

    unset($attrs['value']);

    return <<<EOT
    <select {$this->getAttributesString($attrs)}>
    {$this->___renderOptions($value)}
    </select>
    EOT;
  }

The only other thing I was thinking about - and I haven't done a ton of dev with FormBuilder so there might be a good reason for this - but I was wondering why you built this using a select instead of storing it as a PageField? I like having the ability to display the form using other formats besides the raw name - maybe that's easier with this method?

Anyways, thanks again!

[FireWire]

@gornycreative Sorry for the delay, have been buried with work. I'm a fan of strict typing and comparisons wherever possible, I'd be inclined to cast.

Can't remember if I considered storing it as a page reference rather than ID. The ID worked for this situation since the use case is either rendering via FieldtypeFormSelect or passing the value to FormBuilder to render. Page reference makes more sense though, it's finding the form page anyway so formatting the name for output doesn't rely on it.

What I should have done is render the input select using InputfieldSelect which would let ProcessWire manage theming. Unfortunately I think the answers you seek are all due to how fast I put this module together for use in a current project. I think your suggestions are good and I'll take another look at my approach.

[gornycreative]

Cool yeah I agree re: cast vs loose comparison. I'm not entirely sure why it is getting stored/pulled as a string in my install, but it is.

In terms of PageField vs field, this comes up if you have a braoder library of RepeaterMatrix types and need to iterate over the fieldgroup for the RepeaterMatrix - that field list gets a bit unwieldy (since it includes all fields for all matrix types for the given matrix).

If I have an operation that iterates through the fields list, I've found it useful to test certain operations where Page content is being used to test for instanceof PageField - but that is probably a niche case limited to page builder assemblies...

I don't think under normal circumstances it makes much of a difference.

[FireWire]

34 minutes ago, gornycreative said:

I don't think under normal circumstances it makes much of a difference.

We're planning for paranormal circumstances here.

[FireWire]

@gornycreative I've uploaded a new version of the module to the dev branch in the repository and it would be great if you can take it for a spin. The UI is fixed so that the field renders with the correct styling. Working with the values introduced some new opportunities and I took some notes from the feedback on the FormBuilderHtmx module on return values. The new rendering options are:

• Form ID or null when no form is selected (int)
• Form name or null when no form is selected
• FormBuilder form object or null when no form is selected

Adding the ability to work with the FormBuilder object directly affords some extra utility, it's a direct passthrough in that FieldtypeFormSelect retrieves and returns the form that $forms would have had you done that manually. This was in lieu of using a Page select field since Pages and Forms are retrieved differently. Examples are included on form config pages. I kept the Form ID option as default to help prevent a breaking change, but I haven't directly tested this version against the last version so let me know if you run into any issues.

Download from dev, I'll push a new version if everything works out well.

[gornycreative]

I will take a look this weekend. Thanks!

[JayGee]

Hi @FireWire - Great module thanks.

Using it in Repeater Matrix too and it is working great so far.

One issue - I don't think it's working with conditional fields (required only if, visible only if)... maybe a know issue or still on the roadmap though?

[FireWire]

@JayGee I caught that bug in a project I'm working on right now and forgot to update the repo!

Just pushed 1.0.1. You should be able to refresh your modules and see the upgrade. Let me know if that doesn't fix the issue.

[JayGee]

35 minutes ago, FireWire said:

@JayGee I caught that bug in a project I'm working on right now and forgot to update the repo!

Just pushed 1.0.1. You should be able to refresh your modules and see the upgrade. Let me know if that doesn't fix the issue.

Amazing thanks - will give that a test shortly and confirm back.

[JayGee]

8 hours ago, JayGee said:

Amazing thanks - will give that a test shortly and confirm back.

I've had a moment to check now and can confirm the upgrade solves the issue and conditional fields now work. Although I'm seeing a slightly different issue - some of my styling on the form changes when using your render()method.

At a glance I can't quite put my finger on what changes in the output to cause this - I think it could be to do with where in the page the scripts etc are injected vs. manually putting them into the template rather than a bug.

Which embed method does your module use for the form render?

(Sorry for the vague feedback!... up against a deadline and happy to test more for you later if it would be useful. 🙂) Great module though - super useful addition!

[FireWire]

@JayGee The module expects Method C so your markup should look something like this:

<?php
$htmxForm = $htmxForms->render('your_form_field');

echo $htmxForm->styles;
echo $htmxForm->scripts;
echo $htmxForm;

The module only swaps what's inside the form markup and shouldn't have any conflicts with scripts or styles.

Option C has been the best option for me because I can add the styles and scripts once on the page wherever I want them rather than directly where forms are rendered. I throw the CSS file up in the <head> element and the scripts at the bottom near the closing <body> tag with my others.