pods-framework / pods

The Pods Framework is a Content Development Framework for WordPress - It lets you create and extend content types that can be used for any project. Add fields of various types we've built in, or add your own with custom inputs, you have total control.
https://pods.io/
GNU General Public License v2.0
1.07k stars 264 forks source link

White screen conflict with Ninja Forms #5354

Closed lauras closed 5 years ago

lauras commented 5 years ago

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 commented 5 years ago

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

jimtrue commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

Or at least cross post their issues

lauras commented 5 years ago

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 commented 5 years ago

Appreciate you coordinating @lauras

pglewis commented 5 years ago

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

kjohnson commented 5 years ago

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

kjohnson commented 5 years ago

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 commented 5 years ago

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

image

Pods Framework

image

pglewis commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago
sc0ttkclark commented 5 years ago

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

riverBanjo commented 4 years ago

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

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

JoryHogeveen commented 4 years ago

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

jomarieminney commented 4 years ago

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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

Yes.

Combination of PODS, Elementor and Ninja Forms.

sc0ttkclark commented 3 years ago

@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 commented 3 years ago

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

sc0ttkclark commented 3 years ago

Background on this issue, while we did a no conflict call, somehow the no conflict call was getting called twice by a double register_assets call due to wp vs admin enqueue scripts action issue.

sc0ttkclark commented 3 years ago

Fixed for good in 2.8 as part of #6087