With the newest release of ctools, a new command was made available for drush to export all objects to code with one simple command to a module. Instead of having to copy and paste all code via the bulk export module to your custom module, a simple drush command now saves you a lot of time. But it doesn't stop there. Damian 'damiankloip' Lee started a sandbox to add more powerful funtionality and this has now been merged in the 7.x branch which will be available in the (soon) next release of ctools. An initial patch to select the exportables by hand has also been committed, but could need some more love on the UX side. Apart from that, the goodies that are in already, should make any developer extremely happy and opens up new possibilities in so many ways. So what commands can you use now and what do they do ?

• drush ctools-export-disable: disable one or more exportables
• drush ctools-export-enable: enable one or more exportables
• drush ctools-export-revert: revert one or more exportables
• drush ctools-export-info: get an overview of all possible exportables
• drush ctools-export-view: view one or more exportables
• drush ctools-export: export all exportables to a module

Excited yet ? We are, so we made a screencast, we're pretty sure you'll love it. Damian and I are planning more things for the future, so anyone who wants to help can post issues to the sandbox. Once they're done, we can commit these easily now Damian has access. Let's make ctools drush extremely powerful!

By default it's not possible to override existing paths with Page manager, the excellent module that is bundled in the CTools project. The Page manager existing pages module now allows you to do that. Technically, this module defines one abstract task and one content type plugin, so menu items can be overridden and the original page callback can be called through the content type plugin. This project comes with one default existing page, which is 'node', the default Drupal frontpage.

Basically, you are now able to override any Drupal path in your installation and create variants for it. The module comes with one default existing page (although new ones might be added in future). Default contexts for entities is possible as well. I've created a screencast so you can see the module in action at http://www.youtube.com/watch?v=W-4g01WjwI4.

Daniel "dereine" Wehner has written a blog post about it at http://blog.erdfisch.de/2012/01/override-all-existing-pages-panels with some excellent screenshots!

Display Suite has the ability to create custom fields, either through code or via the UI. Those fields can hold custom content or even PHP code. It is somewhat limited since one field can only have one type of content, unless your field has some crazy PHP code which is not easy to maintain. Those days are over now. You want to add custom content, a node, the logo or any other type on the Field UI screens? The upcoming release - 7.x-1.2 - comes with a new field called ctools field, which can hold any sort of content that is available through ctools' plugin system and which is configurable on the "Manage display" screens per entity, bundle and view mode. Think as of Panels, but in Field UI. And they are of course all exportable. This may all sound a bit cryptic to you, so I've recorded a screencast showing you how this works. Be amazed and watch out for the upcoming release of Display Suite somewhere next week!

For the upcoming release of Conimbo, a Drupal distribution we're building at One Agency, we needed an easy and attractive way to theme your website without knowing anything of CSS. Having the opportunity to experiment once and a while during our free day at work, one of our colleagues started playing around with jQuery and manipulating the properties directly on the frontend - much like the Themebuilder created by Drupal Gardens, which he used as inspiration. After a while, I joined the coding part and sweaver was born - if you really want to know where the name comes from, that's all explained on Drupal.org.

Writing sweaver was interesting because of three reasons:

• jQuery: we now probably know the jQuery manual by heart since we've had to look up a lot of new tricks to manipulate all kinds of stuff: iterating through all parents of a css selector, show/hide/close/open tabs and sliders, find out out the type of a selector and keeping it all manageable in a nice interface. It's been a tremendous ride so far and I'm pretty sure we've not reached the end of it.
• CTools: sweaver uses the CTools plugins and exportables functionality. This means developers heaven both for us as maintainers, but also for other drupal people out there wanting to write their own plugin for this module. We're still into beta phase right now, so we might even use other functionality like object caching, Ajax and form tools.
• Themes: we've learned that creating a re-usable theme isn't that easy, which is not even related to Drupal. Technology like cufon is fun, but clashed with our module. Switching to @font-face was something we've planned, but now got implemented faster. And I personally learned a lot of cool css tricks, but I'll stick with coding though :)

Interested and want to see how it looks like ? You can watch two video's we've created: a basic introduction and another where we show you how I've used the module to rebuild my own website. There is also a demo site where you can login and play around with it - not all plugins are enabled, but you should be able to create beautiful themes or hideous creatures :)

Downloads and more documentation is available on the project page on Drupal.org. It's important to know that we're still in development, so there are things that still act funky and might change completely during commits before a first release. Happy theming!