Drupal Feeds

Chapter Three: Death of skeuomorphism and the future of design

Feeds from Drupal.org - Thu, 2014-05-29 10:17
The future is now

At the Design4Drupal camp in Boston there was a lot of talk about responsive design the state of design and where the future of design is headed. There was much discussion about what types of devices we may soon be designing for and how people will interact with them.





People may use the internet on their fridge, on Google Glass, or even on an alarm clock or inside their car. Almost any electronic device can be readily transformed into an internet capable tool.

Categories: Straight From Drupal

Chapter Three: How to Give Design Feedback Like a Pro

Feeds from Drupal.org - Thu, 2014-05-29 10:17

Giving design feedback is hard, but with a few quick tips you do it like a pro.



The Design Feedback Sandwich.

The best way to keep designers happy is to use what I call the Design Feedback Sandwich.



  1. Start by telling your designer a few things you like about the design. 

  2. Next, tell the designer which pieces are problematic.

  3. Finish by telling them something positive thing about their work.

Validating the positive bits keeps up morale. Remember - people are more creative when they're in a good mood.



The Design Feedback Sandwich

Categories: Straight From Drupal

Chapter Three: Put Some Thought Into Your Files Folder Architecture and The Cats of The Web Will Purr With Thanks.

Feeds from Drupal.org - Thu, 2014-05-29 10:17

Recently, I had the special fun of migrating a new client’s site over to a new host. Everything was going smoothly and quickly until I got to the Files folder. It contained a 4-gigabyte hodgepodge of images, thumbnails, pdfs, known site backups and unknown site backups (Yes, unknown! I don't count the WordPress version of the site from six years ago as a "known about" backup). It got me thinking about one part of Drupal that I think many take for granted: The Files system. Drupal is three-part system: Database, Code and Files. When planning a site architecture, often the Files folder gets treated like the red-headed step child of the three; forgotten, neglected and rather ignored. However, that’s not the way it should be. Drupal is a content management system.

Categories: Straight From Drupal

Chapter Three: The UCSF Drupal Web Starter Kit

Feeds from Drupal.org - Thu, 2014-05-29 10:17

The UCSF Drupal Web Starter Kit project has been our most successful university project to date. It has empowered UCSF to roll out sites for small departments, offices, and researchers in a matter of minutes.



Just 3 months after launch, 70 sites have gone live.



"This fills a tremendous need at UCSF. We're very happy with it."

– Lisa Magargal, UCSF



Here are a few examples of sites leveraging the Drupal Web Starter Kit:

Categories: Straight From Drupal

Chapter Three: Helping Tintri revolutionize the VM-aware storage market

Feeds from Drupal.org - Thu, 2014-05-29 10:17

To expand and gain a stronger foothold in the VM storage market, Tintri turned to Chapter Three to create a new look and feel for their business. As a team, the two companies built a stronger content structure that spoke more effectively to Tintri’s primary audiences.



The project was a resounding success, resulting in an immediate 30% increase in traffic and a significant uptick in lead generation after just one month.



Categories: Straight From Drupal

Chapter Three: Fireworks is (nearly) dead. Long live Fireworks!

Feeds from Drupal.org - Thu, 2014-05-29 10:17

Well, it’s not quite dead yet, but Adobe has effectively removed all life support from Fireworks, according to this recent press release.



As they transition to an exclusively cloud-based system for Creative Suite, Fireworks CS6 will be included but they “are not planning any further feature development.” All of our copies of Fireworks will continue to work, of course, but at some point down the road we’ll all have to move on to the next piece of software.

Categories: Straight From Drupal

Chapter Three: The Heart of Content Strategy

Feeds from Drupal.org - Thu, 2014-05-29 10:17

Content strategy is on enough lips nowadays that most people can call out ideas to sketch out the general borders of this area of discipline. User focus! Clarity! Reusability! Curated content! But where exactly is the heart of content strategy?



The Heart of Content Strategy

Content strategy's ultimately about aligning your organization's content (whether print or digital, written or shot) with its overarching business goals and objectives. Successful content strategies manifest themselves in several key ways: you see

Categories: Straight From Drupal

Shortcode Snippets

Latest Drupal Modules - Thu, 2014-05-29 06:43

TODO

Categories: Straight From Drupal

Shushu's blog: Organic groups API == nicely built architecture

Planet Drupal - Thu, 2014-05-29 06:27

I started to work in Gizra more than 6 months ago. While I did have lots of Drupal experience, I didn't have a lot of Organic groups experience, especially not in Drupal 7 version.
As a developer, I am more interested in the way things are built and less in the way they look. I mean, I know my way around front-end and user interface, but a good looking UI won't make me as exceited as a well developed piece of code.
This is why I enjoy working with OG - since it is well-structured, lots of things works flawlessly, and easy to enhance.

In this post I want to focus on one particular task, and how it was easily done once you know OG API.

Our client decided they want to have a description for each taxonomy term, and to show the description when showing the taxonomy term page. This is easy, considering by default there is a description field. Then they decided they don't want to show the field in all pages, and they want it to be configurable.

The solution seems simple - adding a new boolean field for each taxonomy term, which will define whether the description will be seen or not, and then to use the taxonomy-term.tpl.php to show or hide the description according to this field.

The problem is that since we are working in OG (specifically in OpenSchoalr project), we can't and should not add the field manually, and considering each of the authorized site users can create their own vocabulary, we need to add the field automatically when the vocabulary is being created.

Gladly, OG API is built for those kind of tasks, and with several steps we can achieve what we want.

First, we need to define the field that we need. Once it is defined, it can be exported and then used in code. While it might be possible to define the field manually, I believe it is always better to avoid guessing Drupal multi-dimentional-unvalidatible arrays, and to leave this task for the machine.

  • Create a taxonomy vocabulary via http://example.com/admin/structure/taxonomy/add and then add the field you need via http://example.com/admin/structure/taxonomy/your-vocabulary/fields.
  • Use the features UI in order to create a new feature that includes the new field you just created. We won't use the feature as is, this is just a simple way to export the field configuration (I guess there are other ways as well).
  • Once you download the features file, look for the code inside the hook_field_default_field_bases() and hook_field_default_field_instances() implementations. This is the code we will use later on.

Second, we need to tell OG we have a new field, and to define how OG should use it. This is done using hook_og_fields_info(). What you need to do is to create a new module (or use one of your own modules), and create an implementation of this hook, in which you will add the code exported from the last step (with minor changes). One important issue is the name of the field - it needs to be correct in all places, and it is what you will use later on.
Please look carefully into the comments inside the code in order to see what needs to be changed manually.

Note that the best way to verify your configuration is correct is by using the OG UI in order to manually add this field to your structure via http://example.com/admin/config/group/fields. If your configuration is correct (don't forget to clear cache...) you will see the new field in the fields list.

To be certain, just add it manually to a vocabulary and see whether it is being added properly.

Third, we want to add an action saying "whenever new taxonomy vocabulary is created, add our cool field to it". To do so we need to hook into Drupal core bundle creation (thankfully, vocabulary is an entity, and each new vocabulary is a bundle...), and this is done via hook_field_attach_create_bundle. What you need to do is to create an implmenetation for this hook in your module, and there to use the nicely-structured OG API `og_create_field` with the name of the field you defined in the last step.

Yep, "this is it" !

Is it ?

It is, as long as you build new site. Considering you might handle an existing OG site, that might already have a bunch of taxonomy vocabularies, you must handle all of them as well, and the best way to do it is automatically via the installation or upgrade process.

On how to use the `hook_install`, `hook_update_n`, and when and how to use the Batch API - in another post.

Hope this post helps anyone,

Shushu

Ralates to: DrupalDrupal PlanetOrganic groupsOpenScholarhook_og_fields_infohook_field_attach_create_bundle

Shushu's blog: Organic groups API == nicely built architecture

Feeds from Drupal.org - Thu, 2014-05-29 06:27

I started to work in Gizra more than 6 months ago. While I did have lots of Drupal experience, I didn't have a lot of Organic groups experience, especially not in Drupal 7 version.
As a developer, I am more interested in the way things are built and less in the way they look. I mean, I know my way around front-end and user interface, but a good looking UI won't make me as exceited as a well developed piece of code.
This is why I enjoy working with OG - since it is well-structured, lots of things works flawlessly, and easy to enhance.

In this post I want to focus on one particular task, and how it was easily done once you know OG API.

Our client decided they want to have a description for each taxonomy term, and to show the description when showing the taxonomy term page. This is easy, considering by default there is a description field. Then they decided they don't want to show the field in all pages, and they want it to be configurable.

The solution seems simple - adding a new boolean field for each taxonomy term, which will define whether the description will be seen or not, and then to use the taxonomy-term.tpl.php to show or hide the description according to this field.

The problem is that since we are working in OG (specifically in OpenSchoalr project), we can't and should not add the field manually, and considering each of the authorized site users can create their own vocabulary, we need to add the field automatically when the vocabulary is being created.

Gladly, OG API is built for those kind of tasks, and with several steps we can achieve what we want.

First, we need to define the field that we need. Once it is defined, it can be exported and then used in code. While it might be possible to define the field manually, I believe it is always better to avoid guessing Drupal multi-dimentional-unvalidatible arrays, and to leave this task for the machine.

  • Create a taxonomy vocabulary via http://example.com/admin/structure/taxonomy/add and then add the field you need via http://example.com/admin/structure/taxonomy/your-vocabulary/fields.
  • Use the features UI in order to create a new feature that includes the new field you just created. We won't use the feature as is, this is just a simple way to export the field configuration (I guess there are other ways as well).
  • Once you download the features file, look for the code inside the hook_field_default_field_bases() and hook_field_default_field_instances() implementations. This is the code we will use later on.

Second, we need to tell OG we have a new field, and to define how OG should use it. This is done using hook_og_fields_info(). What you need to do is to create a new module (or use one of your own modules), and create an implementation of this hook, in which you will add the code exported from the last step (with minor changes). One important issue is the name of the field - it needs to be correct in all places, and it is what you will use later on.
Please look carefully into the comments inside the code in order to see what needs to be changed manually.

Note that the best way to verify your configuration is correct is by using the OG UI in order to manually add this field to your structure via http://example.com/admin/config/group/fields. If your configuration is correct (don't forget to clear cache...) you will see the new field in the fields list.

To be certain, just add it manually to a vocabulary and see whether it is being added properly.

Third, we want to add an action saying "whenever new taxonomy vocabulary is created, add our cool field to it". To do so we need to hook into Drupal core bundle creation (thankfully, vocabulary is an entity, and each new vocabulary is a bundle...), and this is done via hook_field_attach_create_bundle. What you need to do is to create an implmenetation for this hook in your module, and there to use the nicely-structured OG API `og_create_field` with the name of the field you defined in the last step.

Yep, "this is it" !

Is it ?

It is, as long as you build new site. Considering you might handle an existing OG site, that might already have a bunch of taxonomy vocabularies, you must handle all of them as well, and the best way to do it is automatically via the installation or upgrade process.

On how to use the `hook_install`, `hook_update_n`, and when and how to use the Batch API - in another post.

Hope this post helps anyone,

Shushu

Ralates to: DrupalDrupal PlanetOrganic groupsOpenScholarhook_og_fields_infohook_field_attach_create_bundle
Categories: Straight From Drupal

Palantir: D8FTW: Unit testing for realsies

Feeds from Drupal.org - Wed, 2014-05-28 21:54
D8FTW! Unit-testing

Code testing: It's like exercise. It's good for you, but most people really don't want to do it. Unless you develop a habit for it and feel the benefit, most people will try to avoid it. And if it's too hard to do it becomes easy to avoid.

That's really unfortunate, as good testing can have a huge improvement on the quality of a system and, over time, even improve how fast a system can be developed because you spend less time finding and fighting old bugs and more time building things right the first time.

Drupal 7 introduced testing to the Drupal world for the first time, but not really unit testing. Unit testing, specifically, is testing one "unit" of a larger system in isolation. If you can verify that one unit works as designed you can confirm that it doesn't have a bug and move on to finding bugs elsewhere. If your tests are automated, you can get notified that you have a bug early, before you even commit code.

The problem with Drupal 7 is that it doesn't really have units. Drupal's historically procedural codebase has made isolating specific portions of code to test extremely difficult, meaning that to test one small bit of functionality we've needed to automate installing the entirety of Drupal, create for-reals content, test that a button works, and then tear the whole thing down again. That is horribly inefficient as well as quite challenging to do at times, especially given the poor home-grown testing framework Drupal 7 ships with. As a result, many many developers simply don't bother. It's too hard, so it's easier to avoid.

Now fast forward to Drupal 8 and we find the situation has changed:

  • That historically procedural codebase is now largely object-oriented, which means every class forms a natural "unit" candidate. (Class and "testable unit" are not always synonymous, but it's a good approximation.)
  • Because most of those classes leverage their constructors properly to pass in dependencies rather than calling out to them we can easily change what objects are passed for testing purposes.
  • In addition to Simpletest, Drupal now includes the PHP-industry standard PHPUnit testing framework.

All of that adds up to the ability to write automated tests for Drupal in less time, that run faster, are more effective, and are, in short, actually worth doing.

Smallest testable unit

Let's try and test the custom breadcrumb builder we wrote back in episode 1 (The Phantom Service). Here it is again, for reference:

<?php
// newsbreadcrumb/src/NewsBreadcrumbBuilder.php
namespace Drupal\newsbreadcrumb;
use Drupal\Core\Breadcrumb\BreadcrumbBuilderBase;

class

NewsBreadcrumbBuilder extends BreadcrumbBuilderBase {
  /**
   * {@inheritdoc}
   */
  public function applies(array $attributes) {
    if ($attributes['_route'] == 'node_page') {
      return $attributes['node']->bundle() == 'news';
    }
  }

 

/**
   * {@inheritdoc}
   */
  public function build(array $attributes) {
    $breadcrumb[] = $this->l($this->t('Home'), NULL);
    $breadcrumb[] = $this->l($this->t('News'), 'news');
   return $breadcrumb;
  }
}
?>

We want to test that the logic in this class works as expected but without testing the entirety of Drupal, or even the entirety of the breadcrumb system if we can avoid it. We just want to test this code. Can we? With good OOP design and PHPUnit, we can!

First, let's create a new testing class in our newsbreadcrumb module. This class does not go in the same directory as our code itself. Instead, it goes in a separate "tests" directory but follows the same file/name pattern.

<?php
// newsbreadcrumb/tests/src/NewsBreadcrumbBuilderTest.php
namespace Drupal\newsbreadcrumb\Tests;

use

Drupal\Tests\UnitTestCase;

use

Drupal\newsbreadcrumb\NewsBreadcrumbBuilder;

/**
* Tests the News breadcrumb builder.
*/
class NewsBreadcrumbBuilderTest extends UnitTestCase {

  public static function

getInfo() {
    return array(
      'name' => 'News breadcrumb tests',
      'description' => 'Tests the news breadcrumbs',
      'group' => 'News breadcrumb',
    );
  }

}

?>

It should look fairly familiar for anyone who's written a Drupal 7 test. The main difference is that we're extending UnitTestCase, which is a very thin extension of PHPUnit's main base class for tests. Now we can define some test methods. As in Drupal 7, a test method is one that begins with test. Rather than assume we have a complete Drupal install and making actual HTTP calls against it, though, we'll just test our class directly.

<?php
  public function testApplicablePage() {
    $node_stub = $this->getMockBuilder('\Drupal\node\Entity\Node')
      ->disableOriginalConstructor()
      ->getMock();
    $node_stub->expects($this->once())
      ->method('bundle')
      ->will($this->returnValue('news'));

   

$attributes = [
      'node' => $node_stub,
      '_route' => 'node_page',
    ];

   

$builder = new NewsBreadcrumbBuilder();

   

Categories: Straight From Drupal

Palantir: D8FTW: Unit testing for realsies

Planet Drupal - Wed, 2014-05-28 21:54
D8FTW! Unit-testing

Code testing: It's like exercise. It's good for you, but most people really don't want to do it. Unless you develop a habit for it and feel the benefit, most people will try to avoid it. And if it's too hard to do it becomes easy to avoid.

That's really unfortunate, as good testing can have a huge improvement on the quality of a system and, over time, even improve how fast a system can be developed because you spend less time finding and fighting old bugs and more time building things right the first time.

Drupal 7 introduced testing to the Drupal world for the first time, but not really unit testing. Unit testing, specifically, is testing one "unit" of a larger system in isolation. If you can verify that one unit works as designed you can confirm that it doesn't have a bug and move on to finding bugs elsewhere. If your tests are automated, you can get notified that you have a bug early, before you even commit code.

The problem with Drupal 7 is that it doesn't really have units. Drupal's historically procedural codebase has made isolating specific portions of code to test extremely difficult, meaning that to test one small bit of functionality we've needed to automate installing the entirety of Drupal, create for-reals content, test that a button works, and then tear the whole thing down again. That is horribly inefficient as well as quite challenging to do at times, especially given the poor home-grown testing framework Drupal 7 ships with. As a result, many many developers simply don't bother. It's too hard, so it's easier to avoid.

Now fast forward to Drupal 8 and we find the situation has changed:

  • That historically procedural codebase is now largely object-oriented, which means every class forms a natural "unit" candidate. (Class and "testable unit" are not always synonymous, but it's a good approximation.)
  • Because most of those classes leverage their constructors properly to pass in dependencies rather than calling out to them we can easily change what objects are passed for testing purposes.
  • In addition to Simpletest, Drupal now includes the PHP-industry standard PHPUnit testing framework.

All of that adds up to the ability to write automated tests for Drupal in less time, that run faster, are more effective, and are, in short, actually worth doing.

Smallest testable unit

Let's try and test the custom breadcrumb builder we wrote back in episode 1 (The Phantom Service). Here it is again, for reference:

<?php
// newsbreadcrumb/src/NewsBreadcrumbBuilder.php
namespace Drupal\newsbreadcrumb;
use Drupal\Core\Breadcrumb\BreadcrumbBuilderBase;

class

NewsBreadcrumbBuilder extends BreadcrumbBuilderBase {
  /**
   * {@inheritdoc}
   */
  public function applies(array $attributes) {
    if ($attributes['_route'] == 'node_page') {
      return $attributes['node']->bundle() == 'news';
    }
  }

 

/**
   * {@inheritdoc}
   */
  public function build(array $attributes) {
    $breadcrumb[] = $this->l($this->t('Home'), NULL);
    $breadcrumb[] = $this->l($this->t('News'), 'news');
   return $breadcrumb;
  }
}
?>

We want to test that the logic in this class works as expected but without testing the entirety of Drupal, or even the entirety of the breadcrumb system if we can avoid it. We just want to test this code. Can we? With good OOP design and PHPUnit, we can!

First, let's create a new testing class in our newsbreadcrumb module. This class does not go in the same directory as our code itself. Instead, it goes in a separate "tests" directory but follows the same file/name pattern.

<?php
// newsbreadcrumb/tests/src/NewsBreadcrumbBuilderTest.php
namespace Drupal\newsbreadcrumb\Tests;

use

Drupal\Tests\UnitTestCase;

use

Drupal\newsbreadcrumb\NewsBreadcrumbBuilder;

/**
* Tests the News breadcrumb builder.
*/
class NewsBreadcrumbBuilderTest extends UnitTestCase {

  public static function

getInfo() {
    return array(
      'name' => 'News breadcrumb tests',
      'description' => 'Tests the news breadcrumbs',
      'group' => 'News breadcrumb',
    );
  }

}

?>

It should look fairly familiar for anyone who's written a Drupal 7 test. The main difference is that we're extending UnitTestCase, which is a very thin extension of PHPUnit's main base class for tests. Now we can define some test methods. As in Drupal 7, a test method is one that begins with test. Rather than assume we have a complete Drupal install and making actual HTTP calls against it, though, we'll just test our class directly.

<?php
  public function testApplicablePage() {
    $node_stub = $this->getMockBuilder('\Drupal\node\Entity\Node')
      ->disableOriginalConstructor()
      ->getMock();
    $node_stub->expects($this->once())
      ->method('bundle')
      ->will($this->returnValue('news'));

   

$attributes = [
      'node' => $node_stub,
      '_route' => 'node_page',
    ];

   

$builder = new NewsBreadcrumbBuilder();

   

Field Collection AJAX

Latest Drupal Modules - Wed, 2014-05-28 20:29

The Field Collection AJAX widget is an alternative entry widget for field collections.

Instead of having every field collection entity directly editable, they are viewed in a table. There are AJAX-enabled buttons to edit each one, and a button to add another one; they are all edited in the same area beneath the table.

The table becomes much more readable, and managing multiple field collections attached to an entity becomes more maintainable.

@TODO: Need help writing a better description.
@TODO: Need screenshots.

Categories: Straight From Drupal

Propeople Blog: Challenges and Opportunities in the Upcoming Drupal 8 Upgrade

Planet Drupal - Wed, 2014-05-28 19:08

When Drupal 7 reached public release in January of 2011, it made waves for being more accessible and more performant than any Drupal to come before. Drupal 8 is likely to receive similar acclaim in the same vein, but to a much greater degree. Easier to use, better performance, and offering simpler, more flexible development, Drupal 8 is poised to improve the Drupal ecosystem more than ever before.

It’s still around six months until the core change, but this post will run through the challenges and opportunities coming up in Drupal 8.

 

An object-oriented approach lowers the barrier to entry for new developers

Drupal 7 and all previous versions used a procedural approach to scripting. This means that code is executed the same way every time the script is run. Procedural scripts are more reliable, but less customizable. Reliability is good, but in order to capitalize on it, developers must be intimately familiar with exactly what procedures are occurring, and in what order. This depth of knowledge gave Drupal 7 its famous steep learning curve.

The object-oriented approach used by Drupal 8 means that the execution of scripts will be much more dynamic. Functionality is treated like mutable objects, able to be modified programmatically. With object orientation, Drupal will operate more like a true API. Newcomers will appreciate this, since the framework will more closely resemble popular imperative languages such as C++ or Javascript.

Having a lower barrier to entry for new developers means that the Drupal community will grow even faster. This is good news for everyone, since it means more Drupal projects will be created, more Drupal jobs will be available, and the labor pool for Drupal development will be even larger.

 

“Twig” reduces front-end programming, makes it easier to develop site themes

Theming is a huge part of Drupal. It’s what separates the look and feel from the functionality of a site. Previously, Drupal used its own PHP framework for developing and executing theme files. Drupal 8 is integrating the Twig framework from the Symfony library, giving frontend developers a new box full of rich and well-established tools. Twig doesn’t reduce the capability of Drupal’s theme engine, but instead makes it easier to accomplish the same tasks with fewer lines of code.

Since Twig is used widely among Symfony developers, the barrier to entry for newcomers will be lower here, as well. More developers creating themes more easily means that we’ll see a real surge of high-quality themes moving into the future.

 

Streamlined content editing inspired by “Spark”

There are several ways to create content in Drupal 8. The default experience is simple and understandable, but not the most intuitive process. Starting with Drupal 8, the Spark framework will be fully integrated with Drupal core, enabling the following features:

  • True WYSIWYG via drag-and-drop layout tools

  • Powerful save tools: autosaves, drafts, and more

  • Mobile content authoring and administration support

A more streamlined authoring environment means your content creators will spend less time fighting the interface and more time creating great content. Imagine a content authoring system that’s more like Google Docs and less like Facebook Posts. This is the vision of Drupal 8.

 

Redesigned toolbar for centralized navigation

Good user experience begins with intuitive navigation, no matter the framework. Drupal 8 has a redesigned toolbar that appears at the top of the page for any content moderator — not just admins.

 

 

With the new “shortcuts” menu, authors will be able to bookmark popular content. This will be particularly useful during development — both of the site and of content in progress.

 

Accessibility options expand the audience for your site

Drupal 8 has several new accessibility options built into core, such as:

  • Large fonts for the visually impaired

  • Braille export for the severely visually impaired

  • Screen reader export

  • Better multilingual support

In the age of online content, the more markets you can reach with your message, the better. Drupal 8 is bringing content to a whole market segment that very few appeal to — the visually impaired.

In addition, Drupal will have dynamic multilingual capabilities including on-server translation. In areas where Google translate is not available, Drupal will offer to translate pages for users. If you have a dedicated localization team, you can optionally save content for a page in each language and have your team review it.

 

Simpler integration with third-party web applications

Part of the object oriented approach to Drupal 8 is its expanded support for RESTful applications. With the Web Services framework, Drupal will be able to seamlessly communicate with any web platform that uses the REST API. In additional, Drupal content can be serialized between formats such as JSON, XML, binary, and plain text. This enables tighter and more performant integration between different platforms.

Drupal 8’s launch is still half a year away, but the developers at Propeople are already getting excited. Nothing scratches a programmer’s itch like a truly flexible core, and Drupal 8 is all about flexibility. These changes come at the cost of familiarity, however. Instead of a scriptable core, we’ll have a programmable core. Although the transition will take some time to get used to, we agree with Drupal creator Dries Buytaert that the big changes will be worth it.

The upgrade to Drupal 8 won’t be easy, but as Dries Buytaert (the founder of the Drupal project) stated:

The reason Drupal has been successful is because we always made big, forward-looking changes. It’s a cliché, but change has always been the only constant in Drupal. The result is that Drupal has stayed relevant, unlike nearly every other Open Source CMS over the years. The biggest risk for our project is that we don't embrace change.

These words of wisdom apply not just to Drupal, but to any business with a significant online presence. When it comes to websites, the biggest risk in ignoring emerging technologies is the possibility of being left behind. Contact us to learn how Propeople can help you stay ahead.

Tags: Drupal 8Check this option to include this post in Planet Drupal aggregator: planetTopics: Tech & Development

Propeople Blog: Challenges and Opportunities in the Upcoming Drupal 8 Upgrade

Feeds from Drupal.org - Wed, 2014-05-28 19:08

When Drupal 7 reached public release in January of 2011, it made waves for being more accessible and more performant than any Drupal to come before. Drupal 8 is likely to receive similar acclaim in the same vein, but to a much greater degree. Easier to use, better performance, and offering simpler, more flexible development, Drupal 8 is poised to improve the Drupal ecosystem more than ever before.

It’s still around six months until the core change, but this post will run through the challenges and opportunities coming up in Drupal 8.

 

An object-oriented approach lowers the barrier to entry for new developers

Drupal 7 and all previous versions used a procedural approach to scripting. This means that code is executed the same way every time the script is run. Procedural scripts are more reliable, but less customizable. Reliability is good, but in order to capitalize on it, developers must be intimately familiar with exactly what procedures are occurring, and in what order. This depth of knowledge gave Drupal 7 its famous steep learning curve.

The object-oriented approach used by Drupal 8 means that the execution of scripts will be much more dynamic. Functionality is treated like mutable objects, able to be modified programmatically. With object orientation, Drupal will operate more like a true API. Newcomers will appreciate this, since the framework will more closely resemble popular imperative languages such as C++ or Javascript.

Having a lower barrier to entry for new developers means that the Drupal community will grow even faster. This is good news for everyone, since it means more Drupal projects will be created, more Drupal jobs will be available, and the labor pool for Drupal development will be even larger.

 

“Twig” reduces front-end programming, makes it easier to develop site themes

Theming is a huge part of Drupal. It’s what separates the look and feel from the functionality of a site. Previously, Drupal used its own PHP framework for developing and executing theme files. Drupal 8 is integrating the Twig framework from the Symfony library, giving frontend developers a new box full of rich and well-established tools. Twig doesn’t reduce the capability of Drupal’s theme engine, but instead makes it easier to accomplish the same tasks with fewer lines of code.

Since Twig is used widely among Symfony developers, the barrier to entry for newcomers will be lower here, as well. More developers creating themes more easily means that we’ll see a real surge of high-quality themes moving into the future.

 

Streamlined content editing inspired by “Spark”

There are several ways to create content in Drupal 8. The default experience is simple and understandable, but not the most intuitive process. Starting with Drupal 8, the Spark framework will be fully integrated with Drupal core, enabling the following features:

  • True WYSIWYG via drag-and-drop layout tools

  • Powerful save tools: autosaves, drafts, and more

  • Mobile content authoring and administration support

A more streamlined authoring environment means your content creators will spend less time fighting the interface and more time creating great content. Imagine a content authoring system that’s more like Google Docs and less like Facebook Posts. This is the vision of Drupal 8.

 

Redesigned toolbar for centralized navigation

Good user experience begins with intuitive navigation, no matter the framework. Drupal 8 has a redesigned toolbar that appears at the top of the page for any content moderator — not just admins.

 

 

With the new “shortcuts” menu, authors will be able to bookmark popular content. This will be particularly useful during development — both of the site and of content in progress.

 

Accessibility options expand the audience for your site

Drupal 8 has several new accessibility options built into core, such as:

  • Large fonts for the visually impaired

  • Braille export for the severely visually impaired

  • Screen reader export

  • Better multilingual support

In the age of online content, the more markets you can reach with your message, the better. Drupal 8 is bringing content to a whole market segment that very few appeal to — the visually impaired.

In addition, Drupal will have dynamic multilingual capabilities including on-server translation. In areas where Google translate is not available, Drupal will offer to translate pages for users. If you have a dedicated localization team, you can optionally save content for a page in each language and have your team review it.

 

Simpler integration with third-party web applications

Part of the object oriented approach to Drupal 8 is its expanded support for RESTful applications. With the Web Services framework, Drupal will be able to seamlessly communicate with any web platform that uses the REST API. In additional, Drupal content can be serialized between formats such as JSON, XML, binary, and plain text. This enables tighter and more performant integration between different platforms.

Drupal 8’s launch is still half a year away, but the developers at Propeople are already getting excited. Nothing scratches a programmer’s itch like a truly flexible core, and Drupal 8 is all about flexibility. These changes come at the cost of familiarity, however. Instead of a scriptable core, we’ll have a programmable core. Although the transition will take some time to get used to, we agree with Drupal creator Dries Buytaert that the big changes will be worth it.

The upgrade to Drupal 8 won’t be easy, but as Dries Buytaert (the founder of the Drupal project) stated:

The reason Drupal has been successful is because we always made big, forward-looking changes. It’s a cliché, but change has always been the only constant in Drupal. The result is that Drupal has stayed relevant, unlike nearly every other Open Source CMS over the years. The biggest risk for our project is that we don't embrace change.

These words of wisdom apply not just to Drupal, but to any business with a significant online presence. When it comes to websites, the biggest risk in ignoring emerging technologies is the possibility of being left behind. Contact us to learn how Propeople can help you stay ahead.

Tags: Drupal 8Check this option to include this post in Planet Drupal aggregator: planetTopics: Tech & Development
Categories: Straight From Drupal

Flickr: Free Drupal 7 theme #drupal_9086

Feeds from Drupal.org - Wed, 2014-05-28 18:23

Free-Templates.lt posted a photo:

Free Drupal 7 theme #drupal_9086

via Free-Templates.lt - Free Drupal, Wordpress, Joomla themes bit.ly/1gB5Xim FREE-TEMPLATES.LT

Categories: Straight From Drupal

Phase2: Having Drupal Performance Nightmares? Join the Dream Team in Austin!

Planet Drupal - Wed, 2014-05-28 17:45

We’re exactly a week away from the start of DrupalCon Austin and I’ve been working hard over the past two months to button up our High Performance and Scalability with the Dream Team training at DrupalCon Austin. I’ve been honored to give this training at DrupalCon Denver, DrupalCon Munich, and DrupalCon Portland, as well as a free version of it at BADCamp 2013.

The Curriculum

In the training, we go from a base Ubuntu LTS machine and go through the process of configuring it first for a basic LAMP stack and then adding in key pieces of the scalability puzzle like Redis, Varnish, and configuration tweaks that help with front-end performance tweaks for Drupal. We also go over MySQL query analysis and optimization, as well as basic profiling with the Devel module and on into advanced profiling with XHProf to dig into performance problems. (A printed copy is also provided.)

This time around, we’ve done a revamp of the Varnish section to talk about exciting new changes in Varnish 4 and are also adding a good amount of new information on MySQL query analysis and optimization, as well as incorporating considerable feedback from previous trainings.

We also typically try to leave a little time at the end of the training to take freeform questions – the combined team has a wide variety of experience with a number of performance, monitoring, and automation tools. In past years, we’ve set up basic automation with Jenkins, talked about ApacheSOLR and advanced Varnish configuration, and distributed filesystems.

The Team

The team here really is a dream team, and I’m humbled to be able to share the podium with the others trainers every time we do this training.

Dan Reif

Dan is a longtime Drupal sysadmin and a member of the Drupal.org infrastructure team. He helped the Drupal project scale its own web infrastructure, and assists with ongoing performance and stability. By day he is the Director of Emerging Technology at BlackMesh, who offers managed hosting and private cloud solutions to help a variety of customers run their websites without worrying about their management. BlackMesh is generously donating the training server environments to participants in the training so you will have a server reference of the work done in class (provided for a limited time after DrupalCon).

Mark Sonnabaum

Mark Sonnabaum is the Senior Performance Engineer at Acquia. He has contributed significantly to projects that make it easier to scale and manage Drupal including the Redis Queue and XHProf modules as well as considerable work on Drush. He is also the maintainer of the cache and queue subsystems in Drupal core and has dedicated considerable time to improving the architecture of Drupal 8. He has also done a good deal of work on optimizing the performance of Acquia Hosting.

David Strauss

David Strauss was a driving force in creating Pressflow 6, a fork of Drupal which made high-performance sites possible in the Drupal 6.x series. He has helped high-profile clients like Wikimedia Foundation, Creative Commons, The Economist, and NBC Universal scale their web infrastructures to handle massive traffic. He is currently a co-founder at Pantheon where he has been pushing PHP performance to its limits using the latest technologies in the Linux kernel and systemd and empowering major clients to run their Drupal (and WordPress) sites without worrying about servers.

Yours Truly

I’ve had the pleasure over the years of working with major media, publishing, and government clients to ensure that their sites would stay up under heavy traffic load, including helping Robin Hood’s small infrastructure handle millions of visitors for information about their 12-12-12 concert for Sandy relief. I’m also a member of the drupal.org infrastructure team where I manage the logging infrastructure that helps us process more than 2 billion logs a month for aggregation and search to track down errors and help keep all the *.drupal.org properties up and stable. I’ve also recently been doing work on helping to make it easy to scale Drupal on Red Hat’s OpenShift Platform-as-a-Service.

Join Us

As of the publication of this blog post, we still have a few seats left. Please join us in Austin if you manage a Drupal site and want to learn how to scale it!  In the meantime check out Phase2′s top 10 DrupalCon Austin session picks.

Phase2: Having Drupal Performance Nightmares? Join the Dream Team in Austin!

Feeds from Drupal.org - Wed, 2014-05-28 17:45

We’re exactly a week away from the start of DrupalCon Austin and I’ve been working hard over the past two months to button up our High Performance and Scalability with the Dream Team training at DrupalCon Austin. I’ve been honored to give this training at DrupalCon Denver, DrupalCon Munich, and DrupalCon Portland, as well as a free version of it at BADCamp 2013.

The Curriculum

In the training, we go from a base Ubuntu LTS machine and go through the process of configuring it first for a basic LAMP stack and then adding in key pieces of the scalability puzzle like Redis, Varnish, and configuration tweaks that help with front-end performance tweaks for Drupal. We also go over MySQL query analysis and optimization, as well as basic profiling with the Devel module and on into advanced profiling with XHProf to dig into performance problems. (A printed copy is also provided.)

This time around, we’ve done a revamp of the Varnish section to talk about exciting new changes in Varnish 4 and are also adding a good amount of new information on MySQL query analysis and optimization, as well as incorporating considerable feedback from previous trainings.

We also typically try to leave a little time at the end of the training to take freeform questions – the combined team has a wide variety of experience with a number of performance, monitoring, and automation tools. In past years, we’ve set up basic automation with Jenkins, talked about ApacheSOLR and advanced Varnish configuration, and distributed filesystems.

The Team

The team here really is a dream team, and I’m humbled to be able to share the podium with the others trainers every time we do this training.

Dan Reif

Dan is a longtime Drupal sysadmin and a member of the Drupal.org infrastructure team. He helped the Drupal project scale its own web infrastructure, and assists with ongoing performance and stability. By day he is the Director of Emerging Technology at BlackMesh, who offers managed hosting and private cloud solutions to help a variety of customers run their websites without worrying about their management. BlackMesh is generously donating the training server environments to participants in the training so you will have a server reference of the work done in class (provided for a limited time after DrupalCon).

Mark Sonnabaum

Mark Sonnabaum is the Senior Performance Engineer at Acquia. He has contributed significantly to projects that make it easier to scale and manage Drupal including the Redis Queue and XHProf modules as well as considerable work on Drush. He is also the maintainer of the cache and queue subsystems in Drupal core and has dedicated considerable time to improving the architecture of Drupal 8. He has also done a good deal of work on optimizing the performance of Acquia Hosting.

David Strauss

David Strauss was a driving force in creating Pressflow 6, a fork of Drupal which made high-performance sites possible in the Drupal 6.x series. He has helped high-profile clients like Wikimedia Foundation, Creative Commons, The Economist, and NBC Universal scale their web infrastructures to handle massive traffic. He is currently a co-founder at Pantheon where he has been pushing PHP performance to its limits using the latest technologies in the Linux kernel and systemd and empowering major clients to run their Drupal (and WordPress) sites without worrying about servers.

Yours Truly

I’ve had the pleasure over the years of working with major media, publishing, and government clients to ensure that their sites would stay up under heavy traffic load, including helping Robin Hood’s small infrastructure handle millions of visitors for information about their 12-12-12 concert for Sandy relief. I’m also a member of the drupal.org infrastructure team where I manage the logging infrastructure that helps us process more than 2 billion logs a month for aggregation and search to track down errors and help keep all the *.drupal.org properties up and stable. I’ve also recently been doing work on helping to make it easy to scale Drupal on Red Hat’s OpenShift Platform-as-a-Service.

Join Us

As of the publication of this blog post, we still have a few seats left. Please join us in Austin if you manage a Drupal site and want to learn how to scale it!  In the meantime check out Phase2′s top 10 DrupalCon Austin session picks.

Categories: Straight From Drupal

Phase2: Workflow within Open Atrium 2

Planet Drupal - Wed, 2014-05-28 17:37

atrium-logo (1)

A key requirement in most organizations is a content approval workflow.  The typical Drupal solution uses the Workbench Moderation module. However, the Workbench Moderation module only allows you to create a single site-wide workflow.  What if you need different workflows in different Open Atrium spaces, or between different content types?  The solution is the new Open Atrium Workbench module!

The Open Atrium Workbench module, along with several dependent modules, was a collaboration between Phase2 (srjosh and myself) and the Community (dsnopek).  It allows you to define multiple workflow “profiles” and apply them to content types within Open Atrium Spaces and Sections.  It also allows you to specify the Groups and/or Teams who are allowed to moderate content through the workflow.

Workbench Moderation Profiles

OA2_Workflow-3A workflow “profile” is a collection of States and Transitions.  A “State” represents where in the workflow a specific piece of content is, such as “Draft”, “Needs Review”, “Published”, etc.  A “Transition” is the act of moving between two states. Typically a Transition can only be made by a specific set of users with proper permissions.  For example, only members of a specific Working Group might be allowed to approve content, or only members of the Marketing team allowed to Publish content.

The Workbench Moderation module allows you to create these States and Transitions, but applies them globally across the entire site.  The new Workbench Moderation Profile module (currently a sandbox) creates a new entity-type for storing workflow profiles.  The States and Transitions are still created globally by Workbench Moderation, but the actual collection of these being used for a specific workflow are controlled by the profile entity.

Workbench Moderation Profiles is very generic and doesn’t care exactly how these profiles are applied.  Submodules to support Organic Groups and Content Types are provided.  Hooks are available for further control.  The Open Atrium Workbench module uses these hooks to provide Space-specific and Section-specific workflow profiles.

Turning it all on

To add workflow to Open Atrium, download and install the Open Atrium Workbench module and all it’s dependencies.  There are several patches needed to Workbench Moderation documented in the oa_workbench.make file.  Eventually these will get committed to Workbench Moderation and much of the Profile sandbox will be incorporated directly.

Once all of the modules are enabled, the various Drupal permissions and Organic Groups (OG) permissions need to be set.  Permissions in Workbench Moderation are a bit backwards from the norm:  submodules *revoke* access rather than *grant* access.  Typically this means you will set the Drupal Workbench Moderation permissions (including View Unpublished content) to be allowed for all authenticated users, then use OG permissions to restrict to Members and/or Space Admins, then optionally use OA permissions to restrict to Groups/Teams.

OA2 Workflow ContentAfter enabling permissions, you next need to enable Moderation of Revisions on the specific content types that you want to use workflow.  When using Open Atrium, enabling Moderation on a content type will not turn on the workflow features until the Space itself enables a Profile.  Typically this means you will enable Moderation on many content types, such as Document Pages, Events, etc.  In most cases, moderation will *not* be used on Discussion Posts since those are usually ad-hoc discussions that do not require approvals.

OA2_Workflow_Creation-2

Finally, the last step it to create your custom Workbench Profile containing the transitions you wish to include, then enable this workflow Profile for your Space or Section.  For Spaces, the workflow profile is set within the Config/Workbench Moderation page.  For Sections, the workflow profile is set by editing the Section node and setting the profile field.

To limit transitions to Groups or Teams, enable the oa_workbench_access module (included with oa_workbench).  To allow transitions to be scheduled automatically in the future, download and enable the Workbench Moderation Scheduled Transitions module (also a sandbox).

How it works

Once Open Atrium Workbench is configured, creating new content within a Section will display the normal Workbench Moderation messages panel.  This panel provides information about what State the document is in and allows options for moving to a different state if you are approved to make that transition.

OA2_Workflow_messages-3For example, a Member creates a new content Draft.  Once they are happy with the draft, they move it to the “Needs Review” state.  Somebody authorized to review the document visits their “My Workbench” page from their User Badge dropdown menu and goes to the “Needs Review” tab to see all of the content awaiting their approval.  After reviewing the document, they can either Reject the document, sending it back to the Draft state, or they can approve the document, sending it to the Published state.  Only the users authorized to publish the document will see the Published option in the workbench panel.

Once content is published, a new draft can still be made.  Workbench Moderation supports having one revision of content published while a different revision is in the draft state.  The new draft will only replace the currently published revision once it is approved and published via the workflow.

See you at DrupalCon Austin!

For more detailed information on using Open Atrium Workbench, watch my hands-on demo webinar.  If you are coming to DrupalCon Austin, stop by the Phase2 booth for a demo, or schedule a demo to discussion your specific organizational needs.  Or just come to our booth and say “Hi” and tell me about the cool and interesting ways you are using Open Atrium 2 in your organization.

While I’ve been using the default publishing approval workflow as my example, each organization has different workflow needs.  The workflow profile used for publishing documents is quite different from the workflow used to manage tasks or issues.  The workflow used in a private section (if any) is likely different than the workflow used in a public section.  Open Atrium supports all of these different cases in a systematic and easy-to-use way, consistent with users familiar with the Workbench Moderation module.  This functionality makes Open Atrium a key solution in the Enterprise Collaboration space on par with many non-Open-Source systems.

Phase2: Workflow within Open Atrium 2

Feeds from Drupal.org - Wed, 2014-05-28 17:37

atrium-logo (1)

A key requirement in most organizations is a content approval workflow.  The typical Drupal solution uses the Workbench Moderation module. However, the Workbench Moderation module only allows you to create a single site-wide workflow.  What if you need different workflows in different Open Atrium spaces, or between different content types?  The solution is the new Open Atrium Workbench module!

The Open Atrium Workbench module, along with several dependent modules, was a collaboration between Phase2 (srjosh and myself) and the Community (dsnopek).  It allows you to define multiple workflow “profiles” and apply them to content types within Open Atrium Spaces and Sections.  It also allows you to specify the Groups and/or Teams who are allowed to moderate content through the workflow.

Workbench Moderation Profiles

OA2_Workflow-3A workflow “profile” is a collection of States and Transitions.  A “State” represents where in the workflow a specific piece of content is, such as “Draft”, “Needs Review”, “Published”, etc.  A “Transition” is the act of moving between two states. Typically a Transition can only be made by a specific set of users with proper permissions.  For example, only members of a specific Working Group might be allowed to approve content, or only members of the Marketing team allowed to Publish content.

The Workbench Moderation module allows you to create these States and Transitions, but applies them globally across the entire site.  The new Workbench Moderation Profile module (currently a sandbox) creates a new entity-type for storing workflow profiles.  The States and Transitions are still created globally by Workbench Moderation, but the actual collection of these being used for a specific workflow are controlled by the profile entity.

Workbench Moderation Profiles is very generic and doesn’t care exactly how these profiles are applied.  Submodules to support Organic Groups and Content Types are provided.  Hooks are available for further control.  The Open Atrium Workbench module uses these hooks to provide Space-specific and Section-specific workflow profiles.

Turning it all on

To add workflow to Open Atrium, download and install the Open Atrium Workbench module and all it’s dependencies.  There are several patches needed to Workbench Moderation documented in the oa_workbench.make file.  Eventually these will get committed to Workbench Moderation and much of the Profile sandbox will be incorporated directly.

Once all of the modules are enabled, the various Drupal permissions and Organic Groups (OG) permissions need to be set.  Permissions in Workbench Moderation are a bit backwards from the norm:  submodules *revoke* access rather than *grant* access.  Typically this means you will set the Drupal Workbench Moderation permissions (including View Unpublished content) to be allowed for all authenticated users, then use OG permissions to restrict to Members and/or Space Admins, then optionally use OA permissions to restrict to Groups/Teams.

OA2 Workflow ContentAfter enabling permissions, you next need to enable Moderation of Revisions on the specific content types that you want to use workflow.  When using Open Atrium, enabling Moderation on a content type will not turn on the workflow features until the Space itself enables a Profile.  Typically this means you will enable Moderation on many content types, such as Document Pages, Events, etc.  In most cases, moderation will *not* be used on Discussion Posts since those are usually ad-hoc discussions that do not require approvals.

OA2_Workflow_Creation-2

Finally, the last step it to create your custom Workbench Profile containing the transitions you wish to include, then enable this workflow Profile for your Space or Section.  For Spaces, the workflow profile is set within the Config/Workbench Moderation page.  For Sections, the workflow profile is set by editing the Section node and setting the profile field.

To limit transitions to Groups or Teams, enable the oa_workbench_access module (included with oa_workbench).  To allow transitions to be scheduled automatically in the future, download and enable the Workbench Moderation Scheduled Transitions module (also a sandbox).

How it works

Once Open Atrium Workbench is configured, creating new content within a Section will display the normal Workbench Moderation messages panel.  This panel provides information about what State the document is in and allows options for moving to a different state if you are approved to make that transition.

OA2_Workflow_messages-3For example, a Member creates a new content Draft.  Once they are happy with the draft, they move it to the “Needs Review” state.  Somebody authorized to review the document visits their “My Workbench” page from their User Badge dropdown menu and goes to the “Needs Review” tab to see all of the content awaiting their approval.  After reviewing the document, they can either Reject the document, sending it back to the Draft state, or they can approve the document, sending it to the Published state.  Only the users authorized to publish the document will see the Published option in the workbench panel.

Once content is published, a new draft can still be made.  Workbench Moderation supports having one revision of content published while a different revision is in the draft state.  The new draft will only replace the currently published revision once it is approved and published via the workflow.

See you at DrupalCon Austin!

For more detailed information on using Open Atrium Workbench, watch my hands-on demo webinar.  If you are coming to DrupalCon Austin, stop by the Phase2 booth for a demo, or schedule a demo to discussion your specific organizational needs.  Or just come to our booth and say “Hi” and tell me about the cool and interesting ways you are using Open Atrium 2 in your organization.

While I’ve been using the default publishing approval workflow as my example, each organization has different workflow needs.  The workflow profile used for publishing documents is quite different from the workflow used to manage tasks or issues.  The workflow used in a private section (if any) is likely different than the workflow used in a public section.  Open Atrium supports all of these different cases in a systematic and easy-to-use way, consistent with users familiar with the Workbench Moderation module.  This functionality makes Open Atrium a key solution in the Enterprise Collaboration space on par with many non-Open-Source systems.

Categories: Straight From Drupal

Pages

Subscribe to My Drupal aggregator