WordPress.org

Ready to get started?Download WordPress

Forums

[resolved] Ajax Event Calendar conflict with Easy FancyBox (17 posts)

  1. danbo
    Member
    Posted 2 years ago #

    I have gone through the forums and tried a few suggestions but I can't seem to get around this...

    Ajax Event Calendar won't work with Easy FancyBox on my site, Calendar view is limited and not showing dates, and link to events are not functioning at all? The Calendar widget shows up but the links don't function either?

    Link to the page here

  2. danbo
    Member
    Posted 2 years ago #

    I am currently running Version 0.9.9.2

  3. danbo
    Member
    Posted 2 years ago #

    time zone is a city value as well

  4. Eran Miller
    Member
    Posted 2 years ago #

    Thanks for the feedback, I'll let you know what I find.

  5. Eran Miller
    Member
    Posted 2 years ago #

    Unfortunately after much searching, I am unable to find the cause of the problem. All I have been able to determine is that the script needed to run the calendar init_show_calendar.js is not getting loaded (and quite a few PHP Notice: Undefined index:... messages in the PHP log) when easy-fancybox is activated. While I doubt the notices are causing the error, they make finding the cause of the problem that much more challenging.

    Perhaps the plugin easy-fancybox plugin author can offer some insight as to what may be causing the conflict.

  6. danbo
    Member
    Posted 2 years ago #

    Thanks Eran, that was my next move. I hope it will work out, I really like your calendar, in my opinion it is by far the best available for wordpress at the moment.

    Thanks for your help, and all the best!

  7. RavanH
    Member
    Posted 2 years ago #

    danbo, thanks for reporting the issue. Hope we can get this sorted :)

    Eran, could you please explain what you did when testing both plugins together? Was it on a clean install without any other plugins? I'm not familiar with your plugin but am willing to take a look. Should simply running both plugins together reproduce the issue or do I need to configure your or my plugin in some particular way?

  8. RavanH
    Member
    Posted 2 years ago #

    Hmmm... I found it. First, I'll try to explain the chain of events causing jquery.init_show_calendar.js not being loaded when both plugins are activated.

    === start ===

    The script init_show_calendar.js is included with a dependency on mousewheel.js:

    wp_register_script('init_show_calendar', AEC_PLUGIN_URL . 'js/jquery.init_show_calendar.js', array('jquery', 'mousewheel', 'simplemodal', 'fullcalendar'), AEC_PLUGIN_VERSION, true);

    which in turn is registered under the handle/name 'mousewheel':

    wp_register_script('mousewheel', AEC_PLUGIN_URL . 'js/jquery.mousewheel.min.js', array('jquery'), '3.0.4', true);

    This, in itself stand alone or running in combination with other plugins that register the same script under the same name 'mousewheel', is not a problem.

    But now my plugin: It also includes mousewheel.js but this time registered as 'jquery.mousewheel' and because I have taken precautions to prevent double loading of the same script file (being registered under different names) twice or more, I have added a routine to deregister the same script registered under different names like:

    wp_deregister_script('jquerymousewheel');
    wp_deregister_script('jquery-mousewheel');
    wp_deregister_script('mousewheel');

    And normally, this would not cause a problem because in the end, the same script (this time coming from my plugin package) gets included just the same but because it is registered as a dependency for jquery.init_show_calendar.js under a different name ('mousewheel' instead of 'jquery.mousewheel') WordPress cannot tell that the dependency is met and drops the registration.

    === end ===

    Hope I explained clear enough. If not, please let me know :)

    Now for possible solutions...

    Eran, is the jquery.init_show_calendar.js script really dependant on the jquery.mouswheel.js script? I mean, will it absolutely NOT run without it? If it theoretically can do without it (even though in practice it will never have to do without it because the mousewheel script will be included by either your plugin or mine) it might be better to remove it as dependency and only use dependencies if they are REALLY dependant, meaning one script cannot run without the other. As would clearly be the case for the main 'jquery' script library :)

    If jquery.init_show_calendar.js really cannot run without jquery.mouswheel.js, we need to synchronize our naming convention. In fact, all plugin devs out there should be doing the same. I did not include the deregister functions for nothing as it turns out many plugin authors register the same scripts under different handle names resulting in them being loaded twice or more, which can (but does not have to) cause problems...

    For example, I have found jquery.mouswheel.js being registered as mousewheel, jquerymousewheel, jquery-mousewheel and jquery.mousewheel. I simply chose the one that has the base filename (without extension, version number nor min/packed designation) as it seems the most logical to me.

    However, this is up for debate. It seems any such logic is not even used by WordPress itself. For example, some the prepackaged scripts in WordPress are registered and available under different names. Just picking three examples from the list on http://codex.wordpress.org/Function_Reference/wp_enqueue_script#Default_scripts_included_with_WordPress

    Official script file name -- Script file in WP -- Handle name
    jquery-1.6.2.js -- jquery.js -- jquery
    jquery-ui-1.8.min.js -- ui.core.js -- jquery-ui-core
    jquery.form.js -- jquery.form.js -- jquery-form
    jquery.schedule.js -- jquery.schedule.js -- schedule
    tiny_mce.js -- tiny_mce.js -- tiny_mce

    I'm not aware of any ongoing public debate on handle naming conventions but it might be time for one :)

  9. RavanH
    Member
    Posted 2 years ago #

    @danbo, to get both plugins running together fast, you need to edit one of the two.

    EITHER:

    A. Open ajax-event-calendar.php in the WP plugin editor and find the line with

    wp_register_script('init_show_calendar', AEC_PLUGIN_URL . 'js/jquery.init_show_calendar.js', array('jquery', 'mousewheel', 'simplemodal', 'fullcalendar'), AEC_PLUGIN_VERSION, true);

    (it's not far from the top, near the end of the list under function __construct()) and remove the 'mousewheel', from there. Save.

    OR:

    B. Open easy-fancybox.php in the WP plugin editor and place // right in front of these lines (you can find them near the end of the file, as part of function easy_fancybox_enqueue_scripts()) to disable them:

    wp_deregister_script('mousewheel');
    // then register our version
    wp_enqueue_script('jquery.mousewheel', plugins_url(FANCYBOX_SUBDIR.'/fancybox/jquery.mousewheel-'.MOUSEWHEEL_VERSION.'.pack.js', __FILE__), array('jquery'), MOUSEWHEEL_VERSION, true);

    so they will look like this:

    //wp_deregister_script('mousewheel');
    // then register our version
    //wp_enqueue_script('jquery.mousewheel', plugins_url(FANCYBOX_SUBDIR.'/fancybox/jquery.mousewheel-'.MOUSEWHEEL_VERSION.'.pack.js', __FILE__), array('jquery'), MOUSEWHEEL_VERSION, true);

    Choose one of the above but do not do both, or you will loose mouse wheel functionality on both lightbox and calendar ;)

  10. Eran Miller
    Member
    Posted 2 years ago #

    RavanH,
    Thank you for that wonderfully detailed reply, very informative!
    I am a novice at WordPress plugin development, the calendar is my first plugin and it's been out less than three months.

    I had not considered that other plugins might be deregistering enqueued scripts. Indeed I hadn't yet considered the implications of cross-plugin duplicate script instances.

    As an long-time advocate of web standards and I am very happy to apply a naming convention to this practice. In my next release I will prepend "jquery." to all jquery plugins. Specifically in this case, jquery.mousewheel.

    Thanks again for your time and effort in resolving this matter.
    Eran

  11. RavanH
    Member
    Posted 2 years ago #

    Hi Eran,

    I'm not telling you that my choice of the handle name with 'jquery' plus '.' in front of it abides by any naming convention. Looking at the naming of WP core scripts, it might even be argued that using a hyphen instead of a dot would be considered appropriate even though it is not used very consistently... So I'll be happy to change my naming scheme if that needs to be done.

    I suppose all it takes is someone with higher authority to decide (for all of us mere plugin dev mortals) which naming convention would take prevalence and what exception to take into account. Just to make our lives a little easier ;)

    Anyone?

    (I think I'll start a new thread on the subject)

  12. Eran Miller
    Member
    Posted 2 years ago #

    Raven,

    I realize you weren't asserting that your choice of naming convention was standard, but I'm willing to adapt. In the interest of being responsive to the problem, I feel it is a valid solution until "a higher authority" establishes a convention. I will be releasing the next version of my plugin in a few weeks and I wanted to put a solution in place (even if temporary) before that time.

    Please advise me of any updates to this topic.

  13. Eran Miller
    Member
    Posted 2 years ago #

    @danbo: please mark this issue as resolved. Thanks!

  14. RavanH
    Member
    Posted 2 years ago #

    Eran, just removing the 'mousewheel', from the array in

    wp_register_script('init_show_calendar', AEC_PLUGIN_URL . 'js/jquery.init_show_calendar.js', array('jquery', 'mousewheel', 'simplemodal', 'fullcalendar'), AEC_PLUGIN_VERSION, true);

    should do the trick... The mousewheel script will still be loaded because you do wp_enqueue_script('mousewheel'); down the line. So basically no need for renaming anything :)

    It's just that we would not have run into this issue when there was a proper naming convention...

  15. Eran Miller
    Member
    Posted 2 years ago #

    RavanH,
    Fair enough. I know you mentioned this approach in your prior post, but it took this repeat mention for it to sink in. :)

  16. danbo
    Member
    Posted 2 years ago #

    Hello Ravan & Eran,

    Just got back in front of my screen after a day off, wow, you guys have been busy!

    Thank you both for your time and help, and for coming up with a great remedy to my problem. I guess this kind of thing happens all too often, this has not been the first time I have had this issue with other plugins conflicting.

    Good luck with getting the convention thing sorted.

    Thanks again and all the best to you both.

    Cheers

  17. danbo
    Member
    Posted 2 years ago #

    ...works like a charm :-)

    awesome, thanks!

Topic Closed

This topic has been closed to new replies.