Flowplayer Breaks JS on Modules admin page (affects Module Filter and collapsible field sets)

I can confirm that enabling Flowplayer API 7.x-1.0-alpha1 breaks any version of the Module Filter module.

There are also reports about breaking Audio Field.
Not clear if these issues are only with alpha1, or if it also happens with the current -dev version?
(I will test that soon now, have not used this module on D7 yet, so I dont know.)

However, this module should not need to take effect on the admin pages?

Same here. Caused Module Filter to no longer function at all. Disabling Flowplayer API module restored the Module Filter module.

My friend Audrey has solved this problem.

Open flowplayer.js.

Insert:

        if (config == undefined) return; 

right after this line:

      // onload
      jQuery.each(settings.flowplayer, function(selector, config) {

This should solve this problem.

Art

I was also having the same problem with module filter. This fix worked for me.

The instructions in #4 also worked for me.

Are there any plans to commit this?

?

Patch in #7 looks good to me. (Also, Rob, I'm going to be doing a fair amount of work with Flowplayer on a site I'm working on / happy to become a co-maintainer if need be)

i can confirm that flowplayer seems to break all javascript on admin/modules

[Error] TypeError: 'null' is not an object (evaluating 'config[event]')
	(anonymous function) (flowplayer.js, line 78)
	each (jquery.js, line 34)
	(anonymous function) (flowplayer.js, line 77)
	each (jquery.js, line 34)
	attach (flowplayer.js, line 52)
	(anonymous function) (drupal.js, line 76)
	each (jquery.js, line 34)
	attachBehaviors (drupal.js, line 74)
	(anonymous function) (drupal.js, line 412)
	ready (jquery.js, line 30)
	u (jquery.js, line 38)

a module should not break core functionality or other modules .. this is a pretty major bug ..

as brought up in #2, the real question for me is why is flowplayer.js getting loaded on admin/modules in the first place

ok, xhprof callgraph tells me that theme_flowplayer is called on "admin/modules" page and that it is called from within flowplayer_help

in there i see a switch statement " case 'admin/help#flowplayer':" which does call theme_flowplayer a few times()

if i had to take a guess, the admin/modules page calls the help hook to see if there is any output, so that it knows whether to paint the help button for the module.
That will cause the javascript to be loaded and fail, because obviously we are not actually rendering the help. If true, then this is a really crappy way of doing it, and i would call it a core bug even.

to fix this we could return true early from the switch statement

    case 'admin/help#flowplayer':

      // workaround for a core design flaw,
      // which actually executes all the help hooks on the module admin page just to see if they exist o.O !!!
      // see https://drupal.org/node/1743410
      if ($_GET['q'] == 'admin/modules') {
        return true;
      }
    ...

i would say the patch in #7 and my fix in #13 should both go in to fix this

i would make a patch but don't know how to do it properly for drupal
*ducks*

well here's a patch anyway, not sure if it is named properly or whatnot..

#15 patch from treksler isn't necessary stick with #4 solution and #7 patch from artt and RobLoach until a better solution is found...

*bump*
anything happening here? Would be great to see this fixed.

#4 Works for me