Why I’d Love Joomla Developers to Stop Encoding Components

Those of you who know me realise I rarely, rarely get worked up ….. I think this is the first time I’ve used this blog to blow off steam. Its so rare, I’ve even had to create a whole new blog category for this.

Anyway, the last couple of weeks I’ve been frustrated one recurring problem – encoded components. This issue has come up in three different situations:

  1. Moving a site. Recently we moved a large site to a new domain name. That meant contacting several different vendors and asking them to work with us to change the licenses. One of them, the developers of a key component, failed to respond for over two weeks while the client and ourselves sat and fumed.
  2. Upgrading a site. One of our clients purchased a component about a month ago. A week later the developer announced that they would be encoding all future versions. The client isn’t on a site that allows IonCube installation and so their new component won’t ever get an upgrade, despite any security holes that might emerge in future.
  3. Developing a site. We developed a site offline and then put files onto a webserver so that it could be accessed it via an IP address. For example, you can access Alledia.com via IP address: 72.249.30.148. However, before the actual domain points to the site, none of the encoded components will work because they’re tied to the domain name. So, instead of a smooth launch, we need to point the nameservers, take the site offline for a day while we test the encoded components are working properly and then launch the site. Very frustrating.

I am not against encoding per se and realise that developers need to be protected from people spreading their files around on warez sites. However, the problem is often with the way that the encoding is implemented:

  1. Customer Support. If you want to use professional-grade encoding, you’d better provide professional-grade support. Some people such as Emir at Sakic.net and Jeff and Joomlaware.com do that. Certain others don’t.
  2. Hosting. Even the best Joomla hosts don’t always have Zend, IonCube and other decoding software available. We host with Rochen.com and recommend them wholeheartedly, but even they didn’t have both available on all servers when we arrived. Zend itself has had some serious issues with some scripts such as phpBB and many hosting companies are reluctant to use it.
  3. Restrictive Licenses. If you’re going to encode, at least allow people some leeway with the license. Some developers won’t even allow the component to be used on a sub-domain. We never return to purchase a second time from companies that do this.
  4. Unclear Licenses. Try this simple test ….visit several component developers websites and see how long it takes you to answer the following questions:
    • What’s their upgrade policy?
    • Will the product work on Joomla 1.5 or will I need to pay again?
    • What happens if the software doesn’t perform as described?

    5. All valid customer support questions but you’ll spend hours looking on most sites without finding the answers.

  5. Usability. Encoding makes Joomla less attractive to the casual user. When we ask a resolutely non-technical user to negotiate their way through the different decoding requirements for three or four different components, we’re drastically reducing the overall user-friendly nature of Joomla.

Finally, in closing, its appropriate to give kudos to those companies that produce commercial components but haven’t yet succumbed to the siren call of encoding:

(I’ll be happy to add anyone I’ve missed)

Leave a Reply

Your email address will not be published. Required fields are marked *