Melissa's blog

  • Keeping on top of security updates

    Oct 01, 2012

    I hear a lot from people who know they should be applying security updates, who *want* to apply security updates, but they don’t.

    Why good people don’t keep up with security updates:

    • The number of updates has built up until the list feels overwhelming
    • In an effort to keep their modules page “green” they’ve applied the yellow updates without reviewing them and changed the way their site works in unexpected and unpleasant ways
    • They’ve been burned by an update that went out untested and broke their site
    • They don’t have time to test the updates and know better than to apply them untested
    • They don’t have a clear test plan that leaves them feeling confident that everything is working

    Know what needs updating

    The Update Status module

    Drupal 6 and 7 make it easy to see what needs updating. When the Update Status module, included in Drupal core, is enabled, it checks automatically to see what updates your site needs. You can view what needs updating at Reports > Available updates.

    Update Status can be configured to suit your notification preferences at Reports > Available Updates > Settings.

    Security Advisories

    Some people prefer to review the Security advisories or subscribe to the Security mailing list. This can be overwhelming if you’re running a single site with just a few modules, but it’s invaluable to people who build new sites regularly.

    Tips for keeping up to date

    Here are a few process tips to help you feel confident about keeping your site secure.

    Don’t:

    • Don’t apply an untested update to your production site

      Really. Don’t do this. A bad experience shared with all of your users is just the sort of thing that discourages people from running updates.

    • Don’t feel pressured to upgrade modules that are highlighted yellow on the available updates page.

      These updates affect functionality and are likely to chage the user experience. If your site is running smoothly and you’re happy with functionality, it’s okay to use the version you have. As rewarding as a page full of green feels to some of us, maintaining a consistent user experience is an excellent reason NOT to update.

    • Don’t skip testing your production site

      • Allow yourself a maintenance window and run through the same tests on production as you do on your staging site, especially if there are any differences in the operating system, database, web server or php versions.

    Do:

    • Remove or disable unused modules on your site

      It’s best to remove unused modules entirely and keep modules that are seldom used in production disabled. That way, you won’t be spending time needlessly maintaining modules that no one is using.

    • Check the security status of your site at a specific time each week

      Setting aside a specific time encourages keeping your site consistently more secure. It’s much easier to approach a single update than to face a mountain of changes that have piled up over months. The Drupal security team makes vulnerability announcements each Wednesday, so depending on your timezone, Wednesday or Thursday is a good time to see what needs doing.

      Many weeks, you’ll see nothing at all needs updating. On those weeks, explore the yellow ones. See what features are being changed, and experiment with them on your staging site.

    • Apply security updates to a staging site first

      This staging site should have the same operating system and the same versions of the web server, database, and php as your production site. Even if for some reason you can’t match them exactly, you’re still better off testing on staging first.

    • Before applying updates, make a backup of your database and code

      This is a good idea for both your staging and production sites. If you run into something unexpected on staging, the experience of restoring the site can help build your confidence for updates to production.

    • Look at the release notes

      When you apply an update, look at the release notes. It’s okay if you don’t understand everything in them, but many module maintainers will let you know when a security update is also going to affect the way the module works. Not everyone can or does call it out, but when they do, it saves you from discovering it on your own - or worse, not discovering it until it’s too late.

    Interested in developing a robust, effective testing process? Check out our new training: Quality Assurance for Drupal Sites!

  • How do you learn a new module?

    Apr 20, 2012

    When I'm writing curriculum, I work hard at sequencing the instruction in order to efficiently demonstrate Drupal site building and to teach interdependent concepts. People who come to web site building from a non-technical background face non-trivial challenges trying to form a conceptual framework when there are so many module choices and so much variation in module quality and documentation.

    To lay a conceptual framework via the FullCalendar module, for example, we do the following:

    • Begin with a clearly defined outcome in mind
    • Install and enable required modules and libraries, which I already know can produce those outcomes
    • Configure the date module so the long, medium, and short formats are the US-preferred am/pm formats and that we've consciously chosen how users will interact with time zones.
    • Create a content type
    • Set its url pattern so that it will match up with the URL for the calendar view we create later
    • Test the new URL pattern while simultaneously creating valid test data
    • Create and configure the view (so that it matches the pattern we set for the content type)
    • Set and test user permissions

    Everything we need is set up to be available before we need it.

    This is almost perfectly inverse to the way I personally learned Drupal and the way I still approach learning a new module, which is more like this:

    • I may or may not have a specific outcome in mind
    • Usually I install the module and head to the config page
    • If I can't suss out what to do from that, I look at the README file
    • If the README file isn't helpful, I look for on-line documentation
    • If I'm still stuck I reference the issue queue. I ignore error messages until they actually stop me from moving forward unless they provide helpful direction.
    • Then I google key words +tutorial because if I haven't gotten it by now, I probably need someone to break it down for me)
    • I look at all the text-based results and switch to screen casts as a last resort
    • If I can't make it do my bidding after all of that, I start looking for other approaches

    In longer courses, I like to demonstrate both approaches, spending most of the day with smoothly sequenced procedures. Toward the end if attendees are on solid ground, I have them describe different functionality they're seeking, then pick a suggestion that will require a module I've not used before and learn it in front of them.

    We don't spend a ton of time this way, but it's important to me that they realize that their experience when they go back to the office is highly unlikely to mirror a smooth classroom experience. I want to demonstrate how to surmount obstacles and show that with persistence, they can learn this way, too. Grumbling, false starts, and regrettable choices seem to me to be very much a part of the learning process.

    Since I've started to focus exclusively on instruction for Drupal site building, I've become intensely curious how other people approach learning a new module and how their learning process has changed over time. I invite you to share your experience.

  • My Top Five Takeaways from NTEN’s Drupal Day

    Apr 06, 2012

    It’s great to return from a conference energized, and that’s exactly how I’m feeling after my first Non-profit Technology Network (NTEN) event. I’d been invited to lend a hand with Drupal Day by presenting an introduction to Drupal terminology and concepts as well as facilitating breakout sessions.

    Anticipating a relatively small number of attendees for this optional session, I’d set up in a corner, but well before I began it was clear I’d need to move to the podium, and by the time I’d finished, we were bringing in extra chairs for the rest of the day.

    Each of the five topic sessions included a 10-minute case study delivered to the whole group followed by 20-minute breakouts more or less related to the case study. In the five breakouts I facilitated, we discussed:

    • Using Drupal to lighten your workload
    • Tips on working with developers
    • How user stories can help keep you on track
    • Care and feeding of small Drupal sites
    • Getting help from the Drupal community



    Here's what I took away.

    5) I finally understand why I’m shy about presenting

    I’ve known for a long time that I get nervous about lecture+slide presentations, but I can stand in front of the same number of people and give short presentations, directions, guidance, etc. The format of Drupal Day helped me realize why: I dread the possibility of making other people feel trapped or bored.

    In large group presentations, it’s harder to tell how everyone is doing, harder to respond to feedback on the fly, and it never feels like an option to abandon an ill-conceived plan midstream. Knowing the session was considered optional and that I’d have a chance to work more interactively with people afterward made it a lot less stressful to prepare and deliver, and feedback was overwhelmingly positive. Huge thanks to Drupal Day organizer Sean Larkin and to Johanna Bates for a great event and keeping me pointed in the right direction!

    4) Breakouts are fun!

    Everyone who comes to a conference, a class, a webinar, brings expertise and valuable information. From my perspective, the very best learning comes from our interaction, not scripts, slides or manuals.

    3) Community politics are everywhere

    As an active participant in the Drupal community, sometimes I get a little down about how hard it can be to reach decisions and how complex human interaction becomes. Immersed in a specialized area, I can forget that complexity and politics are parts of the human experience, so catching hints of the challenges of organizing from elsewhere refuels my patience with my own community.

    2) There's so much more in the world that matters

    I love working in open source software because I control my work and my product. I don't control Drupal itself, but I choose what I do and make the critical decisions about it. The work itself, however, is so far removed from what feels real to me, occasionally I despair. There's something disheartening about knowing that everything I've done today can be destroyed by a single badly-timed hardware failure. It's invigorating to spend time with people who create change in the world that’s still accessible when the power is out.

    1) Next time, stay all week

    Unfortunately, a hectic work schedule, recent travels, and a family life meant that I was only able to stay for Drupal Day. Next year, I'll plan to be there to take part in the official programming and especially for longer conversations. I am best as a trainer and site builder, and I offer more to the Drupal community, when I have a clear idea where the people we serve need to go and what's getting in their way.

  • Melissa Anderson

    Melissa

    OpenSourcery Alumnus