Planet Drupal

Subscribe to flux Planet Drupal
Drupal.org - aggregated feeds in category Planet Drupal
Mis à jour : il y a 36 min 19 sec

Tag1 Consulting: How to Maintain Contrib Modules for Drupal and Backdrop at the Same Time

mar, 03/02/2015 - 16:26
Part 1 - Reuse the Same Code

In mid-January, the first version of Backdrop CMS was released. Backdrop is a fork of Drupal that adds some highly-anticipated features and API improvements to the core Drupal platform while focusing on performance, usability, and developer experience.

read more

Catégories: Elsewhere

Károly Négyesi: The brutal truth about security

mar, 03/02/2015 - 03:00

I have cared a lot, even too much about designing secure APIs for Drupal. To create a software which made it easy to write secure custom code and hard to write insecure. I placed this in front of other concerns including developer and user experience. Sounds nice, isn't it? But in truth, I was trying to tend a garden in the nuclear winter. By and large the Internet is so insecure that making it slightly easier to write more secure code is a trifling concern. It is enough that Drupal is not a house of cards of security wise and indeed it is not. Let other concerns win over security in API design. I was wrong. And I am out.

Catégories: Elsewhere

CivicActions: Backdrop CMS: A Drupal 8 Alternative

mar, 03/02/2015 - 01:30

There's a lot of excitement about Drupal 8 and it's imminent release. There's also a lot of angst. Yes, Drupal 8 is super slick and full of frameworky, object oriented coolness. The thing is, a lot of people have invested a lot of time learning how to do things in Drupal 7, and the idea of learning how to do things in Drupal 8 can be pretty daunting. This is where Backdrop aims to step in and serve developers and end-users who want to continue doing things mostly the Drupal 7 way, but not fall behind the new technology (or product support) curve.

So what motivated this fork in early D8 development?

Drupal 7 took some time to take hold - there were several reasons for this:

1) D7 is different enough from D6 that it took a considerable investment of time and money to learn (it was more enterprise focused).

2) D7 is often times more abstracted than D6. E.g.: The Commerce suite of modules is extremely powerful, and is considered by most Drupal developers to be the defacto solution for ecommerce, but it is more of a construction kit than a fully asembled product. Whereas, in D6, Ubercart is the way to go for ecommerce, which is pretty close to being fully functional right out of the box. The Commerce vs. Ubercart example serves to highlight the differences in approach between the two.

3) Somewhere along the way from D6 to D7, Drupal stopped being a community filled with people of all skill sets, and more of an elite dev community. This is great, but leads to some interesting challenges. First, it causes a talent shortage - some smaller outfits only require an entry level to mid level Drupal dev (we have all heard about the shortage of Developers available for hire - it's more accurate to say there is a shortage of non-elite level employees for hire). Second, a talent pool comprised of only elite level devs means that the limited talent available to do Drupal work will command a higher price point. This makes Drupal more expensive to implement, and often precludes businesses that would otherwise consider it as a web solution.

Backdrop has a well defined philosophy.

The first and most defining tenet of which is to serve small businesses, non-profits, schools or just any organization that doesn't have a big budget. By continuing to use most of the now familiar D7 api, Backdrop lets devs work with and extend what they already know, thereby lessening the talent pool strain which in turn leads to more affordable web development solutions.

A second tenet of the Backdrop philosophy is that it should be easy to use. Site builders who don't have coding experience should be able to use it without a lot of ramp up time.

A third tenet of the Backdrop philosophy is that contrib developers should be valued over core developers. The idea here being that the more hands there are in core (and focus on core development), the more potential for wonkyness awaits module developers who will be trying to hook into an api in constant flux.

A fourth tenet is that backdrop should be low resource. Speaking from a package size perspective, the most recent version of D8 beta has a 17.2 MB package, whereas Backdrop is 3.9MB.

Lastly, and perhaps the most notable tenet of the Backdrop philosophy, is that they are committed to releases being well planned, small, and on time. These have all proven to be a struggle for D8.

So, how is it different from D7?

Side by side, Backdrop and D7 look a lot alike: both come with the default Bartik and Seven themes, and the same default content types. Looking a little more closely, there are enhancements to Backdrop that help get things moving a little more quickly.

1) A dropdown admin menu with sensible options comes baked in.

2) The annoying admin overlay is gone.

3) All themes are fully responsive.

4) Backdrop comes stock with "Layouts", which I would kind of liken to a scaled down, much lighter weight version of panels, with a much more intuitive, simplified ui, but is still very powerful.

5) Blocks are a lot smarter. They have selection rules that when combined with Layouts, enhance the Panels like experience, but with a learning curve soft enough to make a novice developer productive quickly.

6) Configuration Managment! Sick and tired of confusing features conflicts? Yeah, me too. Configuration management is a breeze to use, and makes migrating database / config settings from server instances fast and easy.

How is Backdrop extended? Just like in D7 = with modules.

There are already a few that have been ported over from D7, but creating a new Backdrop module is almost the same as a creating one in D7 (it's pretty much just a difference in namespacing), and all of the coding conventions and hooks appear to be the same. For example, Backdrop doesn't come with any kind of wysiwyg functionality, and I wanted one with a local install I created, so I went to Drupal.org, downloaded the Ckeditor module and the corresponding js library, installed it, and made one change to the .info file, where core was defined as 7.x: I removed this line and replaced with "backdrop = 1.x." After doing this, Ckeditor was available, and I was able to use it. This is possible because Backdrop has a convenient conversion layer in place, that replaces the Drupal namespace in modules to the Backdrop namespace.

Another cool thing about the Backdrop project is that it lives on Github, which differs from Drupal, that hosts it's own repo. This is fine, but I think in the spirit of being extra open-sourcey, and encouraging developers from all disciplines to collaborate and discover this project, hosting it on github seems like a great idea. So, you can find the project, here: https://github.com/backdrop/backdrop.

If you want to read the project api docs, they can be found here: https://api.backdropcms.org/

Or, if you want to have a look at the project website, that can be found here: https://backdropcms.org/.

And if you wanna get an instance setup quickly without downloading anything, you can fire up an instance on Pantheon, here: https://dashboard.getpantheon.com/products/backdrop/spinup - you'll need to setup a Pantheon acct, but it's free and easy to create.

Happy site building!

Topics
Catégories: Elsewhere

Mediacurrent: Dynamic Data in Quick Tabs

lun, 02/02/2015 - 22:18

Quick Tabs is a great module, but if your tabs are named Today, Tomorrow, and the name of the day of the week for the next day, it is not obvious how to make the third tab say “Saturday”, “Sunday”, or anything else that changes.

After a quick search for a preprocess function for Quick Tabs didn’t result in a perfectly outlined tutorial, I decided that I would need to dig just a bit.  

Catégories: Elsewhere

more onion - devblog: D7: How not to use hook_entity_*

lun, 02/02/2015 - 22:02

Recently I came in a situation where I wanted to extend all entities of a specific type (payment) to reliably have a provide (and store) an additional property. At first glance this seems like a no brainer: simply use hook_entity_* to save/update/load the property to or from the database and that should do it. Turns out it isn't … and there is a lot to learn about how entities work in D7.

Lets take a look at a specific example.

Tags:
Catégories: Elsewhere

Matt Grasmick: Remove language from all Drupal aliases

lun, 02/02/2015 - 21:27

Drupal's locale module includes a lot of great features for supporting multilingual sites. One such feature is the ability to associate a language with a path alias. This allows you to have one node with two versions (let's say an English version and a Spanish version)--each with its own alias.

But your use case may not require language-specific paths per node. Maybe you want to call a spade a spade-- you've got a Spanish node or and English node and that's it. No fancy multiple versions.

Well then you've got a bit of a problem--a few actually. This can wreak havoc with aliases, and pathauto in particular. The solution is the Local Path Ignore module. It ignores the language of a given path, and instead forces all paths to have a language of "undefined," effectively allowing path aliases to behave the way you'd expect--one path per node.

7.x, drupal, locale, i18n, language, pathauto, alias, path
Catégories: Elsewhere

Annertech: The 5 best modules to eliminate spam on a Drupal website

lun, 02/02/2015 - 20:31
The 5 best modules to eliminate spam on a Drupal website

//-->

Catégories: Elsewhere

Károly Négyesi: This is the future of Drupal

lun, 02/02/2015 - 18:36

I got these gems from a person at Acquia. I followed up with someone supposedly higher up in the chain but never got an answer. Needless to say I was just an expert helping [redacted] and not someone who makes the decisions for them:

Karoly,

Our colleagues have previously spoken regarding [redacted] web properties. I’m reaching out to introduce myself and see if it would make sense to discuss your web plans for 2015.

Acquia is a Gartner leading web content management provider. Our platform taps into the cost-effective and flexible benefits of open source while providing world-class support for our clients’ websites.

Second email:

Acquia was founded by the creator of the Drupal project and our organization works along side Drupal users to propel their digital properties.

Mind you, this is two years after someone from Acquia pitched Drupal to Matt Mullenweg. I hoped selling open source that some people poured their heart into differs from selling a sack of potatoes. That the salesmen would at least get some rudimentary training on the community their livelihood depends on. That they won't talk like a Dilbert cartoon. I am wrong. And I am out.

Catégories: Elsewhere

Code Karate: Site5 Hosting: A shared hosting solution for designers and developers

lun, 02/02/2015 - 18:01

Code Karate has recently posted numerous times on the importance of hosting and finding a reliabl

Catégories: Elsewhere

SitePoint PHP Drupal: Effective PDF Generation in Drupal

lun, 02/02/2015 - 18:00

A few months ago I had a client requirement for PDF generation, in this case to generate certificates that could be viewed online or printed. I spent some time looking into the best Drupal options available and picked up some advice along the way on how best to accomplish these aims. After mentioning my results to several people, it seemed that PDF generation was a common requirement and now I have the same need again on a personal project, so it seemed a good case study to walk you through what I found.

Why not just print?

If your requirements are simple, it may be easier to just to tell your website users to print and there’s nothing stopping them doing this. If we want a level of control over what is printed or we want to distribute files for printing, then we need to look into other options.

Web vs Print

PDF generation takes a slight change of mindset. As web developers, we have spent a lot of time convincing designers from a print background to stop producing pixel perfect designs that will be difficult to reproduce on the web. If you want to introduce PDF generation or any form of high designed print output, then we need to relearn some of our old skills we left behind. The nature of print means that it is precise and often needs pixel (or millimeter) perfect design.

What am I trying to accomplish?

I am currently working on a board game and I want to allow players to be able to create their own cards that can be shared on the website and printed for use in the game. We have a specific size and layout that these cards will always be and need to conform to, here’s the initial design that we will partially recreate:

PDF options in Drupal

There are two options in Drupal for creating PDFs. The Print module and Views PDF. Views PDF initially seemed the better option as it would allow us to leverage the power of views and the myriad options it offers. However, it has the PHP module as a dependency and as far as I know, is reliant on the eval() function. PDF generation has the potential to be a server intensive task and this method seemed inefficient to me, aside from my reluctance to ever have any kind of PHP evaluation module enabled in Drupal.

This caused me to settle on the print module, which is also better supported and offers many other options for output that may prove useful.

Next we need to decide on our PDF generation library, I am going to suggest you use wkhtmltopdf and explain why later, as I want to build something to compare first. Do this by visiting the wkhtmltopdf website and follow the instructions for your setup. Remember it will need to be installed on local and production sites. After installing you need to create an alias to the wkhtmltopdf executable into your Drupal libraries folder, i.e.:

ln -s /usr/bin/wkhtmltopdf /var/www/sites/all/libraries/wkhtmltopdf

Continue reading %Effective PDF Generation in Drupal%

Catégories: Elsewhere

Drupal core announcements: No Drupal 6 or Drupal 7 core release on Wednesday, February 4

lun, 02/02/2015 - 16:14

The monthly Drupal core bug fix release window is scheduled for this Wednesday. However, there haven't been enough changes to the development version since the last bug fix release three months ago to warrant a new release. A Drupal 7 bug fix release during the March release window is likely instead.

Upcoming release windows include:

  • Wednesday, February 18 (security release window)
  • Wednesday, March 4 (bug fix release window)

For more information on Drupal core release windows, see the documentation on release timing and security releases, and the discussion that led to this policy being implemented.

Catégories: Elsewhere

Drupal Association News: Infographic: Who Attends DrupalCon?

lun, 02/02/2015 - 16:06

Did you know that DrupalCon isn’t just for developers? The community survey we conducted at the end of 2014 turned up some interesting facts, including the fascinating statistic that only about half of DrupalCon attendees self-identify as developers? With project managers, C-level executives, and Drupal sales and marketing experts in attendance, DrupalCon is a great place to meet a wide array of passionate Drupal users and advocates.

So, who goes to DrupalCon? Check out the infographic below for a more complete picture of who attends the biggest Drupal conference on earth.

 

Catégories: Elsewhere

Web Omelette: 6 steps for new Drupal 8 developers

lun, 02/02/2015 - 09:00

So you are taking the plunge into learning Drupal 8 for the purpose of developing sites, modules, themes, etc. You're a great Drupal 7 developer, familiar with many drupalisms but you don't have tons of experience for modern PHP frameworks, principles and practices. Well, Drupal 8 still includes many of the old drupalisms but still attempts to keep in line with times and modernise itself.

In this article I want to outline 6 steps I believe you should take to get started learning how to develop custom modules and/or themes in Drupal 8. On top of these 6 builds everything else.

The first three are PHP related in a more general fashion, while the last three target aspects of Drupal 8 itself.

1. Learn Object Oriented Programming

One of the biggest difference between Drupal 7 and 8 for developers is the way code is written. It's still PHP but it's now much more object oriented. Global procedural functions are still in place but most of the logic happens in classes.

In case you don't have much experience with Object Oriented Programming in PHP, this is the first thing you need to learn, brush upon or revise (depending on your level). There are many resources available out there, all scattered as hyperlinks in this section. There are also courses you can take, both free and paid.

Without quite a solid OOP foundation, you won't be able to understand much of how Drupal 8 modules are built.

2. Learn how to use Composer

One of the consequences of modernizing PHP has been the introduction of the Composer package manager. Projects are no longer built without it as it does a great job of installing, updating and managing in general the external libraries and dependencies of your project. Not to mention its very helpful autoloader.

Drupal 8 uses Composer to manage external PHP libraries and dependencies (such as Symfony components, Guzzle, etc) and there is talk about the ability to handle also contrib modules. So make sure you know how Composer works and even start using it in non-Drupal projects.

3. Get familiar with Symfony

One of the main points of contention (back then) in the Drupal 8 development cycle was the introduction of Symfony components. Some people didn't really agree with this great shift from they Drupal way, but others embraced it wholeheartedly. I am in the latter group as I love Symfony and used it even before developing anything in Drupal 8.

Drupal 7 developers are often being told that knowing Symfony is not required in order to develop in Drupal 8. While technically true, you still end up learning a lot of it through the Drupal experience. That being said, I strongly recommend learning some Symfony before. It is a great modular framework and knowing its concepts will really help you out in understanding how Drupal 8 is built (for the components it uses I mean). Once you can build a small website in Symfony, you'll enjoy developing in Drupal 8 that much more because concepts will be similar a lot of the time. Not too mention that you can use Symfony to build apps on its own.

4. Routing and controllers

Just like with Drupal 7, when starting to learn Drupal 8 you need to create the obligatory hello world module (creating a page with a parameter in the URL( usually world) that displays the text Hello + parameter). This example introduces you to many important things:

  • Module folder structure
  • Routing (no more hook_menu) through routing.yml files that map to Controller methods
  • Controller classes which have various methods that can be mapped to routes
  • Access arguments for these routes
  • Rendering markup to the page inside the Controller methods
  • etc

So I really recommend giving this a go.

5. Plugins

Another important concept you'll need to get familiar with is Plugins. Admittedly, this not the easiest to grasp, but it is super important because it's everywhere. Not to worry though, it's not rocket science.

Many old Drupal 7 implementations of various concepts have been transformed to plugins: info hooks, blocks, field formatters, views handlers, etc. Understanding plugins is therefore also very important for being able to extend default Drupal functionality.

6. Dependency injection and the service container

The last step I am going to mention here is dependency injection. Drupal 8 uses the Symfony dependency injection container to manage service instantiation and injection into classes that need them. This helps decouple functionality and increases testability.

However, many people are scared of this concept, mainly because they don't grasp it. I wasn't super comfortable either before understanding it. But you should definitely learn what it means, why we use it and how we use it. Because it is a very simple concept that is used all the time in procedural code as well.

You can already find many tutorials out there on Drupal 8 that load services statically through the \Drupal class. It is much faster to write so people (me included) prefer it when writing about D8. I usually also tend to make a note that using dependency injection is preferred in theses cases.

Not understanding what the service container and dependency injection is will easily let you fall into the habit of just statically requesting services and coupling your code like it was procedural. Once you are clear on this point, this will hopefully not happen any more and the sight of a \Drupal::get('some_service') will make you think twice.

Conclusion

There you have it. What I think are the first 6 steps you should take when learning Drupal 8 for the first time. Of course there are many other important things to learn and do but I believe they build on top of this foundation. Of course, this is me writing so others may have different opinions (very much welcomed in the comments). So let's discuss.

var switchTo5x = true;stLight.options({"publisher":"dr-8de6c3c4-3462-9715-caaf-ce2c161a50c"});
Catégories: Elsewhere

Gizra.com: Logs, The Easy Way

dim, 01/02/2015 - 23:00

Your team invested countless hours in development.

Your QA people can barely keep their eyes open - they have worked so hard. Your lead developer who's responsible for the deployment is almost dehydrated from so much pressure and sweat.

But it's all worth it. Your app is live. Now everybody goes to sleep, and your pampered app, is all alone, serving your data to the entire world.

You forgot one thing - to give it a phone to call home, and tell you something went wrong.

Continue reading…

Catégories: Elsewhere

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

dim, 01/02/2015 - 07:00

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
Catégories: Elsewhere

Drupal Association News: Nominations Open for Drupal Association At Large Director

dim, 01/02/2015 - 01:00

It’s a great time to be part of the Drupal Association. We’ve done some amazing work in the last few years, and we’re in a great position to work with the community to continue to improve and grow fully into our mission. As a Drupal Association At-Large Director, you’d be in the center of the action. The At-large Director position is specifically designed to ensure community representation on the Drupal Association board and we strongly encourage anyone with an interest to nominate themselves today.

Nominate Yourself Today

The Board of Directors of the Drupal Association are responsible for financial oversight and setting the strategic direction of the Drupal Association. New board members will contribute to the strategic direction of the Drupal Association. Board members are advised of, but not responsible for matters related to the day to day operations of the Drupal Association, including program execution, staffing, etc. You can learn more about what’s expected of a board member in this post and presentation.

Directors are expected to contribute around five hours per month and attend three in-person meetings per year (financial assistance is available if required). All board members agree to meet the minimum requirements documented in the board member agreement.

Today we are opening the self-nomination form that allows you to throw your hat in the ring. We're looking to elect one candidate this year to serve a two-year term.

Log in first and...

To nominate yourself, you should be prepared to answer a few questions:

  • About Me: Tell us about yourself! Your background, how you got into Drupal, etc.
  • Motivation: Why are you applying for a board position? What initiatives do you hope to help drive, or what perspectives are you going to try and represent?
  • Experience: What Drupal community contributions have you taken part in (code, camps, etc.)? Do you have experience in financial oversight, developing business strategies, or organization governance?
  • Availability: I am able to travel to three in-person board meetings per year (either self-funded, or with financial sponsorship)
  • IRC Handle
  • Twitter Handle

We will also need to know that you are available for the next step in the process, meet the candidate sessions. We are hosting 2 sessions: 

Session One
  • Tuesday, 24 February 2015 at:
  • 8 AM PST in the US and Canada
  • 11 AM EST in the US and Canada
  • 1 PM in Sao Paulo Brasil
  • 4 PM in London
  • 12 AM Wednesday, 25 February in Beijing
  • 3 AM Wednesday, 25 February Sydney Australia
Session Two
  • Wednesday 25 February 2015 at:
  • 4 PM PST in the US and Canada
  • 7 PM EST in the US and Canada
  • 9 PM in Sao Paulo Brasil
  • 1 AM Thursday, 26 February in London
  • 8 AM Thursday, 26 February in Beijing
  • 10 AM Thursday, 26 February in Sydney Australia
Session Three
  • Thursday 26 February 2015 at:
  • 12:30 PM PST in the US and Canada
  • 3:30 PM EST in the US and Canada
  • 5:30 PM in Sao Paulo Brasil
  • 8:30 AM Friday, 27 February in London
  • 4:30 AM Friday, 27 February in Beijing
  • 7:30 AM Friday, 27 February in Sydney Australia

The nomination form will be open February 1, 2015 through February 20, 2015 at midnight UTC. For a thorough review of the process, please see our announcement blog post.

If you have any questions, please contact Holly Ross, Drupal Association Executive Director.

Flickr photo: Kodak Views

Catégories: Elsewhere

Drupal Association News: Nominations Open for Drupal Association At Large Director

dim, 01/02/2015 - 01:00

It’s a great time to be part of the Drupal Association. We’ve done some amazing work in the last few years, and we’re in a great position to work with the community to continue to improve and grow fully into our mission. As a Drupal Association At-Large Director, you’d be in the center of the action. The At-large Director position is specifically designed to ensure community representation on the Drupal Association board and we strongly encourage anyone with an interest to nominate themselves today.

Nominate Yourself Today

The Board of Directors of the Drupal Association are responsible for financial oversight and setting the strategic direction of the Drupal Association. New board members will contribute to the strategic direction of the Drupal Association. Board members are advised of, but not responsible for matters related to the day to day operations of the Drupal Association, including program execution, staffing, etc. You can learn more about what’s expected of a board member in this post and presentation.

Directors are expected to contribute around five hours per month and attend three in-person meetings per year (financial assistance is available if required). All board members agree to meet the minimum requirements documented in the board member agreement.

Today we are opening the self-nomination form that allows you to throw your hat in the ring. We're looking to elect one candidate this year to serve a two-year term.

Log in first and...

To nominate yourself, you should be prepared to answer a few questions:

  • About Me: Tell us about yourself! Your background, how you got into Drupal, etc.
  • Motivation: Why are you applying for a board position? What initiatives do you hope to help drive, or what perspectives are you going to try and represent?
  • Experience: What Drupal community contributions have you taken part in (code, camps, etc.)? Do you have experience in financial oversight, developing business strategies, or organization governance?
  • Availability: I am able to travel to three in-person board meetings per year (either self-funded, or with financial sponsorship)
  • IRC Handle
  • Twitter Handle

We will also need to know that you are available for the next step in the process, meet the candidate sessions. We are hosting 2 sessions: 

Session One
  • Tuesday, 24 February 2015 at:
  • 8 AM PST in the US and Canada
  • 11 AM EST in the US and Canada
  • 1 PM in Sao Paulo Brasil
  • 4 PM in London
  • 12 AM Wednesday, 25 February in Beijing
  • 3 AM Wednesday, 25 February Sydney Australia
Session Two
  • Wednesday 25 February 2015 at:
  • 4 PM PST in the US and Canada
  • 7 PM EST in the US and Canada
  • 9 PM in Sao Paulo Brasil
  • 1 AM Thursday, 26 February in London
  • 8 AM Thursday, 26 February in Beijing
  • 10 AM Thursday, 26 February in Sydney Australia
Session Three
  • Thursday 26 February 2015 at:
  • 12:30 PM PST in the US and Canada
  • 3:30 PM EST in the US and Canada
  • 5:30 PM in Sao Paulo Brasil
  • 8:30 AM Friday, 27 February in London
  • 4:30 AM Friday, 27 February in Beijing
  • 7:30 AM Friday, 27 February in Sydney Australia

The nomination form will be open February 1, 2015 through February 20, 2015 at midnight UTC. For a thorough review of the process, please see our announcement blog post.

If you have any questions, please contact Holly Ross, Drupal Association Executive Director.

Flickr photo: Kodak Views

Catégories: Elsewhere

Gizra.com: (Automatic) QA

sam, 31/01/2015 - 23:00

Here is a known fact - it's really easy to break the sites you are building. One wrong line of code, and a page is returning a 503 error.

Here is a known secret - (almost) nobody is doing QA. Since I'm not into arguing about this, I'm willing to soften it a bit to "most companies, don't do proper QA".

The reasons are pretty clear - not enough time and not enough budget. This post isn't going to be about the importance of QA - that point is clear to everybody, but rather give realistic tips and tools that will allow you to start improving the quality of your projects, and actually even save you some time and money.

Continue reading…

Catégories: Elsewhere

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

sam, 31/01/2015 - 20:06

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

Catégories: Elsewhere

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

sam, 31/01/2015 - 02:29
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.

Route 

"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.

URL

Uniform Resource Locator eg. "https://www.drupal.org/community" It's generally the address we use to find content on the web.

URI

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)

Path

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 http://example.com/blog/yakshaving, /blog/yakshaving, or node/5

Link

<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.

Catégories: Elsewhere

Pages