Planet Drupal

Going from static design files to a completed Drupal theme can be a daunting task. I often get asked "strategic" questions by companies who are looking to hire a designer/themer for an upcoming redesign and aren't quite sure what skills they should be looking for. And I often get asked by new-to-Drupal designers how they should approach the task of transforming their design into a Drupal theme. In these conversations the following question (almost) always comes up:

Should I create a static HTML page of my design and convert that into a Drupal theme?

Can you guess what my answer is?

Five years ago, when I was first writing Front End Drupal, the answer would have been "Yes!" Five years ago there were fewer moving parts to creating a Drupal theme. There were fewer contributed modules. Responsive design wasn't even an idea yet. Five years ago I don't think that "mobile" was even a thought for most businesses, let alone a concern.

But today, in 2013, my answer has definitely changed. Now when asked if people should create a static HTML page of their design before converting it into a Drupal theme, my answer is "No!" In fact, depending on your budget size for the entire build and the type of site you're building, you may actually want to skip "static" design files for each layout (and layout variant if you're building a responsive site) and have your designer supplement their work by creating "style tiles" instead of piles and piles of page-specific layouts.

Designing for a style, instead of a specific layout, is a different workflow though. You'll need to have a relatively experienced content strategist, designer *and* themer to help you navigate this workflow for theming Drupal. Pixel precise designers are much easier to find. But here's the problem with pixel perfect design: it relies on exact markup. Drupal is markup-heavy and can drive a themer crazy if every single tag, and every single class must be exactly perfect. These days, it's easier to skip the "static" step and get into Drupal as fast as possible. Sure, you'll still want to refactor some markup (or maybe just start with a different base theme), but the point is that you aren't starting from thin air.

Themers who want markup purity tend to be coming at their work from an Model-View-Controller (MVC) perspective...which isn't what Drupal does. We're a Presentation-abstraction-control (PAC) framework. The main difference between the two (in laymen's terms) is the fragmentation of the output/markup files. Our system has lots of little nested template fragements which are compiled, or collected, into a whole. This means if you want very, very precise markup, you have to alter a lot of little files. Some of us love it because you can get really fine grained control in very tiny places without having to touch all of the markup, others hate it for exactly the same reason.

Regardless of which camp you're in, there doesn't seem to be a lot of information about building themes that talk about these software design patterns. A quick search reveals the following tutorials and articles (most are quite old). If you've got others you'd like to add to the pile, please leave them in the comments. Things get very technical very quickly...but hey, this is a list of links about software design patterns. It's supposed to be technical.

• MVC vs. PAC (from Crell in 2006!)
• Building a site on Drupal using MVC
• Drupal as an MVC Framework (the difficulties of integrating Zend + Drupal)
• An Object-Oriented Approach for Drupal Module Development (or how you will go slowly crazy if you try to treat Drupal like an MVC framework)
• A pretty awesome description of the MVC pattern and how module developers can take advantage of it (when it's appropriate): MVCZ: Model, View, Controller, and Zombies.
• (Software) Design Patterns of Drupal

As web applications become richer and more complicated the amount of JavaScript running them increases. More code means longer download times which means more waiting before your application or web site is usable. Thankfully there’s an easy solution that’s already widely used in the web development community: minification. Minified JavaScript strips whitespace and renames variables to produce a smaller download size.

Removing whitespace is pretty straightforward, but renaming variables is a more abstract concept. With tools like UglifyJS this is handled for you but here’s an example of what’s going on. Let’s look at this simple function that takes a parameter and alerts a message with that variable:

var sayHi = function(name) { alert('Hi ' + name + '!'); };

With script minification the above code will be changed to this:

var sayHi=function(a){alert("Hi "+a+"!")};

without altering the behavior of the function. As you can see, all whitespace that can be removed has been and the variable “name” was changed to “a”. The end result is the removal of 26 characters from the code. It’s not hard to see that the savings from minification will quickly add up!

You can take this one step further by wrapping your code in immediately-invoked function expressions (IIFEs). That’s a pretty scary looking name, but chances are you’ve seen these before, this is an example:

(function($) { $('h1').css('text-decoration', 'blink'); }(jQuery));

The function wrapped in parentheses is immediately invoked with jQuery as its argument. Within the function jQuery is accessed with the $ variable. Abstracting variables in IIFEs is not required though, consider this case:

(function(Drupal) { Drupal.behaviors.sayHi = { attach: function(name) { alert('Hi ' + name + '!'); } }; }(Drupal));

Minifying this code produces the following:

(function(a){a.behaviors.sayHi={attach:function(a){alert("Hi "+a+"!")}}})(Drupal);

Keeping the “Drupal” variable in your script makes sense because that’s the namespace you’re used to accessing it with and it does have meaning in the code, but by including it as an argument to the IIFE UglifyJS will replace any instances of “Drupal” with a shortened variable.

What about Drupal?

So, this is pretty cool, right? Unfortunately Drupal 7 doesn’t provide minification out of the box. Thankfully, there are contrib solutions to this problem! The Speedy module provides pre-minified scripts but unfortunately needs to be re-released every time core is updated or you need to re-minify the files yourself on core updates.

I wasn’t completely satisfied with this approach so I built uglify.me and a companion Drupal module, UglifyJS, to do script minification on the fly. uglify.me isn’t the only “minifier-as-a-service” out there, but I wanted to be able to throw something up quickly and be fairly confident that it wouldn’t upset some other poor developer out there hosting their own service.

The uglify.me service accepts POST requests of un-minified JavaScript and returns the minified version. Simple! The UglifyJS module provides an API to expose Drupal scripts that should be minified:

/** * Implements hook_uglifyjs_info(). */ function mymodule_uglifyjs_info() { return array( drupal_get_path('module', 'mymodule') . '/js/mymodule.js', ); }

The downside to this approach is that each script will create another request to the uglify.me service when the site cache is cold. If you expose a lot of scripts to the UglifyJS API this will be time consuming and could cause timeouts.

If you’re running Pressflow 7.20.1+ or apply this patch to core and you have JavaScript concatenation enabled (which you should, if you’re in production) the UglifyJS module will automatically minify the concatenated scripts. This greatly reduces the number of requests to the web service and overhead associated with minification.

Caveats

The biggest issue that I’ve encountered with this module is the requests made to the external web service. If there’s a problem connecting to the remote server the time spent waiting for the response is wasted and can cause timeouts on cold caches. This is mitigated if you’re using Pressflow 7.20.1+ since core will not request files to be rebuilt if the hash of the concatenated scripts did not change.

The uglify.me service also currently strips some header comments from scripts which would could remove any copyright or license information if they exist. This should be fixable from the uglify.me service, so if it’s bothering you and I haven’t had time to fix it before you need it, As of uglify.me v0.1.0 any comment containing the words “license” or “copyright” (case insensitive), or the common build tags “@preserve” and “@cc_on” will not be stripped from the source code. This is controlled by a regular expression so if you find a general case that’s not met by the current regular expression open a pull request to fix it!

Conclusion

Script minification is a great way to reduce your site’s download footprint and increase usability. If bandwidth and performance are concerns you should be minifying, regardless of your ultimate solution. Informal testing on the recently released Full Plate Living site showed reduction in the front page’s download weight by an average of 110KB*. Not monumental, but not too bad either.

Happy minifying!

* Note: The UglifyJS module is not currently in use on the production Full Plate Living site, but it likely will be soon!

Do you love FileMaker? Do you work with (or for!) someone who does? I’m now a Drupal Developer at Mediacurrent, but my last position (at Georgia Tech’s Office of International Education) involved a lot of FileMaker work, and this FileMaker integration would have been a lifesaver, so here goes!

This post is a quick addition to my previous tutorial: Loading Only One Field From An Entity or Node in Drupal 7. The tricky part there was what to do with node's field data and how to properly display it? Well there are lots of approaches there, but I see three which are of “Drupal Way” kind:

Read on about Working with Drupal Fields: Getting Single Field Values For Display and Manipulaton

Hey guys,
I'm going to be putting together a mini-series on Newsletters in Drupal 7. Just about every site can benefit from having a mailing list, so I figured I'd flesh out the options that are available, right now, for Drupal 7. I'm hoping to have someone on the show to talk about each of the following modules.

Tags:  newsletters, planet-drupal

In the 7 video of this 10 part Drupal video tutorial series on the Views module, we look at the Views API and how to integrate a custom module with Views 3 so that we can build views based on our custom content.

The Views API allows you to leverage the awesomeness that is the Views module when you are doing custom Drupal development and so I show you how to link up our database fields to view fields, filters, sorting, arguments and relationships.

Once this is done, I walk you through building another view based on our custom module and again, we take a quick look at using relationships and contextual filters.

Semantic panels is for Panels what Semantic Views is for Views - better control of the markup.

Todays screencast subject is Semantic Panels. If you are new to panels and Page manager, I recomend you to watch Johan Falks screencasts on the suject.

You could also find the screencast at archive.org.

After Drupal 8 feature freeze, I wanted to create some statistics of Drupal core code base evolution.
All the charts are here together in this infographic:

Drupal Code Base | Infographics

Adding the ability to comment on a blog is one way of allowing two-way communication with your readers. If your readers have an opinion or question, they'll simply leave a comment on your blog post. If you want to keep comments "clean" and without spam, you'll have to manually approve them. Of course, there are services like Mollom and Akismet that do a great job with filtering spam but some still get through.

Drupal's default comments administration page is very basic and if you want to review and approval comments you'll have to jump between two pages.

The Better comments administration module allows you to preview, approve and search comments on a single page.

Episode Number:  113 Post Topics:  Drupal Drupal 7 Module Development Drupal Planet Javascript

In the last two episodes, we covered building a basic Drupal 7 module that displayed a JavaScript confirmation before a user leaves a specific page. In this episode we continue where we left off and add the ability to display the JavaScript confirm form on specific content type node edit pages.

In this episode you will learn:

• How to add a checkbox field on the administration form that displays all the content types on your Drupal site
• How to verify you are on the node edit page of a specific content type

DDoD Video: 

read more

Way back at DrupalCon Chicago the local team created a new track called Core Conversations. The purpose of this track was to focus squarely on the interests of core developers and those interested in keeping up with the bleeding edge of Drupal development. Crazy ideas and wild rants were encouraged, as long as they were focused and discussion and finding solutions. Since then Core Conversations have been a part of every DrupalCon.

Within our company we use Drush and Drush alias files a lot. Recently I wrote a company blog post (in Dutch) about the workflow we’ve set-up and this post is its English translation. For those of you not familiar with Drush, I’ll start with a short introduction. If you are already familiar with Drush and Drush alias files, you can skip to the interesting part.

What is Drush?

A lot of Drupal developers use Drush (Drupal Shell) to speed-up their daily processes. After you’ve install Drush locally, you can run tasks on the command-line which you would normally run via the interface. Here are some often used commands:

• drush cc all: clear all Drupal caches
• drush fra: revert all features
• drush upwd Baris –password=”test”: change the password of user Baris to ‘test’
• drush sql-dump > dump.sql: export the current database to a file
• drush sqlc < dump.sql: import an exported database-dump

It is quite easy to create custom drush commands for task that you need often in your daily work. Many contrib modules come with their own drush implementation (for example drush search-api-index to index your site content).

What are Drush alias files?

In so-called alias files you describe the server information per website. They contain paths and usernames of all environments of a site (dev, test, staging, live). Here’s an example:

Filename: customer.aliases.drushrc.php. I’ve placed this file in my ‘aliases’ folder within my .drush folder. On Linux you can find it here: ~/.drush/aliases

limoengroen.aliases.drushrc.php $aliases['dev'] = array( 'root' => '/Users/BarisW/Sites/company.com', 'uri' => 'dev.company.com', 'path-aliases' => array( '%dump' => '/tmp/dump-company.sql', '%files' => 'files', ), ); $aliases['test'] = array( 'root' => '/var/www/company-test/htdocs', 'remote-host' => 'webserver1.company.com', 'remote-user' => 'username-test', 'uri' => 'test.company.com', 'path-aliases' => array( '%dump' => '/tmp/dump-company.sql', '%files' => 'files', ), ); $aliases['prod'] = array( 'root' => '/var/www/company-prod/htdocs', 'remote-host' => 'webserver2.company.com', 'remote-user' => 'username-prod', 'uri' => 'www.company.com', 'path-aliases' => array( '%dump' => '/tmp/dump-company.sql', '%files' => 'files', ), );

The main advantage of using alias files is that you can use them to run all the drush commands on external servers. To be able to do this you need SSH access to the external server and that Drush is installed on the external server as well. If you don’t want to enter your password each time you run an external Drush command, you can also add your SSH key to the external server.

Using these alias files I can now simple run a command like this to clear the caches on the production environment:

drush @company.prod cc all

Or, to copy the production database to my local machine:

drush sql-sync @company.prod @company.dev

Ideal! Optionally, Drush sql-sync can also sanitize the data (to obscure all e-mails and passwords). This prevents developers to store sensitive customer data on their laptops.

drush sql-sync @company.prod @company.dev --sanitize How to use Drush alias files in teams?

Extremely handy, but each developer had to enter all the settings from the various local environments in their alias files. The solution we found for this is simple and very effective: Dropbox / SparkleShare or similar.

We created a folder in Dropbox that contains all alias files. We symlinked the alias directory in ~/.drush/aliases to that folder. In this way, each team member always uses the correct data for all the project environments. You can also use these same alias files for your Continuous Integration environment (we re-use them also for our automated deployments using Jenkins).

To be able to do so we had to change one setting: instead of the ‘dev’ alias we use the names of our employees (because each employee runs his local environment somewhere else). So in my case it is now:

drush sql-sync @company.prod @company.baris Bonus tip: alias files inheritance

The real fun starts when you start using inheritance within your alias files. For example; we use a ‘localdev’ alias for all local environments:

defaults.aliases.drushrc.php $aliases['localdev'] = array( 'target-command-specific' => array( 'sql-sync' => array( 'sanitize' => TRUE, 'confirm-sanitizations' => TRUE, 'no-ordered-dump' => TRUE, 'no-cache' => TRUE, 'enable' => array( 'devel', 'stage_file_proxy', 'ds_ui', 'fields_ui', 'views_ui', ), ), ), ); customer.aliases.drushrc.php $aliases['localdev'] = array( 'parent' => '@defaults.localdev', 'uri' => 'dev.company.com', 'path-aliases' => array( '%dump' => '/tmp/company-dump.sql', '%files' => 'files', ), ); $aliases['baris'] = array( 'parent' => '@company.localdev', 'root' => '/Users/BarisW/Sites/company.com', ); $aliases['eric'] = array( 'parent' => '@company.localdev', 'root' => '/Users/EricM/Sites/dev.company.com', );

This setup ensures that every sql-sync is automatically sanitized, and that a number of dev modules are enabled that are turned off on the live environment (like the devel module).

PS: to use the 'enable' command, you need to copy the sync_enable.drush.inc file from your drush installation folder to your ~/.drush folder.

How do you use Drush alias files in your team? Please share your tips in the comments!

Tags:  Drupal Deployment drush DTAP commands Planet Drupal

Drupal 7.20, a maintenance release which contains fixes for security vulnerabilities, is now available for download. See the Drupal 7.20 release notes for further information.

Download Drupal 7.20

Upgrading your existing Drupal 7 sites is strongly recommended. There are no new features or non-security-related bug fixes in this release. For more information about the Drupal 7.x release series, consult the Drupal 7.0 release announcement.

Security information

We have a security announcement mailing list and a history of all security advisories, as well as an RSS feed with the most recent security advisories. We strongly advise Drupal administrators to sign up for the list.

Drupal 7 includes the built-in Update Manager module, which informs you about important updates to your modules and themes.

Bug reports

Drupal 7.x is being maintained, so given enough bug fixes (not just bug reports), more maintenance releases will be made available, according to our monthly release cycle.

Changelog

Drupal 7.20 is a security release only. For more details, see the 7.20 release notes.

A complete list of all bug fixes in the stable 7.x branch can be found in the git commit log.

Security vulnerabilities

Drupal 7.20 was released in response to the discovery of security vulnerabilities. Details can be found in the official security advisory:

• SA-CORE-2013-002

To fix the security problems, please upgrade to Drupal 7.20.

Known issues

None.

It's hard to believe that we're closing in on a year since DrupalCon Denver. It seems like only yesterday that I was loading up on shwag and excitedly talking Drupal to a bunch of amazing and passionate people. And now we get to relive the fun and joy of another North American DrupalCon in a few short months over in the city that is stuck in the Nineties.

In addition to our flannel and neon green fannypacks, we're also bringing a case of proposed sessions. We'd love to crack these open and pass them around to everyone at DrupalCon. Enough with the extended metaphors though. Here's the quick and dirty on what we hope to share with everyone.

Oh, and if any of these stand out as sessions you'd like to attend, then leave a friendly comment on the session page letting the presenter(s) know. Comments are also a great way to contact us ahead of time to swap ideas, and get more information on what the session is all about.

Adaptive Content in Drupal

It's been exciting to see how much attention is being given to the way we structure content to adapt across platforms and devices. One DrupalCon keynote speaker will be Karen McGrane, who wrote the seminal piece Content Strategy for Mobile. It's a touchstone text for our company as we work with clients during the Information Architecture process to think about the ways their content will live beyond the page and then structure it accordingly. Joel and I see this as a great follow up to Karen's talk- a time to look at the concrete ways we can put the concepts of Adaptive Content into practice.

Interested? Leave a comment

Dapper Drupal- Custom Tailored Themes

Subthemes are great for leveraging the hard work done by a base theme and customize from there. At some point though, you might want to define those fundamental assumptions yourself. We certainly found that to be true and Garrett and John, with all their front-end swag, will share the lessons they've learned from building the base theme Center and its subtheme sidekick Prototype. Expect to see some great tips and at least one pair of very cool boots.

Interested? Leave a comment

Design Smarter, Not Harder

An ever-changing web and the subjective nature of design can make it difficult to carry out a design process that is both flexible and efficient. Ken has some great principles and tools to work from to make this complex dance with the client a graceful one. Learn and share some valuable advice to make sure you're designing smarter, not harder.

Interested? Leave a comment

Javascript in Drupal

It's not always obvious the best way to manage or apply JavaScript with Drupal. Luckily, Rob has some thoughts on the matter. From best practices for Drupal.behaviors to a peek at what's in store for JavaScript and Drupal 8, this session will be covering a lot important bases when it comes to JavaScript in Drupal.

Interested? Leave a comment

Line'em Up and Knock'em Down: Planning and Executing Multiple Projects for Maximum Efficiency and Amazing Results

Every Monday, as we check in with one another on the work we're doing I'm amazed at how much our company is managing simultaneously. The ability to manage multiple projects at a time comes into play in an especially poignant way when a client wants to roll out several related projects together. This approach makes a lot of sense and can be a lot of fun to implement, but can also get ugly quickly. Justin and Jon will share their insights into how to avoid the ugly and deliver those multiple projects like a boss.

Interested? Leave a comment

Making Drupal Meetups and Events Rock

Ever planned a Meetup only to have your mother, an-out-of work clown and your cat Edgar show up? Awkward. Maybe you have a regular meetup, but the villagers are getting restless and you're looking to spice things up. Or maybe you've always wished your town had more going on in the ways of Drupal. Well, if you're interested in planning or improving upon the Drupal events in your neighborhood be sure to check out this panel.

This discussion will feature some great leaders in the Drupal community, including Karyn and Scott. While we all work together, they'll be offering two unique perspectives on this topic. Karyn is a Women in Drupal community leader and Drupal Ladder evangelist, while Scott has been MCing the Denver Drupal Meetup ever since Jason Yee was shipped off to Portland. This is sure to have some interesting and original thoughts batted around when it comes to making Drupal events rock.

Interested? Leave a comment

Standardized Development with Vagrant and Puppet

Oh the time I have lost trying to replicate a problem locally because a site's server is configured differently...If I had that time back I'd be soaking it up in a bubble bath. Anyways, that's what Puppet and Vagrant are here for. No more fiddling with MAMP, WAMP, XAMPP configuration. When you standardize your development environment the angels sing. Get the nitty gritty from Ryan on Virtualizing with Vagrant and Provisioning with Puppet, then go home and get that bath started.

Interested? Leave a comment

Successful Contrib Projects: Some Non-Technical Tips

You don't want to be "that guy/gal" they talk about in IRC with the abandoned project people wish they could use but whose neglect has rendered it obsolete- do you? Do you?!? I didn't think so. There's a lot to know about managing a contrib project beyond the initial code you wrote. Scott will clue you in on how to manage a successful Drupal contrib project in a way that leaves you fulfilled and the people around you happy. That way, when people mention your name in the forums, you'll know it's a good thing.

Interested? Leave a comment

There are currently 69 new Drupal contributors awaiting review of their first project. This is a great place to contribute to the community and learn about interesting upcoming projects, for example...

Module: Webform Event What does it do?

One of the more exciting aspects of working on Project Review Wednesday is getting a quick glance at things that people are working on out in the world. Many modules solve a particular problem, some provide a means to solve a set of issues.

The Webform Event module is a key example of trying to solve a set of problems. Essentially the module provides an event content type, but also signup (or add their name to a queue if the event is full) for the event. Events can be closed by an end date or by a number of participants and the process ties in with several existing modules.

Zoom Look Useful? Review it!

If this sounds like something you'd like to see readily available on Drupal.org, you should review it and help make that happen.

Review It

Pro Tip: If you've never reviewed a project application before, you can find instructions for reviewers on Drupal.org and the Code Review group is happy to help more people get involved.

Drupal community members are supporters of the Drupal Association because they want to support the Drupal project and DA membership is an easy way to do so. When you join or renew, you get more than just good karma, and you give Drupal more than just member funds.

Personal blog tags: MembershipDrupal Association

The blank canvas in Photoshop is where many well-intentioned Web redesign projects go to die.

If you want a beautiful magazine ad, then find a talented graphic designer and have them draw up something pretty for you. If you want a rational redesign, you need to start somewhere else.

As defined in the first part of this series, a rational redesign delivers true value to an organization, instead of simply consuming time and money for window dressing.

A little fun this morning. I had a great talk with Jacob Redding yesterday as part of his academic work on open source communities. We talked a bit about the early times of Drupal, including the heady days in Antwerp in 2005 when the ideas for what was to become CCK and then fields-in-core were being explored, debated, and scrawled on whiteboards. I thought I'd share this creation by Steven Wittens. He whipped it up late one night after a long day of architectural discussions. It's been on the wall of my office for years.

John VanDyk, Jonathan Chaffer, and the new fragrance of CCK.

Topic: DrupalDrupal History

You did not read that wrong! Yes, Drupal 8 features are frozen, and the massive Drupal 8 Multilingual Initiative is not there to let you even translate a node title or the site name. We made massive amounts of progress with heroic efforts from key contributors, but we are not nearly close to be done yet. Yes, your help is needed! The way the Drupal core release cycle is set up, many things that you might consider features are not classified as such (verified with core maintainers) in the process. Feature freeze means all base features should be in core, however, many things that need to be integrated with these new features are not done yet. Otherwise what would we do for months on still, right? So let's look at the two use cases with this in mind. Start with the bad news!

Translate site name

The biggest feature that will still not be native in Drupal 8 is translation of user provided configuration. We still have lot to work on translating shipped configuration. We've worked hard for months to get a configuration schema system accepted so we can have a programatic understanding of the translatable pieces of configuration. We started work on that in 2012 June at Drupal Dev Days, and it took several forked issues, alternate proposals, personal, IRC and phone meetings to get a universal understanding that a configuration schema system is needed in the first place, with the actual implementation not too far from the original proposals, that landed in core. We would have loved to achieve this milestone sooner but that did not work out.

So the sad news is you will not be able to translate your site name or custom created Views with Drupal 8 core only. Drupal 8 core should be capable to translate shipped configuration though, that is email texts, image styles, default content types, default fields, etc. shipped with Drupal core. The text for these should eventually end up on http://localize.drupal.org for translation. You'll need to use a contributed module to translate user entered configuration though (such as user created Views and your site name). Good news is that the underlying schema system and the configuration override system in core (as well as the soon to be committed configuration context system) supports this use case too, so the missing piece is a user interface to be generated for configuration translation. A very early version of that user interface can be seen in http://drupal.org/sandbox/reyero/1635230.

So as of right now you cannot even translate the shipped email texts, but that is a feature targeted for Drupal 8 core (in combination with http://localize.drupal.org as usual for software translation). Translating configuration created on the user interface and not shipped with modules/themes/profiles will need a contributed module.

Translate node titles

All right, this is a flat out regression, right? Right! Drupal 8 trades node-copy translation that is native to Drupal 7 (using the Content translation module in Drupal 7), where translating a node creates a new copy of the node. In Drupal 8, the module named the same on the user interface (Content translation) works totally differently. It does not create new copies but stores translations in fields under the entity. This has several advantages. For one, it lets us support all kinds of entity types, for example, fields on users, taxonomy terms, comments, etc. We also provide a neat cross-entity configuration screen to set up all your entity types for language.

Yet, node titles remain non-translatable. The basic reason for that is that node titles are not "fields" on nodes, they are good old properties. Properties do not support multilingual storage natively. We introduced a multilingual property system earlier (for the entity_test entity type), and the integration to other entity types did not yet happen. Why? Well, the more sweeping next generation Entity API conversions are still widely underway. Comment entities are done (with performance regressions that are being worked out) and we are hard at work on nodes. There are still files, users, taxonomy terms, etc. ahead.

And then the multilinugal property conversions can happen on top of the new entity system much easier since that system has built-in support for them. That is still not a trivial task and we'll definitely need all hands possible to achieve.

(Side note: once node properties become multilingual, we also need to provide a migration path in core for the legacy content translation module and remove that module from core for good.)

How can I help?

The configuration schema system is easy! We have documentation at http://drupal.org/node/1905070 and a visual configuration browser that applies the schema at http://drupal.org/sandbox/reyero/1635230. There is a huge set of issues at http://www.drupal8multilingual.org/issues/schema to fill in the blanks of schemas where not yet provided or incorrectly written. Tips to help are in the meta issue at http://drupal.org/node/1910624#comment-7088154

The entity API conversions are more involved work. You can participate in the conversion issues at http://drupal.org/node/1818580 - however the process so far has been to attack one type at a time, and nodes are in focus righ now (http://drupal.org/node/1818556). Performance expertise, reroll experience and all kinds of other skills are needed here.

So how can you call Drupal 8 feature frozen? And when will it ever be ready?

Reality is features from the point of the development process are not necessarily the same as user's perceptions. While we wanted to get in solutions sooner (eg. targeted configuration schema and context for Dec 1st 2012), their declared belonging to a later development phase does not help to get reviewers and push them harder for inclusion. We are doing our best to not let this affect the eventual readiness of Drupal 8, but in the state we are in, we are not looking at an integration phase where we can sit back and relax.

The current planned deadline for the integration phase (when all entity properties should be multilingual and all configuration should have schemas) is July 1st 2013. There are three big sprints until then that we plan to use to boost our standing (please come and sign up for these):

• Drupal sprint weekend, March 9th and 10th all around the globe
• Sprints on the weekends both before and after DrupalCon Portland, May 18-19th and 24-26th
• Sprints all week before Drupal Dev Days Dublin, June 24-27th

Sitting around and waiting for later opportunities does not help, so jumping on these issues would be especially helpful. If you have no better idea, start reviewing the configuration schema issues today!

A huge thanks once again for all contributors

I'd like to reiterate once again that all the people on the multilingual intiative worked exceptionally hard (in some cases all the way to burning out) to make Drupal 8 as multilingual as possible for you all. The gaps in implementation are not at all due to people doing poor work, they are due to all the uncertainties involved in working on an Open Source project with set goals but heavy interdependencies and lack of resource commitments possible. As well as all the bliss and baggage of making large scale decisions in an open issue queue format.

See http://www.drupal8multilingual.org/team for more information on our team.

Time from time, while doing your custom Drupal code, you may want to load only one or several specific fields from a defined set of entities. So actually you have three approaches to this:

1. Query for entity/node set and load whole entities to get desired fields data. Works, but not a performant solution.

2. Make a direct sql query and get desired fields out of your database. Works too, is the fasted in terms of performance solution, but not too flexible and portable.

3. Leverage EntityFieldQuery() and field_attach_load(). This approach is not as fast as the second, but way more faster than loading whole nodes, it is flexible and uses field caching mechanism. If you'll decide to change your database backend later in the future, let's say to MongoDB, you'll be able to switch without changing a line in your code, neat!

Read on about Loading Only One Field From An Entity or Node in Drupal 7