Pods: White screen conflict with Ninja Forms

[lauras]

Describe the bug
With Pods enabled, I am unable to edit a Ninja form (mostly JS UI). The forms work fine, and I can preview them. But if I want to edit a form, I get a white screen (though invisible html does get rendered — viewable via dev tools).

To Reproduce
Steps to reproduce the behavior:
(With Pods and Ninja Forms enabled)

1. Go to Ninja Forms admin dashboard
2. Click on gear icon next to any form
3. Click on "edit" under the form name
4. View white screen. (Using dev tools, see html)

Expected behavior
What should happen is a js-driven UI to configure the Ninja form.

Pods Version

2.7.12

WordPress Environment

WordPress Version: 5.1.1

PHP Version: 7.2.16-1+ubuntu16.04.1+deb.sury.org+1

MySQL Version: 5.5.5

Server Software: nginx/1.15.7

Your User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:66.0) Gecko/20100101 Firefox/66.0

Session Save Path: /var/lib/php/sessions

Session Save Path Exists: No

Session Save Path Writeable: No

Session Max Lifetime: 1440

Opcode Cache:

Apc: Yes
Memcached: No
OPcache: Yes
Redis: No

Object Cache:

APC: Yes
APCu: Yes
Memcache: No
Memcached: Yes
Redis: Yes

WPDB Prefix: wp_

WP Multisite Mode: No

WP Memory Limit: 256M

Current Memory Usage: 19.367M

Current Memory Usage (real): 20.000M

Pods Network-Wide Activated: No

Pods Install Location: /www/foo_283/public/wp-content/plugins/pods/

Pods Tableless Mode Activated: No

Pods Light Mode Activated: No

Pods Package Export (helpful!)

{"meta":{"version":"2.7.12","build":1555530048},"pods":{"104":{"id":104,"name":"book","label":"Book Sections","description":"A chapter or part of the book","type":"post_type","storage":"meta","object":"","alias":"","fields":[],"show_in_menu":"1","label_singular":"Book Section","public":"1","show_ui":"1","supports_title":"1","supports_editor":"1","label_all_items":"All Book Sections","label_search_items":"Search Book Sections","label_archives":"Book Archives","label_attributes":"Book Section Attributes","publicly_queryable":"1","exclude_from_search":"0","capability_type":"page","capability_type_custom":"book","capability_type_extra":"1","has_archive":"0","hierarchical":"1","rewrite":"1","rewrite_with_front":"0","rewrite_feeds":"0","rewrite_pages":"0","query_var":"1","can_export":"1","default_status":"draft","supports_author":"1","supports_thumbnail":"1","supports_excerpt":"1","supports_trackbacks":"0","supports_custom_fields":"1","supports_comments":"1","supports_revisions":"1","supports_page_attributes":"1","supports_post_formats":"0","built_in_taxonomies_category":"0","built_in_taxonomies_elementor_library_category":"0","built_in_taxonomies_elementor_library_type":"0","built_in_taxonomies_link_category":"0","built_in_taxonomies_post_tag":"0","show_in_nav_menus":"1","show_in_admin_bar":"1","pfat_enable":"0","pfat_run_outside_loop":"0","pfat_append_single":"append","pfat_filter_single":"the_content","pfat_append_archive":"append","pfat_filter_archive":"the_content","rest_enable":"1","read_all":"1","write_all":"1","menu_position":"5","menu_icon":"dashicons-book-alt","built_in_taxonomies_book_topic":"1","built_in_taxonomies_book_tag":"1"},"137":{"id":137,"name":"book_tag","label":"Book tags","description":"Freestyle tags for specific entities, keywords, topics","type":"taxonomy","storage":"meta","object":"","alias":"","fields":[],"show_in_menu":"1","label_singular":"Book tag","public":"1","show_ui":"1","hierarchical":"0","rewrite":"1","rewrite_with_front":"1","rewrite_hierarchical":"0","capability_type":"default","capability_type_custom":"book_tag","query_var":"0","sort":"0","built_in_post_types_astra_adv_header":"0","built_in_post_types_book":"1","built_in_post_types_custom_css":"0","built_in_post_types_customize_changeset":"0","built_in_post_types_elementor_library":"0","built_in_post_types_mc4wp-form":"0","built_in_post_types_nf_sub":"0","built_in_post_types_oembed_cache":"0","built_in_post_types_page":"0","built_in_post_types_post":"0","built_in_post_types_user_request":"0","built_in_post_types_wp_block":"0","built_in_post_types_attachment":"0","menu_location":"default","show_in_nav_menus":"1","show_tagcloud":"1","show_tagcloud_in_edit":"1","show_in_quick_edit":"1","show_admin_column":"0","pfat_enable":"0","pfat_run_outside_loop":"0","pfat_append_archive":"append","rest_enable":"1","read_all":"0","write_all":"1"},"105":{"id":105,"name":"book_topic","label":"Book Topics","description":"Primary topic areas for book content","type":"taxonomy","storage":"meta","object":"","alias":"","fields":[],"show_in_menu":"1","label_singular":"Book Topic","public":"1","show_ui":"1","hierarchical":"1","rewrite":"1","rewrite_with_front":"1","rewrite_hierarchical":"1","capability_type":"default","capability_type_custom":"book_topic","query_var":"0","sort":"0","built_in_post_types_astra_adv_header":"0","built_in_post_types_book":"1","built_in_post_types_custom_css":"0","built_in_post_types_customize_changeset":"0","built_in_post_types_elementor_library":"0","built_in_post_types_mc4wp-form":"0","built_in_post_types_nf_sub":"0","built_in_post_types_oembed_cache":"0","built_in_post_types_page":"0","built_in_post_types_post":"0","built_in_post_types_user_request":"0","built_in_post_types_wp_block":"0","built_in_post_types_attachment":"0","menu_location":"default","show_in_nav_menus":"1","show_tagcloud":"1","show_tagcloud_in_edit":"1","show_in_quick_edit":"1","show_admin_column":"1","pfat_enable":"0","pfat_run_outside_loop":"0","pfat_append_archive":"append","rest_enable":"1","read_all":"0","write_all":"1"}}}

Additional context
Pods is the only plugin to conflict with Ninja Forms.

Possible Workaround
My only workaround is disabling Pods, then going in to Ninja Forms to edit the forms. Once done, I reactivate Pods and all is fine.

[jimtrue]

@lauras Did you also open a bug report with Ninja Forms?

[jimtrue]

@lauras I just did a check against Ninja Forms and Pods and I'm not seeing any difficulties. Did you check your javascript Developer Console for errors? And also check for any additional conflicts:

We have a fairly good process for checking for conflicts:
https://docs.pods.io/faqs/plugin-theme-conflicts/

[lauras]

I'm going through a health check on the site in question. So far I have Pods, Ninja Forms, Astra theme and its Pro plugin running with no conflict.

As a quick experiment, I installed Pods on my own personal site. I did not do anything but activate the plugin. Then I went to Ninja Forms as described above, and again had the plain white render of the html. Here is what I got from Chrome console:

Uncaught TypeError: Cannot read property 'extend' of undefined
    at builder.js?ver=3.4.10:1
    at u (builder.js?ver=3.4.10:1)
    at c (builder.js?ver=3.4.10:1)
    at u (builder.js?ver=3.4.10:1)
    at c (builder.js?ver=3.4.10:1)
    at u (builder.js?ver=3.4.10:1)
    at c (builder.js?ver=3.4.10:1)
    at u (builder.js?ver=3.4.10:1)
    at c (builder.js?ver=3.4.10:1)
    at u (builder.js?ver=3.4.10:1)

The original site in question has the same error, plus the warning:

Manifest: property 'start_url' ignored, should be same origin as document.

The original site in Firefox console generates:

TypeError: Marionette.ItemView is undefined[Learn More] builder.js:1:2899
    <anonymous> https://foobar.foo/wp-content/plugins/ninja-forms/assets/js/min/builder.js?ver=3.4.10:1
    u https://foobar.foo/wp-content/plugins/ninja-forms/assets/js/min/builder.js?ver=3.4.10:1
    c https://foobar.foo/wp-content/plugins/ninja-forms/assets/js/min/builder.js?ver=3.4.10:1
    u https://foobar.foo/wp-content/plugins/ninja-forms/assets/js/min/builder.js?ver=3.4.10:1
    c https://foobar.foo/wp-content/plugins/ninja-forms/assets/js/min/builder.js?ver=3.4.10:1
    u https://foobar.foo/wp-content/plugins/ninja-forms/assets/js/min/builder.js?ver=3.4.10:1
    c https://foobar.foo/wp-content/plugins/ninja-forms/assets/js/min/builder.js?ver=3.4.10:1
    u https://foobar.foo/wp-content/plugins/ninja-forms/assets/js/min/builder.js?ver=3.4.10:1
    c https://foobar.foo/wp-content/plugins/ninja-forms/assets/js/min/builder.js?ver=3.4.10:1
    u https://foobar.foo/wp-content/plugins/ninja-forms/assets/js/min/builder.js?ver=3.4.10:1
    c https://foobar.foo/wp-content/plugins/ninja-forms/assets/js/min/builder.js?ver=3.4.10:1
    u https://foobar.foo/wp-content/plugins/ninja-forms/assets/js/min/builder.js?ver=3.4.10:1
    g https://foobar.foo/wp-content/plugins/ninja-forms/assets/js/min/builder.js?ver=3.4.10:1

Without Pods activated, there is no error. But maybe it's a 3-way conflict?

I will continue the health check on the client site. I hope some of this helpful?

[lauras]

Okay, I think I found it. Using troubleshooting mode, I found a 3-way conflict:

Elementor + Pods + Ninja Forms results in the error in question. Disable either Elementor or Pods and Ninja Forms works as expected.

This is with Twenty Nineteen theme and no other plugins enabled.

(It's on Kinsta hosting, so there is a MU plugin I can't get at. My personal site is on SG, though, which would seem to rule out a hosting issue.)

[lauras]

Update: I've passed along the info to the Elementor team, and Zachary at Ninja has replied to apologize for their previous form reply. I am passing along the additional info to them.

[lauras]

Passing this along:

I can also replicate the issue on my end, I even tried loading earlier versions of Ninja Forms but the issue remains.

However I tried rolling back Pods to version 2.7.9, Ninja Forms started to work...

—Elementor Technical Support

[jimtrue]

The error above pretty much points to a conflict with marionette/backbone but none of us will get to resolution of we don't all work on a similar ticket. Working in isolation will result in pointing fingers.

[lauras]

Both Ninja and Elementor have private ticketing systems, so there's nothing I can point you to. I've shared this Github issue's link with both teams. Anything else I can do?

[pglewis]

Marionette.ItemView is undefined

One of the other plugins is using an older version of Marionette as ItemView was removed a while ago and absorbed into View to simplify the API.

What needs to happen to fix this in 2.7: #5237

Note that using noConflict to avoid version conflicts will require all the plugins wanting to use Marionette globally to set things up a certain way to avoid stepping on one another (even if we put the noConflict code in place other plugins must do the same for them to work together).

This will go away for good in 2.8, thankfully.

[jimtrue]

Not really but encourage them to discuss here. Ninja should be using their primary GitHub as should Elementor since it's happening in both their free products, right?

[jimtrue]

Or at least cross post their issues

[lauras]

Yes, free versions for both (though I have a Pro account with Elementor and used that to report the issue to them). I'm passing along your messages.

[jimtrue]

Appreciate you coordinating @lauras

[pglewis]

Cross-linking some details on noConflict() for future time travellers: https://github.com/pods-framework/pods/issues/5163#issuecomment-425545680

[kjohnson]

@jimtrue @lauras cross-linking on behalf of the Ninja Forms team: https://git.saturdaydrive.io/_/ninja-forms/ninja-forms/issues/3933

[kjohnson]

At first glance, I see that the 3 plugins mentioned are not prefixing their registered backbone/backbone.radio/marionette scripts:

| Pods | Ninja Forms | Elementor |
| --- | --- | --- |
| backbone.radio| backbone.radio | backbone-radio|
| marionette| backbone-marionette-3 | backbone-marionette |

That said, this wouldn't necessarily cause a conflict if the applications were contained to the corrected admin pages for the respective plugins.

[kjohnson]

Loading the Ninja Forms builder does show that both Pods and Elementor are loading assets on the Ninja Forms builder page: /wp-admin/admin.php?page=ninja-forms&form_id=new

Elementor

Pods Framework

[pglewis]

Loading the Ninja Forms builder does show that both Pods and Elementor are loading assets on the Ninja Forms builder page

5111

Pods can extend things like WordPress's media content types, adding extra fields to be shown whenever someone accesses media items via the media modal. Editing post types that are not managed by Pods may still need our scripts because Featured Image may be enabled and media may be extended by Pods. This is just one concrete example to illustrate why it is difficult/impossible to determine when our script may need to be loaded in the admin, and with more and more plugins directly integrating with Pods it's simply best to always enqueue our client-side dependencies when in the admin.

What we should NOT do, however, is reference global scripts like Marionette in a way that may conflict with other plugins. This is what needs to be fixed and it's something all plugins need to cooperate on to avoid stepping on one anothers' toes.

I'll add details here on how plugins' scripts can coexist on the same page and not cause conflicts as well as a PR for Pods this week.

[pglewis]

The key to this is here: https://github.com/pods-framework/pods/pull/5358/files#diff-e34156692b93ef7d263924ac927338f2R327

1) Do not reference the global Marionette; use Backbone.Marionette instead. The reference in Marionette is not preserved by noConflict() and there is no way to stop the script from setting it if you use enqueue so it'll always be clobbered and will be "last loaded wins".

2) Immediately after enqueue, use Backbone.Marionette.noConflict() to namespace your plugin's private copy.

3) Change all code references to use the plugin's private instance

[pglewis]

• Once #5358 is merged we should no longer cause conflicts to anything referencing the global Backbone.Marionette.

• I've never discovered a way to preserve the bare Marionette reference, which is what I believe Ninja Forms and Elementor are both referencing, so it is likely that our fix will not iron out this conflict without changes to those plugins.

• Even if plugins reference Backbone.Marionette they still run the risk of trying to assign incompatible versions of Marionette to that reference. Plugins should either encapsulate their private copy of Marionette in their bundle-- outside the global namespace-- or use noConflict() like in #5358 to create a namespaced global reference for their own private use.

[sc0ttkclark]

Fixed via https://github.com/pods-framework/pods/pull/5358

[riverBanjo]

https://git.saturdaydrive.io/_/ninja-forms/ninja-forms/issues/3933

I believe this issue has reappeared. I was able to reproduce this today.

[JoryHogeveen]

We already implement noConflict for Marionette since this ticket so please report this at Ninja Forms.

[jomarieminney]

Hey all, if you are following this issue can you please jump onto this issue on Elementor and give it a thumbs up?

https://github.com/elementor/elementor/issues/10399

[janboen]

Hi,

Latest WP and fresh install of Ninja, using PODS and Elementor and have the same issue.
Is there a "permanent" fix available?
I just need this to work as we're forced to migrate to Ninja Forms due to Caldera Forms shutting down.

Thanks,

Jan

[sc0ttkclark]

@janboen to confirm, you're having this issue with Elementor and Ninja Forms, right? Follow up over at Elementor to help speed this along: https://github.com/elementor/elementor/issues/10399

[janboen]

Yes.

Combination of PODS, Elementor and Ninja Forms.

[sc0ttkclark]

@janboen I posted a reply to the Elementor issue with some further details on how Elementor can help address the issue. I don't think it's a Pods-specific issue at this point, it's most likely Elementor and Ninja Forms. Both are conflicting with each other, although Elementor itself is loading it's code on a Ninja Forms admin page unnecessarily -- Ninja Forms should definitely be doing something from their side too in my opinion.

[janboen]

Hi Scott,

Alas either disabling PODS or Elementor allows Ninja Forms to load.
From a practical point of view this means disabling PODS is the easier
work around as Elementor is used for all the pages on our websites.
Not sure who is right and wrong... we would like this to work. We're
paying users of Elementor and soon also of Ninja Forms so we would like
value for our money.
The PODS part we're using the free version but you seem to be shorter on
the ball.

Thanks,

Jan