Roundtable on interactions between 3rd party add-ons

[Yugensoft]

I wanted to open this discussion, as it's an issue that I've faced a little, and one that I've seen many customers bring up.

This is where two add-ons from different suppliers interact in a way that breaks one or more of them (especially one of them). It especially effects customers with large numbers of add-ons, as the chance of an interaction between one or more add-ons obviously increases.

With XenForo core, no such problem exists, as it's all made by one team who are responsible to the same enterprise.

I think the following are the open issues:

• Who should be responsible for fixing a 3rd party add-on clash? Supplier 1, 2, the customer; or some apportionment or procedure be used to rectify it.
• Are there principles that should be followed in 3rd party add-on development to avoid clashes?
• Would a central clearinghouse list of "please observe this when making your add-ons so you don't break mine" help alleviate the problem?
• Are there things suppliers should or shouldn't expect other suppliers to accommodate, in preventing clashes with their add-on?

Cheers

 

[DragonByte Tech]

The way I do it, if a customer reports an issue and I find it to be caused by another 3rd party mod, I tell the customer to report it to them.

Most of the time, that’s the end of it, but if the other coder rejects the bug report, I will endeavour to find evidence that the fault is theirs, and provide a proposed patch to their code.

If they still reject the patch, which has happened only once (because the developer, in their own words, couldn’t understand why it was needed even though it was only adding a variable to the global scope), then I bookmark the post I made explaining to the developer what they could do to resolve it. I can then refer back to this post whenever a customer reports the issue and encourage them to leave feedback for the other developer.

On the other hand, if the other developer responds saying the fault is mine, I will do everything in my power to work around the flaw in my code and reach out to the other developer for assistance if I get stuck. Thus far I’ve not had to reach out for assistance so I can’t speak for how many devs are willing to work with me, but I choose to believe everyone would


Fillip

 

[Xon]

XF1 has a gotcha on the interaction of load_class vs load_class_xxx for priorities, which thankfully XF2 does away with (for the class_extension system).

The biggest thing to avoid is don't replace methods and always allow the call chain to continue, even if it makes you code more complex. This generally allows things to work as expected.

I try to address compatibility issues, but it requires people to report them rather than flame out and blame you for (vaguely) breaking things and then stop using you add-ons.

 

[Aayush]

The way I do it, if a customer reports an issue and I find it to be caused by another 3rd party mod, I tell the customer to report it to them.

Most of the time, that’s the end of it, but if the other coder rejects the bug report, I will endeavour to find evidence that the fault is theirs, and provide a proposed patch to their code.

If they still reject the patch, which has happened only once (because the developer, in their own words, couldn’t understand why it was needed even though it was only adding a variable to the global scope), then I bookmark the post I made explaining to the developer what they could do to resolve it. I can then refer back to this post whenever a customer reports the issue and encourage them to leave feedback for the other developer.

On the other hand, if the other developer responds saying the fault is mine, I will do everything in my power to work around the flaw in my code and reach out to the other developer for assistance if I get stuck. Thus far I’ve not had to reach out for assistance so I can’t speak for how many devs are willing to work with me, but I choose to believe everyone would


Fillip

A customer reported a potential conflict between one of your addons and ForumApps this morning. I'm going to investigate the issue and let you know if there are changes required on your end or we would be able to handle that conflict ourselves. And as @Xon mentioned, from the server log it looked like an issue with load_class.

 

[DragonByte Tech]

A customer reported a potential conflict between one of your addons and ForumApps this morning. I'm going to investigate the issue and let you know if there are changes required on your end or we would be able to handle that conflict ourselves. And as @Xon mentioned, from the server log it looked like an issue with load_class.

Back a while ago, there was an issue where if some mods initialised this bit:

$fc = new XenForo_FrontController(new XenForo_Dependencies_Public());
$fc->run();

Inside a container, the $fc variable would have to be made global.

That being said, that issue should be resolved in the new beta versions, so the only way I can think of this happening would be if your customer is running the older (stable) releases, and you are indeed loading the FrontController not within the global scope.

This is the relevant section of code:

                    try
                    {
                        $fc = XenForo_Application::get('fc');
                    }
                    catch (Exception $e)
                    {
                        if (isset($GLOBALS['dependencies']))
                        {
                            $dependencies = $GLOBALS['dependencies'];
                        }
                        else if (isset($GLOBALS['bridge']) AND $GLOBALS['bridge'] instanceof Tapatalk_Bridge)
                        {
                            $dependencies = $GLOBALS['bridge']->getDependencies();
                        }
                        else
                        {
                            $dependencies = new XenForo_Dependencies_Public();
                            $dependencies->preLoadData();
                        }

                        $fc = new XenForo_FrontController($dependencies);
                        $fc->setup();
                        $fc->setRequestPaths();

                        // Now set this
                        XenForo_Application::set('fc', $fc);
                    }

So if ForumApps does not do XenForo_Application::set('fc', $fc); for whatever reason, please make sure $GLOBALS['dependencies'] is set, otherwise our code will attempt to load them again. If the dependencies are loaded again, that will cause duplicate class issues in load_class.

Again, I should stress that this should not be an issue in the new versions as I have significantly improved my middleware to the point of the above code not being necessary, but I can understand customers not wanting to update until the new versions have reached stable status.

Hope this helps


Fillip

 

[Aayush]

Back a while ago, there was an issue where if some mods initialised this bit:

$fc = new XenForo_FrontController(new XenForo_Dependencies_Public());
$fc->run();

Inside a container, the $fc variable would have to be made global.

That being said, that issue should be resolved in the new beta versions, so the only way I can think of this happening would be if your customer is running the older (stable) releases, and you are indeed loading the FrontController not within the global scope.

This is the relevant section of code:

                    try
                    {
                        $fc = XenForo_Application::get('fc');
                    }
                    catch (Exception $e)
                    {
                        if (isset($GLOBALS['dependencies']))
                        {
                            $dependencies = $GLOBALS['dependencies'];
                        }
                        else if (isset($GLOBALS['bridge']) AND $GLOBALS['bridge'] instanceof Tapatalk_Bridge)
                        {
                            $dependencies = $GLOBALS['bridge']->getDependencies();
                        }
                        else
                        {
                            $dependencies = new XenForo_Dependencies_Public();
                            $dependencies->preLoadData();
                        }

                        $fc = new XenForo_FrontController($dependencies);
                        $fc->setup();
                        $fc->setRequestPaths();

                        // Now set this
                        XenForo_Application::set('fc', $fc);
                    }

So if ForumApps does not do XenForo_Application::set('fc', $fc); for whatever reason, please make sure $GLOBALS['dependencies'] is set, otherwise our code will attempt to load them again. If the dependencies are loaded again, that will cause duplicate class issues in load_class.

Again, I should stress that this should not be an issue in the new versions as I have significantly improved my middleware to the point of the above code not being necessary, but I can understand customers not wanting to update until the new versions have reached stable status.

Hope this helps


Fillip

I haven't looked into the issue or code in depth yet due to other commitments but the issue was reported as

ErrorException: Fatal Error: Cannot declare class XFCP_Audentio_UIX_Model_Post, because the name is already in use - library/XenForo/Application.php(528)

But the user that it started working as soon as he disabled DragonByte Tech: Shout (Lite). The forum was running 1.5 so I just can't say whats the core of the issue is just yet.

Thanks for the detailed response. Will let you know if I require any assistance of yours.

 

[DragonByte Tech]

I haven't looked into the issue or code in depth yet due to other commitments but the issue was reported as

ErrorException: Fatal Error: Cannot declare class XFCP_Audentio_UIX_Model_Post, because the name is already in use - library/XenForo/Application.php(528)

Yeah, that's the exact error that would happen in the circumstance described above. It should be as simple of a fix as to make sure the dependencies exist either in XenForo_Application or in the global scope so our mods can read them


Fillip

 

[Aayush]

Yeah, that's the exact error that would happen in the circumstance described above. It should be as simple of a fix as to make sure the dependencies exist either in XenForo_Application or in the global scope so our mods can read them


Fillip

Great. Would you mind if I ask the user to your support thread? Link would be great.

 

[DragonByte Tech]

Great. Would you mind if I ask the user to your support thread? Link would be great.

Sorry, I'm not sure what you're asking here, can you clarify please?

There's nothing I can do on my end to provide support to the user, unless I am given access to the source code of your product to try to ascertain the exact line of code that needs to be changed so I can provide a patch to you, which I would be happy to do if you want to PM me with a download.


Fillip