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.

Jun 14 2012
Jun 14
Morning stand-up meeting at the Drupal 8 Multilingual Sprint

I was supposed to get into Barcelona at 10:30PM on Tuesday evening, but with delays in my flight, it wasn’t till after midnight that our plane landed; it was after 1 a.m. by the time I reached my hotel. Normally travel, when it runs late and long, makes me feel exhausted, but I was excited to be joining my first Drupal core sprint. I’ve been wanting to do a bit more to help build Drupal and it’s great to not only be somewhat aware of what’s coming in Drupal 8, but to also know that I’ve at least played a small part in making it happen.

I wasn’t sure I would attend the Drupal Dev Days in Barcelona till a couple of weeks ago, but I’m glad I’m here. We have a fairly sizable group of developers here at the Citilab helping work on cutting through the issues for Drupal 8 Multilingual Initiative (D8MI). I’ve been helping with some user interface quirks and since it had been long enough since I’d actually done string translations of the user interface, I started out yesterday as a “tester”… at least trying to look at the problem of translating the interface (e.g. translating “Add content” to German) as if I had never done anything like that before. And we did find some issues and, even better, we were able to address and correct those issues during yesterday’s coding. Others have been working on multilingual issues related to the new configuration management system, and a number of other issues which you, too, can help with, if you’d like to join us remotely (or in person, if you happen to already be in Barcelona — the Sprints continue through Friday, too). There are currently about 40 of us in the IRC channel for i18n and I'd say that at least half of those are working on the Sprint. There are about a dozen (give or take, since people are working on other sprints, too) who are here in Barcelona working on D8MI.

You can help make Drupal 8 better, too!

Jump on IRC (#drupal-i18n) and look at the focus issues for Drupal 8 Multilingual Initiative if you’d like to join use remotely. There is a lot going on right now and it’s not all on Multilingual issues, so if you have some time, I’d like to encourage others to join me in helping ease the burden on the few who do so much and at least do a small bit to make Drupal 8 as awesome as it can be.

Feb 02 2012
Feb 02

Posted Feb 2, 2012 // 0 comments

Well, it's been a few weeks since the 1st of the year, so of course most of us are either dreading or hoping for the question: "How are you doing with your New Year's resolution?" Today, I'm excited to report on one of mine!

At Phase2, we made a New Year's resolution for community management around our products: to increase the amount of documentation we have for OpenPublic, OpenPublish, and Open Atrium. In November and December, we added documentation on section fronts and boxes for OpenPublish and provided information on our Omega-based responsive design themes in both OpenPublic and OpenPublish.

While I'm pleased that we have increased the amount of information available about our products, we want to work hard this year to add more to what we already have. I have taken both the suggestions I have received from the community as well as used my knowledge of what is in each product to create a plan of what documentation we should add. And thanks to members in the community, some of this documentation has already been written!

We will add the following documentation for OpenPublic:

  • Introduction to OpenPublic
  • Documenting the inclusion of security standards (functionality coming soon!)
  • How to add a media gallery node in OpenPublic content
  • Detailed overview of apps that are included in OpenPublic and how to configure them
  • List of Features specific to OpenPublic
  • Accessibility in OpenPublic
  • Upgrade path

We will add the following documentation for OpenPublish:

  • Product tour
  • Explanation of users and pre-defined roles
  • How to configure your site using OpenPublish
  • More details about content
    • Content types 
    • Images
    • Multimedia Content 
    • Relating Content
    • Features specific to OpenPublish
  • Detailing site structure and sections
    • Themes and Regions
    • Taxonomy Basics
  • Translation
  • FAQs
  • Detailed overview of apps that are included in OpenPublish and how to configure them
  • Documenting our new magazine theme (theme coming soon!)

We will add the following documentation for Open Atrium:

  • How to set up content for anonymous users 
  • Limiting the number of items in the Recent Activity feed
  • How to hide a default page in the notebook
  • Creating a new content type for a calendar 
  • Preventing iCal imports from duplicating
  • Theming
  • Translation
  • Adding icons
  • Creating minisites using Atrium

While it looks like a lot, I know we can get it done! We have had several community members contribute to our documentation already and, as you know, I always encourage you to get involved!  We have a documentation wiki for OpenPublish and a documentation wiki for OpenPublic. All you have to do is visit the wiki, sign up for an account if you don't have one already, and you can start creating and editing pages.; We also have our community.openatrium.com site that allows you to create and edit pages once you have a log in. Additionally, if you have other ideas, please feel free to share them in the OpenPublic Drupal.org group, the OpenPublish Drupal.org group, or on community.openatrium.com

I look forward to a year when I can say that I have met my New Year's resolution! I can't wait to work with all of you to make it possible!

As our Community Manager, Danielle is responsible for the communities around our products, which include OpenPublic, OpenPublish, Open Atrium, Managing News, and Tattler, as well as the Drupal modules we maintain.  She is also ...

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