Bugzilla – Bug 1438
Pluging appear in Browse Menu list, even when disabled
Last modified: 2008-09-15 14:37:04 UTC
Plugins pages are now listed in the Browse Menu, however even when disabled they are still on the Browse Menu and clicking them takes you to the selected (disabled) Plugin page.
This was reported as bug 1167 and should be fixed in the latest nightlies. please provide more details, ie...nightly build date, which plugins, d_plugins log when disabling the plugins, screenshots (if available)
bug 1167 may be related but reports menus on player rather than web interface (which is probably why I didn't find it when I searched - sorry). Details are: FC3 / 6.1.0-branch yesterday's subversion (UK time) Plugins diaabled but appearing are: Slim picks, radio.com, shoutcast. AlienBBC appears and IS enabled. Sorry no debug - but let me know if you want me to run something in particular.
ah, radio plugins. I think we're going to have to go back to requiring a restart after changing enable/disable of plugins. it is getting to the point where everything has to be re-initialised, and even since this was done, those radio plugins have broken it. Keeping it cleaned up on the fly just becomes less and less manageable.
other option is to go after the plugin maintainer to play along with the enable/disable state. Oddly enough, the man responsible for 3 of those, was the one who originally filed 1193. AlienBBC is an entirely third party project, and fixing that would have to be left to the AlienBBC team. On changes to plugins, the webPages() subroutine from every plugin is re-executed, giving a plugin that plays along, the chance to erase its web links. The server cannot do this directly since the weblinks can be far too arbitrary. Restarting the server does prevent the plugins from being loaded again, so it is fixed after a restart (much along the lines of what I already noted as part of 1193).
michael, since you're the king of radio plugins now, best make them play along with the enable/disable states. This will have to entail something similar to what RssNews added recently: my $disabled = scalar(grep {$_ eq 'RssNews'} Slim::Utils::Prefs::getArray('disabledplugins')); $disabled && $::d_plugins && msg("RssNews: RssNews plugin disabled.\n"); if ($disabled) { ...remove links... } might not be major enough to block 6.0.2...
Created attachment 459 [details] remove radio from web menu This patch does remove the radio links from the web page's menu. But this is still only part of the problem: the settings/internet radio page isn't updated, _add_ plugins' web pages won't work... Kevin, you may call me "king of radio plugins". But I think it's rather up to you to apply the emergency break on dynamic plugin loading. My kingdom is rather small compared to yours ;-).
In Fishbone you'll have to reload the complete page to have radiostations removed. The list won't be updated automatically.
that patch looks cool. a full page reload is something people will just have to live with. I'll check on the radio page stuff. I'm not sure what you mean by the _add_ plugins' web pages not working?
When I enable a plugin it will correctly show up in the menu. Clicking the link will correctly start the page creation (in the case of Shoutcast it starts downloading the list etc.). But it will finally display an empty page. I think it's TT which does not find the template ("file error - plugins/RadioIO/index.html: not found"). I had a quick look at Slim::Button::Plugins::addWebpages() but did not (yet) find the culprit.
ah yes, I know what you mean. d_http may help since that does have some output regarding the page handlers.
I think I tracked it down to TT's INCLUDE_PATH property: it's initialized the first time it has to create a page for a skin. If I add a plugin later, it's path won't be added. But if I change the skin, it will work, as HTMLTemplateDirs() now contains the plugin's template folder. Problem: I don't know how to add a path to the TT object. Will google around for it.
something in the postChange for the skin pref might give a hint :) will have a patch shortly for the internet radio settings. Will you be committing the plugin changes or shoudl I do them with the radio settings fix? vidur, you want this fixed for 6.0.2 as well?
Created attachment 462 [details] delGroup/addGroup for radio when disabled/enabled.
No, this doesn't seem like a must-have for 6.0.2. Trunk only for now, thanks.
Give me a second... I'm almost done with a _proposition_ for a fix.
Created attachment 463 [details] remove/add plugins from home.html and settings/internet radio This patch contains kdf's addGroup patch. I added a initSkinTemplate() sub to force creation of a new TT object cache as I did not find any information on how to add/remove paths from TT's INCLUDE_PATH property (not even on its site).
From looking at a book on TT, you can have a subroutine reference in the INCLUDE_PATH. That subroutine would return a reference to a list of directories. So, we could have Slim::Buttons::Plugins.pm maintain a list of active html directories and not have to create template objects multiple times. As long as this subroutine reference was last in the INCLUDE_PATH list, it shouldn't impact performance until a plugin page was requested. We could also have a subroutine in Slim::Web::HTTP.pm which returns a reference to @templatedirs. Then push that subroutine on to the end of the INCLUDE_PATH to catch any additions after the template object creation.
Whoops, that won't work, as we need to specify the skin as well. Never mind.
patch was committed to 6.1 at change 3088, perhaps this should be retitled based on the remaining issues (if any) ? if there are no leaks, and nothing we can do about AlienBBC, then this can be marked as fixed.
I sent a patch for AlienBBC to Neil who will include it with the next release. But I'm a little confused... I just doublechecked on the player: while the web interface seems to be ok, the player's interface is not?!? Some of the plugins do disappear, some don't... I guess this will be my today's program...
Change 3102 should remove _all_ plugins, not only those with the optional addMenu()
There are 536 bugs in the database with targets of '---' that were fixed prior to new year 2006. I am setting them to targets of 6.2.1 to keep them from showing up in my queries.