The Google Summer of Code (GSOC) 2012 has finished, and we’re proud to show you what our interns have produced in the meantime. Six of our seven students have made it to the final evaluations (see our mid-term status report), and by now are well-known members of our growing community.
As an open-source organization, we’re happy to say that its been our first participation with “external” mentors from outside SilverStripe Ltd., which is a good sign for the health of the ecosystem. All students were forced to become “early adopters” of SilverStripe 3.0, which was released at the start of GSOC, so you can expect a lot of the resulting code to be compatible with the latest and greatest core releases.
Thanks to all the students for not being afraid to jump into the deep end, and kudos to their mentors for offering their spare time to help develop code, but also to build up new community members. And last but not least, thanks to the community for welcoming the students so nicely!
But let’s have a look at the individual projects, and what our students can report about them:
Yuki Awano (Japan), mentored by Philipp Krenn (Austria)
Yuki probably had the broadest and most experimental scope, with his idea to personalize content to different users. He frequently updated the community about his progress, and the module is in such a good shape that we already have clients interested in using it!
“Since the mid-term evaluation, I added the geolocation options “nearest” and “in” as well as a debug toolbar so that administrators can simulate the location and know which audience type is applied for each personalized block. In addition, I made some performance improvements for practical use. Finally, I set up Continuous Integration with Travis for the module.“
Michal Ochman (Poland), mentored by Ingo Schommer (Germany)
Remote controlling a browser for testing purposes is hard, and doesn't get any easier if you’re using a business-readable non-technical language to do it. Nevertheless, Michal got stuck in it and integrated Behat into SilverStripe, from simple button clicks to complex ajax response handling and database fixture setup.
He’s produced a screencast to show the executed test steps in action. You’re welcome to run the existing CMS tests to sanity check your CMS pull requests (github), or use his Mink Extension to write your own behaviour tests for projects or modules.
Jakob Kristoferitsch (Austria), mentored by Mark Stephens (SilverStripe Ltd, New Zealand)
Debugging is always a pain, and Jakob strives to make it a more integrated process in SilverStripe with his developer dashboard module. It involved learning both legacy APIs in core as well as the Zend_Log logic we’re increasingly relying on, so kudos to him for bringing it all together in a convenient UI. And he even found time to fix some pretty gnarly core bugs along the way!
Out of the box, the developer dashboard module provides a screen that displays debugging and logging information. If a developer wants to display additional information or add new functionality, he can add new panels (tabs) containing FormFields.
Since the mid-term review, the API has stabilized and is now ready for outside use. As an example of how other modules could use the dashboard, I forked the dbprofiler module and modified it to display its information in the dashboard (see the dashboard branch at https://github.com/jakr/silverstripe-dbprofiler/tree/dashboard).
Another very visible new feature is a tab that can follow any log file on the server. The dashboard regularly polls the server for updates and adds any new lines since the last request (similar to the Unix command tail -f).
Ryan Dao (Singapore), mentored by Frank Mullenger (New Zealand)
This has been a particular success story which started prior to GSOC. The payment module used to be maintained by SilverStripe, and was handed over to the community to flourish there. Since then, the module formed the basis for multiple open-source ecommerce modules, as well as numerous bespoke implementations. It was great to see these community efforts being rewarded by a GSOC project, with the opportunity to stabilize and improve.
The Payment API has been through some major API changes since the mid-term, most of which have to do with validation and error handling. Right now the API has reached a stable phase. PayPalPayment, DummyPayment and PaymentTest also changed with respect to the API changes. I have accomplished the minimum-viable objective for GSOC, which is revamping the Payment API with comprehensive testing, demonstration, and documentation. There are still some refactorings to be done. More importantly, more payment gateways need to be supported in order for the module to be ready for a release. That will extend the project past the scope of GSOC and require contributions from the SilverStripe community.
Vikas Srivastava (India), mentored by Julian Seidenberg (New Zealand) and Aaron Carlino aka UncleCheese (USA)
When a code redevelopment has less than half the lines of custom code than its predecessor, you know something went right. This is the case for the long overdue improvements to the modules section of silverstripe. Vikas has taken on this high-visibility project, and rebuilt many of its existing features to work with the composer dependency management. Registering a module should be as simple as committing a JSON file to your project and submitting a URL. Vikas lists some of the features implemented since the mid-term evaluations:
- Storing Keywords, Snapshots, Extension Authors detail using composer.json file.
- Categorization of Extensions according to some predefined categories.
- Creation of package.json file after every extension submission (This file will define proposed website as composer repository).
- Extension submission from subversion repositories.
- Disqus comments.
- Front end Search form which contains more filters now (although some of them are not working properly).
- Base classes are now more stable with help of Unit test.
- Listing of Recently submitted extensions which later will be shown in showcase/gallery after theme work.
- Continuous integration
His code is a standard module (github), which everybody is welcome to improve to speed up the process of getting it onto silverstripe.org eventually. Vikas has also set up a demo site where you can test-submit your own modules already. Special thanks to his (new) mentor Julian for offering assistance halfway through the project, when Aaron had too much on with UncleCheese Junior!
Andrew Short (Australia), mentored by Marcus Nyeholt (SilverStripe Pty, Australia)
Andrew has proven himself as an important core contributor, for example by developing the “nested URLs” feature which everybody takes for granted these days. He’s not sitting on his laurels, and went on to run the GSOC project with the deepest core interaction: Integrating with the composer dependency management system, as well as rewriting SilverStripe to support modules in arbitrary folders and a more flexible bootstrapping. This project is significant beyond code, we hope that it will be a major boost to our third-party module ecosystem, by making it much simpler to install and manage modules.
The Composer integration has largely been completed, and you can now get a SilverStripe site up and running using Composer to install framework, cms and other modules. The upgrade path from a SilverStripe 3.0 site has also been implemented. The install process is still a bit clunky, but this will be made much easier when we have a custom composer repository up and running.
Some key features implemented since the mid-term include:
- Integration with the composer toolchain - when you install a module using composer it will automatically be set up to run without any extra steps.
- You can now store your application code outside the webroot, with public assets copied across. This will be the recommended setup.
- The default application directory structure has been reworked.
- Reworked HTTP request handling (mailing list post)
There are still a few items left to do, some of which will extend past the end of GSOC. At the moment I’m focussing on documentation. Other TODO items include fixing a few remaining failing tests, implementing caching, and integrating composer with the installer.