Support Forum

Providing access was easy.  Fixing it was the work, which you did.  Thanks.

On your comment on deactivated plugins...

and my only real point on deactivted plugins is that wp still has to read them into memory and scan for the header info. That takes time and memory.  and errors in the plugin could cause issues… absolutely agree on deactivating for purpose of testing conflicts…

My understanding is that when loading the plugin admin page, WP scans the list of plugins and builds a list of active plugins.  For the front end, only active plugins are loaded, so deactivated plugins are never read into memory in that situation.  For the back end, the same is true - except for the plugins page.  Presumably, when you're changing plugins, you don't mind the overhead of WP having to build the list of active plugins, so I see that as a non-issue.  I think plugins can also store autoload data.  If you had a plugin that stored a lot of autoload data AND did not delete it on deactivation (ie, a bad plugin), yes, it could be an issue.  But I think for the most part, on all except the plugin admin page, deactivated plugins are never scanned or read.  So I agree with you that it's a good idea to keep the plugin folder of live sites neat and tidy, but there really isn't much of a performance penalty from being a slob in this area.