[Closed] Compatibility issue with HappyForms

[Author]

Posts

[matthewL-7]

Hi

There seems to be an issue with the Happyforms plugin, when using in a Toolset view/archive their custom CSS that has been set does not load from the looks of it, it looks fine in the block editor but then on the front end all messes up. See the attached screenshots.

Thanks.

[Christian Cox]

Okay I can see this in a test site with the basic Happy Forms plugin active. The screenshots below show a difference between the same form loaded in a basic Page and in a View's loop. On my test site, it seems that the stylesheet /wp-content/plugins/happyforms/core/assets/css/layout.css is not loaded when the form is displayed in a View loop. Let me escalate this to my 2nd tier support team for additional investigation. In the meantime, you may be able to enqueue this stylesheet manually on specific pages using wp_enqueue_scripts.

[Christian Cox]

Based on some feedback from the 2nd tier support team, for now it seems that enqueuing the stylesheet manually on specific pages using wp_enqueue_scripts is the most effective solution. Our Blocks team works with other popular plugins to ensure this problem does not occur by adding compatibility layers, but this is the first time we've seen this HappyForms plugin mentioned in the support forums. As more Users mention this issue, we may reevaluate our need for a compatibility layer with this particular plugin, but for now we do not plan to add code specific for HappyForms.

If you need assistance writing a script to enqueue the stylesheet on particular pages, please see the following example that encodes a stylesheet from a child theme on single posts with IDs 1, 2, 3, or 4:

add_action( 'wp_enqueue_scripts', 'my_custom_enqueue_scripts' );
function my_custom_enqueue_scripts() {
  if( is_single( array( 1, 2, 3, 4 ) ) ){
    $parent_style = 'twentytwenty-style';
    wp_enqueue_style( 'child-style',
      get_stylesheet_directory_uri() . '/style.css',
      array( $parent_style ),
      wp_get_theme()->get('Version')
    );
  } 
}

[matthewL-7]

The plugin developers seem keen to resolve this, is there any documentation you provide for plugin devs on compatibility for example I could point them to? Or a contact for them to reach out to?

[Nigel]

It looks like the form plugin scans a page to know whether it includes one its forms so as to know whether to enqueue its assets on that page or not, and because the form isn't on the page itself but is buried in a View (so is dynamically inserted into the page) the scan misses the form and the stylesheet is not enqueued.

The simplest and most performant solution is to just enqueue the assets yourself on pages where you know you have inserted a View containing such a form in its output, or to add the form directly to the page rather than via the View so that it is picked up by the plugin.

If the plugin authors want to "fix" this, they probably need to expand shortcodes in the page content they are scanning to find buried forms in the page, but that could potentially be an expensive solution in terms of performance and I'm not sure they would want to go down that route (or whether you would want them to). They can contact olivia.oprey@onthegosystems.com who conducts 3rd-party relations and she can put them in touch with the right developer.

[Christian Cox]

Let us know if you have additional questions about that.