concrete5 is a complex application. In addition to offering a pleasing, flexible, intuitive interface for managing web content, we provide functionality like drag and drop layout editing, theme importing and customization, powerful file management and manipulation, MVC frameworks for individual content types and full pages, events and extensions frameworks, complex and powerful permissions, extensive interface customization and complete localization for the entire application and is extensions.
Like most other applications of its size and purpose, we didn't write everything ourselves. We're indebted to members of the open source community like jQuery, TinyMCE, ADODB and others. They're integral to what we do, and have been with us since the very beginning. But just recently we've started using several new third party libraries to help us accomplish some impressive things and move us toward wider adoption and greater performance.
What libraries? Those would be some choice components of the Zend Framework. Yes, we've been using the Zend Framework since the very beginning as well, but its usage has become even more important in the latest release, concrete 5.4.
Why'd we start using the Zend Framework?
Before we even take a look at the documentation for a particular library, we check out its history, its place in the web development world, and its track record. It's hard to go wrong with the PHP framework blessed by the language's founders. It also helps that every single proposal for each component of the framework can be found online, with feedback addressed publicly.
Documented and Understandable
In the first version of concrete5, we needed a solution for search that could be packaged up and shipped simply and quickly. We chose Zend_Search_Lucene, because its results were demonstrable and its code samples and API were easy to read and understand.
While we've since moved away from Lucene as a packaged-in solution – and instead have embraced search as a custom problem for custom sites – the lessons learned still resonate.
Integrating Zend_Search_Lucene took all of an afternoon. While the Zend Framework is large and potentially imposing, it's a huge benefit that its components are modular and can be incorporated without also including everything and the kitchen sink.
Localization and Caching in 5.4: concrete5's Primary Use of the Zend Framework
Version 5.1 of concrete5 introduced localization of the concrete5 core, allowing translation of the application into other languages. It wasn't until version 5.4, however, that we provided a way for add-on developers to translate their add-ons as well, and provide their translations independently of the core. We wanted add-on developers to be able to make their add-ons translation-ready with the exact same syntax that the core team uses, and – if at all possible – be able to use strings already translated in the core.
This simply wasn't possible using PHP's built-in gettext localization library. So we switched to Zend_Translate and the Zend Framework, which worked like a charm. I was able to make it happen inside of a day. When finished, all our existing translation files still worked, and new ones for specific add-ons could be easily loaded at runtime.
Moving to Zend_Translate meant ditching our quickly-written, effective but inflexible cache backend for Zend_Cache, which instantly gave concrete5 support for many modern cache backends like APC, XCache, memcached, as well as standard file-system-based caching. This meant that, right out of the box, concrete5 installations on certain servers could receive significant performance improvements just by enabling some runtime options.
As we move forward toward concrete 5.4.1, the benefits are even clearer. With some application tuning and new caching options, plus the benefit of Zend_Cache working with an APC cache backend, preliminary local testing shows concrete5 5.4.1 performing nearly five times faster at rendering the default home page than under 22.214.171.124, all while providing much greater localization flexibility and supporting many more caching layers than we ever could have on our own.
Other Uses of the Zend Framework in concrete5
While caching and localization are the most front-and-center uses of the Zend Framework in concrete5, we employ it elsewhere. Any time you import a file from another web server into concrete5, you're using Zend_Mime. And switching to Zend_Mail has allowed us great flexibility in the mail department, including the ability to process inbound messages, connect to external SMTP servers, and even send HTML mails with attachments, all without worrying about how to connect to different mail servers or speak POP/IMAP.
That's really the promise of the Zend Framework: we can't be experts in everything, and it's to our benefit that there are those out there willing to develop modular, tested frameworks for interacting with the things that are ancillary - but still important - to our applications. concrete5 isn't a caching application, a localization application or an email application: it's a system for building useful, attractive websites and providing a simple means to edit them. But in order for it to be effective at meeting this goal, it needs to be able to connect to mail servers, read mail, send mail, cache its data objects and translate its core and add-on files. Using the Zend Framework means we can more effectively focus on the things we have experience with, and spend our time working on what really matters to us as application architects, interface designers and web developers.