Closed lauras closed 5 years ago
@lauras Did you also open a bug report with Ninja Forms?
@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/
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?
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.)
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.
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
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.
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?
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.
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?
Or at least cross post their issues
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.
Appreciate you coordinating @lauras
Cross-linking some details on noConflict() for future time travellers: https://github.com/pods-framework/pods/issues/5163#issuecomment-425545680
@jimtrue @lauras cross-linking on behalf of the Ninja Forms team: https://git.saturdaydrive.io/_/ninja-forms/ninja-forms/issues/3933
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.
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
Loading the Ninja Forms builder does show that both Pods and Elementor are loading assets on the Ninja Forms builder page
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.
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
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.
https://git.saturdaydrive.io/_/ninja-forms/ninja-forms/issues/3933
I believe this issue has reappeared. I was able to reproduce this today.
We already implement noConflict for Marionette since this ticket so please report this at Ninja Forms.
Hey all, if you are following this issue can you please jump onto this issue on Elementor and give it a thumbs up?
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
@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
Yes.
Combination of PODS, Elementor and Ninja Forms.
@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.
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
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.
Fixed for good in 2.8 as part of #6087
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)
Expected behavior What should happen is a js-driven UI to configure the Ninja form.
Pods Version
2.7.12
WordPress Environment
Pods Package Export (helpful!)
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.