Support » Plugin: Events Shortcodes & Templates Addon For The Events Calendar » Plugin Conflict: Gravity Forms editor breaks when plugin is enabled

  • Resolved KZeni

    (@kzeni)


    – The Problem –
    There’s JavaScript code that’s loaded on Gravity Form editing pages that totally breaks JS execution on that page (making the form unable to be edited.)

    
    [Error] TypeError: undefined is not a function (near '...$('.tf-font .tf-font-sel-color, .tf-font .tf-font-sel-shadow-color').wpColorPicker...')
    	(anonymous function) (admin.php:560:87)
    	i (jquery.js:2:27368)
    	fireWith (jquery.js:2:28123)
    	ready (jquery.js:2:29926)
    	J (jquery.js:2:30282)
    

    Also, it seems this over-bearing JS inclusion is breaking other parts of the site admin (ex. any other Gravity Forms-related page in the site admin, it seems [even Forms => Settings, Forms => Forms, etc.])

    It appears this same code is being called on other site admin pages where things still work per wpColorPicker having been made available.

    – Possible Solution #1 –
    So it might be important to make sure wpColorPicker is always called & available before using that JS code.

    – Possible Solution #2 (recommended) –
    However, why is this JS being called on these pages at all? Why is there wpColorPicker code specific to this plugin being called on Gravity Forms site admin pages, the Settings => General page, and pretty much any/all site admin pages when this plugin has nothing to do with those pages?

    Seems like adjusting when this JS code is called should fix this plugin conflict (a rather important one given Gravity Forms’ popularity & commonly necessary implementation on a given site) among other plugins where this might also be an issue as well as improving things overall (shouldn’t be calling JS code on site admin pages your plugin has nothing to do with, in general.)

    • This topic was modified 1 month ago by KZeni. Reason: Added more info
Viewing 2 replies - 1 through 2 (of 2 total)
  • KZeni

    (@kzeni)

    Again possible solution #2 above is an optimization (don’t call code for something like font picker controls when those controls aren’t ever going to be shown [show specifically on the one page it’s being used rather than on the entire site admin like it appears to be doing now]) as well as fixing a fatal (core functionality breaking) JS conflict with one of the most popular form plugins WordPress has (and possibly others).

    Plugin Support Jyoti Bhandari

    (@jyoti197)

    Hi @kzeni,

    Thank you for your feedback. We have fixed this by initializing settings fields on a specific page(s) only.
    The current workflow of the titan framework is actually creating such conflicts.
    We are already looking forward to migrating everything to a better & more secure framework.
    Please update our plugin as we have already released an update.

    Thanks & Regards

Viewing 2 replies - 1 through 2 (of 2 total)
  • You must be logged in to reply to this topic.