Multisite support

[lexislav]

Support for multisites would be great - are there any plans for that?

• translating form fields
• adjusting form fields settings for differen sites/languages (phone field/phone format, adress field default values etc.)
• editor's premissions to access the forms (based on Sites/SItes group etc.)

[engram-design]

It's something earmarked for further down the track. There's a lot to consider, and we're not even sure if it's possible without a significant amount of work. Namely, because form fields inherit from Craft's own fields, which aren't managed on a per-site basis. We'd need to roll out own fields_sites table, which would get pretty hairy with complex fields like repeater.

Then there's the complication of storing the content on a per-site basis. As each form in each site could have different fields. We'd probably have to just have the field settings site-editable.

Similarly, with editors permissions might be difficult as well. Form's are elements, so it'd be like setting up permissions for a specific entry, which isn't really possible in core Craft.

[giorgiopogliani]

@engram-design What about having only the submissions multi-site aware? The submissions are just elements that can be multi-site aware, am I wrong? I'm trying to add this because I would need to view and filter the submissions by the site where the form was sent.

[engram-design]

That's slightly more achievable, and would also be good to store the site a submission was made on, for a few other issues. There's currently no way to know which site a submission was made on, short of adding custom hidden fields.

I might recommend creating a new issue for multi-site submissions.

[MattWilcox]

Just adding a +1 to this. At the moment we're advising the client to create the "same form" twice, with the only difference being the language used for each of them, and telling them to then pick the correct langauge version to feature on a page via the Formie field-type.

It works, it's just doubling the work for the client each form.

[engram-design]

@MattWilcox Yep, I know it's far from ideal, but that'll be the solution for the near future.

[rtrudel]

Workaround (and cheap) suggestion: What if the fields rendering use whateverTheLabelIs|t. With this set, it could at least translate the default labels (ex: First Name, Last Name, etc.) using Craft translation (or a translation plugin). Or to make it optional (Use translated markup for labels, placeholders and info on rendering).

This is also far from ideal, but at least, most common cases will be handled.

[engram-design]

Yep, that's what we currently do, we use | t (with no category) which uses the site translations (your site.php static translation file). There's really only a small handful of settings that use the formie.php static translations class, but they're mostly for control panel based settings.

The issue I believe is mostly around having forms and their fields managed per-site in the control panel.

[rtrudel]

This may be a long shot, but this workaround achieves something almost satisfactory. You can render the form (using renderForm() or another way) after performing some settings overwrites like this:

    {% set form = craft.formie.forms({ handle: 'contactForm' }).one() %}

    {% do form.setFieldSettings('yourName', {        
        firstNamePlaceholder: 'Prénom'|t,
        firstNameErrorMessage: 'Ce champ est requis'|t,
        lastNamePlaceholder: 'Nom de famille'|t,
        lastNameErrorMessage: 'Ce champ est requis'|t,
    }) %}

    {% do form.setFieldSettings('emailAddress', {        
        placeholder: 'Adresse courriel'|t,
        errorMessage: 'Requis et doit être valide'|t,
    }) %}

     {% do form.setFieldSettings('yourPhoneNumber', {        
        placeholder: 'Votre numéro de téléphone'|t,
        errorMessage: 'Requis et doit être valide'|t,
    }) %}

    {% do form.setFieldSettings('subject', {        
        placeholder: 'Sujet du message'|t,
        errorMessage: 'Ce champ est requis'|t,
    }) %}

    {% do form.setFieldSettings('message', {        
        placeholder: 'Votre message'|t,
        errorMessage: 'Ce champ est requis'|t,
    }) %}

    {# RENDER #}
    {{ craft.formie.renderForm(form) }}

Then you can use Craft translation system to do the rest. For from perfect, somewhat ugly hack, but working.

see https://verbb.io/craft-plugins/formie/docs/developers/field for available attributes.

[wolfwohlwend]

+1 An easy way to localize forms in a multisite environment would be phantastic. 99% of our webistes are multilingual and this would make our work significantly easier.

[wallacio]

Slightly different requirement, but along the same lines - I'm building a multisite although all in the same language.

The "Contact" form is common to all sites, the only difference being that the form on each site posts to a different Campaign Monitor list ID. I can appreciate the complexity in not providing that as an option as things currently are but if the form (currently generated from a Stencil) could account for a paramaterised Campaign Monitor list ID, that would be really useful.

Unless I'm being an idiot, the only alternative I can see is to generate a form per site, customising the Campaign Monitor settings for each.

[engram-design]

@wallacio That'd be similar to https://github.com/verbb/formie/issues/419 I'd say!

[wallacio]

@wallacio That'd be similar to #419 I'd say!

I'd say you'd be quite correct, and apologies for sloppy searching!! I've made the client realise that actually, a single list will do with a "site" field which they can easily segment it by.

[JshGrn]

Yep, that's what we currently do, we use | t (with no category) which uses the site translations (your site.php static translation file). There's really only a small handful of settings that use the formie.php static translations class, but they're mostly for control panel based settings.

The issue I believe is mostly around having forms and their fields managed per-site in the control panel.

If I have a 'Name' field with split names using First Name + Last Name, how do I target these in my site.php file? I have tried many combinations but can't see what its trying to match for placeholder and labels? Did anyone else have success with this?

[engram-design]

So that will have changed since, as Formie 2 uses the formie.php translation category, so everything Formie-translatable will be in that file.

[JshGrn]

Ah perfect, must have missed that in the docs.. works perfectly :).

[daltonrooney]

I have a translated site and wanted to use the same form for both languages. Kind of building on @rtrudel's example above, I'm working on a small module that accepts a form element, iterates through the fields and matches labels with static translations, updates the field settings, and returns the modified form. This seems to be working fine with my site.php translation file:

<?php 

namespace modules\common;
use verbb\formie\fields\formfields\Name;
use verbb\formie\fields\formfields\Address;
use verbb\formie\fields\formfields\Agree;
use verbb\formie\helpers\RichTextHelper;
use Craft;

class FormUtils {

  static public function TranslateLabels($form) {
    $fields = $form->getCustomFields();
    foreach ($fields as $field) {
      $form->setFieldSettings($field->handle, [        
        'name' => Craft::t('site', $field->name)
      ]);
      if ($field instanceof Name) {
        $form->setFieldSettings($field->handle, [        
          'prefixLabel' => Craft::t('site', $field->prefixLabel),
          'firstNameLabel' => Craft::t('site', $field->firstNameLabel),
          'middleNameLabel' => Craft::t('site', $field->middleNameLabel),
          'lastNameLabel' => Craft::t('site', $field->lastNameLabel)
        ]);
      }
      if ($field instanceof Address) {
        $form->setFieldSettings($field->handle, [        
          'address1Label' => Craft::t('site', $field->address1Label),
          'address2Label' => Craft::t('site', $field->address2Label),
          'address3Label' => Craft::t('site', $field->address3Label),
          'cityLabel' => Craft::t('site', $field->cityLabel),
          'stateLabel' => Craft::t('site', $field->stateLabel),
          'zipLabel' => Craft::t('site', $field->zipLabel),
          'countryLabel' => Craft::t('site', $field->countryLabel),
        ]);
      }

      if ($field instanceof Agree) {
        $field->setDescriptionHtml($content = Craft::t('site', RichTextHelper::getHtmlContent($field->description)));
      }
    }

    /* More field types here */

    return $form;
  }
}

[jornwildenbeest]

@engram-design any updates regarding the multisite support?

Will there be an easy way to translate form fields, without adding static strings in the formie.php file, because that defeats the whole purpose of the formie plugin for some of our clients.

[engram-design]

@jornwildenbeest No update, it's a massive task, but some of the prep work has been started in Formie 3. You can expect it in Formie 4, which is a long way away yet.

But of course that's the plan, static translations is entirely a stop-gap for the moment.

[samuelreichor]

@engram-design what are your thoughts on a setting where we can select a default language for forms?

At the moment, the craft user language that you can set in the user settings is the default language for forms, which makes total sense, but not for texts that are output in the frontend, I think.

For example, I always have English as the user language but maintain forms for a German site. So the default error messages and submission texts are in English instead of German.

This could be avoided by setting a default language for all translations that are displayed in the frontend.