Plugin breaks tabs and accorditions of other plugins
wpsoul opened this issue · comments
I found a bug and incompatibility with different plugins. For example, with Visual Composer.
Error code is TypeError: caller is undefined
I found that this part causes issues
$.each(['show', 'hide'], function (i, ev) { var el = $.fn[ev]; $.fn[ev] = function () { this.trigger(ev); return el.apply(this, arguments); }; });
Fix which helps me - I changed to this code
$.each(["show","hide"], function(){ var _oldFn = $.fn[this]; $.fn[this] = function(){ var hidden = this.find(":hidden").add(this.filter(":hidden")); var visible = this.find(":visible").add(this.filter(":visible")); var result = _oldFn.apply(this, arguments); hidden.filter(":visible").each(function(){ $(this).triggerHandler("show"); }); visible.filter(":hidden").each(function(){ $(this).triggerHandler("hide"); }); return result; } });
Hi @wpsoul, thanks for reporting & providing a solution.
I've come up with a slightly simpler solution and I'm wondering if that would solve it just the same. Unfortunately I haven't been able to reproduce the issue as I don't use Visual Composer.
Would you mind testing it ?
You can find my alternative solution here: https://github.com/jrfnl/cmb2-conditionals/tree/feature/fix-issue22-compat-alternative
Can you tell me which of files were changed? because I added many other small changes in extension, so, currently don't want to change whole extension
On second thought, I don't think the alternative will work.
All the same, I'm interested to hear what other changes you've made to the plugin. Anything you think might be useful to others ? Anything which could be turned into a PR (or several PRs) ?
Oh and FYI:
Pro-tip: if you check out the plugin via git, you can create a new branch with another name to make your own changes in and just change branches to test someone else's without losing your own changes.
Oh and also FYI - you can see the exact changes I made in the commit to that specific branch: jrfnl@d7c7662
Hi, we have encountered the same incompatibility with Visual Composer. I don't understand the inner-working of your plugin/code to know if this is a good approach, but we tried the following solution and it seemed to work in our initial tests. Basically, we limited the scope of the "each" where you add the show/hide events:
Original
$.each(['show', 'hide'], function (i, ev) {
New
$('.cmb2-row').each(['show', 'hide'], function (i, ev) {
What are your thoughts?
@jrfnl I just started but I had one question before I send the PR. Should the selector be more greedy than .cmb2-row? Should it apply to that and EVERYTHING below it? Again, I don't really know the inner-workings of your plugin. If you're comfortable with the solution, I will do the PR. Thanks!
Should the selector be more greedy than .cmb2-row? Should it apply to that and EVERYTHING below it?
Good point. The script in general looks at html elements within '#post', '#post .cmb2-wrap'.
Let me try and explain how it works:
It basically checks any form elm within those divs for a change and if a change has been detected, it will check if any other elms are conditional on that form elm and if so, show or hide it and potential child-dependents, depending on the set conditions.
The show/hide detection then kicks in and makes sure that any fields which are required when shown will not prevent the form from being submitted if they are hidden.
In that sense, it is not limited to the form elms being added by CMB2 - it also looks at changes in the standard WP post form elms.
Example: you could have a CMB2 field which depends on a certain category being selected in the normal post category metabox.
Using that line of thinking, the post category metabox might be shown/hidden using the screen options at the top of the screen and we would need to detect that to make sure dependent fields have the correct required attribute set.
So the short answer would be: yes, you might need to make the selector more greedy.
Unfortunately, I haven't got access to VC, so I can't help with testing.
Again, I don't really know the inner-workings of your plugin. If you're comfortable with the solution, I will do the PR.
Not my plugin ;-), though I admit I am responsible for the recent js rewrite, so I hope the above explanation helps.
So, I have another idea. Is it possible to keep the selector as you currently have it but make the custom event names that are created less generic? For example:
$.each( [ 'cmb2c-show', 'cmb2c-hide' ], function( i, ev ) {
This would require that lines 49 and 52 would need to change perhaps like this:
$conditionParent.on('cmb2c-hide', function(evt){
and
$conditionParent.on('cmb2c-show', function(evt){
My hunch is that maybe the 'show' and 'hide' events are conflicting with VC and perhaps other plugins? (Also, there may be something I don't know about those specific names - show and hide - which make my solution not feasible.) That all being said, VC and conditionals both seem to work with this solution. Thoughts?
Hi @cooms13 grin I was thinking along the same lines earlier - #22 (comment) 😎
Unfortunately, I now don't think that will work as we need to pick up on the jQuery 'show'/'hide' events and they are called show, hide, not cmb2c-show / cmb2c-hide, which is why I discarded the idea rather quickly.
The easiest way to test if it works for CMB2-Conditionals is make a conditional field required and leave it empty, make sure the condition is not met (but do toggle the field to make sure we trigger the display and hide events), then try to submit the form.
It should submit ok, but if the 'show/hide' events are not picked up on correctly, it will not allow to submit as a required field has not been filled in.
All the same, while I may know my js, I'm by no means a guru, so there may well be a way to make that work which I haven't thought of yet.
Hi, just so I'm clear, as a rule, if a required field is "hidden", should the form submit?
So, I just tested it. I added a required text field and made it dependent on a checkbox field. I submitted the form. It triggered the required field and would not submit. Then, I unchecked the checkbox which hid the required text field and submitted the form. It submitted successfully.
All this was done with the code change I wrote 4 hours ago. Do you have any other scenarios that I can test to see if this works? (Funny....now I'm looking back at your first set of comments and I see that you're original solution is almost the same as mine. haha)
just so I'm clear, as a rule, if a required field is "hidden", should the form submit?
Yes it should - "required" should only be enforced for visible fields.
So, I just tested it. ... It submitted successfully.
Great! Would be nice if some more people could test it as well, but if you're confident about that the solution will work despite my earlier misgivings, I'd say: go for the PR ;-)
@cooms13 I also encourage you to go for the PR and to read CONTRIBUTING.md for this purpose.
Had the compatible issues with Visual Composer as well. Fixed it with @cooms13 solution:
Original
$.each(['show', 'hide'], function (i, ev) {
Replace with
$('.cmb2-row').each(['show', 'hide'], function (i, ev) {
On line 8.
Thnx guys!
Had the compatible issues with Visual Composer as well. Fixed it with @cooms13 solution:
Original
$.each(['show', 'hide'], function (i, ev) {Replace with
$('.cmb2-row').each(['show', 'hide'], function (i, ev) {On line 8.
Thnx guys!
I had the same problem when using wpcasa theme with this script and Visual Bakery plugin. This fix helped. Thank you, guys.
@jcchavezs I could do it, but I am not the author and I am not familiar with CMB enough to be sure it doesn't break something. I just wanted to confirm that it helped with my problem.