Skip to main content

Coming to a Paris Near You

In:
4Feb2010

January seemed to breeze along without really stopping to say hello, and February doesn't look to be slowing down either. af83 will be hosting a Drupal Commerce Sprint in Paris from February 22 - 26, and we'll be doing as much as we can to make sure it's a productive time. I'll be flying over with mikejoconnor to join DamZ, Bojhan, fago, and whoever else shows up to work on the core Commerce modules and Rules 2 for Drupal 7. We're very excited about the week and doubly excited about the chance to work with Bojhan and fago early in DC's development.

If you're interested in joining us for a week of hard core Drupal in Paris, sound off in the forum thread for the sprint. We'll keep potential attendees notified of plans / IRC meetings through that thread. We're looking to finalize attendees by the 15th and draw up our battle plans to maximize our time together. I can't wait!

Costs will mostly be covered by Commerce Guys and af83. However, if you can't make it but would happily send someone in your stead, stay tuned and we'll post up links to the appropriate chip-ins.

Special Considerations for Views Exposed Filters

In:
26Jan2010

I've taken to building customized administrative interfaces for clients using Views that are restricted by user role and plugged into the administration menu with a normal menu item. My latest creation was on an educational site that uses the Quiz module to test users who listen to online lectures. There's a special user role that has the ability to create quizzes for lectures, and we needed a simple way for them to locate any quiz or question node without having administer nodes access (as required by the default Content administration page). Thus the Quizzes and Questions View was born!

I didn't expect any hiccups, as I'd just be making a quickie table View that included quiz nodes and question nodes. Since access to the View is restricted by user role, I didn't even have to bother filtering out unpublished content. As I was adding the Node: Type filter, I decided on the fly to expose the filter so the administrators could easily drill down to a specific question type if necessary. I then added the necessary fields and went to my preview, where I discovered that forum nodes were included in the results. Yikes!

My first thought was that I'd messed up the settings on the filter, so I reviewed. I had selected the filter to only show Multi-choice question, Matching, True/false question, and Quiz nodes. The operator was locked, selection was limited to a single option, and I'd even checked the box to limit the options to the node types I'd selected. However, it appears that I had a faulty understanding of the Optional checkbox that needed correction.

I've made exposed filters before, and I knew that if I marked a filter as Optional it would default to an <Any> option. Because I limited my options to the node types I had selected, I expected it to still filter my results against all the possible node type options and limit it further based on my selection in the exposed filter. However, as long as the <Any> option was selected, the View simply would not filter for node type at all. The simple solution was to add a second node type filter that was not exposed and limited the nodes to the same types that I made available in the exposed filter. This doubling up gave me the behavior I was expecting.

This same method should hold true for any other exposed filter where you want the user to select from a subset of all the available options. As always, if there's an easier way, post it up in the comments.

Got WYSIWYG?

In:
24Jan2010

WYSIWYG, the acronym that's fun to say, tricky to type, and painful to see on an RFP. I don't have an abiding hatred for WYSIWYG editors, but I'm not terribly fond of them either. However, understanding that most people can't grok HTML (the same ones who don't know what grok means, perhaps), I can see why people appreciate them. Unfortunately, in Drupal, WYSIWYG editors can cause a world of hurt.

I'll be brief: if you're building a site that requires WYSIWYG, do yourself a favor and alter the settings so the editor defaults to disabled and is added only to specific fields on a "need to use" basis. If you're maintaining a WYSIWYG module, do the rest of us a favor and have them default to disabled in most areas with the ability to opt-in specific textareas. I've been managing CKEditor on a client site, and it has a nifty pattern matching system for tweaking the visibility of the editor on various fields. (I still think it might default to being enabled everywhere, though.)

Why? Am I just being crotchety? In truth, while there are routinely used textareas on which the end user might benefit from a WYSIWYG editor, there are an equal number of textareas scattered around Drupal's administrative pages where editors just get in the way. Even worse, most seem to add empty p tags to textareas when their form is saved "just because." I'm not sure how it is for other module maintainers, but at least with Ubercart we regularly received puzzling support requests about simple features not working. This might be an e-mail that doesn't get sent because the textarea where the end user specifies multiple recipients (one per line... sound familiar?) has HTML in it that the end user can't see... thanks to their helpful WYSIWYG editor.

A less is more approach will benefit the end user and the module maintainers. Furthermore, an editor is often just visual clutter, like on the message textarea of a contact form. I don't suppose people usually compose contact form submissions in Word?

There might be modules out there that already operate like this, so please don't take this as an indictment on any particular module. Also, if anyone is aware of a WYSIWYG module like Unfuddle's, I'll give you a bearhug at the next Drupalcon if you'd be so kind as to link to it in the comments. If you haven't seen what they do, you should. It's my ideal solution if someone could ever bake it into a Drupal module.

On Delegating Role Delegation

In:
23Jan2010

I've been working through building a site with one of my pastors to replace our church's dated Drupal 5 site. Early on, I talked him through the process of figuring out what kinds of content he new site would include and how users should interact with that content. This forced him to define what I would implement as node types, user roles, and a handful of flags, Views, and who knows what else.

While the site develops, I want him to have the freedom to setup members of the church as content creators and site administrators without having to ping me every time a new user needs a role. Unfortunately, to give him that ability, I'd have to give him the permission to administer all user permissions. In other words, I'd be introducing clutter for any other site administrators (who really don't need to know what "permissions" are in Drupal speak) and the possibility that someone might grant unsafe permissions to users without me knowing about it.

I quickly imagined a module that would include a single permission along the lines of "grant users roles" and put the role element on user edit forms just like it would appear for users with "administer permissions." I was about to look for the form code in the user module when my Spidey sense started to tingle. A quick search turned up the Role Delegation module. It does exactly what I needed... no more, no less. Happy day! I recommend its use to anyone with a similar need, and I'd loooove to see this permission included in Drupal 8.

Kudos to David Lesieur for a handy utility module that makes it easier for site builders to empower site administrators without overwhelming them or introducing a security weakness.

A Rose by Any Other Name

In:
14Jan2010

Around the release of Ubercart 2.0 in October, several Ubercart developers (including myself and Lyle) met in San Francisco to brainstorm and implement our vision for the future of Ubercart. In short, our plan was to re-implement the core systems of Ubercart on Drupal 7 to reflect everything we'd learned in the past three years and to take advantage of D7's killer new features, like entities and fields in core. To do this without disrupting the current implementation of Ubercart and the thousands of sites depending on it, we opened the Ubercore project with the idea of moving Ubercart on Drupal 7 into the packaged distribution space.

This whole process was dubbed the Ubercore Initiative (d7uc), and we carved out a place where developers could more easily brainstorm and communicate about development. The scope of the initiative included efforts not just to rethink the code but also to rethink the processes we used to write and manage it, so we wanted a clean slate to figure out how to best communicate with current and potential contributors.

With the amount of support the initiative received from the community, it was clear that we hit on something people wanted to happen. The end result would be a much stronger Ubercart with a solid developer community and a core module package comfortable in its place as a support module (like Views, CCK, Hooker) while Ubercart itself would be remade into a full-blown application showcasing the power of Drupal as an e-commerce platform.

All that said, from this point forward, we're having to change our tack a bit. For my part, most people know me as the Ubercart project lead and are passingly familiar with the tale of Ubercart starting as an osCommerce replacement for the restaurant equipment sales company, Prima Supply, I worked for after college. After leaving there to join Commerce Guys, we arranged for me to continue leading the project while Prima retained ownership of various project assets and continued to contribute significantly to Ubercart development.

Unfortunately, we now find ourselves at odds over the future.  I and many others feel the architectural and procedural improvements proposed by d7uc are necessary for Ubercart to evolve and to thrive.  However, conflict surrounding the execution and governance of Ubercore arose with Prima that we were unable to resolve satisfactorily.  This resulted in Prima, on the strength of project / trademark ownership, asking me to either stop the Ubercore Initiative or cede leadership of Ubercart, rename Ubercore, and move on.  I still believe in the vision I originally outlined and cannot agree to the terms of continued Ubercart leadership, so I'm going to step down as the project lead of Ubercart and move forward with a renamed Ubercore.  The goals are the same, the plans for an upgrade path from Ubercart 2.0 are the same, and the future of products on Drupal 7 is still bright.

Hopefully this can explain what one commenter has described as recent "lazy maintaining" of Ubercart. The last couple of months have been counter-productive all around. I haven't been an administrator on Ubercart.org for some time now, nor have I contributed significantly to the Ubercart code itself beyond quick bug fixes. It's unfortunate that circumstances developed as they did, and I definitely wish I hadn't let the Ubercore momentum flag in the midst of the conflict. While I expect Ubercart will continue to be developed, with a bit of sadness but plenty of excitement for the future, it's time for me to move on.

Thus the title of this post. A rose by any other name is still a rose, and Ubercore by any other name is still the best thing to happen for Drupal based e-commerce since the advent of Ubercart. For at least the foreseeable future, Ubercore will continue as Drupal Commerce, managed similarly to Drupal itself. We'll be working our tails off to make sure e-commerce on Drupal 7 shows just how awesome having fields in core can be.

Great Drupal and BBQ in Austin, TX

In:
20Nov2009

I had a great time last weekend taking part in DrupalCamp Austin as a learner, a helper, and a presenter. I also enjoyed sharing an apartment and eating meat (and/or ice cream ) with my fellow Commerce Guys, Mike and Tim, and it was doubly fun to get reacquainted with folks I hadn't seen since last year's Drupalcon Szeged or Do It With Drupal.

As a learner at Drupal events, I tend to benefit most from sessions that discuss meta issues in Drupal development... how to grow your community or business, interact with clients, deploy and manage sites in the wild, etc. Ben Finklea of Volacci didn't disappoint with the weekend's opening keynote session, Building a Successful Drupal Business. He focused a lot on building good business processes for tasks ranging from managing sales leads to hiring. I missed out on Ben's SEO chat later but actually had the pleasure of joining him for church on Sunday morning, a rare opportunity on a Drupal weekend!

As a helper, I had fun doing a little bit of Drupal / Ubercart triage in the Commerce Guys room. Myself and a few other experienced Drupallers fielded questions and offered site building advice to various folks looking to iron out issues with their latest sites and prepare for upcoming projects. Aside from the communal eating of meat and ice cream (see above... and below), this is probably my favorite part of Drupal events.

Last, as a presenter I walked through the installation and configuration of Ubercart starting with the UberDrupal installation profile. It's not perfect, but it gets the job done and helped folks in the audience visualize how to use the sweet Acquia Prosper theme and leverage Ubercart's core systems. I was scheduled to discuss the ongoing Ubercore Initiative the next day, but most in the crowd were there because they had chosen Panels over Ubercart the day before. So, with a slight adjustment, I presented another Ubercart overview with glimpses of the plans for future development (like those in my last post on products). Those interested in learning more than that session afforded should hop in the #d7uc IRC meeting scheduled for Nov. 20 at 1 PM EST and keep an eye on http://d7uc.org.

On the recommendation of Todd Nienkerk of Four Kitchens, I drove the rental with Mike and Tim down to Driftwood, TX (nowhere near a beach) for some Salt Lick BBQ. They brought us plates piled with meat fresh from the open fire pit, treating our taste buds through our yummiest business planning meeting ever. Here's hoping there's a trip to Austin (for Drupal and/or BBQ) in my future!

d7uc: The Future of Products

In:
8Nov2009

This is the second in a series of posts outlining the ideas driving the Ubercore Initiative forward. We've had a lot of positive feedback from developers eager to dig into Drupal 7 to re-implement Ubercart's features like the awesome vision of products outlined below.

For starters, when we gathered for the Ubercore planning sprint in San Francisco, we began by nailing down the core systems without which we wouldn't have an e-commerce system and which we needed to build out other essential features. The links above are our whiteboard scribblings based on Ubercart's current features, but the one we gave the most time to was the core product system. The resultant notes and discussion summarized in this post may be viewed here.

In short... it's gonna be awesome, and it's all thanks to Drupal 7's Fields API. Cool Products are already great in Ubercart, but as one person recently tweeted, the implementation thus far has been a little awkward. Furthermore, from a data standpoint, it's been quite limiting.

How about a visual? It's my first go at Omnigraffle... Smiling

d7uc product

Currently, Ubercart defines a new product node type on install and gives you the opportunity to clone multiple new product node types called "product classes." These can then have default attributes assigned to them, which are customer selectable alterations to products at the point of purchase. For example, your merchandise store can have a t-shirt product class with a size attribute attached to it that your customers choose when adding the shirt to the cart. Each of these attributes can result in a price, weight, or SKU adjustment as well. There are also multiple product types defined at the module level, so that regular products function differently from product kits, each having their own add to cart form and functionality in the cart.

Problems come in you try to define just what a product is. Is it a node? Well, with SKU adjustments, aren't more than one products visible on a single node? How does Ubercart know those altered SKUs exist? There are implications here adversely affecting the development of stock control systems, sales and product reports, the shopping cart and order product handling, representing non-tangible products, and more. Happily, we have a plan we think will address these shortcomings without losing any of our current features.

So, what is the future of products? As fago hinted in his post, the future of products is entities, not nodes. We're separating "what a product is" from "how a product is displayed" and making products themselves top level, fieldable entities. Thanks to bundles, we'll still have multiple product types with various attributes, but instead of the current system where attributes are very loosely defined, we'll be moving more toward a product database where each individual product is defined and described by fields you add. Whereas before you might have had a single t-shirt product node with three variations thanks to a size attribute, you would now define a t-shirt product bundle and enter in the three variations with their SKUs and sizes set.

To handle product display, we'll be using a field that lets you specify which products to show on whatever the field is attached to (like a product display node) and how to prepare them for display. The products selected might all be listed individually for the user to select from a radio list. They might be grouped on their size field so that a size select list appears on the add to cart form as it does now. They might be sold all together at a set price as a product kit. We want this product display field to be flexible and to correct the difficulties people have in working with the current add to cart form.

This approach will clarify what a product is (a bundle of fields, including at least a SKU and a default title / price) and provide greater flexibility in how it is displayed (contributed field formatters, anyone?). Modules working with the product system, like stock control modules, will now have a unique product ID to refer to instead of a node ID with an array of attribute selections. We'll have better Views integration and end up with a product entry field that could attach an add to cart form to any entity.

Honestly, I could go on, but I'll stop here. This is already more gushing than I was planning to include in a single post. If you want to read more, hear what other people are thinking, and provide some feedback, you can check out the brainstorming thread, comment here, or keep an eye on the fieldable product meta issue as we flesh out the development tasks.

If you want to help make it happen, don't be shy. Eye

Drupal port by 3rdWorld : Created by Design Disease