Skip to Content

Planet Drupal

Syndicate content
Drupal.org - aggregated feeds in category Planet Drupal
Updated: 1 day 5 hours ago

Annertech: Check out my website - it's responsive! Yawn!

28 January 2015 - 6:00am
Check out my website - it's responsive! Yawn! //--> "OMG! You've got a responsive website!"

Once something to brag about, this is now old news.

Categories: Drupal

ThinkShout: Reimagined Sprints and Introducing RedHen Raiser

27 January 2015 - 4:00pm

We’ve been experimenting with monthly team sprints at ThinkShout over the last year with varied levels of structure and outcomes. This month, we decided to take a step back, reevaluate our goals, and reimagine our sprint process. And, we moved it to a Thursday. A bow-tie Thursday.

Previously, these sprints were loosely structured around a topic or technology, such as Twig in Drupal 8. Suffice it to say, they were a lot of fun and very exploratory, but they weren’t the most engaging for everyone on the team. This time around, we decided to collaborate on a single initiative - in this instance, a product - that would benefit from the skills and perspectives of everyone in the company. Consequently, we decided to rally around RedHen Raiser, our new peer-to-peer fundraising distribution for Drupal.

Introducing RedHen Raiser

RedHen Raiser is designed for building peer-to-peer fundraising websites, like the sites you see for marathons and walks, where a fundraising campaign is made up of myriad individual and team pages, and can be customized by the participants for fundraising amongst their respective communities, while remaining connected to the larger campaign.

As the name suggests, RedHen Raiser is built on top of RedHen CRM, including the RedHen Donation and RedHen Campaign modules, and it’s chock full of awesome:

  • Easy Campaign creation so site visitors can join right away by creating their own Team or Individual fundraisers.

  • A beautiful, consistent fundraising experience that is based on inherited display values from the larger Campaign.

  • Goal progress widgets including thermometers, leaderboards, etc.

  • Mini-blogs for Campaigns and Fundraisers via Update content type.

  • Ability to create and maintain different pages for different fundraisers with a single account.

  • Automated start and end dates.

  • Commerce-readiness - just add your payment method and go!

  • Single-page donation forms via RedHen Donation.

  • Built using established modules with simple UI (Views, RedHen, Context, etc) for easy customization.

It’s ThinkShout’s latest offering in a suite of nonprofit engagement building blocks that we’ve been developing, and was initially developed for the Capital Area Food Bank of Washington, DC. RedHen Raiser competes feature for feature with top software as a service (SaaS) peer-to-peer fundraising platforms, such as TeamRaiser, CauseVox and Razoo.

As a result of our work with this client, we were able to release a very rudimentary version of RedHen Raiser on Drupal.org that would provide a basic starting point to other developers interested in building a peer-to-peer fundraising tool. The product is also a huge win for CAFB of DC, simply because they were able to reap a huge dividend on their initial investment by getting these improvements for free.

Involving the Full Team in One Sprint

As an open source product, RedHen Raiser presented us with some interesting opportunities to engage more than just our engineers in the sprint process, and it certainly needed a lot of love on a lot of fronts. Leveraging the different interests and expertise of our 18-person company, we split into five teams:

  • Dev Ops - this team focused on deployment infrastructure, build processes, and automated testing;

  • Bug Fix & Feature Dev - team members spent the sprint day working on the development backlog;

  • UX - the User Experience team worked ahead of the feature development team to identify and sketch out new features and enhancements;

  • QA - the Quality Assurance team was made up of our project managers acting as "product owners;"

  • Community Engagement - this team, consisting of our sales, marketing, and operations staff, was tasked with documenting the sprint and sharing our contributions with the wider Drupal and nonprofit technology communities.

It’s worth noting that the quality assurance team and the community engagement team came together for the first half of the sprint for an in-depth training on the Drupal contributed modules and components underlying RedHen Raiser. Ironically, we often get so busy building these sorts of tools for our clients that we don’t stop to educate our own "non-developer" team members on how stuff works. By taking this time to dive into the nitty gritty with our project managers, marketing and operations folks, we create better advocates for these solutions and help ensure that everyone in the company feels like contributor to our success.

Planning for the Sprint

As ThinkShout has grown, the need for sprint planning has grown with it. Back when we first started these sprints, we could fit our entire team around a single table (covered in pizza boxes and beer) and call out with development tickets we each needed help with.

Now, with a team of 18 working together from 11am to 5pm, these sprints take a bit more planning - to say nothing of balancing the opportunity cost of investing a collective 108 hours of non-client work into a single week. To keep things running smoothly, we’ve taken a more project-planning-esque approach to our sprint days:

  • Scheduling in advance: The date and time of the sprint is scheduled a month in advance. We used to just stick with the last Friday of the month, but found that this sometimes excluded certain team members on deadlines or vacation. Now, we coordinate a bit more tightly to help ensure participation of as many team members as possible.

  • Laser focus: the focus of the sprint is announced to the team three weeks in advance. This gives the team time to think about stuff they want to work on, and add to the feature backlog in the weeks coming up to the sprint.

  • Pre-sprint planning meetings: The department leads meet a week before the sprint to form teams and structure the sprint agenda, and prioritize the development/feature backlog two days in advance of the sprint.

  • Pre-sprint presentations: The week before the sprint, we do a short, company-wide presentation on the sprint topic at our weekly staff lunch. This helps energize the team and sparks knowledge sharing in the lead up to the sprint day.

  • Formally "opening" and “closing” the sprint day: As our sprint commences, we kick things off with a quick, all-staff scrum. More importantly, we pull the team back together at the end of the day for each sprint team to present (and celebrate!) what they’ve completed.

Outcomes of Our RedHen Raiser Sprint

So what does it all mean? This new approach to our team sprints resulted in just shy of 100 commits on RedHen Raiser and the underlying modules that power the distribution. We published a new release of RedHen Raiser, RedHen Donation and the RedHen Campaign modules - as well as a release of our base RedHen CRM suite.

One of the biggest wins to come out of the sprint are automated tests powered by Behat. Tests are triggered with every commit to GitHub and run on Travis CI. At this point, test coverage is a bit limited, but the foundation has been laid for complete test coverage for RedHen Raiser, a critical factor when organizations are evaluating which software to use.

To top it off, we cleaned up a few RedHen project pages on Drupal.org and began working on a RedHen-specfic QA testing plan. We also reached out to the RedHen open source community to let them know what we were up to and how folks can continue to get involved. Most of all, we are proud to say that this effort is a huge contribution to the nonprofit tech community, in that it provides major improvements to a powerful tool that can be leveraged for free - and has the documentation to support it!

All in all, the ThinkShout team came together in a big way, and accomplished much more than we could have if we had remained siloed in our approach. We had a lot of fun, drank some beer, ate some good food, and got to collaborate as a whole team on something really cool. We’re really looking forward to the next one!

Categories: Drupal

Drupal Commerce: Shipping the Future

27 January 2015 - 10:57am
Shipping Requirements Have Changed

Heretofore, shipping has focused on exposing a simple yet effective API for connecting rating and shipping companies to the checkout process. Many stores eschew real-time rating and instead opt to offer flat-rate shipping or free shipping on orders. This entirely removes the need for rating. For those who do use real-time rating, the existing process offers a simple set of tools that are only adequate for simple shipping needs.

Categories: Drupal

DrupalCon News: Calling UX Designers

27 January 2015 - 10:13am

Welcome UX Design experts. We want to hear your latest thoughts, ideas, techniques and analysis on the latest state of the web. If you’ve got a burning idea you want to share about how to do things better, we want to hear about it.

We’re looking for talks on:

Categories: Drupal

Cheeky Monkey Media: How to automatically send your content to social networks

27 January 2015 - 9:00am

A few months ago I was asked to help manage our company blog. As a busy drupal developer, I had little time to post all of our new blog content on every social media site. So I decided to automate this so I could spend more time on client projects.

My first step was to look around and see what was currently available. Although there was some options, I found them to be a bit heavy for my application.

One of the things I was looking for was to be able to choose what social networks our content would be posted to. For example, I wanted to be able to choose to post this page to...Read More

Categories: Drupal

Aten Design Group: Creating Custom Ctools Layout Plugins with Yeoman

27 January 2015 - 7:30am

As a front-end developer working with Drupal, I often need to create custom Ctools layout plugins. Ctools is an essential suite of tools for Drupal developers and the basis of many popular modules, including Views, Panels, Context and Display Suite. Its layout plugins provide a flexible alternative to Drupal’s core page region system.

Creating a custom Ctools layout plugin for Drupal is actually quite easy. You define your layout in a .info file, create the html structure in a template (*.tpl.php), style it in a stylesheet (*.css or *.scss) and provide a thumbnail image so the site administrator has an idea of what it looks like. Each of these files follows similar but slightly different naming conventions. This can be tedious when you need to create a number of custom layouts for a project as we often do at Aten.

My previous workflow looked like this.

  1. Find another layout plugin – either an existing custom layout or one from the Panels module.
  2. Copy that folder into the plugins folder in my module or theme.
  3. Rename the folder to match my plugin.
  4. Rename all the files to match my plugin’s name, using the appropriate naming convention and file extensions.
  5. Edit the .info file to point to the appropriate files and change the array of regions to match the new layout.
  6. Edit the template file to match the newly created regions.
  7. Write the CSS to style the layout.
  8. Create a new thumbnail image.

A lot of these steps consist of copy, paste, find and replace – the kind of stuff that’s better suited for computers. That's where Yeoman comes in. Yeoman is a scaffolding tool. It's most often used to quickly create boilerplate code that can be customized to your needs.

I recently published a Yeoman generator that automatically creates a ctools layout plugin based on a few simple settings. Now my workflow looks like this:

  1. Create a directory for my plugin.
  2. Type yo ctools-layout.
  3. Answer questions about my layout.
  4. Add any extra markup to the template file.
  5. Write the CSS to style the layout.
  6. Create a new thumbnail image.

The new workflow eliminates the tedious tasks and allows me to focus on the code that makes a given layout unique: markup, style and a thumbnail.

Here’s how to use it.

Install Yeoman *note: Yeoman is a Node.js tool, so you need to install Node.js in order to use it.

To install Yeoman type the following into your terminal:

npm install yo -g

The -g flag installs this package globally. Doing so allows you to run the yo command outside of an existing node project. A common Yeoman use case is scaffolding out a brand new project, after all.

Note: Depending on your environment, you may need to run these commands with sudo.

Now you have the general Yeoman application. But to be useful, you need some generators.

npm install ctools-layout-generator -g

The ctools layout generator assumes you already have a custom module or theme that you are adding a layout to. For this example we'll assume this custom layout is in our theme. From your theme's root directory create a new directory for your layout plugin, change to your new directory and run the ctools_layout generator command.

mkdir plugins/layout/landing_page cd plugins/layout/landing_page yo ctools_layout

Yeoman will prompt you with a few questions about your layout, such as the name of your layout, the name of the module or theme it exists in and the regions you want to include. After answering the questions, Yeoman creates all the necessary files needed for a working layout.

The ctools layout generator makes no assumptions about what your layout looks like or the actual CSS styles and markup needed to make it functional. That's your world! It's completely up to you. It simply takes your list of regions and adds them to the layout's .inc file and to the template file in which you can add the appropriate markup.

Similarly, the generator will add a placeholder .png thumbnail of your layout. The generator has no idea what you have in mind for your layout, so you'll want to create your own thumbnail and save it over the placeholder. The thumbnail is important as it gives the end user a good idea of what the layout looks like. I've shared a Photoshop template that I use for creating layout thumbnails.

I hope you find this useful. If run into any problems or have feedback, please create an issue on github.

P.S. In case yeoman isn’t your thing, there is a drush plugin that has similar functionality and works for more than just layouts.

Categories: Drupal

Gábor Hojtsy: Drupal 8 multilingual tidbits 17: content translation basics

27 January 2015 - 7:27am

I just updated all prior 16 posts in this series with up to date screenshots and text over the weekend and here is the new post!

In the introduction to content and configuration translation piece we discussed what is considered content in Drupal 8. This is a somewhat misleading term because custom blocks, custom menu items and even user entities (user profiles) are considered content in terms of their implementation.

Content is always stored as entities. The main difference between configuration and content entities is configuration is usually created on the backend (think views, vocabularies, etc.) while content is usually created on the frontend (think free tagging taxonomy terms, comments, blog posts). This is not a black and white differentiation but it helps think of the categories. The other key differentiator is content entities usually get to have configurable fields. You can add new fields to user profiles, taxonomy terms or comments. Again there are exceptions, for example custom menu items cannot get configurable fields in core. Finally, there are even content entities that will not be stored, in Drupal 8 contact form submissions are content entities that live only until they are sent via email. For this tidbit we are concerned for content entities that are stored and multilingual.

Categories: Drupal

Drupal Easy: Creating a Talent Underpinning

27 January 2015 - 6:09am

Having just completed presenting the Drupal career training portion of AcquiaU, we are anticipating great experiences for all ten students as they begin their eight weeks of rotations within three different business groups within Acquia. The past two months have been a whirlwind of teaching, learning and team building, which provided great insight into a forward-thinking approach to building Drupal talent, made possible by the commitment of Acquia.

We are pleased to have contributed to the new AcquiaU with the customization of our Drupal Career Online curriculum. I’d like to share some great lessons learned, as well as introduce the ten people who were lucky enough (luck favors the prepared) to be selected for this amazing program.

-->

read more

Categories: Drupal

Makina Corpus: Turning hackability into a use case

27 January 2015 - 4:45am
When a CMS does not allow happy hacking anymore, it loses a very valid use case.
Categories: Drupal

InternetDevels: Drupal module for messages just like in Facebook

27 January 2015 - 2:00am

We worked hard during a few days and developed our own module called Private message with node.js.

Read more
Categories: Drupal

Appnovation Technologies: 5 Cool Drupal Websites

26 January 2015 - 3:27pm
It’s hard enough trying to find cool websites in general, let alone cool websites made using Drupal. var switchTo5x = false;stLight.options({"publisher":"dr-75626d0b-d9b4-2fdb-6d29-1a20f61d683"});
Categories: Drupal

Phase2: Ultimate Flexibility: Open Atrium’s New Related Content Feature

26 January 2015 - 1:00pm

The constant struggle between content editors and web developers:

  • Content editors want to embed rich media, callouts, and references to related content anywhere within their WYSIWYG.  They love the Body field and want more buttons added to the WYSIWYG.
  • Web developers want to add additional fields for media, attachments, related content to support rich content relationships and access control.  Web developers hate the Body field and wish they didn’t need a WYSIWYG.

In the latest 2.30 version of Open Atrium, we attempt to help both content editors and web developers with a new approach to building rich story content using the Paragraphs module.  Rather than having a single WYSIWYG body, content editors can build their story using multiple paragraphs of different types and layouts. The order of these paragraphs can be rearranged via drag and drop to create long-form content.

Site builders can add their own custom paragraph types to their sites, but Open Atrium comes with four powerful paragraph types “out of the box”:

(1) Text Paragraphs

The simplest paragraph type is the “Text” paragraph.  It works just like the normal Body field with it’s own WYSIWYG editor.  But an additional Layout field is added to control how the text is rendered.  There are options for multiple columns of wrapping text within the paragraph (something nearly impossible to do with the normal Body field), as well as options for left or right floating “callouts” of text.

(2) Media Gallery

The “Media Gallery” paragraph handles all of the images and videos you want to add to your story.  It can replace the normal Attachments field previously used to add media to a document.  Each Media paragraph can contain one or more images, videos, or files.  The Layout field controls how that media is displayed, providing options for left or right floating regions, or a grid-like gallery of media.  Videos can be embedded as preview images or full video players.

When floating media to the left or right, the text from other paragraphs will flow around it, just as if the media had been embedded into the WYSIWYG.  To move the images to a different part of the story, just drag the media paragraph to a new position in the story.

In Open Atrium, images directly embedded into the Body WYSIWYG field becomes Public, bypassing the normal OA access control rules.  However, anything added to a Media paragraph works more like the Attachment field and properly inherits the access permission of the story document being created.  Thus, the Media paragraph provides a way to embed Media within your story while retraining proper privacy permissions.

(3) Snippets

The “Snippet” paragraph type allows you to embed text from any other content on your site.  You can specify whether the Summary, Body, or full Node is embedded and also control the Layout the same as with Text paragraphs.  You can also either display the Title of the referenced content or hide the title, or override the title with your own text.

One of the best features of Snippets is the ability to lock which revision you want to display.  For example, imagine you want to embed a standard operating procedure (SOP) within your story document.  You create a Snippet paragraph that points to the SOP.  However, if the related SOP node is updated in the future, you don’t want your old document to change.  For compliance purposes it still needs to contain the original SOP text.  By “locking” the snippet to the old revision, the old document will continue to display the original SOP even if the SOP is updated later.  If you “unlock” the snippet, then it will display the latest version of the related SOP.

Open Atrium access controls are also respected when displaying snippets.  If you reference content that the user doesn’t have permission to view, that snippet will be removed from the displayed text.  Users still only see the content they are allowed.  This provides a very powerful way to create rich documents that contain different snippets of reusable content for different user roles and permissions.  Similar to adding additional fields with Field Permissions, but much more flexible and easy to use.

(4) Related Content

The “Related Content” paragraph type is similar to Snippets, but displays the Summary or Full rendered node of the related content.  Like the Media paragraph, the Related Content can contain one or more references to other content on the site.  The Layout provides options for displaying the content as a table of files, or a list of node summaries (teasers), or as full node content.  When full node content is used, any paragraphs used in the related content will also being displayed (paragraph “inception”!).  In addition, any special fields from the full related node can be shown.  For example, a Related Event will show the map of the event location.  A Related Discussion will show all of the discussion replies and even provide the Reply Form, allowing you to reply to a related discussion directly from the story document itself!

Related Content is also a bi-directional link.  When you view the related content node, a sidebar widget called “Referenced From” will show all of the stories that reference the node being viewed.

A Real World Example

To pull all of this together with a real-world example, imagine that you are scheduling a Meeting.  You want to create an Agenda for that meeting and allow your team to discuss and edit the agenda before the meeting.  In Open Atrium you can now do this all from a single document:

  1. Create the Event for the Meeting, adding your team to the Notifications
  2. Add a Related Content paragraph for the meeting Agenda document
  3. Add a Related Content paragraph for the agenda Discussion

Open Atrium is smart about where this related content is created.  If you already have a section for documents, the Agenda will be created within that section.  If you already have a section for discussions, the related discussion will be placed there.  You can change these locations if you wish, but the default behavior reflects the most common information architecture.

When your team members receive the email notification about the meeting and click the link, they will be taken to your Event and will see the agenda document and discussion as if they were a normal part of the event body.  They can view the agenda content directly and can post replies directly into the discussion reply field.  They don’t need to go to separate places on the site to see the document or discussion.  If you *do* view the document or discussion nodes directly, such as from a search results page, you’ll see a link back to the meeting event in the References From list in the sidebar.

Conclusion

Not only do the Paragraph features help content editors build rich stories quickly and easily, they allow web developers to create related documents, linked content, better search results, better data structures.  It’s still not a magical unicorn wysiwig of content editor’s dreams, but it’s a significant step for Open Atrium and Drupal. It opens a whole new world of collaboration where all related content can be viewed together.

Looking for more information about Open Atrium? Sign up to receive Open Atrium newsletters and updates! Don’t miss our winter release webinar on Wednesday, January 28th, at 11am EST!

Categories: Drupal

Chocolate Lily: Drupal 8 and distributions part 2: problems and prospects

26 January 2015 - 11:10am

This is part two of a series on configuration management challenges in Durpal 8. Part 1 looked at challenges for small sites and distriubtions.

What is the state of support for distributions in Drupal 8?

Trying to gauge the state of anything in Drupal 8 has its inherent pitfalls. The software itself is still changing rapidly, and efforts in the contributed extensions space have barely begun.

Categories: Drupal

Another Drop in the Drupal Sea: Seeking Pilot members for Udemy Drupal Training course

26 January 2015 - 10:22am

The Kickstarter campaign was not funded, but that does not mean that it was not successful! We are still moving ahead. I've just published my first course on Udemy and would like to get pilot members to provide feedback so that I can make sure the course ends up being world class.

Here is a coupon code to access the course for free: https://www.udemy.com/getting-started-with-drupal-for-total-beginners/?c...

read more

Categories: Drupal

Web Omelette: Creating a custom Views filter in Drupal 8

26 January 2015 - 12:05am

In the previous article we've seen how we can interact programatically with Views in Drupal 8 in order to create a custom field in our Views results. Today, we will be looking a bit at how we can create a custom filter you can then add to the View in the UI and influence the results based on that.

The code we write here will be available also in this repository together with the one we explored in the previous tutorial.

Filters in Views have to do with the query being run by Views on the base table. Every filter plugin is responsible with adding various clauses in this query in an attempt to limit the results. Some (probably most) take on configuration parameters so you can specify in the UI how the filtering should be done.

If you remember from the last article, to create our field we extended the FieldPluginBase class. Similarly, for filters, there is a FilterPluginBase class that we can extend to create our own custom filter. Luckily though, Views also provides a bunch of plugins that extend the base one and which we can use or extend to make our lives even easier. For example, there is a BooleanOperator class that provides a lot of the functionality needed for this type of filter. Similarly, there is an InOperator class, a String class, etc. You can find them all inside the views/src/Plugin/views/filter directory of the Views core module.

In this tutorial, we will create 2 custom filters. One will be a very simple one that won't even require creating a new class. The second one will be slightly more complex and for which we will create our own plugin.

The code we write will go in the same module we started in the previous article and that can be found in this repository.

Node type filter

The first filter we will write is very simple. We want to be able to filter our node results by the machine name of the node type. By default, we can use a filter in which we select which node types to be included. Let's say, for the sake of argument, we want a more complex one, such as the one available for a regular text value like the title. The String class will be perfect for this and will provide actually 100% of our needs.

So let's go to our hook_views_data_alter() implementation and add a new filter:

... $data['node_field_data']['node_type_filter'] = array( 'title' => t('Enhanced node type filter'), 'filter' => array( 'title' => t('Enhanced node type filter'), 'help' => t('Provides a custom filter for nodes by their type.'), 'field' => 'type', 'id' => 'string' ), ); ...

Since the table that we are interested in altering the query for is the node_field_data table, that is what we are extending with our new filter. Under the filter key we have some basic info + the id of the plugin used to perform this task. Since our needs are very simple, we can directly use the String plugin without us having to extend it. The most important thing here though is the field key (under filter). This is where we specify that our node_type_filter field (which is obviously a non-existent table column) should be treated as being the type column on the node_field_data table. So, by default, the query alter happens on that column. And this way we don't have to worry about anything else, the String plugin will take care of everything. If we didn't specify that, we would have to extend the plugin and make sure the query happens on the right column.

And that's it. You can clear your cache, create a View with nodes of multiple types and add the Enhanced node type filter to it. In its configuration you'll have many matching options such as equals, contains, does not contain etc you can use. For example, you can use contains and specify the letters art in order to return results whose node type machine names contain these letters.

Node title filter

The second custom filter we build will allow Views UI users to filter the node results by their title from a list of possibilities. In other words, they will have a list of checkboxes which will make it possible to include/exclude various node titles from the result set.

Like before, we need to declare our filter inside the hook_views_data_alter() implementation:

... $data['node_field_data']['nodes_titles'] = array( 'title' => t('Node titles'), 'filter' => array( 'title' => t('Node titles'), 'help' => t('Specify a list of titles a node can have.'), 'field' => 'title', 'id' => 'd8views_node_titles' ), ); ...

Since we are filtering on the title column, we are extending again on the node_field_data table but with the title column as the real field to be used. Additionally, this time we are creating a plugin to handle the filtering identified as d8views_node_titles. Now it follows to create this class:

src/Plugin/views/filter/NodeTitles.php:

<?php /** * @file * Definition of Drupal\d8views\Plugin\views\filter\NodeTitles. */ namespace Drupal\d8views\Plugin\views\filter; use Drupal\views\Plugin\views\display\DisplayPluginBase; use Drupal\views\Plugin\views\filter\InOperator; use Drupal\views\ViewExecutable; /** * Filters by given list of node title options. * * @ingroup views_filter_handlers * * @ViewsFilter("d8views_node_titles") */ class NodeTitles extends InOperator { /** * {@inheritdoc} */ public function init(ViewExecutable $view, DisplayPluginBase $display, array &$options = NULL) { parent::init($view, $display, $options); $this->valueTitle = t('Allowed node titles'); $this->definition['options callback'] = array($this, 'generateOptions'); } /** * Override the query so that no filtering takes place if the user doesn't * select any options. */ public function query() { if (!empty($this->value)) { parent::query(); } } /** * Skip validation if no options have been chosen so we can use it as a * non-filter. */ public function validate() { if (!empty($this->value)) { parent::validate(); } } /** * Helper function that generates the options. * @return array */ public function generateOptions() { // Array keys are used to compare with the table field values. return array( 'my title' => 'my title', 'another title' => 'another title', ); } }

Since we want our filter to be of a type that allows users to select from a list of options to be included in the results, we are extending from the InOperator plugin. The class is identified with the @ViewsFilter("d8views_node_titles") annotation (the id we specified in the hook_views_data_alter() implementation).

Inside our plugin, we override three methods:

Inside init(), we specify the title of the set of filter options and the callback that generates the values for options. This callback has to be a callable and in this case we opted for the generateOptions() method on this class. The latter just returns an array of options to be presented for the users, the keys of which being used in the query alteration. Alternatively, we could have also directly created the options inside the init() method by filling up the $this->valueOptions property with our available titles. Using a callback is cleaner though as you can perform various logic in there responsible for delivering the necessary node titles.

The point of overriding the query() and validate() methods was to prevent a query and validation from happening in case the user created the filter without selecting any title. This way the filter has no effect on the results rather than returning 0 results. It's a simple preference meant to illustrate how you can override various functionality to tailor your plugins to fit your needs.

And that's it. You can add the Node titles filter and check the box next to the titles you want to allow in the results.

Conclusion

In this article we've looked at how we can create custom filters in Drupal 8 Views. We've seen what are the steps to achieve this and looked at a couple of the existing plugins that are used across the framework which you can use as is or extend from.

The best way to learn how all these work is by studying the code in those plugin classes. You will see there if they are enough for what you want to build or extending them makes sense. In the next article we are going to look at some other Views plugins, so stay tuned.

var switchTo5x = true;stLight.options({"publisher":"dr-8de6c3c4-3462-9715-caaf-ce2c161a50c"});
Categories: Drupal

Drupal Association News: Drupal.org team week notes #31: 2014 in review

25 January 2015 - 4:24am

Now that we are few weeks into 2015, we’d like to look back at 2014 and share some interesting numbers about Drupal.org.

Audience

Last year Drupal.org received almost 48.9 million visits from 21.2 million unique visitors. The spike around September/October is due to spam-related traffic, and, of course, DrupalCon Amsterdam.

Users

152,200 users logged in to Drupal.org at least once during the year. Out of those, 31,466 users performed at least one activity on the site, such as commented, created a node or committed code.

More than 21,500 people left a comment or more in the issue queues. More than 4,000 people commented in the Drupal core issue queue.

Commits

Overall 145,907 commits happened on Drupal.org, with more than 4,000 commits to Drupal core specifically.

More than 3,200 people committed code to contributed projects (not counting Drupal core), with an average of 37.43 commits per user.

More than 1,400 people got commit mention in Drupal core patches.

Comments & Issues

Our users left 569,217 comments, 94% of them were comments in the issue queues. 30% of all comments in the issue queues happened in Drupal core queue.

On average there were 22.4 comments per user, with 38.74 comments per user in the Drupal core issue queue.

Our users created 78,505 issues, with an average of 4.55 issues per user.

5,192 contributed projects were created on Drupal.org in 2014. 31% of those are sandbox projects.

Infrastructure

On the infrastructure side our uptime was 99.97% over 12 months, and the average full page load time for the year is 3.64 across Drupal.org. It improved throughout the year; we are down to 3.08 as an average for December. Our time to first byte response was 1,374ms in January; we are down to 441ms for December.


Drupal.org testbots tested over 33,300 patches. An average test queue and test duration times for Drupal 8 core were about 35 minutes each.

Support

On support front 82% of issues in Drupal.org-related issue queues got a response within 48 hours after being created.

An average response time (time between an issue was created and first comment not by issue author) across all issue queues on Drupal.org was 82.87 hours. For Drupal core issue queue this number was 60.68 hours. For Drupal.org related queues 34.19 hours.

* * *

Full stats you can find in the 2014 stats spreadsheet.

Compared to 2013 some of the user activity numbers go down, which is directly related to the phase of the Drupal release cycle. Right after Drupal 7 release user activity peaked and then was slowly going down as Drupal 7 and contrib ecosystem matured. We are looking forward to Drupal 8 release! In the recent Drupal Association community survey about 80% of respondents said they have firm plans to adopt Drupal 8, suggesting that release will cause a huge boost in user activity on Drupal.org.

2014 was a great year, and thank you for spending some part of it on Drupal.org! We are excited to see what 2015 will bring.

Categories: Drupal

Wellnet Blog: Building Bridges - Webprofiler meets Drupal Console

25 January 2015 - 1:50am

The has the purpose to bring the Symfony Profiler to Drupal 8.

Categories: Drupal

Commerce Guys: Platform.sh hosting for eCommerce – it’s a game changer

24 January 2015 - 12:05pm
Agency and online customer Use Case & experiences

Platform.sh is a 2nd generation Platform as a Service (PaaS). It accelerates your PHP/Drupal/Symfony based project development and reduces the risk of moving new features into live. Some customers are seeing circa. 40% reduction in project budgets and revenue loss prevention, whilst gaining huge improvements in developer productivity, eliminating environmental resource management and reducing live downtime to zero, all at commodity hosting prices! For an Agency providing web development, commerce and hosting services, or the end customer themselves, understanding the detail behind these very powerful messages is an important factor to making the right decisions around the critical tools and technologies that impact their business, especially if say the pricing structure appears to be a little higher than the known alternatives.
 

There is a huge amount of eCommerce experience built into Platform.sh

Commerce Guys are involved in many leading edge developments that are pushing the boundaries of how eCommerce is being utilized and evolved to meet new business models, many of which are tied into faster development, more frequent changes and better uptime. These include the migration of offline customers into advanced online purchase environments; encouraging said customers to spend more money whilst at the same time becoming less expensive to support, requiring tighter integrations of support and customer care functions; also important is the delivery of B2C-like experience for B2B customers; as well as defining online and mobile strategies in conjunction with each other; Drupal 8, Distributions etc. etc.

What gives Commerce Guys the credibility to offer such a convincing project development tool? We are a commercial software vendor, and we’ve invested several $m into building the Drupal Commerce application and its Kickstart distribution (deployed into over 50,000 active sites), so we know how to develop successful software products on an industrial scale. Of further relevance is the deep involvement we have in so many of our partner projects each year, providing analysis, design authority and development skills that puts us in the middle of hundreds of individual and unique development processes ! What we have engineered into the heart of Platform.sh is the flexibility to overcome the big problems and common manual activities that hold project teams back.
 

Different customers, all with common problems

Let’s take a look at a handful of typical eCommerce customers, and work through their issues:

  • A Digital Agency (DA) with a global pharmaceutical client who has many simple but different web-shop brands across 18 European countries.
  • A Systems Integrator (SI) with a high street optician as their customer, with an eCommerce system covering 14 territories. They have all the usual requirements of a high end client plus an unusually complex hosted infrastructure accommodating various index sites and 10 plus environments in each location, totalling 150 service instances.
  • A Retail Fashion client rolling out a Distribution based eCommerce system to 4 geographies.
  • A pureplay online marketing business providing 4,000 products through a Social Media community exceeding 200,000 people in 22 countries around the world, of which the mobile traffic accounts for over 70% of their revenues.

And although both the Agency and the Integrator are at the high end of technical capability, and the 2 retailers have way less experience, they all have similar sets of problems that only Platform.sh seems to be able to solve.

 

Complex eCommerce applications versus simple brochure-ware sites

 

To properly emphasize the advantages that Platform.sh brings to an eCommerce system, we first need to draw a comparison between the complex and transactional nature of these customers’ applications, and that they usually work differently in each country, and as such require various different code bases. By comparison, these are very different for example, to brochure-ware sites with a central content repository, combined with simple language differences plus content change workflow pushed out through a multi-site architecture.
 

Typical lifecycle issues that all 4 of these online businesses worry about

To start with, the development process differences between these two project personalities (multi-region eCommerce and multi-site brochure ware) are significant, the differences being 1) many more environments through which the upstream movement of code is being managed, 2) a much longer code-test-production timeframe, 3) bigger testing overheads (including tools, time and people), 4) complex content approval workflows, 5) higher consequential management costs, and 6) a severe risk impact of changes not working in production and feature release delays due to poor Continuous Integration (CI).

All the above are directly related to revenue loss - exacerbated by reputational damage in severe circumstances – which of course make them fairly unique to eCommerce. The effects on cost, time and business risk all increase exponentially when considering multi-country implementations.

 

What Platform.sh does for eCommerce that nobody else can !

Platform.sh solves many problems specific to this eCommerce Use Case, as well as easing various issues that make such projects more expensive to deliver and very laborious to manage,as follows:

  1. Many development process issues are greatly affected, resulting in a significantly reduced number of coding errors due to inconsistent environments, and greatly reduced elapsed times in the code delivery process from local environment through test, staging and user sign-off.
  2. Hugely improved Continuous Integration (CI) process that speeds up the change process for similar features across multiple environments into different local production services.
  3. True Continuous Delivery (CD) now becomes possible because the process no longer requires large number of changes to be bundled up and tested together before going to production say every 6-8 weeks. In this new regime, even the smallest of changes can whistle through in less than 60 minutes, which is vital for changes to aspects of the ‘Sale Offer’ during peak season, modifying coupon functionality for instance, or making micro changes during the advertising campaign.
  4. Steep cost reductions associated with maintaining multiple static environments (because re-creating from staging for new development environments isn’t possible or takes too long). Developers now have the power to create and destroy their own full-stack environments that mirror staging or say the master.

We’ve learned from various retailers using Platform.sh in the run up to holiday periods and promotions (especially Black Friday, Cyber Monday and December 26th) that the reduced risk of making changes into live offered by Platform.sh, plus the triple redundancy we provide in the Platform Enterprise (PE) offering with its ability to seamlessly upscale around traffic peaks are all regarded as extremely valuable to their business, the combination of which simply cannot be provided by alternate vendors ! This makes Platform.sh a must for any mission critical eCommerce site.

Categories: Drupal

DrupalCon News: Send Us Your Sessions and Training Proposals

23 January 2015 - 4:28pm

Think you’ve got Drupal or web smarts? We’re seeking mind-blowingly good sessions for DrupalCon Los Angeles, and want to hear from you about what you know best.

You don’t have to be the best in everything, but if there’s one topic you know inside and out, you should submit a session.

We’re looking for topics for the following tracks:

Categories: Drupal


Google+
about seo