Bugzilla – Bug 979
disabledPlugin keeps adding pref
Last modified: 2008-08-18 10:53:01 UTC
disabledplugins# = 12 disabledplugins0 = Archive disabledplugins1 = Archive disabledplugins2 = Archive disabledplugins3 = Archive disabledplugins4 = Archive disabledplugins5 = Archive disabledplugins6 = Archive disabledplugins7 = Archive disabledplugins8 = Archive disabledplugins9 = Archive disabledplugins10 = Archive disabledplugins11 = Archive disabledplugins12 = Archive
Do you have any idea how/when this happened? I can't seem to trigger this right now. postChange for plugins should be deleting the entire disabledPlugins list. Web::Setup line 1271: Slim::Utils::Prefs::delete('disabledplugins'); if you change disable a plugin with svn 2379, they should all disappear. possibly try this again with the Prefs Write Interval set to 0
this may have something to do with a change done a few days ago, and one before. In Setup.pm r2357, we are reloading the string and the package name into the pluginlistref. This list is then sorted as we return the results. This sort now no longer matches the pre and post checks. This causes a misalignment of the plugins and we can have odd symptoms like plugins showing as disabled when they are not, and plugins being set as disabled when they are not. the results vary depending on how many plugins are misaligned. if one 8 plugins were set to be disabled, the other sorts might use the same name 8 times to fill the array. making this sort consistent may help this problem.
Created attachment 324 [details] make sorts consistent. This clears up the enabled/disabled problems I was seeing, and I am hoping this will fix the problem you are seeing as well. I havent yet been able to reproduce. If you still have the problem, can you send me a copy of the plugin that is getting disabled multiple times
Nope - that patch doesn't work.
can you attach a screenshot of the plugins page? heck, at this point I'll take a zip of your entire plugins dir :) have you tried this with a fresh conf file?
how many (which ones) are non6.0?
Just the one. Trying with clean pref file.
Created attachment 329 [details] plugin dir
Created attachment 330 [details] non6.0 compatible should just NOT be listed rather than pushing in strings or keeping track of non6.0 compatible plugins, we should just ensure they are never part of the list. This way, users can't re-enable and they shouldn't end up in the disabled list either. give this a shot and lets see if this will clear up this way. Any plugin that doens't have a existing stringname will be removed in the listings.
That fixed it.
great! . I think it cleans up a long standing problem we kept grabbing every plugin in the plugins folder every time, thus we get users wondering why its listed but wont work. This way, if they fail for any reason, the string should never get added properly and the plugin wont be listed. committed to r2454