Feed aggregator

There are currently 99 new Drupal contributors awaiting review of their first project. This is a great place to contribute to the community and learn about interesting upcoming projects, for example...

Module: Subscriptions by Reference What does it do?

The Subscriptions module allows you to subscribe directly to nodes, but what if you want to subscribe to one node referenced by another? Previously, you could do that with a moderate amount of custom code, maybe with the help of a blog post explaining the process. Now, the Subscriptions by Reference module promises to make that even easier. Just tell it which content types and field you want to use in the subscription and it does the rest.

Look Useful? Review it!

If you would like to see this module readily available on Drupal.org, you should review it and help make that happen.

Review It

Pro Tip: If you've never reviewed a project application before, you can find instructions for reviewers on Drupal.org and the Code Review group is happy to help more people get involved.

In this lesson we're going to talk about what is possibly the most useful Drupal site building module of them all - Views. If you're coming from a WordPress or Joomla background, you won't have experienced anything quite like it. Not only does Views allow you to easily build queries on your site's content, but it gives an amazing degree of control over the display of those query results.

We're going to begin by creating a very basic view just to get acquainted with the interface and some of the settings we'll be using the most often. If you've been following along and are using my free installation profile, then everything you'll need is ready to go. If you're using your own site, make sure you have Views installed along with some content you can work with. If you have a fresh install of Drupal, the Devel module is great for generating dummy content.

Once you're all set, let's get started creating our first view.

Creating a View

To begin, let's head to Structure > Views. You should see something like the screenshot below. At the upper left of the page is a link that says, "Add new view". Go ahead and click it.

You'll next be directed to the screen below. If you wanted to keep things super easy, you could just add a title and then save to have a view of all your site's content presented as teasers. We're going to do something a bit different, however. Take a look at the settings below.

You'll see that I've named the view "Blog grid" and set it to only show content of the Article type. Often you may want to create an additional display, such as a block, but in this example we're going to just stick with the default Page view.

The ability to create multiple displays is one of the really cool things about Views. We're building one query, but we have the option to display it in multiple ways - a page, a block or even a feed - and then tweak the display of each as needed.

We'll go with what we have here and click "Continue and edit". You'll next see the view edit form as in the screenshot below.

OK, there's a lot going on with this form, but we're only going to focus on a few of these settings to keep it simple this time around. Let's begin with two that we're not going to edit in this lesson, but that I'd like you to take a moment to check out. These are the Filter Criteria and the Sort Criteria settings.

You'll see that they determine the type of content we're working with, the publish status and how the results will be sorted (in our case, by date with the newest displayed first). These settings make it very easy to add criteria to further filter our results.

For example, one thing that is often useful to do is only include nodes in your view that have been promoted to the front page. This allows you to do something like publish a post but not include it in the main list of your blog articles. I do this occasionally when I don't want a post distributed to email subscribers, but do want it available through my Categories menu.

Take a look at these options, play around with them bit and see what changes you can come up with. Experimenting is a great way to figure out all the things Views is capable of doing.

Editing a Field Display

In our last tutorial, we talked about content types and the Fields UI. In this lesson we're circling back a bit on that subject by using fields to create our view. That's what a view mostly boils down to - a query where we ask Drupal to return certain fields so we can use them in a display we place on our site. You'll see that in this view all that we currently have being displayed are the titles of our articles. The preview (down at the bottom of the page) also shows us that our titles are being displayed as simple, unformatted links. 

Although it's a good idea to have the title as a link, we should probably change the display style to a heading. To do this, click on Content: Title under Fields. You'll see something like the screenshot below.

You'll notice that I've expanded the Style Settings tab and checked "Customize field HTML" and set it to display the title as an H2. I could have done a lot of other customizations, including adding a class, changing the field wrapper and more.

Farther down this screen you'll see the Rewrite Results tab and that is where things get really interesting. You can pretty much go nuts with how you want to customize a field's display. This is super powerful stuff! The only criticism I'll offer is that by default, Views generates markup that is quite bloated - it has a serious case of divitis. Fortunately, we have the Semantic Views module to tidy things up. We won't get into using that module in this lesson, but I recommend you take a look at it on your own.

I'm going apply these settings for all displays, but note that by using the drop down at the top of this screen you could choose to instead apply it to a specific display. This is very useful when you're using the query to create multiple displays (pages, blocks or feeds) and modifying how each one outputs the view.

After applying the changes, you should notice in the preview that the titles have been successfully changed to headings. So far, so good. But let's add another field to our display to make it a bit more useful. You'll see in the screenshot below there is an arrow pointing to the link that adds a new field to our view.

After clicking that button, you'll see a long list of options pop up. Let's select Content: Body and then continue by clicking the, "Apply (all displays)" button. You'll next see the same screen as when we edited the Title field. One difference this time is that "Create a label" is now checked. In most cases I uncheck that so that my views don't add labels, but you may find situations where it comes in handy.

Another difference this time is that we're going to make a change to the format of the field. We probably aren't going to want the entire Body field to be displayed in our view, so instead we'll set it to only display a summary. You'll see a drop down under Formatter. Go ahead and select, "Summary or trimmed". In this case the default settings are fine, but I encourage you to play around with some of these a bit and see what you come up with. Now we'll click, "Apply (all displays)" to continue.

After saving that, take a look at the preview - looking pretty good, huh? We've come far enough that we should see what this Page view we've created actually looks like on our site. First, however, make sure you save your view! That's an important thing to remember - none of your changes are applied until you save the view, so if you ever get off track, just click cancel and start over.

After saving, look for a small link at the upper right of the view edit screen that says, "view Page". Let's click that and take a look at the view we've created as it will appear on our site.

That was pretty easy, right? I'll bet that you can think of a lot applications just using what we learned today, but in future lessons we'll be coming back to the Views module and adding to our bag of tricks. In fact, our next lesson will cover some advanced features of views (contextual links and relationships) and in a few weeks we'll use Views and the Flex Slider module to add an image slider to our front page.

Until then, you can keep up with this series either via the RSS feed or subscribing to blog updates (at the top of the sidebar).

If you'd like to comment on this post, you can do so on this discussion forum.

Guest blogger Yvonne Chen of Dayvin Internet Solutions shares the results of the Shanghai Global Training Day event this past March.

Following-up with the Global Training Day series, we were glad to be able to organize the Drupal Training Day on March 15, 2013 in Shanghai.

Personal blog tags: Drupal Global Training DaycommunityChinaguest blog

Ah, base themes.

If there's an analogue to the Windows/Mac/Linux battle in Drupal land, it's probably Zen vs. Omega vs. AdaptiveTheme.

Garrett Dawson and John Ferris have a way out of that eternal struggle: Custom base themes. As they put it in their Drupalcon Portland session description:

"By necessity, base themes make assumptions about how teams and individuals work. By rolling your own, you’ll become much more comfortable and informed about the Drupal theming layer, and have a better launchpad for your front-end projects."

Here in Portland we take home gardening and permaculture seriously, so what better place to talk about "growing your own" custom base theme!

I spoke with John and Garrett about how creating your own base theme can make work for you and your team easier. Take a gander at their session, “Dapper Drupal: Custom Tailored Themes,” on Thursday at 2:15 PM for the full story!

IB: Base themes that are out there make some assumptions about how you want to theme. What's the advantage to rolling your own base theme rather than finding the theme that already makes the assumptions you do?

JF and GD: If you can find a base theme in contrib that fits perfectly into your workflow, by all means, use it. There's a lot of solid tools out there. We don't want to deter people from using and contributing to them. With that said, we feel it's unlikely a contributed base theme will be ticking all the boxes and making all the right assumptions about your workflow.

There's no one-size-fits-all approach. Your front-end process is heavily influenced by team dynamics, contrib module choices and a whole host of other considerations. The majority of base themes cannot account for those variables like you can. We want front-end developers to take a critical look at their tools to see where they can make improvements. That may mean creating a custom base theme; a custom starter theme for use with an existing base theme; or even a set of helper modules.

All the popular base themes started because someone wasn't happy with what was available at the time. The ultimate goal is increasing efficiency while improving the quality of the final HTML, CSS and JS.

IB: Do you recommend custom base themes for big shops? Small distributed teams? Freelancers? Everyone?

JF/GD: Yes, all of the above. At least consider it as an option. If you find yourself doing any kind of repetitive work, there's an opportunity for improvement. The only people who should steer clear of custom base themes are those new to Drupal. You need to be familiar with the tools that are available before setting out to create your own.

IB: Besides your the custom base themes you developed yourselves (Center and Prototype) what other custom base themes have you seen in the wild?

JF/GD: Yes! We've learned a lot working with and iterating on Center and Prototype. They work well for the structure of our team and the type of work we do at Aten. However, we realize every team is unique. We were really interested in seeing how other organizations were approaching the front-end problem space. We chatted with a range of teams of varying sizes working across different industries. Everyone has their own unique set of tools based on their own strengths and constraints. We're excited to share those with you, but you'll just have to come and see for yourself!

Images: National Archives and Flickr user McBeth.

Join Rootwork on Twitter, Facebook and SlideShare.

Learn about Rootwork's services for nonprofits and social change.

Everyone planning and building Web solutions with Drupal benefits from understanding what a "hook" is—and why Drupal is not a CMS. more>>

Kraftwagen

• On the kraftwagen.org it says that Kraftwagen is “Drupal for large (distributed) development teams and staged deployments.” Can you elaborate on what exactly that means?
  • (Rolf) pain of configuration in DB. Everything in code is essential. Standardized workflow
• What do you mean when you say “Drupal for developers”?
• It states that everything is in code. Does that include info from the database, like configuration?
• How does this compare to the configuration management initiative in Drupal 8?
• How does it integrate with multiple deployment targets like local, staging and live environments?
• It mentions skeletons, what are those?
  • (Rolf) start points. mention scaffolding
• So, how does this all work? What are the components of Kraftwagen?
  • (Rolf) kraftwagen (drush extension) and 2 important modules (kw-manifests and kw-itemnames). explain the workflow of Kraftwagen (setup, build, init db, update)
• On the site is says something about Environment awareness, and mentions that the Devel module shouldn’t be enabled on a live server, but should on a development environment. I get around this by using a global git ignore file on my local machine that ignores the devel module. So, when I spin up a new site on my local machine, part of that process is to install the Devel module, but my system prevents it from ever being pushed anywhere automatically. How does Kraftwagen deal with that?
  • (Rolf) builds are not environment aware, but dependencies and manifests are.

Use Cases

• Are you familiar with Aegir? How would you compare the two?

Every Drupalcon, Jam and I welcome people to the conference in our own special way. Whether it's Dirndl's and Beer in Bavaria, The Spirits of Drupalcon, or an iPad Orchestra, we always try to keep it fun but informative. This year we've got a special theme picked out and we need some volunteers. So if you want to play along, and can commit to being at the session on Tuesday, May 21, from 10:15 to 11:15, fill out the form below and we'll get you on stage as part of the show! 

Oh, did I mention there are prizes to win?

 

E-mail * Drupal.org profile page (URL) * Skype, IRC, Google+ or other chat ID * I'll contact you via this channel to discuss details of the show. I solemnly swear to be at the session Tuesday, May 21, at 10:15 * So help me Druplicon The Price is Right I'm familiar with "The Price is Right" Sign me up, I want to play! What CMS systems have you worked with in the past? Check all that apply I write code for a living I've worked in software sales I've worked in software procurement I've been a product manager for a software company Wheel of Fortune I'm familiar with "Wheel of Fortune" Sign me up, I want to play! Check all that apply I'm a Drupal site builder I use Drush I'm multilingual Jeopardy I'm familiar with "Jeopardy" Sign me up, I want to play! How many Drupalcon's have you attended? none, Portland is my firstonetwothreefour or more American Idol I'm familiar with "American Idol" I have talent! I'm going to be a star! What's your crazy talent that you can display in 90 to 120 seconds? Bonus points if you can demonstrate this talent by providing a link, or even a Skype audition with Robert! By submitting this form, you accept the Mollom privacy policy.

I can confidently say that this book will teach you a lot about nginx, both as tutorial and reference. It's now mandatory reading for anyone on our team who will ever touch an nginx config file.

read more

Since a few days we have Qt 4.8.4 (4:4.8.4+dfsg-3) in some archs of the experimental Debian archive. This release allows Qt4 to coexist with Qt5 while avoiding FTBFSs of current Qt4 packages in the archive.

So if you maintain a Qt4 app and want to check how it works with 4.8.4, you should be ready to go.

I love maps — something that became clear to me when I was looking at the tag cloud of my bookmarks a few years back. One of my favorite blogs (now a book) is Frank Jabobs’ Strange Maps.

So it’s no coincidence that a number of my favorite MIT Mystery Hunt puzzles are map based. Trying to connect the two worlds, I sent Jacobs a write-up of the hunt and of a particularly strange sound-based map puzzle called White Noise that I worked with Don Armstrong to solve in the 2006 hunt. While I wasn’t paying attention, Jacobs did a very nice writeup of my writeup of the puzzle for Strange Maps!

Today, Mediacurrent and Acquia are proud to announce that one of the highest profile websites in the world, Weather.com, based in Atlanta, will be joining the Drupal community!  To my knowledge, Weather.com will be the highest traffic Drupal site in existence. Over the last six months, Mediacurrent and Acquia have been shepherding Weather.com’s on-ramping of Drupal via a proof-of-concept and discovery engagement. 

More than anything, this adoption helps further advance our region's commitment to Drupal and open-source technologies. We are really excited about the positive impact this project will have on our local Drupal ecosystem.

Please see my blog post on Acquia’s website for the entire story.

My last post I said that I had to remove my internet query tools due to some bugs that were a concern.  Some of the code was hard to maintain and probably had holes and I had noticed that it looped at times.

I’m happy to say that I have restored some of those tools now, still located at http://enc.com.au/itools

This code is completely re-written in Python using the TurboGears toolkit which means it is a lot cleaner in how it works and how it looks.  Some of the lookup tables use a database rather than an array for ease of updating and querying.  The downside is the backends will take time.  It currently only does nslookup queries and whois only works for IPv4 addresses. The domain name queries will be a while off as these are the most complicated to handle. To give you an idea, all IPv4 and IPv6 address information comes from 5 sources with two formats while domain names come from over 200 sources with about 40 formats.  This means the information from Regional Internet Registries will be done first.

One important factor of running a company, as well as becoming a rockstar developer, is efficiency. Here at LevelTen we are constantly tweaking and revising our development processes to become as efficient as possible while still providing clients with the best possible solution for their website needs.... Read more

Next week, a gaggle of Palantiri, and more than 3,000 of our closest friends, will descend upon Portland for DrupalCon, an international conference that brings together a worldwide community of enthusiasts, users, developers, designers, fanatics, and many others who in myriad ways support and play nice with the Drupal open-source content management framework.

This year, we're proud to announce that we are supporting the conference in a big way. As Platinum sponsors of the conference (and Supporting Partners of Drupal Association), Palantir builds on our commitment to actively contribute to the Drupal community by educating those who work with Drupal from beginner to advanced, evangelizing audiences for whom Drupal would provide the best content management solution, and helping to support major strategic community initiatives like Drupal 8.

In addition to sending a contingent of Palantiri who will be holding court at our booth and speaking at sessions, we are also sponsoring some special guest attendees. If you're going to DrupalCon, make sure to stop by Booth 333 to say, "Hi," and pick up a little something we made for your downtime in Portland: Palantir's Portable Portland Pocket Planner. And, should you hit any of our suggested destinations, it would be cool if you could Tweet about it using #PalantirPDX.

Who's Going

Palantir is sending a great mix of people to DrupalCon Portland including folks new and old to Palantir and big enough to form a decent a kick line: Robin Barre, Beth Binkovitz, George DeMet, Nancy Essex, Larry Garfield, Steve Persch, Dave Reid, Ken Rickard, John Albin Wilkins, and Rodney. Any one of us would enjoy learning about what's on your mind as we inch toward Drupal 8.

Who's Speaking

Check out the below sessions at which folks from Palantir will be presenting or speaking, and make sure to share your feedback or continue to the conversation with us at our booth.

Larry Garfield answers the question which plagues us: "Is Drupal a CMS?" on Tuesday from 2pm-3pm.

Steve Persch and Commerce Guys' Pedro Cambra take a different approach to plugins with, "Plugin Haikus" on Tuesday from 3:15pm-4:15pm.

The Palantir team gathers at the Day Stage to deliver the goods on the next version of Drupal with, "Drupal 8: The Good, The Bad and The Ugly" on Tuesday from 3:15pm-4:15pm.

Dave Reid talks Drupal 8's file management initiative with, "Throw New\Drupal\Core\Initiative\Filemanagement\Failureexception();," part of Core Conversations on Tuesday from 4:30pm-5pm.

John Albin Wilkins will participate in the "Using Twig: The New Template Engine in D8" roundtable on Wednesday from 3:45pm-4:45pm.

John follows that up with the lip-smacking, "Making D8 Mobilicious" on Wednesday from 5pm-6pm.

Larry Garfield, Sam Boyer and Rob Loach talk integration with, "Composer: There's a Module (or Library) for That"
on Wednesday from 5pm-6pm.

Larry Garfield and John Albin Wilkins will join others at the "Dries & Company Q&A" Core Conversations panel on Thursday from 2:15pm-3:15pm.

Larry Garfield is also speaking at the Symfony Live! conference running concurrent with DrupalCon, where he talks, "Modernizing Drupal with Symfony2" on Thursday from 1pm-2pm.

Building Bridges, Connecting Communities

Inspired by the theme of this year's DrupalCon—Building Bridges, Connecting Communities—Palantir held a DrupalCon Pass Giveaway, offering free conference passes to applicants with an active interest in Drupal but for whom cost was a barrier to attending this year. After receiving dozens of entries, the below deserving winners were selected. Keep an eye out for them at the conference (we're hoping to engage them in our Day Stage session), and share whatever important bits of wisdom you have. (Actually, you might learn a thing or two from them.) Whatever you do, don’t scare them.

Minneapolis' Tess Flynn (socketwench) would like to participate in sprints and is also interested in professional development; Portland's Dalene Bloom (sunslant) wants to gather knowledge to build her first Drupal site; Portland's Ingrid Choy-Harris (quartz45) is interested in mentorship, networking and inspiration; Cleveland's James R. Stone (fndtn357) wants to connect with folks at Commerce Guys and Pantheon; New York's Carl Wiedemann (c4rl) just wants to continue to give every drop of blood he has to Drupal; Reno's Andy Guzman (andyguzman) recently crossed Dries' "I kick ass" threshold and wants to kick more of it; Vancouver's Colin Stone (scolin22) wants to beef up his engineering studies at University of British Columbia; and from Jalisco, Mexico comes engineer Elias De la Torre Aceves (eliasdelatorre) who wants to continue to support the Drupal initiative and strengthen its presence in Latin America.

Related to our pass giveaway, Palantir also donated at pass to Italian Vincenzo Rubano who successfully ran an Indiegogo campaign to raise funds which would allow him to not only attend DrupalCon but also take his first solo trip outside of Italy. Vincenzo has an inspirational story and we’re very excited to have the opportunity meet him in Portland.

All of us at Palantir look forward to seeing our friends, clients and associates at DrupalCon. Reply to this email if you want to try and get together while there, and use #PalantirPDX for tweets about our people, sessions, or if you go to any of the destinations offered up in our Portable Portland Planner!

Let’s consider the following scenario: I have two Python processes receiving the same events and I have to measure the delay between when process A received the event and when process B received it, as precisely as possible (i.e. less than 1ms).

Using Python 2.7 and a Unix system you can use the time.time method which provides the time in seconds since Epoch and has a typical resolution of a fraction of a ms on Unix. You can use it on different processes and still compare the results, since both processes receive the time since Epoch, a defined and fixed time in the past.

On Windows time.time also provides the time since Epoch, but the resolution is in the range of 10ms, which is not suitable for my application.

There is also time.clock which is super precise on Windows, and much less precise on Unix. The mayor drawback is that it returns the time since the process started or since the first call of time.clock within that processes. This means you cannot compare the results of time.clock between two processes as they are not calibrated to a common t-zero.

I had high hopes for Python 3.3 where the time module was revamped and I was reading about time.monotonic and time.perf_counter. Especially time.perf_counter looked like it would suit my needs as the documentation said it provides the highest available resolution for the system and was “system-wide”, in contrast to for example the new time.process_time which was “process_wide”. Unfortunately it turned out that time.perf_counter acts similar to time.clock on Python 2.7 as it provides you with the time since the process started or the first time the method was called within the process. The results of time.monotonic are comparable between processes, but again not precise enough on Windows.

Here is a small script which demonstrates how the times provided by time.clock and time.perf_counter are not comparable between processes. It starts two processes and lets both of them print out the output of the timer to stdout. In the output the times should be monotonically increasing. Since I let process 2 sleep for one second before calling the timer method for the first time, the output of this process is usually one second smaller when using time.clock or time.perf_counter.

#!/usr/bin/env python from multiprocessing import Process import time timers = ['clock', 'time', 'monotonic', 'perf_counter'] def proc(timer): timer = getattr(time, timer) time.sleep(1) for i in range(3): print('P2 {time}'.format(time=timer())) time.sleep(1) if __name__ == '__main__': for t in timers: print("Using {timer}".format(timer=t)) p = Process(target=proc, args=(t,)) timer = getattr(time, t) p.start() for i in range(3): print('P1 {time}'.format(time=timer())) time.sleep(1) p.join()

The result when running on Windows with Python 3.3:

$ python timertest.py Using clock P1 6.146032526480321e-06 P1 0.9926582847820045 P2 2.9612702173041547e-05 P1 1.9941743992602412 P2 1.0008579302676737 P2 2.0022709590185346 Using time P1 1368614235.509732 P1 1368614236.511172 P2 1368614236.601301 P1 1368614237.512612 P2 1368614237.602741 P2 1368614238.604181 Using monotonic P1 484.636 P1 485.63800000000003 P2 485.738 P1 486.639 P2 486.73900000000003 P2 487.741 Using perf_counter P1 12.390910576623565 P1 13.39050745276285 P2 7.542858100680394e-06 P1 14.39190763071843 P2 1.0014012954160376 P2 2.0041399116368144

So as far as I see it, there is no way of getting comparable times between two processes on Windows with more precision than 10ms. Is that correct or am I missing something?

A decent issue tracker, allowing you and your clients to report issues and track the progress, is key to any successful project. Issue trackers can range from a simple spreadsheet to systems like mantis or JIRA, some free and some paid. So when it comes to selecting a system to use how do you choose?

Insert View is a cool module that lets content creators insert an existing View right into their content. Using a simple syntax, users can specify which View should be rendered, with which Display and what arguments should be passed as contextual filters.

It's fair to say that in the last year, adopting the CSS preprocessor SASS has completely changed frontend development for me. That's a sentiment I've heard others express when they started using it — and I was pretty late to the party.

I got attracted to it initially through variables. We've all been there when a client or a designer wants to change a color and suddenly we have to change dozens or hundreds of values across CSS.

Dale Sande captures that kind of revolution in efficiency that SASS brings, as seen in a screenshot from his upcoming presentation at Drupalcon Portland.

But Dale, who's spoken plenty on SASS and organizes the Seattle SASS meetup, is taking us way past the SASS basics like variables, and that's why I'm excited to see his presentation next week.

Around the same time SASS came onto the scene, some thoughtful people were exploring more maintainable frontend development and CSS architecture through ideas/acronyms like OOCSS, SMACSS and BEM, and folks like Nicole Sullivan, Jonathan Snook (a Drupalcon featured speaker!), Nicolas Gallagher, and Harry Roberts.

I spoke with Dale about SASS, object-oriented CSS and some the things he'll be covering at Drupalcon. Be sure to join me at his session, "Sass: OO'S'CSS w/Extends and Silent Placeholders," on Wednesday at 2:15 PM!

IB: Some people argue SASS creates bloated code — do you see placeholders addressing that concern effectively?

DS: Sass doesn’t create bad code. Bad coders do.

The whole concept of placeholder selectors was designed to fight code bloat and be a more pragmatic solution to OOCSS. In my presentation, I illustrate how using the various techniques generate code.

The real "ah-ha" moment comes when we see how using placeholder selectors makes it easier to manage and literally re-use code — thus reducing dreaded CSS bloat.

IB: What's the advantage to using silent placeholders over mixins for a set of rules?

DS: Simply put, being able to re-use code without duplicating code. The use of mixins was the first part of being DRY with our code. Looking at the Sass it felt AWESOME! But when we looked at the output CSS, this is when we realized that we were all living a lie.

Our CSS rules were being duplicated tens, if not hundreds of times. We weren't being DRY, we simply put the onus of duplication on the machine.

Placeholder selectors embrace the one of the oldest concepts of CSS and that is to extend the CSS selector for reuse. But with traditional CSS this was difficult to do, especially when you were dealing with thousands of lines of code. Sass' @extend directive allows developers to create name-spaced reusable chunks of code that is portable, re-usable and extendable without duplicating anything.

IB: Do you see placeholders as helping to reduce the amount of tight coupling — scattering pieces of styles in multiple places?

DS: While Placeholder Selectors are a tool that can help with scattered code, it is not the only solution. Having a file/folder structure that embraces the different types of code, e.g. CSS selectors, placeholder selectors, mixins and functions, can assist in creating reusable modulare code and maintain a process of control over the many parts.

Images: Screenshot from Dale Sande's presentation.

Join Rootwork on Twitter, Facebook and SlideShare.

Learn about Rootwork's services for nonprofits and social change.

Last weekend, I spent several hours carefully going over some of the WebLogin code to try to track down a weird bug that we ran into in our UAT environment. The bad part is that I didn't find it, although restarting Apache made it disappear. The good part is that I found a bunch of other bugs that would have been troublesome later.

This release is just a WebLogin bug fix release, cleaning up those issues plus a few other things we've found in testing for our upcoming production upgrade. Specifically, there's now a way to preserve remember_login across a failed login attempt, clearing of failed login attempts after a successful one works properly, cookies are set correctly on the error page, and WebLogin no longer erroneously clears cookies when redirecting to check for cookie support.

You can get the latest release from the official WebAuth distribution site or from my WebAuth distribution pages.

Most OpenPGP User IDs look like this: Jane Q. Public <jane@example.org> This is clean, clear, and unambiguous.

However, some tools (gpg, enigmail among others) ask the user to provide a "Comment:" field when they are choosing a new User ID (e.g. when making a new key). These UI prompts are evil. The savvy user knows to avoid entering anything in this field, so that they can end up with a User ID like the one above. The user who provides something here (perhaps even something inconsequential like "I like strawberries", due to not being sure what should go in this little box) will instead end up with a User ID like:

Jane Q. Public (I like strawberries) <jane@example.org> This is bad. This means that Jane is asking the people who certify her key+userid to certify whether she actually likes strawberries (how could they know? what if she changes her mind? should they revoke their certifications?) and anywhere that she is referred to by name will include this mention of strawberries. This is not Jane's identity, and it doesn't belong in an OpenPGP User ID packet.

Furthermore, since User IDs are atomic, if Jane wants to change the comment field (but leave her name and e-mail address the same), she will instead need to create a new User ID, publish it, get everyone who has certified her old key+userid to certify the key+newuserid, and then revoke the old one.

It is difficult already to help people understand and participate in the certification network that forms that backbone of OpenPGP's so-called "web of trust". These bogus comment fields make an already-difficult task harder. And all because of strawberries!

Tools like enigmail and gpg should not expose the "Comment:" field to users who are generating keys or choosing new User IDs. If they feel it absolutely must be present for some weird corner case that 0.1% of their users will have, they could require that the user enters some sort of "expert mode" before prompting the user to do something that is likely to be a mistake.

There is almost no legitimate reason for anyone to use this field. Let's go through some examples of this people use, taken from some examples i have lying around (identifying marks have been changed to protect the innocent who were duped by this bad UI choice, but you can probably find them on the public keyserver network if you want to hunt around):

domain repetition

John Q. Public (Debian) <johnqpublic@debian.org> We know you're with debian already from the @debian.org address. If this is in contrast to your other address (johnqpublic@example.org) so that people know where to send you debian-related e-mail, this is still not necessary.

Lest you think i'm just calling out debian developers, people with @ubuntu.com addresses and (Ubuntu) comments (as well as @example.edu addresses and (Example University) comments and @example.com addresses and (Example Corp) comments) are out there too.

nicknames already evident

John Q. Public (Johnny) <johnqpublic@example.net> John Q. Public (wackydude) <wackydude@example.net> Again, the information these comments are providing offers no clear disambiguation from the info already contained in the name and e-mail address, and just muddies the water about what the people who certify this identity should actually be trying to verify before they make their certification.

"Work"

John Q. Public (Work) <johnqpublic@example.com> if John's correspondents know that he works for Example Corp, then "Work" isn't helpful to them, because they already know this as the address that they're writing to him with. If they don't know that, then they probably aren't writing to him at work, so they don't need this comment either. The same problem appears (for example) with literal comments of (School) next to their @example.edu address.

This is my nth try at this crazy system!

John Q. Public (This is my second key) <johnqpublic@example.com> John Q. Public (This is my primary key) <johnqpublic@example.com> John Q. Public (No wait really use this one) <johnqpublic@example.com> OpenPGP is confusing, and it can be tricky to get it right. We all know :) This is still not part of John's identity. If you want to designate a key as your preferred key, keep it up-to-date, get people to certify it, and revoke or expire your old keys. People who care can look at the timestamps on your keys and tell which ones are the most recent ones. You do have a revocation certificate for your key handy just in case you lose it, right?

Don't use this key

John Q. Public (Old key, do not use) <johnqpublic@example.com> John Q. Public (Please only use this through September 2004) <johnqpublic@example.com> This kind of sentiment is better expressed by revoking the key in question or setting an expiration time on the key or User ID self-sig directly. This sentiment is not part of John's identity, and shouldn't be included as though it were.

"none"

John Q. Public (none) <johnqpublic@example.com> sigh. This is clearly someone getting mixed up by the UI.

I use strong crypto!

John Q. Public (3092 bits of RSA) <johnqpublic@example.com> This comment refers to the strength of the key material, or the algorithms preferred by the user. Since the User ID is associated with the key material already, people who care about this information can get it from the key directly. This is also not part of the user's actual identity.

"no comment"

John Q. Public (no comment) <johnqpublic@example.com> This is actually not uncommon (some keyservers reply "too many matches!"). It shows that the user is witty and can think on their feet (at least once), but it is still not part of the user's identity.

But wait (i hear you say)! I have a special case that actually is a legitimate use of the comment field that cannot be expressed in OpenPGP in any other way!

I'm sure that such cases exist. I've even seen one or two of them. The fact that one or two cases exist does not excuse the fact that that overwhelming majority of these comments in OpenPGP User IDs are a mistake, caused only by bad UI design that prompts people to put something (anything!) in the empty box (or on the command prompt, depending on your preference).

And this mistake is one of the thousand papercuts that inhibits the robust growth of the OpenPGP certification network that some people call the "web of trust". Let's avoid them so we can focus on the other 999 papercuts.

Please don't use comments in your OpenPGP User ID. And if you make a user interface for OpenPGP that prompts the user to decide on a new User ID, please don't include a prompt for "Comment" unless the user has already certified that they are really and truly a special special snowflake.

Thanks!

Tags: openpgp, ui