Joomla Development Blog

In 2011, Monotype Imaging approached us to build an extension to deliver fonts from their font service, Fonts.com, and Google Web Fonts. The idea was that a web designer could easily integrate fonts from a variety of sources seamlessly into their website design using an interface that accepted CSS selectors. We built it and they were so happy with the result, that they hired us to rewrite the PHP service class that connects to their API. Since then, over 30,000 people have downloaded and used the extension we built.

One of our partners approached us recently about re-creating a client's site in Joomla. The original site was working fine, but they wanted to make it responsive. The problem was that the marketing agency who originally created the site wanted an arm and leg to make it responsive. On top of this, they were busy for several months and it could be a year before the work was completed. Unfortunately, there wasn't a lot the client could do. They had already paid an arm and leg to have the site developed and the platform that it was developed on was proprietary to the marketing agency. This is a form of vendor lock-in. In this post, we'll discuss why lock-in is terrible for your business and 3 common techniques that I've seen used to create it in web development.

We just launched a portfolio plugin for WordPress at the beginning of September. Every project has its gotcha moment right at the end when you think you're done and an undiscovered assumption rears its ugly head. The plugin, Pizzazz Portfolio, was no different. The business model for Pizzazz is freemium where a free version is available to everyone and a commercial version with more features is available to those who want more beef. Our stumbling block was when we realized that we couldn't perform a direct upgrade from free to premium using WordPress. We've built several WordPress plugins, however the portfolio plugin is the first time we've released a plugin into the WordPress plugin directory for mass distribution. I asked some peers of mine how they handled these types of upgrades and they told me that they typically wrote custom updater classes. We could have done this, but there was just one problem: like any good developer, I'm lazy. I don't want to write custom updater classes if I don't have to. I won't explain here why it is good for developers (and benefits their clients) to be lazy, but I will blow your hair back by explaining how we used Joomla to upgrade WordPress.