Drupal 7 session from Timisoara prezi at http://prezi.com/ujogfpnqjwsb/drupal-7-timisoara/ (also linked from session page) #drupalro
Submitted my first @drupalcon Copenhagen session proposal: http://bit.ly/bybUSZ #gonnabeawesmoe
Want to help #drupal core run better on PHP 5.3? See http://drupal.org/node/587568 and http://drupal.org/node/360605#comment-2866234
After some organization around travel and accommodation (which is still in flux to some degree), looks like there is nothing in the way for me to attend Drupalcamp Timisoara 2010 and contribute some content to the session schedule as well. Fun! This Drupalcamp is taking place in the Politehnic University of Timisoara in one month on June 5th and 6th, and is primarily English. I'm spotting others coming from as far as Belgium, Serbia, Moldova, Hungary, Austria and Germany.
The two sessions I've submitted for the schedule are the following:
Come for the software, stay for the community - how Drupal improves and evolves
"Come for the software, stay for the community" could become Drupal's new slogan (see the discussion), so what better title to use to explain what Drupal is about? In this session I intend to provide a brief overview of what Drupal is and instead of delving into technical details, focus more on how the different avenues to improve Drupal work. Systems like distributions, localizations, issue queues, the core and contributed modules repositories, the security team, automated testing and so on. How can you collaborate with the community and make money on the way?
This session is aimed at beginners or those who could use a good high level overview of different areas of Drupal.
What's up with Drupal 7?
Drupal 7 is about to be released sometime later this year. We don't yet know when, but it is steadily marching towards in its release cycle. As always, this new version of Drupal comes with all kinds of bells and whistles promising to improve our lives. What's even better is that many contributed modules are pledged to release on the day of Drupal 7's release. Automated testing is now the norm and Drupal Gardens is doing an immense deployment of beta testing on a Drupal 7 based service so no Drupal release will be as well tested as this one. Come see the improvements coming up in this release and see why the Drupal 6 maintainer is envious.
I've intended to announce this development at Drupalcon San Francisco but unfortunately the session on this was merged with a more general i18n session which was coupled by the ash cloud above Europe, so I could not go. Evidently, collaborative software translation is not a mainstream topic. On the other hand, I keep receiving requests of the general applicability of the tools Drupal.org uses about every two weeks, and this interest always amazes me. While the localization server tool used on localize.drupal.org grew out of needs of the Drupal community, the solutions were architected to be useful in a general purpose software translation environment. While the architecture was there, it was lacking useful UI controls to just run it as a generic software translation tool.
Existing non-Drupal users like the Gallery 2/3 project and the Musescore desktop app utilize custom data connector modules, which the localization server nicely supports, allowing for custom code to gather data for translation. Gallery even uses a custom Localization client port for clients to submit translations to the server, even though their software is not Drupal based. However, translating arbitrary software without writing your custom connector code was not possible earlier.
RT @robertDouglass: Drupal as a software product: http://is.gd/bUa66 First of many, Open Scholar now available from Acquia.
At the Hungarian community, we are organizing yearly local Drupal conferences ever since 2006 under the "Drupal Conference" and "Drupal Weekend" names. We've also just had our 22nd monthly meetup in a row. We've hosted Drupalcon Szeged 2008. Over these years, we've found that naming for all these events is tricky, and nowadays, the "Drupalcamp" name is sticky for local Drupal conferences. However István Palócz of the Hungarian community had a different dream around camps.
This year, we're gonna have the first Drupal Summer Camp in Hungary (and by the looks of Google search results maybe the first Drupal Summer Camp ever). Unfortunately (at least for my non-Hungarian speaking audience), the event is all in Hungarian (except all the jargon thrown around that is :).
The camp is on from the 23th of June to the 26th and is organized with community participation in mind. People can get experience translating interfaces and sharing their translations, look into drupal.org project maintainership aspects, work with the issue queues to get problems solved, etc. By the nature of being together for four consecutive days (with a complete dormitory floor rented for cost-concious and/or community addicted attendees), lots of hands-on experience can be gathered.
And continuing our good tradition of organizing events with side parties (remember SZIN from Szeged?), this summer camp will take place in Pécs, which is 2010's European Capital of Culture with a vast number of options for chilling out. (Check out more photos of Pécs on Flickr).
I'm looking forward to how this model works out, and am happy to share experiences with anybody looking to make actual summer camps in the future.
Early on in the development of Drupal Gardens, it was clear that we needed some type of simple Views-like functionality. You know, letting users set up simple lists of content beyond what is included with Drupal 7 core, but simpler than the Views UI which can be quite intimidating to first-time users. Drupal Gardens' goals include making Drupal easy to use, and that sometimes comes with feature sacrifices. You cannot do everything you could do with a self-hosted solution, but you can do most things easier. If you exceed what Drupal Gardens can do, no worries, simply export your code and database and adopt any Drupal 7 module.
So when looking at our options for implementation, we had the obvious choice to roll our own code and live with that or postpone this feature to get released with Views D7. There is some very nice discussion going on around the Views D7 UI at http://groups.drupal.org/node/64143 and it is evident it is not a small task. For Gardens, we needed a very easy to use UI with a limited feature set. And of course there is a module for that, its called Simpleviews, from Jeff Eaton himself.
We decided to contribute to the community efforts within our limited scope, so we took Simpleviews and upgraded it to Drupal 7 and posted it for review in the issue queue. But Simpleviews depends on Views, right? So without a Drupal 7 version of Views, how useful could that all be? Whether by chance or Jeff Eaton's genius, Simpleviews is actually a pretty standalone module. It only requires Views where it clears the Views cache. The architecture of Views lends itself very well to these kinds of alternative interfaces because it works with array dumps, so an alternate UI module can just have its own ways to generate these arrays.
The original Simpleviews UI screenshot from the module's page
Simpleviews itself stores all simpleview settings in a database table and generates Views arrays out of that. So if we don't have Views, we can just look at the settings in the database and generate output based on that. This way we get the best of Simpleviews by being forward compatible with Views if we later decide to include Views in its entirety, while we can have a very simple and lightweight module to generate output for the small use-cases we cover today. Because Simpleviews is indeed very simple, the backend for generating pages based on the settings there is also surprisingly simple.
My initial version of this backend module was 167 lines with plenty of code comments, which covered all kinds of funky Simpleviews features, except exposed filters. Honestly, we attempt to practice restraint around adding more features to it, but currently it already grown to 460 lines to support some additional things like taxonomy term based filtering and style support for blocks. It is still a little-bitty module compared to Views.
What are we going to do with this feature in the future? Well, we are still not decided yet. We certainly want to provide a lot more Views-like functionality and features this year, but we are starting with design and UX first -- and then we will decide what back-end supports it best. We might use all or some of Views in the future, we might tone down its UI, we might use another alternate UI, we might keep using an alternate backend. It is an ongoing discussion at the Gardens team at this stage. I believe that there is no point in publishing our current backend module on drupal.org given its interim nature, but that does not make it closed source or unreleased. Any Gardens site that is exported will include a copy of this module, and it is released under the GPL.
What do you think about our approach? How would you make the Views user-experience so easy anyone could use it without getting help? If your suggestion pertains to the Views module itself, please contribute to the existing groups discussion, otherwise leave a comment. Thank you!
amazing post: RT @Dries, Breaking news: Drupal 7 found in a bar in Antwerp! http://bit.ly/adwyRX /cc @bertboerland #drupal #iphone