Hi Dave. I'm no pro by any means, but what I do know is that, from a css standpoint, chat, messages, and notifications are tightly integrated. Parts of the elements pull from an ow css, and not the base css while there are still parts in the base css. There are also ties to system files. Most other plugins are straight forward as to their ties, but the are like a spider web. I'm sure this doesn't help, but if you find the common integrations between them, maybe that could lead to a solution.

Thanks Darryl :),  

yeah i switched them around thinking that it was a similar case as the forum and groups deal where one has to be deactivated before the other due to dependencies however that did not help at all. 

Part of troubleshooting as you know is changing the question you ask along the way and defining it more and more until the point when you get the answer down the road that solves the original question. 

So far i have defined it down to three quesitons. 

Does the PluginManager getPlugin function fire with every deactivation?

If not then:

Why does it fire with these two plugins and not the others. 

If so then: 

Why does it not toss the exception with other plugins but does with these two.

Digging thru it again, maybe i missed something.   See it would make sense if the deactivate function had a "try catch" trap on it like the update function does.  Then i would know that Oxwall just traps the erorr on all deactivations when the plugin manager executes the getPlugin, and i would know that it executes that function on a normal bases. 

However there is no "try catch" on the deactivation function from admin, so that tells me that they do not expect an exception to happen and im not sure why.   

Also, someone might say well just "try catch" the error from your plugin.  Well i will admit here that i have never had to do that from outside my class file.  I have never had to trap an error thrown by another class file and honestly i dont know how to do it.  A normal try catch does not work. 

It is certainly the most difficult aspects of the platform to work with. I would hope that Ross, or one of the other team members will jump in on this one for you. I will take a deep understanding of the platform, and how these plugins are coded into it.  I, for one, am glad to see devs becoming active again.

Well i spoke with a team member developer last night, said he could help as his profile said he could help with plugin development.  When his first attempt to find the cause did not work his reply was something like "oh sorry i have much work to do - buy my plugins".  Which i understand they are busy but honestly that kind of shocked me.  I also have tried to speak with several other devs and team members with no replies.  So ill just have to work it out i guess. 

I have answered one question though, that getPlugin function is fired on every deactivation whether it be just refreshing the page during the end of the process or during the process it self it is fired as i did a test to check for execution.   

So now for the other question, why is it triggering an exception with these two plugins and not the other 17 that i deactivate?   First ill check the status of the plugin when this executes. Then i will compare that to the others. 

I can remember that when I activated plugins at different times after a platform update that there was one, or maybe two that had dependancies on another plugin, and a message would pop up stating that. I don't know if one of these was one of those, but that could possibly be the exception. If one gets deactivated, it may be throwing that exception. Just a thought.

True, i considered that and so last night i deactivated everything but mailbox, and then everything but notifications, and then everything but mailbox and notifications.  So there was nothing active but those two items or one of those items and i still got the exception.  So that might be that for some reason the getPlugin status is different which tosses the exception. 

However surprise surprise, all the objects are the same when it comes to that function.  I executed it 3 times, once with notifications, once with messages, and once with contactus. And saved the objects for comparison, they are all exactly the same, i mean exactly the same, there is no variation not even for plugin name or key, every element in the object  is exactly the same on all three.    

So i ask myself how does it know one from the other then.   I dont know?  Not yet anyway ;) 

I have the plugin. Not sure if the deactivation process is sequential "one by one", or mass deactivation "all plugins hitting a deactivation code at once", or not. Not even sure if that would matter, but when I deactivate manually, I do third party, then core plugins allowing the screen to update between deactivations. I can remember having some issues when I tried doing it to fast. Probably more to do with the server updating than the code.

As a matter of fact that function getPlugin is executed 19 times for every deactivation, me thinks there might be some over doing server requests there a bit. lol   19 times wow....  

As per your question, yes what i do is i sort out the plugins between primary and secondary, primary are the ones that are readily available with oxwall and ready to go, those are also the ones that other plugins tend to rely on.  Secondary plugins are those that after you install oxwall you typically have to install from the available plugins menu.  

So what i do is i hold primary and secondary aside and deactivate everything else first (this includes third party), that gets most of the dependencies out of the way.  Then i do secondary, then i do primary.  So by the time i get down to primary most all of the dependencies should be gone, all i do is just make sure that group is deactivated before forums and done. 

PS yes it is one by one, nothing mass, its in a foreach so its one by one.  

Also this version i think they added a bunch of new special instructions to each of the plugins which i have added to my process.  So the sooner i can get this out the better. 

I stand corrected 66 times that process is called, i didnt catch some of them that were off the screen. 

Through my testing i have come to the conclusion that somehow there "might" be a (i wont call it a bug yet) process improvement that can be done in the way of the plugin_manager function getPlugin.  

I don't see why it has to execute so many times per deactivation and along with that there is a reason why it is called after a plugin has been deactivated which concerns me.   When i commented out the exception trigger everything works fine. So it really has nothing to do with the deactivation process at all. 

I believe i has to do with some other process which repeatedly calls that function over and over way too many times.  This causes for some reason the notifications and mailbox which are so interconnected with everything to trigger the exception if deactivated via executing the process remotely from a plugin.

Now i may be forced to release my plugin without the ability to deactivate the notifications and mailbox, which is really no big deal for the user.  

However looking at it from a developers point of view there should be no reason that major processes such as this cannot be called on remotely just as every other method or process is called on from plugins.  The software has no clue that the request is coming from a plugin and as long as you tap into the same process as the onboard scripts use, and provide the same data for processing, then there should be no difference in the results, and this is what bugs me.  

I will consider releasing it without the two processes tomorrow. 

Dave

PS.. as a follow up it appears that friends is among this group as well.  But i have run test after test on all the rest and everything works perfect.  So the release will be without friends, notifications, and mailbox.