Bug 1438 - Pluging appear in Browse Menu list, even when disabled
: Pluging appear in Browse Menu list, even when disabled
Status: RESOLVED FIXED
Product: Logitech Media Server
Classification: Unclassified
Component: Web Interface
: 6.1.0
: PC All
: P2 normal (vote)
: ---
Assigned To: Michael Herger
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-04-26 01:25 UTC by Patrick Dixon
Modified: 2008-09-15 14:37 UTC (History)
3 users (show)

See Also:
Category: ---


Attachments
remove radio from web menu (3.08 KB, patch)
2005-04-26 09:09 UTC, Michael Herger
Details | Diff
delGroup/addGroup for radio when disabled/enabled. (906 bytes, patch)
2005-04-26 14:33 UTC, KDF
Details | Diff
remove/add plugins from home.html and settings/internet radio (5.17 KB, patch)
2005-04-26 15:18 UTC, Michael Herger
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Patrick Dixon 2005-04-26 01:25:16 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.
Comment 1 KDF 2005-04-26 02:18:21 UTC
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)
Comment 2 Patrick Dixon 2005-04-26 02:39:54 UTC
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.
Comment 3 KDF 2005-04-26 03:17:08 UTC
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.
Comment 4 KDF 2005-04-26 03:24:14 UTC
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). 
Comment 5 KDF 2005-04-26 03:40:02 UTC
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...
Comment 6 Michael Herger 2005-04-26 09:09:36 UTC
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 ;-).
Comment 7 Michael Herger 2005-04-26 09:15:44 UTC
In Fishbone you'll have to reload the complete page to have radiostations removed. The list won't be 
updated automatically.
Comment 8 KDF 2005-04-26 09:23:30 UTC
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?  
Comment 9 Michael Herger 2005-04-26 09:32:37 UTC
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. 
Comment 10 KDF 2005-04-26 09:42:51 UTC
ah yes, I know what you mean.  d_http may help since that does have some output
regarding the page handlers.
Comment 11 Michael Herger 2005-04-26 14:19:43 UTC
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.
Comment 12 KDF 2005-04-26 14:32:11 UTC
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?
Comment 13 KDF 2005-04-26 14:33:17 UTC
Created attachment 462 [details]
delGroup/addGroup for radio when disabled/enabled.
Comment 14 Vidur Apparao 2005-04-26 14:35:31 UTC
No, this doesn't seem like a must-have for 6.0.2. Trunk only for now, thanks.
Comment 15 Michael Herger 2005-04-26 14:43:40 UTC
Give me a second... I'm almost done with a _proposition_ for a fix.
Comment 16 Michael Herger 2005-04-26 15:18:05 UTC
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).
Comment 17 Robert Moser II 2005-04-26 16:39:08 UTC
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.
Comment 18 Robert Moser II 2005-04-26 16:43:28 UTC
Whoops, that won't work, as we need to specify the skin as well.  Never mind.
Comment 19 KDF 2005-04-28 23:36:52 UTC
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.
Comment 20 Michael Herger 2005-04-29 00:02:07 UTC
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...
Comment 21 Michael Herger 2005-04-29 01:37:36 UTC
Change 3102 should remove _all_ plugins, not only those with the optional addMenu()
Comment 22 Chris Owens 2006-06-16 14:41:12 UTC
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.