Oct 06 2014
Oct 06

One Drupalcon session of particular interest to many in the community, since the first “episode”, has been the “Q&A with Dries”, a core-conversation-track session in which Dries is joined by a panel of his initiative leads and others in the “inner circle” of Drupal 8 core development. Since I’d wished, in the past, that sessions like these had a video recording to show who was talking, I brought my DSLR and a shotgun microphone this time, thinking I’d contribute the resulting video. I don’t think the video I shot was technically perfect enough to share; perhaps I could fix that, but I also realized that one panel member prefers to limit her exposure on the Web—and respect that, of course; since it’s much easier to blur or block out a face in a few images than in a video, and since you can read this summary in much less time than the hour+ -length session, I decided to provide stills from the video, along with a summary of the questions and answers, which ranged from the whimsical (a bet on how long it would be till Drupal 8 would be released as “stable”), to various business and architecture questions, and other concerns.

Q and A with Dries and panelists, Drupalcon Amsterdam

(You’ll find a more serious answer to that question if you read on...). Of course, Dries began by asking each of his panelists to introduce themselves. Those present were:

intro_gabor.jpgGábor Hojtsy, who works for Acquia and introduced himself, first, as the Drupal 6 maintainer; he also leads the Multilingual initiative for Drupal 8.

Nathaniel CatchpoleNathaniel Catchpole (catch), a major core maintainer with special focus on optimizing performance.

intro_alexpott.jpgAlex Pott, who works for ChapterThree, and supports Drupal as a core maintainer, also contributes actively in the configuration management initiative for Drupal 8.

yched introduces himselfYves Chedemois (yched), a freelancer and volunteer contributor to Drupal core, especially active as the maintainer of the Drupal 8 Field API (he formerly maintained CCK).

Wim Leers, core maintainerWim Leers (of Acquia, who works on the Spark initiative and Drupal 8 performance

Jess (xjm), who was the major heavy lifter for getting Views into Drupal 8 core, alongside her very active community mentoring role, now is most active with release planning and other steps toward getting Drupal 8 to the community.

Dries jokes and introduces himself as 'Drice'

Dries made everyone laugh, then, by introducing himself… and pronouncing his name as if it rhymed with “rice”. He followed by submitting the first questions to the panelists; these initial questions were selected from those emailed to him before the day of the session. Everyone had something to say for the first question.

Q: Are there any lessons learned, so far, from the Drupal 8 release cycle?

Alex Pott pointed out that changing core is taking longer and longer as the complexity increases and the needs of the greater Drupal community become more varied. “It’s no longer a matter of developers having a good idea and putting a patch on Drupal.org”, he said. You have to get everything reviewed and tested and re-tested, usually through many iterations, before a patch finally makes it into core.

Yves Chedemois (yched) added that it really helped having a bigger team of people assisting in the Field API initiative, compared to how things have sometimes been in the past, before the initiatives, with only one or two people working on a particular sub-system; so now he might have five or six developers actively supporting him and who are all able to review each others work, and take over from one another if anyone is ill or leaves the team. He pointed out that, of course, finding five or six people who can keep active for the full 2-3 years that has been this development cycle has been one challenge; it’s just not realistic to expect.

Gábor weighed in with the fact that the whole extra communication with the community was something that hadn’t been so present before and has helped to find people identify their strengths and find ways to contribute to the development process. Extra communications on Drupal.org, the core conversations like this Q&A session, and the initiatives, themselves, helped to build a better level of involvement and ability to contribute.

Dries also added that people asked whether the initiatives, themselves, were a success, and wanted to say that he, indeed, found them very useful for the development cycle. It helped communicate a sort of roadmap for Drupal with the key areas that needed work. Having clearly communicated, specific goals, and teams working with specific areas of interest, in turn helped gather more people to help. He pointed out that the initiatives which were most successful in gathering a team to rally to their cause tended to be the ones with leaders with the best ability to communicate their goals; and of course they also had to have great technical skills and be skilled project managers. Dries added that, if he were to do it again, he would try to get a small team together for each initiative, from the start, with individuals able to bring all important strengths to work for each initiative. It’s a lot to ask from one person.

Q: How do you best prepare for Drupal 8?

Nathaniel Catchpole (catch), suggested that if you are a site-builder, experiment with building up a Drupal 8 version of a site you want to migrate to Drupal 8, or just begin building up a site; just remember that we are just at the first beta, so things might be changing. But if you just practice building up your site structure and learn what you can do, that can be very helpful as a first step to being comfortable with Drupal 8.

Wim Leers added that it’s a good time for the community to get the input from experienced site builders who have familiarity with how things work in Drupal 7 and might find some areas where performance or user experience have been affected in a negative manner; there might still be time to fix remaining issues identified now.

Jess recommended that users who need to migrate from Drupal 6, which is scheduled for “end of life” about six months after the release of a stable Drupal 8.0.0, practice building up the functionality they need in Drupal 8, determining any areas where core functionality doesn’t fill their requirements. A lot of functionality which was formerly only in contrib is now in core, but you can identify what contrib modules you still need to see ported. Keep your Drupal 6 site running, but you can locally test and practice the migration path from Drupal 6 to Drupal 8. Currently this path lacks a user interface and has some other rough areas, but there is documentation. Then you can follow and support the development of contrib modules that are blockers for your ideal upgrade.

Alex Pott added that if you are a PHP developer, it’s a good time to be learning about all the new object-oriented stuff in core; getting your head around that. He recommended looking at PHP: The Right Way for some good tips. Themers should work on learning Twig and a new base theme, Classy, just committed to Drupal 8. But beware, the others added: the theme layer will not be frozen until closer to the final release date, so there are still some things that will change. Also, there is now a full-featured Entity API in core, so when modeling your site, think in terms of entities and think about what is really content or not.

Gábor reminded us that even if you aren’t ready to dive into Drupal 8, there are a lot of good talks, blog posts, and development surrounding bringing a lot of “Drupal 8 improvements” into Drupal 7 sites, so you can learn your way around PHPUnit, Composer, etc, as a first step to getting comfortable with Drupal 8.

Dries then opened the floor to additional questions from the audience. The first participant actually asked two questions, one more serious than the other.

Q: If you had to bet on the release date for Drupal 8, what date would that be?

That guy who asked three questions...This question got a good laugh and perhaps more discussion time than was necessary. After skipping it to take his serious question, this one actually did get some answer time; Jess made some cogent points: that it’s not a good idea to base business decisions on any predictions around the release date of Drupal 8, but that the community is betting on it being soon and successful. She suggested that any really large projects which will take years to develop are good candidates for looking at the components of Drupal 8 as appropriate building blocks and starting work. His second question was one that, perhaps other developers who haven’t yet worked (much) with Drupal 8 code, could relate to.

Q: In the past, someone who doesn’t do a lot of development could still make a simple tweak to simple module. Now there is so much code for the new Symfony-based modules. Isn’t all this code scary?

catch pointed out that once you are familiar with it, there are still lots of places you can easily make the same kind of tweaks with Views in core, and with plugins and the configuration management. yched added that most of the hooks available in Drupal 7 are still available. Gábor said that he could remember a time, not so long ago, when he’d also been daunted by the complexity and differences between the way things are done in Drupal 8 versus how they were done in Drupal 7, but after starting to work with it, you will learn the new patterns and it starts to make sense and actually be easier, in many ways. Dries added that it’s common to be daunted by the “more-lines-of-code”, but that the object orientation actually reduces the complexity and makes it easier to extend and understand, once you are familiar with the design patterns. He also pointed out that in Drupal 7 you had to know all the hooks and that now, it’s more declarative and you can work with what you want to happen, based on events. So there is less you need to learn, and less “magic”.

Wim reminded us that Drupal 8 introduces greater strictness, which translates to an increase in verbosity, but also makes it easier to find and avoid problems.

Q: How does Drupal 8 architecture matter to clients? Why should they care about developing a site in Drupal 8?

Chris Amato, aka knectar on drupal.orgChris Amato (knectar) asked this question, to which Dries began by pointing out that there is a lot more support “out-of-the-box” for things like mobile content, with responsive designs and services deeply integrated. yched added that every entity type is now natively translatable and versionable and that every field can be manipulated with the same familiar tools. Gábor added that there are lot more Views and things that can be individually tweaked to a clients needs. Even admin pages are Views-based and the modules you use will also incorporate this flexibility, so there should be less need for hacks to work around what a client needs.

The next question had to do with decoupling in Drupal 8 and so-called “headless Drupal”

Q: (paraphrased) How does “headless Drupal” and decoupling fit in and is this something we will be seeing more of in Drupal 9?

The guy who asked about headless Drupal in Drupal 9Dries said that it was really too early to know what the focus of Drupal 9 would be, but that it would likely involve greater decoupling, yes. Others pointed out that it’s already possible to do a lot with headless Drupal and that we can look for a big growth in that direction coming from contrib and possibly making its way into core before Drupal 9.

The next question brought us to the issue of documentation.

Q: Will there be some books for Drupal 8 and better documentation?

That guy who asked about documentation...Gábor started by pointing out that there is already a Drupal 8 API section, a lot of which is pretty well fleshed-out. There are still places for people to get involved and help update since there have been so many changes since the initial pages were written. And Jennifer Hodgdon is already working on a book for Drupal 8 development. Dries pointed out that there are now about 50 or so books on Drupal 7, and that things are still changing enough it’s still too early for publication of Drupal 8 books, but that we can expect a variety of books on Drupal 8 soon after its release. The API documentation and other Drupal 8 usage documentation is in various stages of completion. xjm pointed out that we need help with the documentation on drupal.org and that this is a great way to get involved.

Q: “What is being done or can be done to help bring funding to Drupal development?” (heavily paraphrased)

Rudi van Es of the local Amsterdam Drupal community

Rudi van Es, an Amsterdam-based member of the local Drupal shop, limongroen, came with this question.

Dries indicated that the Drupal Association can sometimes help find parties who would also benefit from certain development to help find funding for some projects, but that this is part of what Large Scale Drupal is working to accomplish and that maybe we also need a “Small Scale Drupal” to work more directly with individual developers. Some of the funding that has already come out of Large Scale Drupal went into improving workflows for media and publishing companies on Drupal; this effort has been added to the Workbench project. Dries also reminded us of his keynote, where he discussed better incentivizing contribution. And some organizations might be more willing or able to donate than actual time and expertise to Drupal development. Dries acknowledged that there are limits to the number of companies who are actively funding Drupal projects and initiatives and this is one of the challenges facing the community. While Wikipedia has been able to successfully crowdfund, they have a unique advantage in being able to directly access the end users; Drupal end-users are largely unaware of Drupal.

Q: Is it possible for us to reach a point where we can remove the trouble of upgrading and Drupal is just Drupal, regardless of version number?

Matt Smith, aka smithworx on Drupal.orgThat question came from Matt Smith of Lingotek, who asked a question I have asked before; a tough question. catch started by discussing what they have planned for Drupal releases now, which is already a huge improvement, that Drupal 8.1.0 and 8.2.0 can bring new functional improvements without breaking the API and that by growing slowly, they can minimize the API breakage needed when when it finally is necessary, to re-think a way of doing something and that would be the point we move to 9.x development. We might not be able to avoid breaking the API, because avoiding this can put us in a place the we have to deal with stagnation, but we will make our best efforts to minimize this going forward and it may be that in the beginning of Drupal 9, modules that have worked with each progressive minor version will, mostly not be broken by the initial changes in Drupal 9. As the architecture becomes closer to ideal, we should be able to greatly improve this, as we move forward. xjm added that the release cycle they have adopted now is like Ubuntu and there will be long-term support for some releases.

The final question taken was about tools. In short, the question was…

Q: What development tools are you (core committers) using to manage your work?

That guy again... asking the third questionThis question came, again, from the same fellow (sorry, I didn’t quite get your name), who asked “stable release date”, and the “Isn’t the big, new code complicated and scary?” questions. As the code-base becomes more and more complex, people who used to simply work with a text editor are finding it harder to manage and more and more developers are using IDEs, in particular PHPStorm, which this guy felt seems to be so prevalent now as to be almost a “soft requirement” for Drupal development.

Here, Dries suggested each of the panelists provide a quick answer about their preferred editors of choice and then wrap up the session: xjm started by saying she still mostly uses Emacs, but has started “tasting the forbidden fruit of an IDE in the form of PHPStorm” and said that without 16 years of using Emacs, it wouldn’t be a tough decision. It does make your development life a bit more sane. Gábor said that he has adopted PHPStorm. catch said that he’s still using Vim and holding out as long as he can, but will probably give in at some point and start using PHPStorm. There was brief discussion then, about fear that if everyone adopts a commercial product like PHPStorm, that this could lead to JetBrains taking advantage of us with monopolistic behavior. (Personally, I'm not worried and have respect for the offer they continue to honor: free licenses for open-source contributors.) Moving back to the panel, Alex Pott confessed that he uses PHPStorm. yched also uses PHPStorm and added that it really just makes navigating a large object-oriented codebase so much simpler; navigating between the classes, implementations, overrides, and so on. Wim Leers said that he continued to use text editors until a few months ago and has now also started using PHPStorm. Dries joked that he uses email, then confessed that he doesn’t get to code that much these days, so shouldn’t be taken as a reference, but still uses vi when he needs to make some quick changes.

Final thoughts…

It may be late in the game, but it’s a good time to help with the final work to get all the biggest bugs resolved so that Drupal 8 can be considered stable. There are lots of way to help, from identifying issues (beta testing or areas where documentation is lacking, etc), to simply verifying that bugfixes do what they are supposed to do. And there are a lot of nice tools, now, for helping review tickets. If tickets can be reviewed right away, it is more likely they just get finished before they drag on for months, require “re-rolls”, and all those hassles, and many such tickets are not difficult to review. I’m glad I made it to the Drupalcon rather than just watching/listening when I had the time.

And I should probably say that it’s been far too long since I’ve written a Drupal-related blog post here. I’m not going to make excuses: the truth is that I’ve been pretty much inundated with OtherStuff™, including some work on a complex, semi-mature project which only involves Drupal and so stopped having time to contribute, look at much actual Drupal code, or spend much time learning about all the “new things” going on. So I didn’t feel qualified to write about what was going on in the Drupal world. But I came to Cocomore for the Drupal, so I’ll work on reaching a better balance and hope to find time between all the OtherStuff™ to see you again, soon. The sprint Friday and weekend got my Drupal-thirst going again; Randi and I are already looking at a vacation rental for the full week in Barcelona next year (woohoo!), so you can count on it at least not being too long.

Sep 07 2012
Sep 07

Drupal 8 Multilingual Initiative Code Sprint weekend

I took a train from Frankfurt (Germany) down to Munich the Saturday before the DrupalCon. When I joined the Multilingual Sprint on Sunday morning, many of them had already been sprinting for a full day and a number of issues were ready for review, so I dived in, observing the behavior of Drupal 8 before and after applying patches, proof-reading the patches for anything odd (e.g. typos in the documentation), discussing the issues in comments and in IRC with people who were sitting just across the room (other times actually speaking in person). By the end of the day, instead of the dozen or so people that Gábor Hojtsy, the Multilingual Initiative team lead, had expected, there were close to 50 people at the location, some joining us in the work on Multilingual issues, some working on other Drupal 8 tasks, and some who were just arriving in Munich and followed the Tweets to where we were. Luckily, the location rented for the Saturdays and Sundays before and after the DrupalCon week was big enough to accommodate all the extra arrivals.

While on the topic of the venue we used for those weekends, I’d like to personally thank Stephan Luckow and Florian (“Floh”) Klare of the Drupal-Initiative e.V. for all that they did to find a nice place that would still leave us with a budget for food and for their valiant work on stretching the food budget while still serving up excellent fare, in keeping with the fantastic meals we enjoyed the rest of the week. Instead of ordering delivery, they prepared almost everything themselves, including beautiful open-face sandwiches, fruit platters, and lovely grilled specialties at a club we went to where you can barbecue in the Biergarten.

…thanks for the huge help to the local organizers, especially Florian Klare and Stephan Luckow. They helped us manage collecting and spending sponsor money wisely with the Drupal Initiative e.V, prepared great sandwiches and fruit plates for us and even organized a sprinter party night with grill food. It was amazing to work with such helpful and flexible local organizers.
Gábor Hojtsy, September 5, 2012

Luckow and SirFiChi of the Drupal Initiative, organized the location and made us great food!

Since people were “fresh”, I think a lot of work got done on the first weekend and the Monday before the conference (more than 50 people joined us and worked on various core initiatives on Monday in the room we later used for core most conversations at the Sheraton), which also meant that issues were still fresh in our minds while we had days of sessions and conversations, so when we started sprinting again on Friday we had lots of new ideas for the tasks we were still working on. Friday’s sprints were at the Westin Grand, where there was great attendance both upstairs in the main room as well as a large room downstairs from it, where Drupalize.me hosted a core contribution workshop to ease people into the process of contributing to core. I decided to go to that workshop since I’m still pretty new to it all and found a few people sitting nearby who were I was also able to interest in some Multilingual tasks, so while the main group sprinted upstairs, we also worked downstairs. Later on, I came upstairs, and since there were not a lot of simpler tasks for “core newbies”, like myself, I took some time to sprint on a module I contributed some time back, before there was much of anything for Drupal 7 in the area of “multilingual”… and tried to make my module more multilingual-friendly. I got a few good commits and a new release out for Internal Links and also recruited a colleague to look at the code with me, provide some ideas, and become another maintainer. So I personally found Friday quite productive.

*/ First off, a sprint on this scale would not be possible without sponsors and significant on-site help. DrupalCon provided us with space on Monday and Friday, and some great food on Friday. The rest of the days would not have been doable without comm-press, dotProjects.be, Open8.se, OSINet and Acquia. The [ … ] financial sponsorships they provided paid for our weekend venue [ … ].

I continued sprinting with the Multilingual initiative at the Film Coop Saturday and Sunday, leaving mid-afternoon on Sunday to get back to the train station. When I left the other sprinters, Webchick was only finally getting some rest after her trip home and we had about 20 issues that were marked “RTBC”. In all, there were dozens of issues tackled over the weekend. For a complete overview of all the issues we made progress on, see Gábor’s post about the sprints, where you can also check out his excellent DrupalCon core conversation presentation, “Drupal 8’s Multilingual Wonderland”. There is still a lot to do in the time between now and the “feature freeze” deadline, but we made good progress in the DrupalCon sprints, so hopefully we can push on and get the rest of the critical tasks done in the time remaining.

One of the less trivial tasks I took on during the final sprint weekend was documenting the new language_select field type, which involved checking out the Drupal API (documentation) project, updating the Form API table to include a new Element column (language_select) and Property row (#languages), as well as information about these (below the table) and linking them in all the appropriate places. Currently, updating this page is a bit of a pain, but hopefully we will move to a better system for maintaining this information, perhaps even automated generation. While I’d worked on other Drupal documentation pages before, this was the first time I’d actually contributed patches to update the API, so it was a good learning experience.

If you’d like to help out with the Multilingual initiative or other core contribution, you might first want to take a look at the Drupal 8 Initiatives page, where announcements about coming IRC meeting can be seen. This page also has links to the news, roadmaps, filtered issues, and other pertinent information. Drupalladder.org is also a great place to go for lessons to help you work through the steps of being ready to contribute to Drupal core.

I look forward to seeing you all in IRC and in coming code sprints.

Sep 07 2012
Sep 07

I started writing this post at the DrupalCon and then continued work on it on the train back home after a long week, last Sunday after the code sprints—even now, more than a week later (after being ill for a week—I think I was burning the candle at both ends for a bit too long), it’s hard to believe that it’s finally over. I arrived the weekend before to participate in the pre-con code sprints and stayed for the Friday–Sunday after the conference to continue that effort. I’ll write about the sprints in another post. This one will cover the highlights of the actual DrupalCon, what I think worked well, and recommendations for those attending their first DrupalCon; with two new continents getting a ’con this year, I think there will be more than a few at their first.

The food at DrupalCon Munich was great

For me, one of the major highlights of this conference was the outstanding food quality. It was so good I was distracted enough I never pulled out my camera to take photos of i, but it was attractive, gourmet, and delicious and there was something for everyone, even a fantastic salad buffet as well as more desserts than anyone could try… and hot dishes with plenty of options for both vegetarians and omnivores, alike. In the closing plenary, it was revealed that the catering costs for the event were about €352,000 for the 1800+ of us in attendance; not surprising for the quality and abundant variety of fare they served us. Food service tables were put in place in all areas of the conference so that there was no crowding into one area and the same dishes were provided at both the Sheraton and the Westin Grand, which were a few minutes’ walk away from each other. The conference occupied the three conference center floors of the Westin Grand and a few smaller rooms in the Sheraton, which were primarily “core conversations”. One might think I would gorge myself, but most days I had simple salad items, walnuts, and seeds… and gave myself a break before finishing with some fresh fruit and a light mousse from the dessert buffet. Despite the fact that the days were hot and many of the rooms weren’t well conditioned, people were alert and in good spirits and I think the food had more than a bit to do with that.

To continue a moment in the vein of “food”, since I really do think it was notable at this DrupalCon, I hope this reflects some new recognition of the importance of good sustenance when organizing a successful event like this. And I hope that future Drupal events will also place emphasis on food quality. That said, I also think that the community would pull together if we had commercial kitchen space and quality ingredients—we could prepare similar gourmet meals without quite the budget we used for catering at this conference; on the other hand, such a model might work better at one of the large DrupalCamps (a few hundred attendees) than at a huge (North American or European) DrupalCon. Of course preparing our own food would provide another place for people to connect (food preparation and more volunteer service), which I think would offset the downsides (not being able to be someplace else whenever you have “kitchen duty”).

The Venue

munich_olympic-park.jpg

Munich is a beautiful city I’d never really visited before the DrupalCon. Public transportation was not too expensive, but I got to see a bit more of Munich by walking almost everywhere, so my walks back from the pre-conference sprints and out to dinner (beer) in the evening were mostly through parks where I got to see the huge Olympics installation and unusual sights like Munich’s famous river surfing.

Surfers have a man-made wave on the Eichbach

Sessions and participation

Choosing sessions

This was my second time attending a DrupalCon and I decided I wanted to primarily attend the “core conversations” track (with a few exceptions). For those who don’t know, the “core conversations” sessions are where plans for the future of Drupal are presented, discussed, and refined. It’s truly an amazing experience to sit in a room with dozens of top-notch developers as they hash out the architecture for new Drupal features or present the innovations they have already completed. Of course participating in the Drupal 8 (Multilingual initiative) sprints in Barcelona (a couple months ago) and before and after the DrupalCon session days probably also spurred my interest in the areas being covered by other initiatives, but it is definitely an interesting track if you are not sure what to attend. In the past, core conversations were often not fully recorded, another reason I chose to attend this track, but it looks like you can view most core conversations pretty well now, online. If you missed them and are interested in the future of Drupal (i.e. Drupal 8), there are many that you might want to watch.

Volunteering

Another first for me was helping the DrupalCon staff as a volunteer, mostly monitoring the rooms I was in and taking a head-count in mid-session. Other activities of a room monitor included being a bit early and making sure the speakers had everything they needed; I got to loan out a display adapter for one session and was prepared with multiple power adapters if anyone happened to be missing a way to plug in—we also tried to make sure that questions were recorded in session audio (either by having those with questions come to a microphone or the speaker repeating the question). I found volunteering rewarding and I thank Adam Hill, the DrupalCon Munich volunteer coordinator, for being a great guy to work with.

DrupalCon Munich Volunteers

Drupal 8 will be great!

Angie Byron’s current overview of Drupal 8 (aka “”) had not changed a lot since I last saw her similar presentation at the “Developer Days” in Barcelona a couple of months earlier, but it filled the largest session room, so there may have been close to 1,000 in attendance. Some features are more polished, some of the features are not yet written, but are better conceptualized than they were a couple of months ago, but the general ideas are mostly the same so in a presentation providing an overview of Drupal 8, while much has changed, it wasn’t much that affected the presentation. I’ve take the liberty to add a few specifics which were actually covered in separate sessions (sessions which covered each core initiative, for example), just for the sake of brevity and consolidation of information.

Webchick presents an overview of Drupal 8 features and initiatives

One key point that was made by all Drupal 8 core initiative leads is that we are only 3 months away from “Feature freeze” for Drupal 8 (December 1st, 2012), so it’s time to pitch in and try to help get all the great planned features into Drupal 8. All of the major initiatives need help and have areas where they are behind schedule as far as being ready for the freeze deadline with all the features the community would like to have in core.

Key Drupal 8 initiatives and components

- This finally ends the problem of having an evolving set of configuration on the development/staging sites which needs to be moved to production… but can’t be since the configuration (in Drupal 6 and 7) tends to be all over the place. Having a set of YAML documents stored in your sites “files” directory is a good way to manage and deploy common patterns to multiple sites, update configuration on production sites, etc. And it gets around the issue that pushing a database update from a development/staging server to production might overwrite actual content. So we now have a working configuration management system based on YAML files and a developers’ API, but no user interface for adjusting configurations; the UI still needs to be written. We also need ways to determine if configuration has been changed on the production server, have a range of multilingual configuration issues to still resolve, and performance issues, among other outstanding tasks. Join the #drupal-cmi IRC channel during the CMI meeting times and work on the issue queue if you want to help get the CMI full-featured for Drupal 8. Most active work is in the CMI sandbox repository.

deals with helping sort out inconsistencies and inflexibility in the core blocks functionality. It’s been described as, “Like panels in core, only better”… well at least that’s the goal. Everything on a page has context and is a block or layout/nested layout. Since blocks are rendered independently, caching is well-supported. A responsive layout designer from Spark can allow you to figure out your layouts for different screen sizes without a ton of divs complicating their HTML. If you would like to help with improving Drupal 8 layouts, there are office hours every Friday in Drupal IRC in the #drupal-scotch channel and you can read more about their current issues by looking at the “sandbox” project for the Drupal 8 Blocks and Layouts Everywhere initiative (it is not yet in the 8.x master branch of Drupal).

features will be in core and better than ever before. Interface translation, content translation, base language functionality and language configuration are all being greatly simplified so that it can all be in core with a nice, normal workflow. A lot of the real “pain points” with multilingual sites (or even simply non-English ones) have already been addressed and there is a ton that’s been done, but there is still a lot more to complete in the next three months if we want to really consider this a success. A lot of great progress was made during the code sprints before and after the conference. If you would like to help improve the Multilingual workflow in Drupal 8, there are lots of ways for anyone new to Drupal core development to still pitch in. There many open issues and many ways to move them forward without even writing a single patch. The best place to find active issues is probably to look at Gábor Hojtsy’s “focus issues” list. You can join the Drupal Multilingual initiative meetings in IRC (#drupal-i18n). See the meeting schedule on the main Drupal 8 initiatives’ help page.

is one of the biggest initiatives in terms of importance to Drupal 8’s success… ensuring that a site is responsive to the display size and has toolbars which nicely resize for device type is one of the major aspects of this work. We need good front-end performance for running on smaller, lower-powered devices; we need good, solid, clean, uncomplicated HTML5 code, and we need to be able to support easily using Drupal as a back-end for native mobile apps, purely responsive web design, web apps, or anything in between. There are some big parts of this which are not far along yet, so this is a great place for front-end developers and others interested in Drupal 8 mobile experience to get involved. One current obstacle to the Mobile initiative achieving its goals is greater completion of the Web Services initiative (WSCCI) also achieving its goals. Otherwise, John Albin Wilkins, the Mobile initiative project lead indicated two other areas which need a lot of work: front-end performance and the Drupal 8 mobile admin interface, likely designed with Spark’s Responsive Layout Builder. There are regular meetings on IRC (see meeting schedule on the mobile initiative’s official Drupal Groups page) and the Drupal 8 issue queue has a tag for "mobile" so it’s easy to jump in and help make mobile support rock in Drupal 8. You don’t need to be a rocket scientist to help move the issue queue along. As Dries and others have indicated, this might be the primary initiative for determining Drupal’s future success, given current trends.

: One of the highlights of DrupalCon Munich sessions certainly had to be Angie Byron and the Spark team’s presentation of all the awesomeness that comes from the Spark-distribution modules. Spark is only still in “alpha”, but you can already tell how amazing the features are. The idea is that while they design the perfect authoring experience for Drupal 8, the community can use, test, and help to refine the new functionality (in Drupal 7 via the Spark distribution) so that the feature-set will be well-tested and as awesome as possible when Drupal 8 is launched. Spark allows you to simply edit content, in-place (via the Aloha editor used by the Edit module) and also has a number of nice tools for designing responsive layouts, and has a tool palette which pulls out from the side and responsively adapts to the device. The goal is for the editor system to output only clean code without a mess of ugly divs and inline styling… and the editor is already living up to most of that promise. Words don’t really do Spark justice, so rather than take my word, you can try the demo. Note: Since anyone can make changes to the demo site that might be a bit weird, if things are really messed up, you can check back later. And of course reviewing patches in the Spark issue queue and creating new issues, where applicable, can help smooth the way to getting the envisioned “perfect” content authoring experience into Drupal 8.x core.

The Aquia Spark team prepare their presentation at DrupalCon Munich.

: Theming/Templating improvements in Drupal 8 include the use of Twig, a templating system also designed by Fabien Potencier of Symfony. It eliminates PHP from the theming layer for simpler code and removal of many security threats. The work on Twig does figure heavily into some of the initiatives, but is not an official core initiative on its own. Work is being done in a Twig sandbox led by Andreas Sahle of Wunderkraut. If you are interested in helping build this up, you can check out this sandbox and assist with the issues.

: Drupal 7 was released in January 2011, but it took over a year before there were enough of the important contrib modules ready enough for it that Drupal 6 was finally surpassed (in terms of numbers of Drupal 7 installations). Getting Views into core will hopefully help boost the uptake of Drupal 8 use as soon as it’s released. This will be a lot of work and there is a fund to help pay for development time. A lot of Drupal 8 Views features actually already work. Major parts of cTools are now in core. There is a funding request for getting Views into core (I threw 10 € into the donation box at the DrupalCamp in Barcelona), and the more we can donate, the more the Views team can allocate paid developer time to ensure that Drupal has a nice version of Views available when it ships. Of course you can also help with the Views for Drupal 8.x issues.

in core (only better). There is still a lot to do, but the idea is that the site can take any kind of request and send appropriate responses without a lot of headache. A lot of Symfony components being brought into Drupal are especially important here. Symfony integration helps bridge a gap between ours and the also-dynamic PHP-based developer community around Symfony, so should help provide a lot more experienced developers for Drupal. There is still a lot to do here; you can check out the current status via the WSCCI sandbox and help with the issue queue. See the core initiatives overview page for IRC meeting times and details. If you weren’t there for Larry Garfield’s Munich presentation, Web Services and Symfony Core Initiative, you can still watch it to get a good overview.

Automated testing in Drupal 8 is much faster and the Symfony components also help allow us to have more modular modules… ones which can more easily be unit-tested. In Drupal 8, PHPUnit will replace Simpletest although the latter may remain in core for a transition period.

The social side of the DrupalCon

What happens between sessions is the real reason that most of us go to DrupalCons. There is nothing quite like participating in code sprints with Webchick sitting across the room, committing the patches you’ve just been helping with. And of course you can take your favorite Drupal developer out for a beer or something. It’s great to be in an atmosphere where there are thousands of people who actually have an idea what you are talking about when you tell them your occupation—and of course it’s nice, for a change, to be able to leave out any explanation of Drupal. If you go to a DrupalCon, it’s a given that you will leave having made new friends—new friends who will feel a bit more like “old friends” the next time you see them.

More DrupalCons in the coming year than ever before

If you have never been to a DrupalCon, there are more DrupalCons coming in the next year than we’ve ever had in a year period, before. Granted, the two new (Australia / South America) cons are planned as smaller events that would actually be dwarfed by some of the larger DrupalCamps, but this is all a sign that Drupal is growing, world-wide. Note that the U.S. and European DrupalCons are both being held a bit later than in previous years. I look forward to seeing you all at a coming DrupalCon.

Jun 19 2012
Jun 19

It’s been a busy past several days in Barcelona (for the Drupal Developer Days) and most of us who’d been sprinting during the week before seemed to be in the same condition by Sunday—rapidly running out of energy from progressive sleep deprivation from an increasingly later return to our hotels. But it’s been an exciting week for Drupal core (and contrib) development and significant work has been completed on the Drupal core (mostly building up Drupal 8, but also some for added features in Drupal 7) while a lot of important decisions have been made which will likely shape development in a number of initiatives for the coming months until the sprints at DrupalCon Munich.

In addition to the Sprint I was primarily involved in (I was just trying to get my feet wet with assisting the Drupal 8 core development process by joining the multilingual sprint, but I did write my first committed core patch—admittedly this was a very basic patch), there were also sprints running for “Views in core”, Entity API, Media initiative, Mapping in Drupal 7, configuration management, abstracting social networking, search-related sprints, the Drupal.org upgrade… and possibly more still. I’ll cover some of the highlights of the week that I’m most knowledgeable about.

Multilingual Initiative

The multilingual initiative sprinted all week before the Developer Days sessions, and even continued through the weekend. And a lot of key decisions were made and important code changes committed and pushed to the central Drupal 8.x repository.

New user interface translation improvements in Drupal 8

This is something I got to do a bit with, but Swiss developer, Michael Schmid (Schnitzel on d.o), of Amazee Labs, was the primary developer working on this task during the Sprint. He and his colleague, Vasi Chindris, were among the stars of the week. It was a real privilege to get to look over their shoulders and to get Michael’s support when it came to using Git to manage code in the sandbox we were using for the issue. (Thank you, once again, Michael!) Once everyone was happy with the work, it got committed to core. This new sandbox workflow, used for larger issues, helps avoid a lot of bugs creeping into the main branch, as has happened during previous periods of intense core development. Of course the tests and test bots catch a lot of issues which could otherwise be major headaches for all concerned (automated testing was also a part of Drupal 7 development). If you recall, the long wait for Drupal 7’s release was due to hundreds of critical bugs. Now this should be a thing of the past since we have an established threshold for critical issues; and the core team only commit new patches to the central repository when we are below that threshold (15 “critical” bugs, 100 “major” bugs… among other thresholds specified).

New system for translating Drupal’s user interface

The new user interface translation system allows you to keep imported (community contributed) translations separate from customized translations and search for a particular translation within either or both categories as well as filter by translated strings, untranslated strings, or both. If you have any unsaved translations, they are highlighted to help remind you not to leave the page without saving them and there discussion about providing a dialogue to prevent a site admin from accidentally leaving the page with unsaved changes, too. There is also an issue to allow the string search to be non-case-sensitive (checkbox) to find more strings that contain a particular word or phrase, regardless of text case. Since this feature came up in discussion after the rest of the user-interface changes had already been made, we elected to put the discussion about adding this feature in a separate issue. If you have ideas for what might further improve the Drupal 8 user-interface translation workflow, your input is valued.Customized and imported (community) translations are stored separately

*/

New content language options

Drupal 8 has new language settings per content typeYou can enable translation for a particular content type and also choose to hide the language selector (automatically selecting the language for a new piece of content by any of a number of contextual rules). The automatically selected language for a new piece of content can be any particular language enabled on your site, “not specified”, “not applicable”, “multiple”, the “site’s default language”, the “current interface language”, or the “author’s preferred language”. While all these settings might arguably be a bit confusing for new users, they should help smooth the content creation and translation workflow for most sites. Of course the option to “enable translation” is hidden if the default language for the content type cannot be resolved to a single language (i.e. for “not specified”, “not applicable”, or “multiple”), since translation does not make sense here.

Translate the English UI to… English!

Drupal 8 — Enable English UI translationIn the edit preferences for the English language, you can enable translation to English and then it’s easy to change, for instance, the “Log out” link to “Sign out” (or “Disembark”, “Abandon ship”, “Terminate session” or anything else you might want on a particular site). Of course this could also be useful for fixing any oddities you find in the UI strings provided by contributed modules if you find a mistake in a field description, for instance, you don’t need to wait for a module developer to commit your patch or add a “site English” custom language just to modify a few strings.

Configuration Management related to Multilingual sites

Drupal core team leads and other sprinters discussed multilanguage configuration

One of the biggest issues of the week was determining how multilingual configuration would be handled in Drupal 8. The core team knew that they wanted to store language configuration in files rather than in the database, so that it’s easy to “push” new language configurations to an established site that already has content, among other benefits of this approach. But this brought with it a number of challenges which the Multilingual Initiative team, Configuration Management Initiative team, and other interested parties discussed in several sprint discussions through the week. Many of the standard configurations for a site might also differ, depending on the language: you might, for example, want a different site name or site slogan or logo for each language. There were three different proposals for how to handle multilingual configuration, and to keep a long story short, the final decision was to go with “Plan B” (or a minor variant, thereof). You can still lend your voice to the “review” process in the main issue for the language configuration system in Drupal 8. If you would like an overview of the plans, there is a nice graphic by Gábor Hojtsy (the Multilingual Team lead) which outlines the differences between the three proposals and some variants.

Drupal 8 Configuration Management

Greg Dunlap (“heyrocker” on drupal.org) presented the new configuration management

Angie Byron, aka “webchick” gave a quick overview of the configuration management initiatives goals, tooOne great session from the weekend was the Introduction to the Drupal 8 Configuration Managment System by Greg Dunlap (“heyrocker” on Drupal.org), the Configuration Management Initiative team lead. There has been some good progress in determining what this is going to look like, some of which took place during the sprints in Barcelona. Basically, this will be a bunch of smaller files stored within a logical directory structure in the sites/[…]/files directory. The new configuration system is currently planned to be YAML-based (rather than PHP or XML, which were used in earlier visualizations of the system). And the goal, as described by a slide in Angie Byron’s Sunday-morning keynote, “Drupal 8: What you need to know” is to be like “Features in core, only better”. The aim is to help us remove the complications involved in pushing configuration changes, modified in a development or staging environment, to a site that already has user-created content that we don’t want to lose. The main problem with the current system is that there is no consistent system: configuration settings are scattered across multiple tables, variables, files, and other locations and there is no consistent structure in any case. The idea is now to have a contexts, which Drupal responds to, when determining which configurations files to use.

Angela Byron (“webchick”) talks about the problems the new configuration management system aims to solve

What it should look like when loading a configuration from module code, is something like this:

  $config = config('image.style.large.yml';
  $config->get('effects.image_scale_480_480_1.data');

And when setting and saving configuration data:

  $config = config('system.performance');
  $config->set('cache', $form_state['values']['cache']);
  $config->save();

The YAML code for the image example, which saves configuration for the “large” image style would look something like this:

  name: large
  effects:
    image_scale_480_480_1:
      name: image_scale
      data:
          width: '480'
          height: '480'
          upscale: '1'
      weight: '0'
      ieid: image_scale_480_480_1

This should be pretty easy for developers and site builders to learn to work with and of course an interface is planned which should automatically build the configuration files, when edited by site builders. Configurations will be loaded into the “active store”. Changes are saved back to the active store and back to the YAML files so they can easily be moved between sites (staging and production sites, or completely different sites if they should have some settings in common). Building up an ideal import/export system for configurations is one of the major remaining hurdles. Update: heyrocker’s presentation slides are now available for download, so you can see other examples of Drupal 8 configuration.

Other Drupal 8 news

Twig library committed to core!

Drupal 8 now has Twig in the core/vendor directoryOne of the new developments which has received some press is that Twig, the templating system designed by Fabien Potencier, the innovator behind Symfony, which also bundles Twig, has now been added to the Drupal core repository.

However, the fact that the Twig library is in the repository does not mean that it’s ready for any kind of use yet, except for those who are working to build a new templating engine for Drupal, which uses it. How this works is still open to discussion; according to webchick, it may be that we keep both PHP-based and Twig-based templating engines to ease the pain of this change. On the other hand, while there is a learning curve involved, there are many advantages to Twig, especially in terms of security (removing PHP vulnerabilities from themes, altogether), and the saying that “the drop is always moving” applies here. It may be that Twig is the only templating engine which will be supported by Drupal 8, but if you feel strongly about this or have ideas for how to do this “right”, it’s a good time to get involved.Twig vs PHP template syntax

Context-based layout and blocks

Angela Byron lays out the plan for Drupal 8 layout with contexts

Everything in Drupal 8 will be a block or a layout area and blocks can have multiple contexts which determine their behavior (and whether or not they are displayed). This is going to be a major change which should produce much more flexible layouts and site designs. Of course this will touch on every major Drupal initiative: configuration, HTML5, mobile, multilingual… all are involved.

Drupal 8 will have clean, semantic HTML5 (and will abandon IE)!

Say goodbye to the messy nested div hell! Drupal 8 code is going to be much smaller and cleaner which will make designer/themer types love Drupal and make it possible to produce code that renders nicely, regardless of display size. Oh, and don’t worry about trying to support older versions of Internet Explorer; the community has decided it’s time to put that tiresome task to rest. Yay!

Drupal 8 development needs you!

Webchick, heyrocker, Gábor Hojtsy… all made the same point: As a community effort that’s still underway, the Drupal 8 effort needs more of the community at large to get involved and find ways to help out. There is a lot of complexity, but there will be smaller tasks that anyone could work on, so there’s going to be something for everyone. Even non-coders can help by testing, filing bug reports, helping manage the issue queues, making suggestions, documenting finished features and APIs. There are several places where you can get involved:

  • The core initiatives overview page provides information about when the different teams meet in IRC and in which channels among other information which can help people who want to find ways to get involved.
  • Drupal Ladder is a project aimed at helping more people learn how to contribute to Drupal
  • [ … ] (Comment below if you have other tips for where to get involved)

Big thanks to the organizers, sprint leads, and session speakers

The Drupal Developer Days in Barcelona were a big success because of all of you pulling together to make things happen. The local organizers made us all feel welcome and provided a lovely venue and took us out on the town just about every night. The sprint leaders helped find ways for everyone to play a part in building Drupal 8 or contributing in other ways, and the sessions were awesome.

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web