clemens-tolboom opened issue build2be/drupal-8-rest-angularjs#3

On github - 2 hours 42 min ago
Feb 1, 2015 clemens-tolboom opened issue build2be/drupal-8-rest-angularjs#3 Solve the problem json versus hal+json

clemens-tolboom pushed to master at build2be/drupal-8-rest-angularjs

On github - 2 hours 52 min ago
Feb 1, 2015 clemens-tolboom pushed to master at build2be/drupal-8-rest-angularjs

clemens-tolboom pushed to develop at build2be/drupal-8-rest-angularjs

On github - 2 hours 55 min ago
Feb 1, 2015 clemens-tolboom pushed to develop at build2be/drupal-8-rest-angularjs

DrupalOnWindows: Distinct options in a views exposed filter: The Views Selective Filters Module

Planet Drupal - 12 hours 7 min ago

You have built an application where there was a taxonomy or options field with more values defined in them than what was really being used after release. And these fields are being used as exposed filters in a View. This basically means that you end up with an option in an exposed filter that yields no results when selected. Not a good UI behaviour, and confusing for the end user.

Language English

Ryan Szrama: Why not combine shopping carts on user login?

Planet Drupal - Sat, 2015/01/31 - 8:06pm

When I first wrote Ubercart's Cart module, we knew we were going to support both anonymous and authenticated shopping carts and checkout. The decision came at a time when there wasn't consensus around the impact of forced login on conversions, but we knew we wanted it to be optional if at all possible. Additionally, for authenticated users, we wanted to preserve items in their shopping carts so they would see the same items when logging in from multiple devices or across multiple sessions.

This resulted in a small conflict that we had to figure out how to deal with: users could have items in their authenticated shopping carts but browse the site anonymously, create a new shopping cart, and then log in. What should happen to the items in their authenticated carts vs. the items in their anonymous carts?

There are three basic resolutions: combine the shopping carts together so the user still has a single shopping cart, remove the items from the previous session and leave it up to the customer to find them again if desired, or retain the old shopping cart but ignore it until the customer has completed checkout for the current cart. In Ubercart, I chose to combine the items, but in Drupal Commerce I changed course to retain the old cart but, from the customer's point of view, treat that anonymously created cart as the current cart after login.

We got some push back for this decision, but ultimately I didn't change the default functionality of Drupal Commerce. We just made sure there was an appropriate hook (hook_commerce_cart_order_convert()) so developers could alter this behavior on a site-by-site basis as need be.

From the merchant's standpoint, the thinking behind combining carts goes that you don't want customers to forget they intended to purchase those products in the past. However, from the customer's standpoint, suddenly having additional items in the cart after logging in during the checkout process is quite jarring.

In fact, I've been bitten by this behavior when shopping online at Barnes & Noble. Weeks prior to placing an order, I had put a Wheel of Time novel in my shopping cart but eventually bought the book in store. When I came back to the site to purchase a gift for my wife, I used a login button on the checkout form to quickly reuse my previous addresses and payment details. Unbeknownst to me, the website combined my old shopping cart with my current one such that my "quick checkout" experience made me accidentally order a book I already owned! I then had to spend 30 minutes with customer service canceling the order and placing it afresh just for the book I actually wanted.

That experience confirmed in my mind we made the correct decision not to combine carts automatically. As eCommerce framework developers, we have no clue where a developer might like to integrate login during the checkout process. Best to let them decide if it's safe to do something with those previous cart items instead of silently making the decision for them.

That said, I believe we can improve the experience. Right now, Drupal Commerce retains the old shopping cart order, and after the customer completes checkout they'll see the previous shopping cart as their current cart. This can be confusing as well! My ideal situation would likely be a user interface component on the shopping cart page where customers can see items they had added to their carts in previous sessions, giving them the option to add those products to their current carts. If they decide not to, I don't see any harm in then just deleting those historical carts and moving on.

There's always room for improvement.

Photo credit: alphageek


clemens-tolboom opened issue build2be/drupal-8-rest-angularjs#2

On github - Sat, 2015/01/31 - 4:48pm
Jan 31, 2015 clemens-tolboom opened issue build2be/drupal-8-rest-angularjs#2 bower.json file misses

KatteKrab: How does Drupal use these different terms? Route, Path, URL, URI, Link, Menu item

Planet Drupal - Sat, 2015/01/31 - 2:29am
Saturday, January 31, 2015 - 12:29

Sometimes, diving in to try and help work on something in an open source project can leave you feeling stupid, lost and confused. Generally, you'll find you are not alone. Sharing the problem, and the solution when you find it, can be helpful to build your own understanding, but also might help others too. So, just in case I'm not the only one feeling lost and confused about why the path / route / link issue in Drupal is so complex, I thought I'd share some of my confusion and a little ray of light that might help unravel this tangle of related terminology.

In the Drupalverse, we use IRC to connect with each other.  So I popped into channel and asked:

Can someone describe how drupal uses these terms? route, path, url, uri, link, menu item - or point me to a reference?

Angela Byron generously responded with a rough outline of definitions, which I've fleshed out a bit below with some references.


"this URL goes to this PHP code, and can only be accessed by these kind of people."
As far as I can tell, this is a relatively new concept for Drupal with routing and controllers, replacing the hook-menu system we had previously. Here's a couple of references that might be helpful if you want to build a deeper understanding.


Uniform Resource Locator eg. "" It's generally the address we use to find content on the web.


Uniform Resource Identifier is often confused with URL because it's so similar. See the URI wikipedia page for more information. I'm not sure if or how Drupal distinguishes between the use of URIs, URLs and URNs (Uniform Resource Names), but let's save that yak to shave on another day.

The Build a module team made a video that describes the difference between a URL and a URI
What the difference is between a URI and a URL (a Drupal how-to)


The path is like a pathway to find content eg. admin/content but because it can be an alias, it may not actually represent the location of a file on disk, which helps lead to some of the complexity under the hood in Drupal, and the confusion about when to use, /blog/yakshaving, or node/5


<a href="/foo">foo</a> - This one seems pretty straightforward - it's the HTML markup used to point to a URI or path.

Menu item

A link in a menu - which could be pointing to a route, path or URI.

Hope that helps you, it certainly helps me to lay it all out like this. And, just in case you're wondering how I fell down this rabbit hole, this relates to a series of critical issues holding up the release of Drupal 8.  If you can help, please get involved  or buy a ticket in my chook raffle to help fund the Drupal 8 Accelerate initiative.


Drupal Association News: Help us welcome our four new staff members

Planet Drupal - Fri, 2015/01/30 - 10:06pm

The Drupal Association is thrilled to announce the addition of four new staff members. As part of our goal to increase Drupal adoption and provide the community with strong support and advocacy, the organization has been growing at a rapid rate over the past year. Now, we’re welcoming four new staff members into the fold. Please help us say hello to Elise, Lucia, Rachel, and Tim!

Elise Horvath, Operations Team, Operations Coordinator

Elise (EliseH1280) is joining the Operations team as an Operations Coordinator. She will manage key details of the Drupal 8 Accelerate program, will manage the Drupal Store, will assist Operations with any accounting needs, and will assist the board of directors by managing meetings and schedules and taking meeting minutes. Prior to joining the Association, Elise worked in logistics and operations for scrum training services. When not working, Elise enjoys spending time with her fiance, watching movies, cooking and baking, riding her bike, and going to Disney World whenever she has the chance!

Lucia Weinmeister, Revenue Team, Sponsor Fullfillment Coordinator

Lucia (lweinmeister) is the Association’s new Supporter Fulfillment Coordinator, and will be working with the revenue team to ensure that all our Supporting Partners, Hosting Supporters and Tech Supporters get the most out of their sponsorships. Lucia is one of three Austin, TX-based Association employees, and comes to the Association with a marketing and advertising background. Lucia was born and raised primarily in Mexico City, is fluent in Spanish, and enjoys reading, running, doing Crossfit, cooking, and chasing around her two sons, Bruce and Leon.

Rachel Rivera, Revenue Team, Junior Account Manager

Rachel (rayn1ta) grew up in the San Francisco area and spent four years living outside the US in Latin America, Asia, Africa and Europe. She has worked as a ski instructor, English teacher, and digital marketer. In addition to learning foreign languages, she enjoys yoga, hiking and scuba diving. As a Junior Account Manager with the Drupal Association's revenue team Rachel will focus on identifying and satisfying the needs of awesome Drupal Businesses.


Timothy Constien, Community Programs, DrupalCon Sponsor Fullfillment Coordinator

Tim (timconstien) is joining the Association’s Community Programs team as a DrupalCon Sponsor Fulfillment Coordinator. In this position, he will be ensuring that DrupalCon sponsors enjoy all their benefits and receive top-quality service before, during, and after the convention. Tim is a graduate of Oregon State University, and most recently worked to support the sales and marketing departments at a national radio group based in Portland. In his free time, Tim enjoys exploring: Whether he is finding new pubs to shoot pool at, finding the new best food joint, exploring new tree runs to snowboard through, or road tripping to the next music festival, he is always on the go.

Please help us give a warm welcome to our four new staff members. It’s great to have you on board!


Commerce Guys: Drupal Commerce Site Spotlight: Pam Kerr Designs

Planet Drupal - Fri, 2015/01/30 - 2:32pm

We're always on the lookout for great sites built with Drupal Commerce, our truly flexible software that's changing the face of eCommerce one site at a time.

Pam Kerr is one of New Zealand's leading independent jewelry designers. Her company - Pam Kerr Designs - had a Shopify site that served retail customers well, but it didn't meet their growing B2B needs. With the help of Blue Fusion, a New Zealand based web design and development chose Drupal Commerce for its flexibility, power and customizable user interface.

For more information, check out the full write-up DrupalCommere Showcase


To see Drupal Commerce sites we've Spotlighted in previous weeks view the Other Spotlight Sites


Annertech: Welcome to 2015, the European Year for Development

Planet Drupal - Fri, 2015/01/30 - 12:48pm
Welcome to 2015, the European Year for Development

Last Thursday - Jan 22nd - President Michael D. Higgins launched the European Year for Development at Dublin Castle, saying that "2015 is a seminal year for the future of human development".


Jonathan Brown: Using Bitcoin dust transactions to prevent website spam

Planet Drupal - Fri, 2015/01/30 - 11:49am

Previously: Ensuring security of funds and preserving anonymity when using Bitcoin for e-commerce

I quite often use Mollom to prevent spam submissions on contact and comment forms. It works pretty well, but some spam still gets through.

An alternative anti-spam technique is to require a Bitcoin dust transaction before an unprivileged user can POST a form. The value of such a transaction would only be about $0.001 USD. For a non-spammer this cost is fine, but for a spammer this is enough to make it totally uneconomical as they need to send out millions of posts.

I created a Spam Filter sub-module in my Coin Tools project for Drupal. It can be used to require a Bitcoin payment on any form on a Drupal website.

Coin Tools already has a Bitcoin payments system. When viewing a form, a new payment is created for the minimum amount possible. In the latest Bitcoin reference implementation the smallest output is 546 satoshis. However, many wallets still use the old value of 5460 so that is what is used.

The form's submit button is hidden with CSS (it still needs to be in the DOM for the form to function correctly) and a clickable QR code for the payment is put in its place. Coin Tools payments are BIP 70 compatible so a payment can either be satisfied by a direct POST from the wallet to the Drupal website, or the wallet can broadcast the transaction through the Bitcoin network (slightly slower).

Once Coin Tools has determined that the payment has been completed it will POST the form via JavaScript. If there are any validation errors the form will reload in the normal Drupal way. In this case, the submit button is no longer replaced by a QR code as it is recorded in the form state that the payment has been made.

When the form is submitted it is also verified on the server that the payment has been completed.

Here is a video of it in action.

Of course, this technique requires that the user has a small amount of bitcoin. For a website not targeting the Bitcoin community it would not only prevent spammers it would actually prevent everyone from posting. As Bitcoin usage increases this technique will be able to become more commonplace.

Browser integration

It has been proposed before that web browsers should have Bitcoin SPV wallets built-in, e.g. for paywalls. If a payment is required an "HTTP 402 Payment Required" response would be generated. In that situation it would make sense for the browser to prompt the user before a payment is made. For the spam filter this could just happen automatically. The transaction could actually just be included as part of the POST to submit the form.

Burning Coins

Because the transactions are for such a small amount it may not be economic to spend the received funds as large miner fees would be required. It might be simpler to just generate a random Bitcoin address for each payment. This means that you don't have to have a wallet on the server and could just use Chain to check if the payment has completed.


If a double-spend on a comment submission was detected after it had been accepted, the post could be deleted. For email submissions, they could be delayed a few seconds to be sure there is not a contradictory transaction floating around.

Even without implementing these protections, double-spending wouldn't make sense for a spammer.

Could a spammer double spend and avoid paying the dust amount? No - double spending is extremely expensive so it would be even worse value for money than just paying the dust amount.

Could a spammer simultaneously broadcast many transactions that spend the same outputs to many different forms and websites? In theory this might be possible and some of the forms would accept the POST before realising the transaction is a double spend. Spamming multiple forms on the same website simultaneously would be impossible because the website would be connected to just one Bitcoin node. If this did become an issue the fee required to POST could just be increased to make it uneconomic.

Greater amount?

Of course, it may be desirable to actually charge a larger fee for the purpose of generating revenue. The admin interface could be extended to allow a configurable amount.


Lullabot: Drush and Composer

Planet Drupal - Fri, 2015/01/30 - 11:29am

In this week's episode Addison Berry hosts Greg Anderson, one of the Drush maintainers, and Juampy Novillo Requena to discuss Drush. We start off by explaining why Drush exists and some cool things about it. One of the big hangups people have with Drush is installation, so we talk a bit about that, and how it is easier now with Composer.