Migrate API in Drupal 8 and a glimpse at the migration process

Posted by InternetDevels on January 20, 2017 at 4:05pm
Migrate API in Drupal 8 and a glimpse at the migration process

Drupal 8 is so irresistible in its innovations that it just makes you wanna… pack your things and migrate! ;) To “pack” your website’s content and configuration carefully and move them to Drupal 8, there exists a cool tool called Migrate API. As with any relocation, it's easier to “pack your things” when they, let's say, fit into “standard boxes”. The same applies to websites: the less custom functionality they have, the quicker the upgrade process will go.

Read more

Web design trends 2017

Posted by ADCI Solutions on January 20, 2017 at 6:02am

Good practices are always worth maintaining. Since design is a rather vulnerable area, not everybody keeps up-to-date about trends popping up here and there. We got inspired by some of the Drupal designs we've seen recently and would love to share the trends we'd learned with you. We will learn what's better take to 2017 from previous years’ trends. You'll be taken through design approaches, Material design and Atomic design in particular. Then we will proceed to a design process, content representation tips and other visual web trends. We also will introduce few trends that don’t cover design only, but do affect the Web and how users interact. For your convenience we give design examples implemented on Drupal websites - real case studies practiсe. Read the whole article here.

Web design trends 2017

Webinar: How to Manage Media Assets in Drupal 8

Posted by Web Wash on January 20, 2017 at 1:00am
Yesterday I presented a webinar on how to manage media assets in Drupal 8. The webinar went for just over an hour and we looked at the current state of media management in Drupal 7 and what's new in Drupal 8. I spent the rest of the time demonstrating how to: Store media assets using Media Entity. Embedding assets using Entity Embed. Displaying a browser page to browse and select assets using Entity Browser.

Drupal SEO with Ben Finklea

Posted by Lullabot on January 19, 2017 at 9:00pm
Mike and Matt sit down with Ben Finklea, and talk all things SEO and Drupal, including his new book "Drupal SEO."

Submit a Front End Session for DrupalCon Baltimore!

Posted by Amazee Labs on January 19, 2017 at 5:14pm
Submit a Front End Session for DrupalCon Baltimore!

This is my fourth year as a member of the North American DrupalCon Program Team. Each year, I'm surprised how quickly the submission deadline rolls around. The conference is in late April, but did you realize the submission deadline is less than two short weeks away?

Kathryn McClintock Thu, 01/19/2017 - 18:14 photo of a flip clock

I imagine if the deadline sneaks up on me—a person looped into the event’s planning—how easy it must be for a community member to miss the deadline altogether. That’s why I hope this blog post reaches many of my fellow Front End Drupalers.

The DrupalCon Baltimore Call for Proposals ends Wednesday, February 1st at 11:59pm (EST). Learn about the Front End track and the types of topics and submissions we’re hoping to receive.

There are many reasons you should consider submitting a Front End session: a complimentary ticket to the conference, an opportunity to reach a broad audience, and most importantly, a chance to share your knowledge and passion with like-minded community members.

This is an exciting time in Drupal’s history—there are many appealing and universal reasons to get involved. If you’ve been learning / researching / doing cool things with Drupal’s Front End, we want you!

So, be sure to submit a Front End session today!

DIY Drupal hosting

Posted by lakshminp.com on January 19, 2017 at 12:42pm

The meta stuff

I'll be writing a series of posts exploring DIY drupal hosting options. Many agencies and freelancers need a workflow to manage and maintain their Drupal sites on a budget. Of course, they incur the cost of maintiaining and deploying the system(at least initially) and the additional learning curve involved in using the system, but they get the following advantages:

  • More control over the hosted sites. It is easy to create and deploy new environments to demo sites to clients, triage bugs, run tests etc.

Entity browser feature freeze will happen in two weeks

Posted by Janez Urevc on January 19, 2017 at 8:56am
Entity browser feature freeze will happen in two weeks

Today I released Entity browser 8.x-1.0-beta4. Release includes some nice features; specially Improved MultiStep selection display, which vastly improves editorial experience.

This is also the last release before the feature freeze, which will happen on February 3rd 2017. No new features will be accepted after that day until 8.x-1.0 is released. Feature requests that are not breaking backward compatibility will be accepted after that.

Huge thanks to all contributors. It has been an interesting and very rewarding ride!

slashrsm Thu, 19.01.2017 - 09:56 Tags Drupal Media Enjoyed this post? There is more! Join us at the next Drupal Media sprint at the Mountain camp in Davos! Results of the Drupal 8 media sprint Call for Drupal 8 media ecosystem co-maintainers

Building Views Query Plugins for Drupal 8, Part 3

Posted by Lullabot on January 19, 2017 at 1:39am

Welcome to the third part of our series on writing Views query plugins. In part 1, we talked about the planning work that should precede coding. In part 2, we covered the basics of actually writing a query plugin. In this final chapter, we will investigate some enhancements to make your plugin more polished and flexible.

Exposing configuration options

Allow Site Admins to set their preferred units: metric or imperial.

Most Fitbit endpoints accept an option to set the units the response is returned in. If you are Canadian like me, you know that metric is preferable, but it’s also in our nature to be be nice, so we should expose a configuration option to allow our American friends to show data in their anachronistic imperial units. (I jest, love you guys!)

Exposing configuration options for a query plugin is done in two parts. First, build the UI and, second, make use of the stored configuration. In our query plugin class, we’ll implement two methods to help us create the UI, defineOptions and buildOptionsForm :

/**
 * {@inheritdoc}
 */
protected function defineOptions() {
  $options = parent::defineOptions();
  $options['accept_lang'] = array(
    'default' => NULL,
  );
  return $options;
}
/**
 * {@inheritdoc}
 */
public function buildOptionsForm(&$form, FormStateInterface $form_state) {
  parent::buildOptionsForm($form, $form_state);
  $form['accept_lang'] = [
    '#type' => 'select',
    '#options' => [
      '' => $this->t('Metric'),
      'en_US' => $this->t('US'),
      'en_GB' => $this->t('UK'),
    ],
    '#title' => $this->t('Unit system'),
    '#default_value' => $this->options['accept_lang'],
    '#description' => $this->t('Set the unit system to use for Fitbit API requests.'),
  ];
}

With this done, we should see our configuration options in the Views UI under Advanced > Query settings.

undefined

However, it won’t work because we’re not actually using the stored configuration yet. To do that, we’ll add to our execute method in our query plugin:

/**
 * {@inheritdoc}
 */
public function execute(ViewExecutable $view) {
  // Set the units according to the setting on the view.
  if (!empty($this->options['accept_lang'])) {
    $this->fitbitClient->setAcceptLang($this->options['accept_lang']);
  }
  // Clip...
}

Query plugin options are available via $this->options, which Drupal provides as part of the QueryPluginBase class that our Views plugin is extending. We use the stored value, together with a method on the Fitbit client service to set the preferred units for all subsequent API requests: $this->fitbitClient->setAcceptLang($this->options['accept_lang']); . With that, site admininstrators can set their preferred units, and the result set will reflect that choice. Since this is Views and we’ve exposed height as a numeric field, Views core gives us a nice way to format the data and suffix it with units so we end up with a polished result. Just edit the field options.

undefined Field plugin options

Adding options to customize the appearance of the avatar field.

Views also allows us to have custom options for our field plugins. In the last article, we set up a field plugin for avatar which uses the avatar URI from the API response and renders it as an <img> tag. Fitbit’s API actually provides two avatar size options and it would be great to leave it to the site administrator to decide which size to render. We’ll use field plugin options to do that.

As with query plugins, exposing configuration options for a field plugin follows the same two parts, with one small addition. In our query plugin class, we’ll implement two methods, defineOptions and buildOptionsForm , to build the UI:

/**
 * {@inheritdoc}
 */
protected function defineOptions() {
  $options = parent::defineOptions();
  $options['avatar_size'] = ['default' => 'avatar'];
  return $options;
}
/**
 * {@inheritdoc}
 */
public function buildOptionsForm(&$form, FormStateInterface $form_state) {
  $form['avatar_size'] = [
    '#type' => 'select',
    '#title' => $this->t('Image size'),
    '#options' => [
      'avatar' => $this->t('Default (100px)'),
      'avatar150' => $this->t('Medium (150px)'),
    ],
    '#default_value' => $this->options['avatar_size'],
    '#description' => $this->t('Choose the size avatar you would like to use.'),
  ];
  parent::buildOptionsForm($form, $form_state);
}

This should be fairly self explanatory; we’re defining a form element for the UI and, once saved, the configuration option will be stored in $this->options['avatar_size'] . The small addition I referred to earlier lies within the query plugin. Before, we were only passing along the single value for avatar. Now that the site administrator has the option, we’ll want to make sure both values for avatar are passed along in the Views result. We do that, in the query plugins execute method like so:

$row['avatar'] = [
  'avatar' => $data['avatar'],
  'avatar150' => $data['avatar150'],
];

Instead of a flat value, we’re setting ‘avatar’ to an array with both values for avatar from the API response. Then, back in the field plugin, in the render method, we take care to use the appropriate size avatar according to the option selected:

/**
 * {@inheritdoc}
 */
public function render(ResultRow $values) {
  $avatar = $this->getValue($values);
  if ($avatar) {
    return [
      '#theme' => 'image',
      '#uri' => $avatar[$this->options['avatar_size']],
      '#alt' => $this->t('Avatar'),
    ];
  }
}

We simply call $this->getValue($values), which is able to pull out the value we want from the ResultRow object. The render method receives a ResultRow object that has all of the data for the row. FieldPluginBase has a getValue method which we can access since we are extending FieldPluginBase . With that done, we can now click on the avatar field in the Views UI and set the desired image size:

undefined Filter plugins

Filtering the leaderboard by user id.

What if we wanted to limit the result to only a particular user? Say we wanted to show a user's Fitbit details on their Drupal user profile page. For that, we’d need to filter the result set by a user id. To make that happen, we need a Views filter plugin. The first step is to define the field to filter on in hook_views_data():

/**
 * Implements hook_views_data().
 */
function fitbit_views_example_views_data() {
  // Base data and other field definitions...
  $data['fitbit_profile']['uid'] = [
    'title' => t('User id'),
    'help' => t('Drupal user id, not to be confused with Fitbit profile id.'),
    'field' => [
      'id' => 'standard',
    ],
    'filter' => [
      'id' => 'fitbit_uid',
    ],
  ];
  return $data;
}

The part we are most concerned with here is the ‘filter’ key. Its value is an associative array with one key ‘id’, which we set to the name of the filter plugin we’re going to create. Also, note the ‘field’ key, which makes the Drupal user id available as a field in the Views UI. It doesn’t hurt to add it, and it also illustrates how plugins related to a certain field (e.g. field, filter, and others like relationship and argument) are all defined in the same array in hook_views_data(). So, for the next step, we’ll create this file: fitbit_views_example/src/Plugin/views/filter/Uid.php 

<?php
namespace Drupal\fitbit_views_example\Plugin\views\filter;
/**
 * Simple filter to handle filtering Fitbit results by uid.
 * @ViewsFilter("fitbit_uid")
 */
class Uid extends FilterPluginBase {
}

So far, this is typical Drupal 8 plugin scaffolding code. The file is placed in the right folder for the plugin type. The namespace follows PSR-4 naming. The annotation for the plugin type assigns an id to our plugin. Finally, we extend the base class provided by Views for the plugin type. Now let’s look at the specifics required for our filter plugin implementation:

class Uid extends FilterPluginBase {
  public $no_operator = TRUE;
  /**
   * {@inheritdoc}
   */
  protected function valueForm(&$form, FormStateInterface $form_state) {
    $form['value'] = [
      '#type' => 'textfield',
      '#title' => $this->t('Value'),
      '#size' => 30,
      '#default_value' => $this->value,
    ];
  }
}

$no_operator = TRUE tells Views that we are not interested in the site administrators having an option to select an operator. In our case, we’ll keep things simple and always assume '='. You could, of course, allow for choice of operators if your remote service supports it. The key component here is the valueForm method. In it, we need to set an appropriate Form API element for the ‘value’ key of the $form array passed as the first argument. The name ‘value’ is important as the base class expects this key to work. The form element that you return is used in a couple of places. It’s used in the Views UI for when the site administrator is setting up a filter. It’s also used if the filter is exposed, rendered in the exposed filters form with the view itself. That’s it for the plugin implementation.  At this point we can add the filter in the Views UI:

undefined

The last step adjusts our query plugin to be able to handle and make use of the filter. The first thing we’ll need to do is implement an addWhere method on the query plugin class:

public function addWhere($group, $field, $value = NULL, $operator = NULL) {
  // Ensure all variants of 0 are actually 0. Thus '', 0 and NULL are all
  // the default group.
  if (empty($group)) {
    $group = 0;
  }
  // Check for a group.
  if (!isset($this->where[$group])) {
    $this->setWhereGroup('AND', $group);
  }
  $this->where[$group]['conditions'][] = [
    'field' => $field,
    'value' => $value,
    'operator' => $operator,
  ];
} 

Here, especially, we can see Views’ biases to SQL rear its head. The method name, addWhere, is odd from our perspective of querying a remote service. There is no notion of a WHERE clause present in the Fitbit API. Further, Views supports grouping filters, and logical operators within each group. Here again, the remote service we are using has no notion of this. It’s possible the remote service your implementing does in which case the flexibility Views affords is amazing. In our case it’s overkill, but I’ve copied core Views implementation for the SQL query plugin, so we’ll be able to handle everything that the Views UI allows for setting up filters. The final step is adjusting the execute method on our query plugin to incorporate the filter into the call to the Fitbit API:

/**
 * {@inheritdoc}
 */
public function execute(ViewExecutable $view) {
  // Clip ...
  if (isset($this->where)) {
    foreach ($this->where as $where_group => $where) {
      foreach ($where['conditions'] as $condition) {
        // Remove dot from beginning of the string.
        $field_name = ltrim($condition['field'], '.');
        $filters[$field_name] = $condition['value'];
      }
    }
  }
  // We currently only support uid, ignore any other filters that may be
  // configured.
  $uid = isset($filters['uid']) ? $filters['uid'] : NULL;
  if ($access_tokens = $this->fitbitAccessTokenManager->loadMultipleAccessToken([$uid])) {
    // Query remote API and return results ...
  }
}

Here, we’re looping through any filters that have been configured on the view and grabbing their values. We then ignore any other filter that may have been configured on the view, since we’re only supporting uid for now and pass it along to $this->fitbitAccessTokenManager->loadMultipleAccessToken([$uid]), which will limit the access tokens we get back to just the uid set and only show us results for the corresponding user.

Often, as was the case on a recent client project, the filters that you set up will actually get passed along in the remote API request. The Fitbit API is a bit odd in this regard in that most endpoints only return data for a single user anyway, so there is no filtering that makes sense.

That’s it! After all that work, we can set up a filter by uid to limit the results to a single user.

Wrap up

We did it, at long last, we’ve produced a custom Fitbit leaderboard, which might look something like this:

undefined

Of course this is just stock Drupal 8 with the Fitbit module installed and configured, but it’s Views and we all know how to customize the look and feel of Views, so make it pretty to your heart's content.

While we've looked at a lot of code, I don't think that any of it has been horribly complicated. It's mostly a matter of knowing what to put where, with a healthy dose of planning to make sure our data fits into the Views paradigm properly. In summary, the steps are:

  1. Make a plan of attack, taking into account the data you're retrieving and the way Views expects to use it.

  2. Create field handlers for your data as necessary.

  3. Write remote queries to retrieve your data and store it in rows in the view object.

  4. Write filter plugins as necessary to narrow the result set.

There's a lot of work in those steps, but after running through it a couple times the architecture makes a lot of sense.

Get the code!

The code from this article can be found in the Fitbit module on drupal.org. It consists of a base module to handle application setup, authentication and access token storage and two sub-modules for Views integration. The first is fitbit_views_example, which I created specifically for this article series. You’ll find all the code we went through in there. The other one, fitbit_views is a more fully featured and slightly more complex version, including spanning multiple API endpoints with relationship plugins. You should use fitbit_views if your intending on using this functionality on your Drupal site. Feel free to file issues and patches!

Phew, that was a lot. Thanks for sticking with me through it all. Special thanks to Greg Dunlap for trusting me with the reboot of his original series, which has guided me through my own Views query plugin implementations. Thanks also to the Fitbit module maintainer, Matt Klein, who was kind enough to grant me co-maintainer rights on the project.

Great UX design with Drupal

Posted by Appnovation Technologies on January 18, 2017 at 9:37pm

Drupal is the #1 platform for web content management systems. It powers millions of websites in more than 180 languages, with a massive online community with more than 26,000 constantly building and sharing themes and resources.

Project Management: The Unsung Hero of Project Success

Posted by DrupalCon News on January 18, 2017 at 4:30pm

Project management is often the unsung hero in our work. When a project is completed on-time, on-budget, and in-scope, the wheels of innovation keep moving. However, when poor project management takes hold, the work, creativity, and excitement can come to a screeching halt.

Extending PureCloud for Drupal customer support integration

Posted by Third & Grove on January 18, 2017 at 12:45pm
Extending PureCloud for Drupal customer support integration mike Wed, 01/18/2017 - 07:45

Set Required and Optional Address Inputs for Address Field in Drupal 8

Posted by TimOnWeb.com on January 18, 2017 at 12:44pm

This one is dedicated to all my fellow Drupalers. There’s no better exercise for a brain than reading ancient chinese poetry taming Drupal 8. When I’m bored, I turn to Drupal!

Recently I got my Drupal 8 Address module updated and it turned out that from now on street address ...

Read now

10 Drupal modules for quizzes

Posted by ADCI Solutions on January 18, 2017 at 9:11am

Quizzes and contests are the ways to improve a user activity and to grab the attention of even a rather passive user. We’ll tell about Drupal modules enabling different widgets and voting feature/quizzes features: Webform default fields, Quiz, Advanced Poll and other are combined in this compilation. Click! :)

Drupal modules for quizzes, polls and contests

SRI International Drupal Case Study

Posted by Third & Grove on January 18, 2017 at 8:00am
SRI International Drupal Case Study antonella Wed, 01/18/2017 - 03:00

Using Panels to Build Page Layouts in Drupal 8

Posted by OSTraining on January 18, 2017 at 6:34am
Using Panels to Build Page Layouts in Drupal 8

One of our OSTraining members asked about the current state of the Panels module in Drupal 8. They already had experience with Panels in Drupal 7.

Panels is one of the most popular ways to create page layouts in Drupal.

In this quick tutorial, we will show you have to create your Panel in Drupal 8. The process is definitely different when compared to Drupal 7, although many similarities remain.

For this tutorial, you do not need to have experience with Panels.

Drupal + Cloud9

Posted by Mike Crittenden on January 17, 2017 at 10:26pm
Drupal + Cloud9 Clouds

Cloud9 is an IDE and development environment in the cloud. Yeah yeah, buzzwords buzzwords, but what does this really mean?

Let's dig in a bit, starting with the positives.

What I Like

I've been using it heavily for a few months now, and here are the features that stand out to me. 

Workspaces

C9 gives you "workspaces", each of which is a complete Ubuntu-based environment (i.e., a Docker container behind the scenes). This means that you can install stuff, use sudo, change config, etc. You can create and delete workspaces as you please.

You can really go to town on these things in pretty much any way that is useful. 

Workspace cloning

C9 also lets you clone workspaces to create new ones. Cloning is super fast - usually around 30 seconds for me from start to finish. This means I can do things like having a stock "Drupal" workspace that has all the tools and config that I like to have for Drupal projects, which I just clone when setting up a new Drupal site. There are other cool possibilities here too, which I'll get to shortly.

Sure, theoretically Vagrant and friends let you do this already for local environments, but the speed and ease that C9 brings to this process is unmatched compared to anything I've seen.

Out of the box debugging (for Node.js, PHP, Go, and C++)

Interactive debugging is already there, waiting for you. In PHP for example, you just click the little "bug" icon before running your app, and then set a breakpoint wherever you want. No messing with xdebug config or path mappings or exposing ports, none of that. Just click and you're done.

This is especially nice for me on the Node.js side, since I've never learned how to set up a Node debugger and don't particularly want to.

Custom runners

Cloud9 environments come with some pre-configured "runners", which are basically commands that you can run by clicking a button, and have their output stuck into their own tabs. For example, starting the app typically means starting the "Apache" runner to get the server running, which will throw Apache logs into the output of that tab. 

That's all fine, but it gets more interesting when you create custom runners. You can drop in a name and command and some configuration such as the current directory, and then you have a nice little command runner waiting to be clicked. I like this for things like "grunt watch" which watches for Sass updates, but it's even more useful for commands with hard to remember names, so that you can kind of abstract that away. It's like shell aliases on steroids, in a way.

Performance

Cloud9 is surprisingly quick given that it's a pretty bulky web app. I don't have an insanely powerful laptop or anything, and I found the Cloud9 IDE to be responsive enough that I never really saw any noticeable slowness, which is the goal after all.

What I don't like

No VPNs

Due to the way Cloud9 is built, it can't really connect through an existing VPN. So if you're trying to work on a site that is hidden behind a VPN, then it might be test to avoid Cloud9 for that project.

IDE limitations

The C9 IDE is ok, but not good, and definitely not great. If PHPStorm is a 9/10 in terms of IDE functionality, then Cloud9 is more like a 4 or a 5. It's a pretty decent text editor, but a pretty lame IDE.

For example, it's missing features like:

  • Jumping directly to a function definition from somewhere that function is called
  • Auto-generating block comments with @params, etc., based on function code
  • Function parameter hinting as you type
  • Viewing all usages of a given function
  • Project-wide autocompletion that works smartly and consistently

Restricted workspace cloning

You can only clone your own workspace - you can't clone someone else's. This means that it's basically impossible to have a setup where a tech lead manages a "pristine" project workspace which everyone else can clone whenever they need to start fresh, or when new people are ramped on. I love the sound of that workflow, and it's disappointing that it isn't allowed.

Credit card required for signup

You can't sign up to C9 without entering your credit card info, even for the free accounts. This isn't the end of the world for me or possibly for you, but it can be a real bummer when you want to give someone on your team access to your codebase to do some pair programming. The "how much do I really want this?" factor kicks into high gear when you're asked to pull out your credit card.

Use cases

Open source work

C9 is great for doing open source work. It gives you the ability to share your code or your environment when anyone just by sending a link,  which can help a lot when collaborating on something remotely that is only on your local environment.

Plus, with workspaces being so cheap and powerful, you can have a separate workspace for each open source project that you maintain. That way, you always have an environment ready to be worked on for everything, and you never have to wonder if that environment you build 6 months ago for module X is still running and working.

Demos

Creating a workspace specifically for a demo (or a prototype or anything else temporary that you want to show other people) can be really nice. It even gives you a URL to share with people so they can try out your demo with their own two hands.

This lets you work on your demo in a clean, empty environment, which can just be deleted when you're done. 

Random fiddling around

You know that thing where there's a new tool or app or whatever that you want to try installing, but you don't want to worry about adding more dependencies or possibly bringing in a different version of a dependency that will break something else? 

The speed with which you can spin up C9 workspaces is great here. Create a workspace in a few seconds, do whatever you want, and delete it. That way you never have to worry about leaving any remnants of your random tinkering on your main computer.

Pair programming

One of the banner features of C9 is the ability to live-edit code along with other people, and see each other's updates in real time. If you ever pair program, then this is basically the dream. It sure beats screen sharing over a Google Hangout. 

Debugging

The out of the box debugger support kind of automatically makes "debugging" a good use case for Cloud9. The fact that you have a full Ubuntu environment means that you can usually change whatever you need to change to replicate your prod setup, and the built in debugger can take it from there to help you find your bug.

Again, you can always just use Docker yourself to replicate an environment and install Xdebug, but this is just so much easier.

Regular old development

If you can live without advanced IDE features, and you don't need a VPN to access anything, then you can really do most of your regular everyday development on C9. That way you have cheap workspaces and easy debugging and shareable URLs for everything that you work on.

Tips

Finally, here are some tips for getting the most out of Cloud9, especially if you're using it for Drupal.

1. Start each workspace from a starter instance that has all the tools you need

For example, create a "Drupal" starter workspace that has Drush, Drupal Console, Apache config, git aliases, XHprof (here are installation instructions), etc. Then, whenever you spin up a new site, just clone that workspace.

2. Create per-ticket workspaces

Taking workspace cloning to the next level, you can just create a stock workspace for your project which you never actually touch except to keep it up to date. Then just clone it every time you start work on a new ticket. That way you can have completely separate environments for unrelated workstreams, and you never have to worry about clobbering data or whatnot when switching back and forth. Plus, that ticket you worked on 3 weeks ago will still have a working environment to go back to when it fails QA and needs a fix.

3. Make the keybindings match your main editor/IDE

Cloud9 has fully configurable keybindings for just about everything. This means that you can make C9 keyboard shortcuts match the ones you're already used to from your normal editor/IDE. That way it's really easy to switch back and forth. There are even Vim and Emacs modes!

4. Create custom runners for all the things

Think of all the commands you run on a regular basis. Things like "grunt watch" or "drush cc all" or "drush updb -y && drush fra -y", etc. Put all of those things in custom runners, so you can just click a button to watch them run in their own tab. This is especially useful for complex commands that you're likely to forget.

5. Go crazy with the layout

C9 lets you drag and drop tabs to dock to the left or right or bottom, and resize however you want. You can have a terminal on the right and server logs at the bottom, or keep them all in tabs in the same place. It's up to you. 

6. Don't ignore the project search (and replace)

If you're like me then you might be tempted to install The Silver Searcher or Ack or just use grep to search your codebase. Before you do that, at least give C9's code search a try. It's fast, it supports regex, and it gives you lots of options about where you want to search. It's surprisingly robust, so give it a shot.

The end

Overall I think Cloud9 is really pretty great for what it is. It's lacking some IDE features and it suffers a bit unavoidably just based on the fact that it's cloud based, but it also solves a lot of real world problems that make up for all that in most cases.

I'm using it for a pretty big chunk of my day to day development nowadays, and it's saved me plenty of headaches.

Do you have any concerns or questions? Feel free to comment below if so. I'm curious to hear about the types of things holding other people back from using it.

mcrittenden Tue, 01/17/2017 - 17:26

How to Choose the Right eCommerce Solution for Your Drupal Project

Posted by Zivtech on January 17, 2017 at 8:24pm
Store open sign Drupal has a powerful suite of tools and features for just about any type of website, and eCommerce websites are no exception. Drupal has a very active and healthy eCommerce community that creates some amazing features.

The Drupal eCommerce market mainly consists of Ubercart and Drupal Commerce, but there are also some impressive emerging technologies to keep an eye on, such as the Stripe payment API, that allow for more customized solutions.

The eCommerce solution that you choose will depend upon the particular Drupal site you’re developing. Is it a simple online store with just a few products, or a much more robust site with a wide variety of products? This is one of the strengths of eCommerce with Drupal: you can build the kind of solution you need without the extra, unnecessary features and functionalities. Ubercart vs Drupal Commerce Drupal Commerce is by far the most popular Drupal eCommerce solution these days. It’s the successor to the original eCommerce solution, Ubercart. Drupal Commerce was written for Drupal 7 by the same developer that created Ubercart, Ryan Szrama, using the latest APIs and features for Drupal 7.

Drupal Commerce is supported by Ryan Szrama’s company, Commerce Guys, and the Drupal community as a whole. Developers are more likely to add new features to Commerce because it is more widely used in Drupal 7 and beyond. The Drupal 8 version is still in beta, so more work needs to be done to get it to a full release. Check out the Drupal Commerce issue queue to see where you might be able to help.

Drupal Commerce learned from Ubercart's primary shortcoming; it was difficult to configure and not very modular. Where Ubercart was one module that was difficult to build upon, Drupal Commerce has a small set of features in the main module and a large suite of available contributed modules. This allows for easier configuration and more customizations. Kickstart Your Online Store One of the most useful features available for Drupal Commerce is the Commerce Kickstart Drupal distribution. This is a great way for non-technical store owners to get a Drupal Commerce store up and running quickly and easily. It comes with an impressive installer that allows you to install an example store to see how everything can be configured. It then allows you to wipe the site clean and start a fresh build of your own custom store.

The Commerce Kickstart comes with some additional built in modules and configurations that help get a Drupal Commerce site up and running quickly. This is a more efficient solution than building from scratch with the Drupal Commerce module and any contributed modules that are necessary to achieve the desired functionality. The Commerce Kickstart distribution shows off the power of Drupal distributions; it’s a turnkey solution for Drupal eCommerce websites. Stripe API One of Drupal’s greatest advantages over its competitors is how well it integrates with third party APIs. This allows for integration with many different payment gateways, one being Stripe API. Drupal developers can integrate Stripe with a Drupal site through a custom module and create highly customized payment solutions. This type of customization allows for a variety of solutions for selling and accepting payments that would be more challenging to implement with Drupal Commerce. Which Solution Should I Choose? The solution you choose depends on the site’s needs. A small online store that only needs a simple shopping cart might be best suited for Ubercart. At its core, Ubercart is still the easiest to set up without using a Drupal distribution like Commerce Kickstart.

Drupal Commerce is a much more robust eCommerce solution for Drupal with enterprise level features that large online stores use to sell products like product displays. On top of that, you get all the features of a normal Drupal website like content types, taxonomies, and user permissions.

If you are looking to build a very customized payment solution that doesn’t really fit into either of these categories, perhaps a custom solution with the Stripe API module is best.

In the end, the Drupal eCommerce solution you choose should be easy to use for your store administrators and easy for your customers to buy your products online.

Managing Complex Configuration with Drupal 8

Posted by Chromatic on January 17, 2017 at 5:34pm

Configuration management (CM) in Drupal 8 is great. However, when more complex configuration scenarios arise, we must find solutions to problems that core CM functionality doesn’t address (yet).

Chromatic at DrupalCon Dublin

Posted by Chromatic on January 17, 2017 at 5:34pm

Learn all about Twig templates in Drupal 8 from our very own Larry Walangitan.

Drupal Code Standards: Documentation

Posted by Chromatic on January 17, 2017 at 5:34pm

This is the fourth post in a series about coding standards. In this post we’ll talk about why good, standardized documentation is crucial to your project, and review Drupal coding standards regarding documentation and comments.

Pages

Subscribe with RSS Subscribe to Drupal.org aggregator - Planet Drupal