Here is a little trick to beat plugin’s depth

There is a common problem which happens to my plugins over time. As I keep adding more and more code, at some points all those relationships between the plugins are becoming really confusing – there might be an update in one plugin which will kick off another plugin, and that plugins, in term, might lead to the code in the first plugin being executed again.

This goes into an infinite loop, which, of course, get intercepted by the engine, and, eventually, the whole operation that started this cycle gets terminated.

When this happens, the most practical approach is, sometimes, to just cut this Gordian not:

The recipe is quite simple. Imagine there is this code in the plugin:

And imagine the plugin is registered to run on update of the “contact” and on create of the account.

With the code above, whenever I try updating a contact, the plugin will run. It will start creating a new account. That will trigger the same plugin to run again. In that second run the plugin will try updating an existing contact. Which, in turn, will trigger the same plugin again.

And, so, this will go into an infinite loop:

Which I could try preventing by comparing “contact.Depth” to 1, for example, but what if, in my example, I only wanted this process to stop once the contact has been updated? No matter if the depth is 1 or more?

Especially since, in the example above, it’s all very simple. In reality, this kind of sequence may involve different plugins calling each other, and blindly verifying “depth” might not even be the right approach.

Well, unless you want to refactor the whole solution at that point, here is a trick.

You just need to add a dummy field to the table and use it to terminate the plugins chain above.

Set it whenever you want all subsequent plugins to ignore the action.

In those other plugins, just add a condition to verify if that attribute is set in the target, and, if it is, do nothing.

That way, you won’t have to rely on the “depth” property, since the value of that property may vary depending on what exactly has happened, how the plugins were executed, etc.

Instead, you’ll instruct your plugins not to do anything whenever no further processing is needed by passing that dummy field in the target. And, since you won’t be adding it to the forms, it’ll never come with the data that’s being submitted through the UI forms.

PS. There is a continuation to this post here