February 4, 2010
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.
January 26, 2010
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.
January 24, 2010
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.
January 22, 2010
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.