Planet Drupal

Lullabot has always had a big presence at DrupalCon and next week's event in Portland, OR is no exception. We're teaching 4 classes and presenting 11 sessions. We've got 2 booths in the expo hall. We're having a big party on Tuesday night. And nearly the entire Lullabot team will be in Portland. For the latest updates, please follow us on Twitter and like us on Facebook.

Here's the breakdown of where we'll be and when:

Topic: Drupal

In Drupal core, we use issue thresholds to manage technical debt. Both critical (release-blocking) and major (non-release-blocking, high-impact issues) are considered. When we have more open issues than our thresholds, we do not commit new features.

Currently, we have 27 critical bugs, 41 critical tasks, 155 major bugs, and 149 major tasks. This is more than twice our current thresholds for critical issues, and about 50% more than our thresholds for major issues. We need your help to resolve these issues so that we can resume adding new features to Drupal 8. That would be a very exciting place to get to!

There are many ways to help, including not only programming but also updating these issues' summaries, testing the patches, and making sure the patches still apply. I encourage everyone to collaborate on major and critcal issues, and to consider making them a focus at the DrupalCon Portland sprints.

There have been a lot of mentions that Drupal 8 is using Annotations. In this article I will dive in how Drupal uses them and how to leverage Annotations mechanism yourself.

In brief, annotations are blocks of comments that are parsed and used as a source of information about something. For example in Drupal 8, plugins system Annotations are used to describe plugins. They are alternatives to our TYPE_hook_info hooks and are now widely used.

For example:

<?php
/**
* Defines a default processor implementation.
*
* Creates lightweight records from feed items.
*
* @Plugin(
* id = "aggregator",
* title = @Translation("Default processor"),
* description = @Translation("Creates lightweight records from feed items.")
* )
*/
class DefaultProcessor extends PluginBase implements ProcessorInterface {
}
?>

How does this work technically?

For parsing annotations Drupal uses AnnotationReader class from Doctrine. This class can retrieve annotations from classes, class methods in the following way: <?php
use Doctrine\Common\Annotations\AnnotationReader;
use Doctrine\Common\Annotations\AnnotationRegistry;
use Doctrine\Common\Reflection\StaticReflectionParser;

$object = new CustomClassWithAnnotations();
$annotation_name = 'Drupal\custom_module\Annotation\CustomAnnotation';

$reader = new AnnotationReader();

// Register the namespaces of classes that can be used for annotations.
$annotation_namespaces = array(
'Drupal\custom_module\Annotation' => DRUPAL_ROOT . '/modules/custom_module/lib',
);
AnnotationRegistry::registerAutoloadNamespaces($annotation_namespaces);

$reflection_class = new StaticReflectionClass($object);
$annotation = $reader->getClassAnnotation($reflection_class, $annotation_name);
?>

In the example above $annotation will be an object - instance of class that is registered as annotation. For example in case of:

<?php
/**
* @CustomAnnotation(
* property1 = "value1",
* property2 = “value2”,
* )
class CustomClassWithAnnotations() {
} ?>

AnnotationReader will check if it understands the CustomAnnotation class and instantiates it. In order the reader to understand this annotation, we should register it with AnnotationRegistry.

How do we define the CustomAnnotation class? A good idea would be to inherit it from – Drupal\Component\Annotation\Plugin. It will parse annotation to an array that you can access the "get()" method $definition = $annotation->get();

Defining a new type of annotation can be done in the following way:

<?php
namespace Drupal\custom_module\Annotation;
use Drupal\Component\Annotation\Plugin;
/**
* Defines an CustomAnnotation annotation type.
*
* @Annotation
*/
class CustomAnnotation extends Plugin {
}
?>

Of course you can skip creating a new type of annotation and use @Plugin instead.

In Drupal, the primary usage of annotations is in AnnotatedClassDiscovery, to discover plugins. But we can go further and apply reading annotations from class methods:

<?php
$reflection_method = new \ReflectionMethod('CustomClassWithAnnotations', $method_name);
$annotation = $this->reader->getMethodAnnotation($reflection_method, 'Drupal\custom_module\Annotation\CustomAnnotation');
?>

We can use this for example for validation of arguments or even unit testing our methods (providing a set of arguments and results to test against).

Hope this article made it a bit clearer about annotations. If you need some help on annotations we will be glad to assist you on Facebook or Twitter.

You may also share your thoughts/comments below.

For further reading:
Declarative development using annotations in PHP
Using annotations in PHP with doctrine annotation reader
Use Annotations for plugin discovery

Language English Tags: DrupalDevelopmentTutorialsCheck this option to include this post in Planet Drupal aggregator: planet

Are you a project manager working for a company adopting Drupal? Are you new to managing Drupal projects? This course is the right one for you!

This course follows the life cycle of a Drupal project from start to finish and back again and is based on our full day Drupal for Project Manager’s course.

Mentorship consulting is one of the many services that Lullabot provides, and is something we’re known for in the Drupal community. When we work with potential clients to describe what we can do for them, it can sometimes be very difficult to explain how a consulting relationship works. This is especially true if they have never participated in consulting engagements with us or another agency.

Twig is Drupal's best theme engine! Tomorrow I will speak at the DrupalJam about 'Twig in Drupal 8'. I will explain the pros and cons of Twig for Drupal themers, show examples of new Twig templates, explain a summary of the Twig syntax and of course do a small demo of working with Twig templates. You'll find my slides here.

Tags:  theming Twig Render Array

My team has been looking into the Firefox add-on Selenium IDE as a quick and simple way to create automated tests for our Drupal sites. Selenium IDE out of the box does not support conditionals, making it hard to account for unexpected behaviour. For instance, it's easy to make a test of the basic Drupal login functionality, but if the user is already logged in when running that test (a common scenario when working on a site), the test will fail. The solution to this is called Sideflow.

Sideflow was created by Darren DeRidder and currently extends Selenium IDE with these commands: goto/gotoLabel, label, gotoIf, while, endWhile, and push. I'm only going to use gotoIf and label in this example, but you can read about the others in the Sideflow GitHub repo and in the announcement on Darren's blog (where you can also find a lot of general Selenium IDE tips). Also see his blog posts Selenium IDE Sideflow Update 1 and Selenium IDE Sideflow Update 2. You might wonder why I don't just start the test with deleteAllVisibleCookies (a tip I got from 6 Ways to Make The Most of Selenium IDE), which in effect would log out the user before running the rest of the test. Well, it doesn't work with Drupal's session cookie since it's set to HttpOnly, meaning it can't be controlled by Javascript. A test that does work, however, is this: open | /userstoreElementPresent | //input[@id='edit-name'] | userIsLoggedOutgotoIf | ${userIsLoggedOut} == false | userIsLoggedInwaitForElementPresent | //input[@id='edit-name'] |type | //input[@id='edit-name'] | adminwaitForElementPresent | //input[@id='edit-pass'] |type | //input[@id='edit-pass'] | adminwaitForElementPresent | //input[@id='edit-submit'] |clickAndWait | //input[@id='edit-submit'] |label | userIsLoggedIn storeElementPresent looks for an element, in this case the username field shown when the user is logged out, and stores a Boolean value (true or false) in the variable userIsLoggedOut. If that element isn't present we can make a qualified guess that the user is already logged in, and just skip down to the label userIsLoggedIn, ending the test.  Green every time!

I'm a millennial, but even I remember the experience of calling the telephone operator and getting a live human to look up the number of a business or place a collect call. We have the digital means to complete lots of tasks like that today, but that doesn't mean all of our methods are equally effective for everyone.

"Drupal 8 will be the most accessible version of Drupal yet," declare J. Renée Beach and Wim Leers in their Drupalcon Portland session description.

They're both part of the Spark team, an initiative to improve the authoring experience in Drupal for everyone.

Spark is more well known for things like in-place editing and a mobile friendly toolbar, which you can see at right. But from the beginning, improving the experience for everyone has been a big priority, and one of the most exciting developments is a new aural interface.

That's right, Drupal is getting a switchboard operator:

OK, so that doesn't look terribly exciting all on its own. But trust me, when you watch the videos of people interacting with Drupal 8 and having menus and selections read as they go, it's pretty cool.

When I spoke with J. Renée about Drupal 8 and the nature of working on accessibility, the passion for this work really shown through. I'm really looking forward to their session with Wim, "Drupal Speaks: Aural user interfaces, new Drupal 8 accessibility features," on Wednesday at 10:45 AM. Hope to see you there!

IB: What are we missing when we talk about accessibility right now?

JRB: I want developers to understand that accessibility is fundamental to user interface development. We tend to talk about accessibility like we talk about gender. Both have coded values. When we speak of being gendered, we are often talking about being non-male. Male is a kind of genderless base state. So is it with accessibility. When we speak of making something accessible, we tend to refer to making an interface for blind users or for users with physical capabilities that make keyboard and mouse use difficult, as examples. Visual is a kind of accessible base state.

We risk "othering" folks for whom accessibility is an issue because as developers, in general, non-visual accessibility has not been a primary concern. I know what is is like to be othered. In some ways, highlighting otherness can be an effective way to bring focus to a problem. Eventually though, we need to resolve those issues and close the loop on the otherness. We can be other and also be equal. Now is the time for front end developers to start thinking about accessibility as a multi-modal effort. We no longer have the excuse that the tools and technologies available to us do not support efficient workflows for non-visual UI development.

IB: Where is Drupal 8 going to do better?

JRB: Most importantly, we have more individual core contributors this cycle who truly believe in addressing accessibility issues. And they are all smart, wonderful people which makes working with them a pleasure!

For example, take this issue about requirement warnings during installation. For a sighted user, a warning during installation is immediately apparent. The missing requirement is made distinct with color contrast. For a blind user, they must traverse every cell in the table to discover a missing requirement. Would we ever impose such a burden on a sight user through the UI? No, not without grumbles in the issue queues at least. With more contributors invested in improving these types of non-visual details, we are polishing all the rough edges — the ones we see and the ones we don't.

IB: How important is context in aural interfaces?

JRB: Context is important to all interfaces. As front end developers we build templates that expose context in a predictable, consumable way. As a practice we have established and then refined patterns of visual expression over the past 30-plus years.

Metaphors grounded visual pointer displays on a virtual desktop. We talk of visual affordances in rounded, gradient-embellished, reflective buttons. Skeumorphic designs bring our understanding of the physical world to bear on pixels and bits.

Where are the metaphors in aural interface design? I know of none. To me, these interfaces are flat. The metal is bare underneath them.

Perhaps non-visual interfaces have one less level of abstraction to traverse. Maybe there's no need to translate language into symbol and then back into language. But that little bit of designer in me, that memory of a linguist I almost was, remembers being thunderstruck with insight reading Jackendoff's unfurling of metaphor after I had just so recently fallen smitten with the strict generative grammar of early Chomsky. Jackendoff gives us a way of understanding language that starts at basic physical dichotomies — up/down and near/far — and from there offers us a model of communication. He gives us pattern. (Early) Chomsky gave us metal. So much that we humans do starts with structure that softens with time to fit our curvy, winding nature.

I want to believe that the aural interfaces we have today still just the awkward first attempts to build an abstract audio interface pattern language. That non-visual interface design is still working through its structuralist phase. We are still learning how to pack context into denser forms through non-visual expressions.

IB: Will the Drupal 8 improvements have things to offer module developers?

JRB: In Drupal 8, we are building tools that manage a couple of the trickier components of accessibility in a browser. These are:

1. Outputting audio updates
2. Managing tabbing in constrained workflows

Module developers will be able to pass a string to a method called "announce" on the Drupal object and have that string read by a screen reader.

Another method on the Drupal object called "tabbingManager" will constrain tabbable elements on the page. A developer will select those elements, either through JavaScript methods or jQuery, and pass them to the tabbingManager. Tabbing is then constrained to those elements until the constraint is superseded or released. I know that must not be completely clear, but that's why we're presenting a session about aural user interfaces and how we can use these new tools to build them!

Top image: Public domain. Drupal images from the drupal.org issue queue and the session slides.

Join Rootwork on Twitter, Facebook and SlideShare.

Learn about Rootwork's services for nonprofits and social change.

With Drupalcon now only a few days away, preparations are beginning to ramp up (or maybe starting to die down, depending on how much prep work your company has already done). Drupalcon is *the* Drupal event of the year—and with more than 3,000 attendees and 50+ expert-led sessions, there’s a lot to think about before boarding that plane to Portland.

So you're launching a new website or replacing an old one and want to make sure everything goes smoothly? This guide will give you a run-down of everything you can check to avoid common pitfalls!

Site status

You should always start by checking the status report (http://example.com/admin/reports/status). This page shows you all of the basic requirements for your Drupal site to run correctly.

Any issues will be highlighted in red and typically have a link to a configuration page or the documentation to help you resolve the problem.

Scheduled tasks

Drupal 7 will run scheduled tasks (known as cron jobs) out of the box, but only when users are visiting your site.

This is great for small sites which don't need much housekeeping, but if your site is a bit bigger or if you don't have visitors 24/7, you should set up a cron job to run periodically.

You can also look at a module such as Ultimate cron which gives you fine grained control over when each scheduled task will run.

Web services

Many web services such as Mollom or Google analytics need a domain name specific API key to use.

If you use any of these services on your website, you should ensure that you've registered your real domain name with the service and you've updated Drupal with your new API key.

Broken links

It can be easy when copying and pasting to accidentally link directly to a file or image on a development site.

These links can often stop working or perhaps worse, may direct users away from your live site and onto the development site instead.

You can use a module such as Link checker to ensure this doesn't happen, and it is good practice to password protect your development website, so that users (or more likely Google!) cannot stumble accross it.

Site optimisation

The site performance page (http://example.com/admin/config/development/performance) will allow you to configure a number of options to help optimise your Drupal site. This includes page caching and optimising CSS and JavaScript files.

See our series on High Performance in Drupal for some expert tips - High performance in Drupal Part 1: Give your site a boost and High performance in Drupal Part 2: Lightning fast code.

Development modules

Development modules such as devel can often reduce your website's performance, so it's worth turning them off on your live site. You can still keep them running in your development environment if needed.

User accounts

Many of us are guilty of using a common or simple password to make life easier when building a website.

Once the site is live, it's worth taking the time to update any administrative accounts with secure passwords.

It is also worth removing any unnecessary development accounts and content. Just in case.

Error messages

Being able to see debug messages and errors are handy when creating a site, but may scare off users once the site is live.

Ensure that errors and warnings are hidden by visiting the Logging and errors config page.

Site information

The site information config page holds all of the most common site information, such as the website name and email address.

It's worth double checking that all of this information is correct. It could be quite embarrassing if your first newsletter arrives from dev@example.com.

 

Some of these pitfalls can be avoided from the get go, if you follow a few simple principles. Check out Rick Donohoe's blog article Drupal site building 101 for some handy hints and tips on this!

Moving Drupal website clients to cloud hosting has been great as they're able to get high performance, scalable capacity at a pretty reasonable rate. However, we have discovered when clients offer an email sign-up, the emails that are generated from the cloud-hosted Drupal website are often rejected as spam. For those clients who have chosen the Rackspace cloud, here is a step-by-step solution to the problem.... Read more

This post discusses the differences between Drupal and WordPress, and also takes a quick look at a couple of other web frameworks. What are the benefits with each platform, and how do you know which one to choose?

We are pleased to announce that Commerce Kickstart has won the Walkthrough documentation prize. The prize, which was determined by votes from Walkthrough.it backers, will use the Commerce Kickstart Drupal distribution to showcase the capabilities of Walkthrough.it.

Commerce Kickstart is the quickest way to get up and running with Drupal Commerce. The distribution provides everything to create a fully-featured demo store out of the box, complete with theme, catalog, and custom back office interface.

Field as Block is a lightweight module that allows you to display a field as a block. The same results can be achieved by using Panels, Display Suite or custom code but this module offers a lightweight alternative.

CCK Blocks offers similar functionality, however on the project page they recommend that you use Field as Block for new projects. It looks like CCK Blocks will be deprecated in favour of Field as Block. For more details read issue #1920636 (comment #4).

Today Google announced PHP support for Google App Engine! I have been one of the lucky folks who had early access and so of course I worked on getting Drupal up and running on GAE. There are a few things that still need to be worked out which I will continue to discuss with the app engine team, but I have a working Drupal setup which I will detail below. Note that much of this may also apply to other PHP frameworks.

Getting up and running

I will cover the steps specific to getting Drupal 7 (notes for Drupal 6 along with branches in repository) up and running on App Engine and not how to use the SDK and development flow which is detailed in the documentation. For an example (minimal profile from core) of Drupal running on Google App Engine see boombatower-drupal.appspot.com.

Sign up to be whitelisted for PHP runtime

Currently, the PHP runtime requires you to sign up specifically for access. Assuming you have access you should be able to follow along with the steps below. Otherwise, the following steps will give you a feel for what it takes to get Drupal running on GAE.

Create an app

Create app by visiting appengine.google.com and clicking Create Application, see the documentation for more details.

Create a Cloud SQL Instance

Follow the documentation for setting up a Cloud SQL Instance. Be sure to give your application access to the instance.

Once the instance has been created select the SQL Prompt tab and create a database for your Drupal site as follows.

CREATE DATABASE drupal;

Download Drupal

There are a few tweaks that need to be made to get Drupal to run properly on GAE which are explained below, but for the purposes of this walk-through one can simply download my branch containing all the changes from github.

git clone --branch 7.x-appengine https://github.com/boombatower/drupal-appengine.git   # or for Drupal 6 git clone --branch 6.x-appengine https://github.com/boombatower/drupal-appengine.git

or download as a zip or for Drupal 6 download as a zip.

Configure Drupal database settings

Since GAE does not allow the filesystem to be writeable one must configure the database settings ahead of time.

Copy default.settings.php as settings.php and add the following bellow <?php $databases = array(); ?> around line 213.

<?php
$databases = array();
$databases['default']['default'] = array(
  'driver' => 'mysql',
  'database' => 'drupal', // The database created above (example used 'drupal').
  'username' => 'root',
  'password' => '',
  // Setting the 'host' key will use a TCP connection which is not supported by GAE.
  // The name of the instance created above (ex. boombatower-drupal:drupal).
  'unix_socket' => '/cloudsql/[INSTANCE]',
//  'unix_socket' => '/cloudsql/boombatower-drupal:drupal',
  'prefix' => '',
);
?>

For Drupal 6 around line 91.

<?php
$db_url = 'mysql://root:@cloudsql__boombatower-drupal___drupal/drupal';
?> Push to App Engine

Update the application name in the app.yaml file to the one you created above and upload by following the documentation.

# See https://developers.google.com/appengine/docs/php/config/appconfig.   application: drupal # <-- change this to your application version: 1 runtime: php api_version: 1 threadsafe: true   handlers: # Default handler for requests (wrapper which will forward to index.php). - url: / script: wrapper.php   # Handle static requests. - url: /(.*\.(ico$|jpg$|png$|gif$|htm$|html$|css$|js$)) # Location from which to serve static files. static_files: \1 # Upload static files for static serving. upload: (.*\.(ico$|jpg$|png$|gif$|htm$|html$|css$|js$)) # Ensures that a copy of the static files is left for Drupal during runtime. application_readable: true   # Catch all unhandled requests and pass to wrapper.php which will simulate # mod_rewrite by forwarding the requests to index.php?q=... - url: /(.+) script: wrapper.php appcfg.py update drupal/ Install

Visit your-app.appspot.com/install.php and follow the installation steps just as you would normally except that the database information will already be filled in. Go ahead and ignore the mbstring warning and note that the GAE team is looking into supporting mbstring.

Explanation of changes

If you are interested in what changes/additions were made and the reasons for them continue reading, otherwise you should have a working Drupal install ready to explore! There are a few basic things that do not work perfectly out of the box on GAE. The changes can be seen by diffing the 7.x-appengine branch against the 7.x branch in my repository.

File directory during installation

The Drupal installer requires that the files directory be writeable, but GAE does not allow for local write access thus the requirement must be bypassed in order for the installation to complete.

Author: boombatower <boombatower@google.com> Date: Wed May 15 15:49:03 2013 -0700   Hack to trick Drupal into ignoring that file directory is not writable.   diff --git a/modules/system/system.install b/modules/system/system.install index 1b037b8..9931aad 100644 --- a/modules/system/system.install +++ b/modules/system/system.install @@ -333,6 +333,8 @@ function system_requirements($phase) { } $is_writable = is_writable($directory); $is_directory = is_dir($directory); + // Force Drupal to think the directories are writable during installation. + $is_writable = $is_directory = TRUE; if (!$is_writable || !$is_directory) { $description = ''; $requirements['file system']['value'] = $t('Not writable'); Clean URLs

In order to take advantage of clean urls, of which most sites take advantage, mod_rewrite is required for Apache environments. Since GAE does not use Apache it does not support mod_rewrite and thus another solution is needed. The app.yaml can configure handlers which allow for wildcard matching which means multiple paths can easily be routed to a single script. Taking that one step further we can alter the <?php $_GET['q']?> variable just as mod_rewrite would so that Drupal functions properly. Rather than modify core this can be done via a wrapper script as show below (this should work well for other PHP applications).

<?php
/**
 * @file
 * Provide mod_rewrite like functionality and correct $_SERVER['SCRIPT_NAME'].
 *
 * Pass through requests for root php files and forward all other requests to
 * index.php with $_GET['q'] equal to path. In terms of how the requests will
 * seem please see the following examples.
 *
 * - /install.php: install.php
 * - /update.php?op=info: update.php?op=info
 * - /foo/bar: index.php?q=/foo/bar
 * - /: index.php?q=/
 */

$path = parse_url($_SERVER['REQUEST_URI'], PHP_URL_PATH);

// Provide mod_rewrite like functionality. If a php file in the root directory
// is explicitely requested then load the file, otherwise load index.php and
// set get variable 'q' to $_SERVER['REQUEST_URI'].
if (dirname($path) == '/' && pathinfo($path, PATHINFO_EXTENSION) == 'php') {
  $file = pathinfo($path, PATHINFO_BASENAME);
}
else {
  $file = 'index.php';

  // Provide mod_rewrite like functionality by using the path which excludes
  // any other part of the request query (ie. ignores ?foo=bar).
  $_GET['q'] = $path;
}

// Override the script name to simulate the behavior without wrapper.php.
// Ensure that $_SERVER['SCRIPT_NAME'] always begins with a / to be consistent
// with HTTP request and the value that is normally provided (not what GAE
// currently provides).
$_SERVER['SCRIPT_NAME'] = '/' . $file;
require $file;
?> PHP $_SERVER['SCRIPT_NAME'] variable

The <?php $_SERVER['SCRIPT_NAME'] ?> implementation differs from Apache mod_php implementation which can cause issues with a variety of PHP applications. The variable matches the HTTP spec and not the filesystem when called through Apache.

For example a script named foo.php contains the following.

<?php
var_dump($_SERVER['SCRIPT_NAME']);
?>

When executed from command line here are the results.

$ php foo.php string(7) "foo.php"   $ php ./foo.php string(9) "./foo.php"

When invoked through Apache like http://example.com/foo.php.

string(8) "/foo.php"

The documentation does not talk about this behavior (although many comments demonstrated the expected Apache behavior), but it is definitely depended on.

The difference causes Drupal to format invalid URLs.

example.com.foo.css (instead of ...com/foo.css) example.comsubdir/foo.css (instead of ...com/subdir/foo.css)

Drupal derives the URL from <?php dirname() ?> of <?php $_SERVER['SCRIPT_NAME'] ?> which will return . if no slashes or just / for something like /index.php.

The wrapper script above solves this by ensuring that the SCRIPT_NAME variable alway starts with a leading slash.

HTTP requests

GAE does not yet support support outbound sockets for PHP (although supported for Python and Java) and if/when it does the preferred way will continue to be streams due to automatic caching of outbound requests using urlfetch. I have included a small change to provide basic HTTP requests through drupal_http_request(). A proper solution would be to override the drupal_http_request_function variable and provide a fully functional alternative using streams. Drupal 8 has converted drupal_http_request() to use Guzzle which supports streams. Making a similar conversion for Drupal 7 seems like the cleanest way forward rather than reinventing the change.

php.ini

GAE disables a number of functions for security reasons, but only softly disables some functions which may then be enabled. Drupal provides access to phpinfo() from admin/reports/status and uses output buffering, both of which are disabled by default. The included php.ini enables both functions in addition to getmypid which is used by drupal_random_bytes().

# See https://developers.google.com/appengine/docs/php/config/php_ini.   # Required for ob_*() calls which you can find by grepping. # grep -nR '\sob_.*()' . output_buffering = "1"   # See https://developers.google.com/appengine/docs/php/runtime#Functions-That-Must-Be-Manually-Enabled # phpinfo: Provided on admin/reports/status under PHP -> "more information". # getmypid: Used by drupal_random_bytes(), but not required. google_app_engine.enable_functions = "getmypid, phpinfo" Future

I plan to continue working with the GAE team to ensure that support for Drupal can be provided in a clean and simple manner. Once current discussions have been resolved I hope to provide more formal documentation and support for Drupal.

File handling

I worked on file support, but there were a number of upcoming changes that would make things much cleaner so I decided to wait. GAE provides a stream wrapper for Google Cloud Storage which makes using the service very simple. Assuming you have completed the prerequisites files on GCS may be accessed using standard PHP file handling functions as shown in the documentation.

<?php
$file = 'gs://my_bucket/hello.txt';
file_put_contents($file, 'hello world');

$contents = file_get_contents($file);
var_dump($contents); // prints: hello world
?>

Unfortunately, the wrapper does not currently support directories nor does file_exists() work properly. Keep in mind that the filesystem is flat so a file may be written to any path without explicitly creating the directory. Meaning one can write to gs://bucket/foo/bar.txt without creating the directory foo. With that being the case it is possible to get some hacky support by simply disabling all the directory code in Drupal, but not really usable. It should be possible to hack support in through the stream wrapper since directories are simply specially name files, but the app engine team has indicated they will look into the matter so hopefully this will be solved cleanly.

Assuming the stream wrappers are fixed up then support can be added in much the same way as that Amazon S3 support is added except that no additional library will be needed.

Additionally, the documentation also notes the following.

Direct file uploads to your POST handler, without using the App Engine upload agent, are not supported and will fail.

In order to support file uploads the form must be submitted to the url provided by CloudStorageTools::createUploadUrl() and the forwarded result handled by Drupal. A benefit of proxying requests through uploader service is that uploaded files may be up to 100TB in size.

Other

There are a number of additional services provided as part of GAE of which Drupal could take advantage.

• Task Queue API
• Google account authentication
• Memcache seems to work out of the box with the memcache module
• <?php $SERVER['HTTP_X_APPENGINE*'] ?> variables (like geo information) Large number of services in API Console

Closing

Hopefully this will be useful in getting folks up and running quickly on GAE with Drupal and understanding the caveats of the environment. Obviously there is a lot more to cover and I look forward to seeing what others publish on the matter.

Tags:

• drupal
• drupal 6
• drupal 7
• google
• google app engine

Come meet Drupal.org team in person at DrupalCon Portland!

We’re hard at work upgrading Drupal.org to Drupal 7. DrupalCon is a perfect opportunity for you to find out what is going on with the upgrade, give us feedback on the new issue page layout and, of course, help us in the issue queue.

Where to find us:

• Weekend before DrupalCon - We are taking part in the extended sprints, come and help us close some issues
• Tuesday, May 21, 4:30pm - We’re having a BoF, Drupal.org improvements and D7 upgrade (Room B112)
• Wednesday, May 22 at 6pm - I’m presenting D7 upgrade report at the Drupal Association board meeting
• Thursday, May 23, 10:15am-1:15pm - I’ll be at the Drupal Association booth in the Exhibit Hall’s Community Village
• Friday, May 24 - We'll be closing more issues at the Contribution Sprint

Come and learn how you can help out with development, site building, or QA!

Here are the highlights from a few of the conversations I had with attendees of the 2013 Drupal Camp Alpe-Adria, held in April in Ljubljana, Slovenia. The camp was a wild success and attracted a large, international crowd. I'll post a couple more interviews I did at this event in coming weeks.

alpe-adria-voices.mp3

There are currently 99 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: Subscriptions by Reference What does it do?

The Subscriptions module allows you to subscribe directly to nodes, but what if you want to subscribe to one node referenced by another? Previously, you could do that with a moderate amount of custom code, maybe with the help of a blog post explaining the process. Now, the Subscriptions by Reference module promises to make that even easier. Just tell it which content types and field you want to use in the subscription and it does the rest.

Look Useful? Review it!

If you would like to see this module 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.

In this lesson we're going to talk about what is possibly the most useful Drupal site building module of them all - Views. If you're coming from a WordPress or Joomla background, you won't have experienced anything quite like it. Not only does Views allow you to easily build queries on your site's content, but it gives an amazing degree of control over the display of those query results.

We're going to begin by creating a very basic view just to get acquainted with the interface and some of the settings we'll be using the most often. If you've been following along and are using my free installation profile, then everything you'll need is ready to go. If you're using your own site, make sure you have Views installed along with some content you can work with. If you have a fresh install of Drupal, the Devel module is great for generating dummy content.

Once you're all set, let's get started creating our first view.

Creating a View

To begin, let's head to Structure > Views. You should see something like the screenshot below. At the upper left of the page is a link that says, "Add new view". Go ahead and click it.

You'll next be directed to the screen below. If you wanted to keep things super easy, you could just add a title and then save to have a view of all your site's content presented as teasers. We're going to do something a bit different, however. Take a look at the settings below.

You'll see that I've named the view "Blog grid" and set it to only show content of the Article type. Often you may want to create an additional display, such as a block, but in this example we're going to just stick with the default Page view.

The ability to create multiple displays is one of the really cool things about Views. We're building one query, but we have the option to display it in multiple ways - a page, a block or even a feed - and then tweak the display of each as needed.

We'll go with what we have here and click "Continue and edit". You'll next see the view edit form as in the screenshot below.

OK, there's a lot going on with this form, but we're only going to focus on a few of these settings to keep it simple this time around. Let's begin with two that we're not going to edit in this lesson, but that I'd like you to take a moment to check out. These are the Filter Criteria and the Sort Criteria settings.

You'll see that they determine the type of content we're working with, the publish status and how the results will be sorted (in our case, by date with the newest displayed first). These settings make it very easy to add criteria to further filter our results.

For example, one thing that is often useful to do is only include nodes in your view that have been promoted to the front page. This allows you to do something like publish a post but not include it in the main list of your blog articles. I do this occasionally when I don't want a post distributed to email subscribers, but do want it available through my Categories menu.

Take a look at these options, play around with them bit and see what changes you can come up with. Experimenting is a great way to figure out all the things Views is capable of doing.

Editing a Field Display

In our last tutorial, we talked about content types and the Fields UI. In this lesson we're circling back a bit on that subject by using fields to create our view. That's what a view mostly boils down to - a query where we ask Drupal to return certain fields so we can use them in a display we place on our site. You'll see that in this view all that we currently have being displayed are the titles of our articles. The preview (down at the bottom of the page) also shows us that our titles are being displayed as simple, unformatted links. 

Although it's a good idea to have the title as a link, we should probably change the display style to a heading. To do this, click on Content: Title under Fields. You'll see something like the screenshot below.

You'll notice that I've expanded the Style Settings tab and checked "Customize field HTML" and set it to display the title as an H2. I could have done a lot of other customizations, including adding a class, changing the field wrapper and more.

Farther down this screen you'll see the Rewrite Results tab and that is where things get really interesting. You can pretty much go nuts with how you want to customize a field's display. This is super powerful stuff! The only criticism I'll offer is that by default, Views generates markup that is quite bloated - it has a serious case of divitis. Fortunately, we have the Semantic Views module to tidy things up. We won't get into using that module in this lesson, but I recommend you take a look at it on your own.

I'm going apply these settings for all displays, but note that by using the drop down at the top of this screen you could choose to instead apply it to a specific display. This is very useful when you're using the query to create multiple displays (pages, blocks or feeds) and modifying how each one outputs the view.

After applying the changes, you should notice in the preview that the titles have been successfully changed to headings. So far, so good. But let's add another field to our display to make it a bit more useful. You'll see in the screenshot below there is an arrow pointing to the link that adds a new field to our view.

After clicking that button, you'll see a long list of options pop up. Let's select Content: Body and then continue by clicking the, "Apply (all displays)" button. You'll next see the same screen as when we edited the Title field. One difference this time is that "Create a label" is now checked. In most cases I uncheck that so that my views don't add labels, but you may find situations where it comes in handy.

Another difference this time is that we're going to make a change to the format of the field. We probably aren't going to want the entire Body field to be displayed in our view, so instead we'll set it to only display a summary. You'll see a drop down under Formatter. Go ahead and select, "Summary or trimmed". In this case the default settings are fine, but I encourage you to play around with some of these a bit and see what you come up with. Now we'll click, "Apply (all displays)" to continue.

After saving that, take a look at the preview - looking pretty good, huh? We've come far enough that we should see what this Page view we've created actually looks like on our site. First, however, make sure you save your view! That's an important thing to remember - none of your changes are applied until you save the view, so if you ever get off track, just click cancel and start over.

After saving, look for a small link at the upper right of the view edit screen that says, "view Page". Let's click that and take a look at the view we've created as it will appear on our site.

That was pretty easy, right? I'll bet that you can think of a lot applications just using what we learned today, but in future lessons we'll be coming back to the Views module and adding to our bag of tricks. In fact, our next lesson will cover some advanced features of views (contextual links and relationships) and in a few weeks we'll use Views and the Flex Slider module to add an image slider to our front page.

Until then, you can keep up with this series either via the RSS feed or subscribing to blog updates (at the top of the sidebar).

If you'd like to comment on this post, you can do so on this discussion forum.

Guest blogger Yvonne Chen of Dayvin Internet Solutions shares the results of the Shanghai Global Training Day event this past March.

Following-up with the Global Training Day series, we were glad to be able to organize the Drupal Training Day on March 15, 2013 in Shanghai.

Personal blog tags: Drupal Global Training DaycommunityChinaguest blog