Planet Drupal

Hello there!
A lot has happened since I last sent out a newsletter... here's a very brief overview:

Podcasts

There have been a ton of podcasts! I'm still releasing one every week. (Shooting for Wednesdays, but sometimes I'm a little behind.) So, here are a few of the recent ones.

Playing around with Drupal 8 together with Graph API and Graph I generated this UML through admin/config/system/graphapi/uml/Drupal\views\Plugin\Core\Entity\View ... it has some rough edges still.

Tell us what you think of this UML Diagram and your needs to have on site information.

Image from Curled up kitten

• planet drupal
• drupal-8

This week we look at an image utility module that lets you insert images that you upload using the Drupal core image field inline into any text field in your node.

• First-off, we’re going to be talking about both the MailChimp and Mandrill modules. So, before we get into the modules, can you explain the difference between the two services?
• Unique relationship with MailChimp and how they’re sponsoring development, etc.
• What do you see as the benefit of using an external service like MailChimp as compared to a “Drupal” specific setup like using Simplenews or Message notify?
• And for the sake of argument, what would you see as a benefit of using a “Drupal” setup over an external service?

Mail Chimp

• How much integration is there between the module and the service?
• Can you create new lists from the Drupal interface? How many lists?
• Can you create the newsletters in the Drupal interface?
• How do you work with templates? Do you configure them on the MailChimp side, and then select them in the Drupal interface?
• MailChimp has a “drag and drop editor”, is that functionality carried over to the Drupal interface?
• How do you include site content?
• How does it deal with images in a newsletter?
• How can you add site content into a newsletter?
• Can you setup autoresponders?
• Can you setup split tests in the Drupal interface?
  • LT: MailChimp handles this with it’s email optimizer
• Can you view reports and analytics in Drupal?
• How do users subscribe and unsubscribe from a newsletter?

Mandrill

• What is Mandrill?
• How does the Module integrate with the service?

Use Cases

• MailChimp
• Mandrill
• When would you use both?
• Documentation? Screencasts?

Questions from Twitter

• Q’s

The end is nigh. Starting March 5th, 2013 Twitter is stopping the support for unauthenticated requests, i.e. turning off the API v1 and RSS/Atom feeds.

Twitter wants that we authenticate every request with OAuth in their API v1.1, that only supports JSON.

It's the end of an era. I will be nostalgic for the days when it was so easy to fetch and parse JSON from Twitter. All those tutorials in the web will be lost in time...

Twitter mercifully warned us long time ago, on August 2012. But it's totally understandable for us, developers, to leave it for later. Deadlines are our thing.

The plan for API v1’s Retirement

This is the important link: read this Twitter plan, probably it will be updated frequently with more information during the next days.

We will perform the first of what we call "blackout tests" for API v1 on March 5th, 2013. [...] from around 9:00am to 10:00am PST

All unauthenticated requests during that time window will be responded to with a HTTP 410 Gone.

Over the next few weeks we'll be announcing additional blackout tests and a more detailed schedule regarding the retirement of API v1.

Modules for Drupal

You should be using in your Drupal site the last version of Twitter module, then you will be safe. Thanks to my mate juampy for implementing all the new changes and maintaining this awesome module for Drupal 6 and 7.

If your Drupal site is using the easy and light-weight Twitter Pull module, this module is based on the Twitter API v1, so it will stop working.
Some days ago the maintainer has committed a patch to make work Twitter Pull module on top of the Twitter module.

In that same issue, I saw Boriana Ditcheva gave really good instructions on how to switch to the Twitter module. I asked her permission to publish them here, and she gladly agree. Thank you!, here it goes:

Instructions to switch to Twitter module

1. Go to https://dev.twitter.com, login with the twitter username you'll want to pull tweets from and add your website as a new application! This is needed so your website is identified as an application that can communicate with your twitter account once the new authentication requirements are in full effect. Then you'll have the consumer key/secret the twitter module uses to login.
   
   Choose 'Read Only' for the access if you'll only be pulling tweets (versus posting tweets). I'm assuming we're only in that boat, since we chose the twitter_pull module in the first place.
2. Download and enable the OAuth and Twitter modules.
3. Go to Admin --> Configuration --> Web Services --> Twitter --> Settings and paste in the consumer key & secret you got when you added your website as an application to interact with your twitter account above
4. Now go to the 'Twitter' tab of the configuration screen. I had a hard time getting this to work on localhost, since it seems that the 'Website' and 'Callback' URLs on the twitter application side have to match what's listed in the settings tab of this module. Something like http://YOURSITE.com/twitter/oauth. Since I was working on localhost, it would not accept that as a URL, and I had to end up doing this all on my test site that's actually online!!!. Once you've got that part figured out though, click here to add a new user, and just make sure you're logged into the twitter account you want to add.
5. Check the 'Tweet' or 'Tweet' and 'Mention' options next to the user, once you add them, depending on what you want to download.
6. Now go to the 'Views' section of your website and either modify or clone-then-modify the views that come with this module, until you get them looking similarly to what your twitter_pull blocks looked like.... I had to re-do some of my custom styling, but now it looks identical. Hooray

More?

Do you have some tips in your experience upgrading to API v1.1 ? I will update this post with your suggestions.

Ever wanted to give form elements a custom look? Theming entire forms is straightforward, if laborious. But theming individual textboxes, checkboxes and radio buttons is slightly more obscure. Keep reading to find out how to fully customize your form elements, from the input itself to the label.

Episode Number:  117 Post Topics:  Drupal Fields Contrib Drupal 7 Drupal Planet UI/Design Javascript JQuery

The Drupal 7 jQuery SelectBox module is a simple module that makes HTML select boxes easier to style. It replaces the HTML form select element with easier to style HTML markup.

In this episode you will learn:

• How to download and install the jQuery SelectBox module
• What the jQuery SelectBox module is doing in the background to make the select boxes on the site continue to work correctly

Thanks to Drupalize.me for sponsoring this episode.

DDoD Video: 

Start:  2013-03-04 17:30 - 18:00 Europe/London Online meeting (eg. IRC meeting) Organizers:  tvn lisarex

Have you ever visited Drupal.org Case studies, or Marketplace, or Drupal Planet? All of them are moderated by a small team of volunteers. And they really need your help! No coding skills are required to contribute to Drupal.org in this way.

Each Monday content team meets in the #drupalorg IRC channel. Join the meeting and help us improve content on Drupal.org!

When is it for your time zone?

28 FebWalkthrough.it crowdfunding campaign launched!Read more

EVA, short for entity views attachment, and Display Suite – like Wu Tang vs The Beatles – is a great combo for getting diverse information on a page.  If you just want to see what it looks like and how it works http://www.bioconnector.virginia.edu/galaxy.  For those of you who like the video style learning here you are: http://www.youtube.com/watch?v=E9uq2ZOZNVw

Use case: We have a content type “Experts” that we want to link to the content type “tools” that they are adept with.  Tools  chosen during registration will then show their profile on the page and on their profiles there will be a link to their tools.

Screenshot of the layout with the attached view

What we built: If you’ve used views attach in D6  the EVA concept should be pretty straightforward and the views attach tutorial here covers it pretty well.  As the name suggests EVA takes the broad level entity API as the starting point.  This gives us a lot of flexibility in terms of where we can use the EVA module.  By using an entity reference on the “Expert” content type we are able to create a select list for the end user.

Some of the basic aspects of EVA

Could you do this with a node reference… sure – but entity references are so mo betta!

entity reference in the content structure

Ok so you’ve got the entity reference in place, and the EVA view built… now you want to drop that view stylishly on the the page…  and because the good folks at EVA did things so well all you need to do is install Display Suite and your work is almost done.  The nice thing now is that all you need is to pick a layout and viola… you got pretty music   I realize this is all pretty 101ish stuff, and that is the good news.  There’s really not much more you need.

A few other handy modules that made things pretty: Sweaver.  Some folks can’t stand this module…  I happen to love it for the basics of getting spacing and font sizes correct. Gallery Formatter with the Lightbox2 plugin handled the gallery in the content type – also positioned thanks to Display Suite.

Display suite 101

What the editing user sees: and the last thing to note is what the user sees when they’re adding experts in to the site:

All the end user needs to know

Download Podcast 100

Angie Byron (webchick) joins Andrew Riley, Ryan Price, and Mike Anello for the centennial edition of the DrupalEasy Podcast.

read more

At the most recent Drupal4Gov,* Zane McHattie and I presented a session on "Considering Accessibility Throughout the Process." This Drupal4Gov was targeted at theming and accessibility, and since I'm a front-end dev, my part of the presentation does focus on what themers can do to make sites more accessible. However, we also addressed the idea that developers are the ones who make a site accessible; a truly accessible site is the result of developers, designers, and content creators working together.

This was my first presentation to a group of people not in my workplace, so I'll admit that I woke up very nervous the day of and wrote out crazy detailed notes on what I was going to say. Since these notes would otherwise go to waste, I repurposed them to write up the presentation for this blog post.

1. Gather requirements early.

Front-end developers, designers, project managers, and clients all benefit from thinking about where time will have to be spent on accessibility during a project. If you're making a 508-compliant, accessible site, planning for this in your timelines, making sure your team knows how it will affect each member, and testing and revising throughout the process will go a long way toward a successful launch.

Kick off your project with a solid understanding of your agency's or client's requirements. While everyone is subject to Section 508, different agencies can interpret it differently and even enforce more stringent accessibility requirements (HHS is a good example). Some clients who request YouTube videos on their site may not want to spend time skinning the YouTube player to make it more accessible; others may require it.

It also helps to know what third-party content your client intends to serve up on their website (e.g. videos, podcasts, etc.) and whether the services they use for this are accessible. If you have to embed an iframe on your site with inaccessible content inside, all the work in the world won't make it compliant, and communicating that to your client early can prevent you from being held responsible for work outside your control.

Conducting some discovery on the site will help you identify places where you can compromise. Dan Mouyard of Forum One had a great presentation at Drupal4Gov on testing site accessibility; during it, he pointed out that there is no such thing as a 100% accessible site that meets every benchmark. Instead, you're aiming to get sites as accessible as possible, as fast as possible, as efficiently as possible. For example, if your client wants a maps mashup, you may choose to provide that information in an alternative format (more on that below) rather than spending a lot of time and testing on creating a map that screenreader users can browse intuitively.

Finally, remember that accessibility isn't just about screenreader users; it's about all kinds of users, from those with mobility issues to hearing impairments to those who have trouble with content that's not written in plain language. Catherine McNally's Drupal4Gov presentation did a fantastic job of showing the many types of users impacted by poor accessibility. At its heart, accessibility is good usability; everyone benefits from it.

2. Know where themers invest time making things accessible.

Assuming that you’re working from an accessible base theme that already includes basic accessibility features, such as skip navigation, you can expect to spend time on:
- alternative formats
- JavaScript fallbacks
- content type adjustments
- module markup adjustments
- heading level adjustments
- mobile accessibility
- admin accessibility

I’ll go over specific examples of the first five and touch on mobile and admin accessibility.

Alternative formats

During the planning phase of a project, you may identify things you want to build that will be difficult to make fully 508 compliant; knowing where you need to compromise is key here. However, any information you present on your website needs to be accessible by your full audience. You may decide to display some information in an alternative format to make sure that everyone can access it.

I’m showing a basic example of an alternative format above. A search on Google Maps will return a map that would be difficult for a screenreader user to navigate, with markers and even small dots that could be difficult for someone with mobility issues to click. Fortunately, there’s also a text list that shows the restaurant name, address, phone number, website, and reviews. This list can be tabbed through. That’s not to say Google does it perfectly; the lack of a focus indicator is pretty frustrating. But it gets at the heart of showing information in a way your audience can digest.

Knowing we have the option to create an alternative format, it's tempting to declare this an easy option during the planning phase; however, anything you put on your website is going to need time from a front-end developer to build and style appropriately. If you’re creating a view with a long text list of locations to complement a map, you may need to include anchor links to help users skip around more easily. You may want to include icons, as Google Maps does. Your designer will almost definitely have thoughts about how it should look. This means that even your easy option can be time-consuming, and your timeline and estimates should take this into account.

JavaScript fallbacks

If your design has interactive elements, chances are good that you’ll be using JavaScript or modules that rely on JavaScript. The simplest example is a carousel. With JavaScript enabled, it may cycle -- or allow you to move through -- several featured items. With JavaScript disabled, it still needs to allow you to access those featured items, and you probably want it to do that without breaking the look and feel of your homepage.

This screenshots below show the rotator from the Social Security Administration. With JavaScript enabled, it shows 4 slides. With JavaScript disabled, it degrades nicely to a text list. This takes theming and some forethought about what you want the non-JavaScript behavior to be.

For an example of what can happen without fallbacks, see the dropdowns in the boxes underneath the rotators. The Javascript-off version doesn't have these, meaning that someone with Javascript off won't be able to jump to any pages in that dropdown. A simple "More" link replacing the dropdown in a noscript element would make things easier.

As you’re selecting modules that use JavaScript, you might find ones that handle their own fallbacks, but this will require testing. For example, while using an earlier version of Colorbox, I used Colorbox triggers in my views assuming that they would degrade nicely to a simple link (normal Colorbox behavior). But when I tested, I ended up with links that went nowhere. This was fixed in the current version of Colorbox, but it was a valuable lesson in assumptions about module functionality.

The key here is that if you include JavaScript elements in your design, your designer or UX strategist may need to spend some time figuring out how they should work with JavaScript off and then making them work that way; at a minimum, they will have to work iteratively with the themer during development.

Content type adjustments

Whether or not your front-end developer is the one making your content types depends on your team’s workflow, but chances are good that they’ll have to touch them to make changes that affect the markup. I once worked on a project that had the alt tag in a separate field from the image due to an issue importing content with Feeds (see http://drupal.org/node/1080386).

Now, if you use the alt tag attribute on the image, it will appear with its alt anywhere it’s used on the site -- most notably in views or teasers. But if you don’t, it appears with null alt. During testing, I had to make an adjustment to the content type (shown below) to add the alt field to the image and then work with the backend developer or the content person to move those alt tags.

Alternatively, you could spend time doing views rewriting (my original approach) or making template files to get that alt tag field associated with the image; in my case, this proved too time-consuming. In short, it would be ideal if we didn’t have to revisit the content types for markup reasons, but it’s a good idea to test things out and identify trouble spots before a large-scale migration; that way you’ll save yourself some work in the long run.

Module markup adjustments

The front-end developer is probably not the person with primary responsibility for modules. But you may find yourself needing to test and override contrib module markup in one way or another -- the most common being by copying their TPLs into the theme and adjusting them. The image below shows a typical example from the Twitter Block module. It has a link wrapped around an image and some text. The link text is the person’s Twitter username, and the image gets the alt text “Twitter Avatar.”

<div class="twitter_block tweet"> <div class="twitter_block_user"> <a class="twitter_block profile_image" href="http://twitter.com/<?php echo $user_image; ?>"> <img src="<?php echo $user_image; ?>" alt="Twitter Avatar" /> <span class="twitter_block_user_name"><?php echo $user_name; ?></span> </a> </div> <div class="tweet_text"><p class="tweet"><?php echo $text; ?></p></div> </div>

This alt text isn’t really useful to someone with a screenreader, and it’s repetitive for each tweet, so I copied this into my theme and replaced <img src="<?php echo $user_image; ?>" alt="Twitter Avatar" /> with <img src="<?php echo $user_image; ?>" alt="" />. The result is that all screenreaders would encounter is the username, which is much more intuitive.

This is a simple example. A more complex one is a recent update I had to make with Colorbox that didn’t include a TPL. When a Colorbox popped up, it didn’t tab the user into it, so a screenreader could open the modal window and then continue reading the page as if it hadn’t. We had relevant information in the pop-up, so we needed a way to give it focus. Since Colorbox relies on JavaScript anyway, we used JavaScript to give the first link in the pop-up focus when the trigger was clicked. Little adjustments like this are fairly simple, but they add up quickly if you’ve got a lot of contrib modules to work through.

Heading level adjustments

Your headings should be structured semantically: heading 1, then heading 2, then heading 3. Sometimes you’ll encounter modules that don’t respect this. If you use Views and group by a field, it puts a heading above a list of its children; trouble is, that’s always an h3, and sometimes an h3 isn’t appropriate -- for instance, if it’s the first heading underneath your h1, you’d want it to be an h2. Sadly, the normal way of changing HTML elements in views doesn’t work on group headers because it’s hard-coded in the TPL. However, you can hunt down that TPL (views-view-unformatted, usually; will be different if your view format isn't Unformatted) and change the h3 to an h2, globally for a view format or on an individual view basis.

<?php if (!empty($title)): ?> <h3><?php print $title; ?></h3> <?php endif; ?> <?php foreach ($rows as $id => $row): ?> <div <?php if ($classes_array[$id]) { print 'class="' . $classes_array[$id] .'"'; } ?>> <?php print $row; ?> </div> <?php endforeach; ?>

To change the heading level of the grouping header, change <h3><?php print $title; ?></h3> to <h2><?php print $title; ?></h2>.

You might also use a module like Fences to pick semantically appropriate elements for different fields on your content types. For example, if you’re working on a Biography content type and you want the Role field to appear as an h2 above their responsibilities, Fences will let you pick the h2 from the Manage Fields screen. This is a great module that will save you some work as you’re creating something that’s structured semantically (and strip out a lot of unnecessary markup -- a nice plus).

Mobile and admin accessibility

Depending on the requirements of your site, there are two other areas where themers can sink a lot of time: mobile accessibility and admin accessibility. If you’re building a site that functions differently on a mobile device than on a desktop one (particularly when it involves different JavaScript), you might have to spend some time testing it in that device’s accessibility tools, like Voiceover for the iPhone.

You might also find yourself spending a lot of time on creating an accessible administrative interface, since the admins for government sites should be 508 compliant as well. It’s easy to spend time focusing only on the front-end portion of the site since that’s what the vast majority of users will see, so it bears noting up front that this is a potential trouble spot and getting your team -- or client -- on board with that.

3. Consider design accessibility, not just theme accessibility.

Plenty of people assume that a themer's going to have to spend time on this, but accessibility needs to be considered throughout the process to make sure that the end result is 508 compliant. Few designers appreciate it when a front-end developer starts changing the colors in their approved design; this means that color contrast needs to be considered up front, way before development starts. The design should be checked for color contrast before the people who’ll be approving it ever see it (see color tools at the bottom of this entry).

You’ll also want to spend some time ensuring that information is communicated with more than just color. For example, if the only difference between your links and your regular text is a dark blue color, some people may not be able to identify the links. If you add an underline, there’s an easy way to tell them apart. If your site features inforgraphics or graphs, make sure color isn't the only way distinctions are drawn -- add patterns or, even better, clear labels.

Accessible designs go beyond color; you’ll also want to make sure that your fonts are large enough -- preferably 12pt, 10pt minimum. Your fonts should be either web-safe, or can be purchased from a service like FontSpring and embedded. This ensures that you won’t have to use images for your headings, which are worse for accessibility and much worse for your content creators to maintain. Changing a stylized image heading can become nearly impossible if you don't have the font or the original PSD.

If your designers have an opinion about how focus indicators look, they should specify them up front; otherwise the usual dotted gray box will be used when users tab through or click links. Removing the focus indicator during development should not be an option.

Finally, if your design has a lot of interactive elements that will require JavaScript, you should start thinking during the design stage about how you want the fallbacks to work and how much time you’re prepared to spend making the experience the same for users with JavaScript disabled.

4. Consider content accessibility.

If the developer receives content that isn’t accessible, the site won’t be accessible no matter how much work he or she does. Most obviously, content creators should create alt text at the time of image selection. If an image is just decorative, it’s okay to have null alt text, but if it conveys meaning -- like a photo of an agency administrator testifying before Congress -- it needs to be communicated to the user.

Both video transcripts and video captions should be provided. Contrary to popular belief, both are necessary for 508 compliance. If only video transcripts are available, make sure you budget extra time to add captioning to videos. If you're providing audio files, make sure you include an audio transcript.

Content should be structured semantically. This goes beyond just theming; content creators are going to continually interact with your WYSIWYG and will need to be trained on proper heading order (h2, then h3; no h1s, since the h1 is reserved for the page title). When possible, content should be written in plain language so it's easily understandable.

5. Test iteratively.

There are a lot of ways a site can be inaccessible, and getting a big list of deficiencies right before launch can derail a project. To avoid this, you can educate content creators early and test iteratively throughout design, development, and migration to identify problems early and correct them as they arise. The result is a more cohesive site with graceful fallbacks where they're necessary.

If someone outside your team will be evaluating the site before launch, it's a good idea to reach out to him or her early. We've had success with submitting prototypes of potentially tricky functionality for testing before heavy development begins. When you do encounter problems, these evaluators can be a resource since they often have a breadth of experience with these issues and know the quirks of their testing software enough to provide some guidance.

6. Know your tools.

There are way too many testing tools for all of them to be listed, but here are a few that we use at Rock Creek to get a jump on testing.

Color tools

• Colour Contrast Check (website)
• Contrast Analyser (program for Windows and Mac)
• Color Blindness Simulator (website)
• Color Oracle (program for Windows, Mac, and Linux)

Markup tools

• WAVE (website and Firefox extension; the Firefox extension offers more thorough testing results)
• AMP (proprietary Windows tool; there's also an express version)

Notes

• If you missed the presentations, you can watch the videocast of the event. ↩

Tuesday was another great night at the Drupal Coffee club. As usual we ran the gamut of topics ranging from privacy and legal issues with information to leveraging cloud services for your development environment.

"How can we leverage the cloud with our development environment?" 

One of our members was looking to setup a development environment using a flash drive as the local source for his files. He wanted easily transfer them between his laptop and his desktop. Since he had a Gmail account so we decided to forgo the use of a flash drive and sync a folder on his desktop with his google Drive account.

28 FebA distribution for Drupal User Groups III

In my earlier blog post about a distribution that all Drupal User Groups regardless of language and location could use, I invited you to a presentation and code sprint on DrupalCamp Bratislava. Thank you to those who showed up! If you couldn’t attend, read on for a summary of my presentation and an invitation to the next code sprint on Drupal Sprint Weekend on 9th March.

Read more

Back at the start of 2008, I was in a major rut. I was stuck in a job that I didn't much care for, and had been for almost 13 years. I suffer from social anxiety and it was much easier to stick with the same job than to find another one.  Living in a small village, I didn't know any other local geeks either.

I'm not sure how I stumbled across it, but in mid-January 2008, I found the GeekUp mailing list.  I was amazed, there were people similar to me out there after all and I quickly made some great friends on there.  Big thanks go to Andrew Disley for creating GeekUp.

Although I was employed as an electronics engineer, I also looked after the company website.  I'd built it as a static site originally, but as it had grown, it was getting harder to manage.  I'd heard a lot about CMSs and had started looking round for a solution when I saw a post on the GeekUp list.

"Good news! menusandblocks.co.uk (aka James Panton and Chris Maiden) are running a Drupal workshop at Manchester Digital Development Agency on Wednesday 9th April 2008."

I signed up for the course and persuaded work to pay for it.

Looking back, the 1st March 2008 was a big turning point for me.  It was the date of the first Manchester Barcamp, the first geek event I'd attended.  To say I was nervous about going would be an understatement!  I didn't know anyone else going, but I knew that Chris and James were going to do a talk about Drupal.  Only many months later did I discover that they were just as nervous about meeting me – I was Menusandblocks' first paying customer.  Big thanks go to Paul Robinson and all the helpers for organising that Barcamp.

After meeting many of the people I knew from the GeekUp mailing list, I started going along to the GeekUp meetings in Manchester.  That progressed to me going to NWDUG and PHPNW meetings too.  Getting involved in the Manchester geek community really helped to boost my confidence and helped a lot with my social anxiety.

As 2008 progressed, I was hearing more and more about the upcoming Drupalcon in Szeged.  I'd got no holiday plans, so I decided to book up, together with James and Peter Jones, and see what all the fuss was about.  It was the first Drupalcon for all of us, so we were all buzzing!  It was an amazing experience – the community spirit was incredible with 600 or so Drupal people taking over the town.  I made some great friends that week, including Stella.  We were both thinking about setting up Drupal companies and egged each other on.  Shortly after getting back, I handed in my notice at work and Galooph Industries was born.

On the flight back from Hungary, James and I half-joked about how good it would be to run a Drupal event in Manchester and get the Drupal community spirit going there.  Well, one thing led to another and June 2009 saw about 90 people get together for Drupalcamp Manchester.  It was fantastic to feel I was giving something back to the community that had halped me so much and again I was amazed how people offered to help and give talks.  It was also the only time I've ever ordered £1000 worth of pizza!

Photo courtesy of cubicgarden.

One of the attendees was Mike Bell and several years later he wrote a blog post about Drupalcamp Manchester that still brings a lump to my throat.  In an awesome demonstration of the ripple effect that communities can have, he went on to help organise DrupalcampNW last year and also runs NWDUG together with Philip Norton.

From Galooph Industries, I went on to join Menusandblocks and now Code Enigma.  It's been an incredible 5 years for me and I can only apologise to all those people that've helped me along the way that I haven't mentioned here.  I still fight with my social anxiety, but it's much better than it's ever been.  I've just got back from spending four days teaching a course in Brussels, which 5 years ago I just wouldn't have coped with at all.

One thing I'm certain of though is that GeekUp, Barcamps and the Drupal community changed my life for the better!  So, get involved in your local geek communities – you never know where a chance conversation will lead.

Teaser: I recently passed the 5 year mark on drupal.org. It got me thinking about all the different communities that helped me along the way.Categories: CommentDrupal PlanetPrimary Category: CommentTags: communityDrupal Events

For the uninitiated, the term ‘caching’ in computing is the idea of saving a copy of something that usually needs to be generated, in its complete form, to avoid generating it again later. This happens on many levels in a typical computer system.

One good example is the popular APC ‘opcode’ cache available for PHP. PHP as a programming language is ‘interpreted’, which means every time you want to run an application written in PHP the computer needs to ‘compile’ that application (prepare it in a form that the computer can understand and run) before it can actually execute it. This is time-consuming, and that’s where APC comes in. APC caches (saves a copy of) the compiled PHP code so the next time someone requests that exact same piece of code, and provided it hasn’t changed, APC can intercept the request and serve the pre-compiled code without compiling it again. This is a classic demonstration of caching in computing – saving some work that was done earlier to avoid having to do that work again later.

Knowing broadly what caching means, let’s move on. At its heart Drupal has an API for caching ‘stuff’. For example, one of Drupal’s many caches is the page cache. If you have not logged into a Drupal site and you request a page, and if someone else has requested that page before you, in all likelihood the page you will see will come from Drupal’s page cache. When some previous person accessed this Drupal page, some time in the past, Drupal had to go through the motions of building the page, which is slow and time-consuming. So once it was finished Drupal saved a copy of the built page in the page cache. From that point forward, unless or until the page changes, everyone will get the pre-built page instead of making Drupal build it all over again.

Drupal modules actually cache lots of different things – the page cache is the easiest one to explain, but there are block caches, variable caches, menu caches, etc. etc. all designed to speed things up. And they do – massively. But there is another ‘problem’ with Drupal. Not unique to Drupal by any means, every content management system with a database backend that needs to build pages in real time has the same problem:

The database is a bottleneck. There is only one database and there is no (easy) way to scale the database. (It is possible, but it’s expensive, introduces risk and requires specialist knowledge.) Drupal, by default, stores the caches it generates in the database. For a high performance site this is bad. The database has enough to do already, without serving the cache as well! If we can take any load off the database then we should.

In a high performance environment!!!

Don’t get me wrong, every single Drupal site benefits from not using the database as a cache, this is a fact, but a badly configured alternative cache is worse than just leaving things alone. If your site doesn’t need to run particularly quickly, if it doesn’t have high traffic and, crucially, if you don’t know how to configure a Linux server properly... leave it alone!! (Or at worst, install the File Cache module, that’s harmless enough – http://drupal.org/project/filecache)

I’ll give you an example. We were recently called in to do a performance audit of a website that was choking at a relatively low number of concurrent users, especially given the size of server it was residing on. We battered the site with BlazeMeter to get up to traffic numbers that started to make the application sweat and then had a look at the stack traces New Relic was generating:

Oh my. The function responsible for serving the Drupal page cache is taking up almost 50% of the page load time and look at that time!! 60s, just to retrieve the cache! That is a big ouch. (That was with 50 concurrent users, but still, that’s a horrific response time.)

We dug further and here’s what we found. Drupal had been set up to use APC (the opcode caching application I mentioned at the start of the post) as the Drupal cache, not just for caching the popular PHP functions, using the APC module – http://drupal.org/project/apc

However APC itself had been left with default settings, which meant only 32M of RAM was allocated to it. 32M of RAM is not enough for Drupal as an opcode cache, never mind if you want APC to replace the Drupal cache too! So APC could not possibly handle the amount of data it was being asked to cache and was continually stowing cache data back to disk, then trying to retrieve it, then stowing something else, then retrieving another thing, etc. This is commonly known as ‘thrashing the disk’ and it’s very, very bad for performance, because the disk is the slowest component of any computer.

This wasn’t a site with a particularly high volumes of traffic. It had no specific performance requirements, nor did it have specific performance issues per se (I mean, we found other stuff that wasn’t great, but nothing the server couldn’t have handled reasonably enough). Our first action was to disable the APC module for Drupal and immediately the site performed 50% more quickly. (We later swapped APC for memcached, but that’s another story.)

The point here is this: whoever set this site up thought “I know, I’ll use APC to make this Drupal website run faster, because everyone knows APC is faster than Drupal’s default cache, right?” WRONG!! APC is quicker than Drupal’s default cache if you know how to set it up properly. If not, you’ll probably do more harm than good.

The message is simple. If you have a ‘normal’ Drupal site with ‘normal’ performance requirements and you’re not prepared to learn how to configure Linux properly, leave Drupal’s caching alone. It is fine. If you have specific performance issues and you need to change the way Drupal handles its cache to alleviate them, either get researching or call in the Drupal performance experts. Don’t just switch stuff on and walk away.

This isn’t just an APC issue. So far this year we’ve seen a badly configured Boost implementation that was caching referring pages as well as Drupal and filling the disk. Daily! We’ve also seen memory limits tweaked for MySQL with disastrous effects. And we’re still in February. If you don’t know what you’re doing, either get educated or get help.

</rant>

Related Service Areas: DevelopmentHostingSupportTeaser: We all want to make Drupal run faster, but meddling with things you don’t understand can get you into big trouble. Here’s why.Categories: ConsultancyDevelopmentDrupal PlanetHostingSupportPrimary Category: DevelopmentTags: high performancecachingapcphpmemcachedFreshbridgeNew RelicBlazeMeter

Using Drush Make with private git repositories on github

At SystemSeed, we use Jenkins to trigger automated platform builds directly from commits to our git code repositories. A lot of our code is hosted on github, although due to the nature of our work, some of our client repositories are private. Our Jenkins build scripts are heavily based on Mig5's article Zero-touch Drupal deployment with Jenkins, Aegir, Git, Fabric and Drush which enables drush make files to be fetched and build directly from the web. However, one difference is that our repositories are private, and therefore inaccessible to drush make directly. Yesterday, I found a way to overcome this by using Github's API directly with drush make.

I love the fact that there is an API in Drupal for nearly everything. So I wasn't surprised to find out that there is a module called ChecklistAPI. This module allows developers to create a checklist with tasks and a progress bar within a Drupal website. There are already a few modules that implement the API: SEO Checklist, QA Checklist and Performance and Scalability Checklist. In this article, I'll introduce you to these useful modules.

If you know of any other modules, let the ChecklistAPI maintainers know and they'll link to the module from the project page.

DrupalCon Portland is only a couple months away (early bird registration ends soon, so get your tickets if you haven't already!), and I'll be headed out that way. If this will be your first time attending a DrupalCon, be sure to read my First Timer's Guide to DrupalCon from last year.

At this year's DrupalCon, I'm excited to hear about everything going on with Drupal 8, as we're nearing the end of the development cycle, and a release candidate is on the not-too-distant horizon.

I've been watching a new competition for the past couple weeks called Moduleoff. It's a bi-weekly Drupal module development challenge. You are given a set of criteria and then you are required to submit a video and sample module. (You even receive a prize if you win!)

At last, a challenge I had an idea for—Challenge 5: Do something cool with Node.js

I ended up going with a module that somewhat mimics the functionality of Real time Google Analytics. It only makes sense to use Node.js to provide a real time dashboard; that shows the user all the requests coming in and some ancillary data about them, like location and username. Plus, with Drupal, we have many contributed modules ready for use; I ended up using Hostip for determining location and Visualization API for rendering the charts.

Sweet Code

Other than leveraging the contributed modules, the real guts and real time data is going to be handled by Node.js and the integration module for Drupal.

The integration module is message based; when you want something to occur, you send a message. We can send messages to users in a channel pretty easily. Here I am sending some arbitrary data to the nodejs_accesslog channel and specifying the nodejs_accesslog callback.

$message = (object) array( 'channel' => 'nodejs_accesslog', 'data' => array( 'access' => l($current_path, $current_path, array('attributes' => array('target' => '_blank'))), 'period' => _nodejs_accesslog_get_period(), 'user' => format_username($user), 'country' => _nodejs_acceslog_get_country(), ), 'callback' => 'nodejs_accesslog', ); nodejs_send_message($message);

Important to note that you should almost always use a channel, because if you end up with multiple uses for Node.js on your site you could run into conflicts—and even worse, having the wrong users receive data.

Then on the client side, the callbacks will get called with the message we just sent. At this point you can do whatever you desire with the message data. In our case we refresh the charts and table, but below you see a limited version of the real file.

Drupal.Nodejs.callbacks.nodejs_accesslog = { callback: function(message) { \\ Switch on channel and ignore messages that might have broadcast => TRUE switch(message.channel) { case 'nodejs_accesslog': \\ do stuff with message.data (the same data array that we made when we did nodejs_send_message() in PHP break; } } }; Goodies

There's a demo running on my personal Linode here: nodejs_accesslog.alexdoesit.com

The code is available on my Github here: github.com/alexh58/nodejs_accesslog

And as stated in the submission guidelines, below is a video with a brief explanation and demo of the module.

More Resources

• My Node.js Presentation for DrupalCampMA 2013
• Another example module using the Node.js Integration (with Cats!)
• Using Forever to run Node as a server and keep it alive

Tags: drupalNode.jsCategory: Development, Drupal Planet