As part of ExtDN (the Magento Extension Developers Network) we kicked off two initiatives at this year's Imagine: Extension quality and extension interoperability.
For the second topic I suggested a DevExchange topic to kickstart a discussion:
Extensibility is one of Magento's hallmark features of the platform. Unfortunately unforeseen issues can arise when various extensions are installed alongside each other. No one likes dealing with these conflicts and they are a drag on any implementation.
Let's make this a better experience by discussing common and not so common causes and how we can improve on status quo. The goal of this table is to jumpstart a solid list of action items that each extension should follow to increase interoperability with other extensions.
We had a great cross section of participants at our table - merchants, agency reps and extension developers all shared some great insights and examples. Below is a summary of where we got to with extension interoperability, some of my thoughts, and where we plan to take this next at ExtDN.
Why interoperability matters
It's a topic which requires attention as pretty much everyone involved has a bad experience with extensions that just don't play nicely together. Merchants are left with extra unexpected costs and time spent troubleshooting and chasing developers. Agencies are often stuck in the middle trying to fix issues, after making recommendations to choose particular extensions. It's not fun for extension developers either, with extra support issues and getting blamed for poor quality extensions.
Extensions being 'compatible' can mean two different things:
- Both extensions are technically working
- Additional functionality provided by one extension is incorporated into the other extension
Let's look at each in turn.
Technically working means that two extensions will work together on the same site without causing any issues.
As a general rule, an extension will work in a vanilla Magento environment without issues. However no merchant will ever run a vanilla Magento environment - every merchant will have a unique combination of 3rd party and custom built extensions to enable their store to serve their customers. Why do conflicts occur? Extension developers essentially create software that will run in an unknown environment. There's an infinite number of potential theoretical combinations of different extensions, extension versions and Magento versions. No matter how good or clever your software is, it's impossible to foresee them all. How it usually goes for us is that a customer emails us with an issue. If we can't replicate the issue with the provided information we would then suspect an issue that only shows in the presence of another extension. However at this stage we wouldn't know which extension might be causing the issue, and without access to the source code of the 3rd party extension it would be impossible to understand why it's happening. As you can imagine, this involves a huge amount of back and forth troubleshooting to pinpoint the issue, contact the developer of the other extension (and if you're lucky, hear back from them), and work out a way to resolve the conflict.
From the merchant and agency perspective it's cumbersome to isolate extension conflicts. To prove it's the fault of a particular extension one would need to set up a vanilla installation, replicate the issue and rule out a whole host of other potential issues in the process. It costs time, and time is money.
From our discussions it was pretty clear that there are no silver bullets and it's about working together to come to a resolution.
Test sites are really valuable. It's helpful to have a demo store available from the extension developer as it offers a quick option to prove something is not working with the extension. If it's not an issue that can be replicated on a vanilla Magento instance, the issue likely is caused by a combination of extensions. For merchants and agencies, the ability to easily provide access to a dev/testing site that exhibits the issue is going to save a lot of time troubleshooting issues with an extension developer. For extension developers, it's helpful to create a streamlined process for creating support requests (one that doesn't require back and forth over 5 emails to work out IP addresses and public keys!).
Even with various different extensions all technically working correctly, there is still one often overlooked area as a possible pitfall. When requirements for a merchant are scoped, how two separate extensions interoperate (or not) is not always fully discussed.
Both extensions technically work correctly. But this is where assumed functionality can sometimes come into play. A merchant might assume that something seemingly simple like the additional delivery date provided by ShipperHQ should show on the packing slip pdfs provided by the Pdf Customiser module. However without additional coding effort extra functionality like this does not happen. Depending on the two extensions involved, this extra assumed functionality can be a big blind spot that's often only discovered late in a project.
(Sidenote: we now offer an additional addon Pdf Customiser module that will help in displaying this extra piece of information).
Awareness helps and the general assumption should be, unless otherwise stated, features added in one extension will not automatically get picked up in a separate extension. One action point for extension developers here is to state what other extension functionality might be incorporated and how.
It would also be great to have a central place to look up how extensions interoperate and to be able to find past resolutions that were developed.
Where to next
At ExtDN we are committed to improving interoperability, and will share our thoughts and recommendations with the community as we make progress on this important topic. If you are interested in joining the efforts please hit the Join button on extdn.org. Also if you have a story to share about a particular extension conflict please add it here - we are looking for a wide range of examples.