XF 2.0 At what point are extensions active

[Snog]

I'm 99.9% sure I know the answer to this, but I figured I'd ask just in case some magic was done in XF 2 that I don't see.

Is there any point after an add-on has been re-enabled, after being disabled, that the add-on's extensions are active prior to being send back to the add-on list screen?

The reason I'm asking is when a certain add-on of mine is disabled, it does some mandatory actions before disabling. That's easy enough to catch in the entity presave.

It's when it's re-enabled that I'd like to automatically undo the actions taken when it was disabled.

Now I don't think it's possible, I never found a way to do it in XF 1, and I make it a manual action that has to be done by the user. So, I won't be disappointed if I have to do the same thing in XF 2.

 

[Mike]

Essentially you won't have any access here because your add-on code won't run until the next request.

What needs to happen with disabling that doesn't automatically happen?

 

[Snog]

Essentially you won't have any access here because your add-on code won't run until the next request.

What needs to happen with disabling that doesn't automatically happen?

Because of the possibility of sensitive information being in threads the add-on controls, threads need to be put into moderation so they can't be viewed by anyone that shouldn't see them. I can do that in the presave.

The reverse it true when the add-on is enabled. They can be taken out of moderation because access is now controlled by the add-on.

 

[Snog]

I have thought about enabling a cron task in the presave when the add-on is disabled. That way the task would run when it's re-enabled and disable itself when complete.

I'm still undecided if I'll do that, or keep it as a manual action the admin needs to do after re-enabling the add-on.

 

[Chris D]

Is it not something you can trigger a manual job for?

You should be in another request by the time it runs, and it's a manual job so it will happen before the admin is allowed to move on to something else.

 

[Snog]

Is it not something you can trigger a manual job for?

You should be in another request by the time it runs, and it's a manual job so it will happen before the admin is allowed to move on to something else.

To be perfectly honest, I haven't even looked at the job system yet. So, I have no idea how to trigger a job at this point in time.

I may take a peek at it tomorrow.

And when I said a manual action, that's pretty much what happens. The admin checks a box, clicks a button and the action is completed before he can do anything else.

 

[Chris D]

A manual job in this context is a little bit like one of the rebuild jobs under Rebuild caches in that it redirects the user to the job runner and they pretty much can’t leave until the job completes.

It seems like it would be a good way of making this automatic without the user having to click things (or forget to, as I imagine the case may be sometimes!)

 

[Snog]

I've taken a look at the job system, and I think I'm in the same boat. There's no way to trigger the job to remove the moderated status until after the add-on is re-enabled. And there's no way to tell if the add-on has recently been re-enabled.

I suppose I could use a listener for the admin add-on page, have a flag set somewhere if the add-on was disabled at some point and if it was, trigger the job.

I'm going to have to look really close at the whole idea.

 

[Snog]

Just an update to this...

I looked at various ways of triggering the job and the best solution I found was to trigger it on the add-on screen reload after re-enabling the add-on. Doing it anywhere else didn't seem to activate the job after re-enabling the add-on.

All in all it is a good solution to not have the end user manually do anything to take the threads out of moderation and works very well.