Planet Drupal

Subscribe to Planet Drupal feed
Drupal.org - aggregated feeds in category Planet Drupal
Updated: 5 min 39 sec ago

Freelock : I've got a theory: The Scientific Method applied to web site performance

Sun, 13/07/2014 - 18:10

What can you do about this page being so slow? That's a question we've been asked by half a dozen customers in the past 6 months, and as it turns out, we can do quite a lot.

One of my long-standing complaints about Drupal is that it's a resource hog. That's an issue we can generally help by throwing lots of hardware and caching systems at the problem -- but that's not the kind of performance issue these clients were having.

PerformanceScalingMonitoringDrupalDrupal PlanetTechnical
Categories: Elsewhere

Mediacurrent: The Power of Giving

Fri, 11/07/2014 - 22:00

Several years ago, a mentor told me to add computer tech services to my web design company’s services because “everyone’s a web designer.” His point: there’s a lot of competition in the web design and development market. With so much competition, why would web development shops like Mediacurrent place so much value in sharing industry knowledge and even custom code for free with the Drupal community? Why is it worthwhile for a for-profit company to share knowledge to a community that includes competitors?

Categories: Elsewhere

Midwestern Mac, LLC: Multi-value spatial search with Solr 4.x and Drupal 7

Fri, 11/07/2014 - 21:59

For some time, Solr 3.x and Drupal 7 have been able to do geospatial search (using the location module, geofield, or other modules that stored latitude and longitude coordinates in Drupal that could be indexed by Apache Solr). Life was good—as long as you only had one location per node!

Sometimes, you may have a node (say a product, or a personality) affiliated with multiple locations. Perhaps you have a hammer that's available in three of your company's stores, or a speaker who is available to speak in two locations. When solr 3.x and Drupal 7 encountered this situation, you would either use a single location value in the index (so the second, third, etc. fields weren't indexed or searched), or if you put multiple values into solr's search index using the LatLonType, solr could throw out unexpected results (sometimes combining the closest latitude and closest longitude to a given point, meaning you get strange search results).

Categories: Elsewhere

Joachim's blog: The ripple effect

Fri, 11/07/2014 - 21:21

Hello! I'm back. I've not made any blog posts in over a year and a half due to the site where my blog was before, drupaler.co.uk, closing down. And while it took me some time to get round to writing a Migrate script to import my posts from the old site's database, it was actually getting round to setting up this new domain that took the longest.

So what have I been doing all this time? Especially as I still don't have a single Drupal 7 site out there to my name? Well, these days I work on a humongous web application which has kept me busy for the last 18 months; it's a large Drupal site (we hit a million of one of its several custom entity types recently), but to the general public it's just a login page. I may talk more about the development challenges in future posts.

Prior to that, I was building what would have been one of the earliest big Drupal Commerce sites to launch... except that very shortly before launch in October 2012, the whole project got canned.

Tags: contributing codedrupal commercedevelopmentmaintaining projects
Categories: Elsewhere

Lullabot: Front-end Rapport #3

Fri, 11/07/2014 - 20:00
Current Trends in Browser Market Share

Topics: Browsers

Arstechnica does a visual deep-dive into browser market shares through multiple charts and graphs — breaking down worldwide browser trends and adoption rates.

Categories: Elsewhere

Aten Design Group: Design4Drupal 2014

Fri, 11/07/2014 - 18:33

Design4Drupal 2014 is almost here, and Aten couldn't be more excited. This year, along with being the Design Partner for the event, members of Aten's Design & UX team will be presenting four different sessions.

This year's Design4Drupal (August 1-3) has been structured to give each day a specific focus. Friday kicks things off with a business summit, Saturday is chock full of sessions and Sunday wraps things up with sprints and trainings. Make sure you catch as many of Aten's sessions on Saturday as you can:

Saturday, August 2, 10:15am Enhancing Design with Adaptive Content

Aten’s Joel Steidl, Lead Architect, and Christine Coughlan, Information Architect, will share practical tips for breaking down and organizing content for projects of any size. They’ll share case studies to reinforce the theory and practice behind adaptive content and best practices for implementing it in Drupal and other platforms.

Layout Design Patterns

John Ferris, Aten's Lead Front-end Developer, presents reusable solutions to common layout problems. He'll begin with foundation CSS layout concepts and then build up to specific techniques for implementing complex layouts in Drupal.

Saturday, August 2, 2:15pm Anti-Handoff: A better design & front-end relationship

Front-end Developers delivering on what's promised by Designers can make or break a project. Erin Holloway, Aten's Senior Designer, will walk through approaching this problem with clear communication, the right tools and mutual respect. If you're struggling with collaboration between your team members, this session can help.

Saturday, August 2, 3:30pm Giving and Getting Great Feedback

Great feedback can be the lifeblood of a successful project. However, setting aside personal preference and giving objective feedback can be challenging. Responding to that feedback can be even harder. Aten’s Designer, Roxy Koranda, will give you the tools to both give and get great feedback.

With just 3 weeks until the event, there isn't a ton of time left to register. If you use Drupal and want to learn more about how best to approach Design, UX and Front-end Development, Design4Drupal is the place to be. We hope to see you there!

Categories: Elsewhere

Acquia: Brant Wynn: Demo Framework – How we pitch Drupal to potential clients

Fri, 11/07/2014 - 15:52

Brant Wynn, Acquia Solutions Architect, and I covered some interesting ground in our conversation preceding his jam's Drupal Camp session on selling Drupal to potential clients via beautiful, out-of-the-box demos. Listen to hear about working as a professional open source software developer, the potential wins from having migration tools built into Drupal 8, how Drupal 8 is bringing so many open source technologies and communities together, and more.

Categories: Elsewhere

Code Karate: Drupal 7 Mobile Friendly Navigation Toolbar module

Fri, 11/07/2014 - 13:12

The Mobile Friendly Navigation Toolbar is a replacement for the standard administration toolbar that comes with Drupal 7.

Categories: Elsewhere

DrupalCon Amsterdam: Inside Drupalcon Amsterdam Frontend Session Selection

Fri, 11/07/2014 - 08:21

After attending and helping to organize several Drupal events in Europe I have met a lot people and also had the chance to listen to many good speakers. I am also an usual speaker in DrupalCamps. That brought me enough experience to know when a session was interesting for the audience and feedback from attendees and organizers helps improve my sessions in the future.

It’s important for the speaker to know how to engage and entertain attendees. People will learn more and will be more satisfied if the session is dynamic and, why not, funny.

A few weeks ago I had the opportunity to collaborate, together with Lewis Nyman, in the Frontend track session selection for DrupalCon Amsterdam. I have never spoken in a DrupalCon so it was a good chance to learn from the best.

Our role was to help guide those who proposed a session by better aligning proposals with the suggested topics. That was a really good experience because I had to contact speakers I met in previous conferences and others I wanted to meet but we didn’t coincide in any event. Also we tried to invite speakers from other communities to spread the word of Drupal in other horizons and also to have opportunity to learn from professionals that are working in different projects and environments than those we use to know.

The response was impressive: we had more than 50 proposed sessions only in our track, for a total of more than 500 submissions overall. That’s a really big number taking into account that the topics were related to theming and design and because we have other tracks that cover development and site-building topics. Sometimes we had to move sessions from one track to another because it was difficult to decide which track the session fit best in.

Session topics were diverse but fit well with our needs, what made it really hard to decide between them. We had a limited amount of sessions to accept so Lewis and I tried to estimate different factors in the valuation process. We took into account previous speaking experience, using speaker profiles and videos or slides from previous sessions in other events.

A session's description was one of the most important factors to evaluate. Tip for prospective speakers: you should be really careful with your session description if you decide someday to speak in any conference. We contacted a few speakers prior to and during session selection to suggest slight variations on their session content so they can fit better with track topics or differ from other proposed sessions.

We tried to have a diverse Frontend track with interesting sessions, not only for front-end developers but also for UX designers, site builders, graphic designers… and not only Drupal people will be interested in them. I think anyone dedicated to web will enjoy and learn new techniques and tools used by well-known professionals in high-end projects.

You can imagine all the amount of time invested to prepare and coach speakers and also to plan and organize. We meet weekly as a team to comment, discuss and make decisions (also have a good time with Drupal fellows). It was a really enjoyable opportunity for me to gain more experience organizing Drupal events.

--
Ruben Teijeiro (rteijeiro)
DrupalCon Amsterdam Frontend Co-Chair

Categories: Elsewhere

godel.com.au: Ideas to help keep your Drupal project secure against the OWASP Top 10

Fri, 11/07/2014 - 07:24
Fri July 11, 2014 Ideas to help keep your Drupal project secure against the OWASP Top 10

I'm sure you've heard the phrase "Security is a process, not a product" before, or something along those lines. Drupal has a pretty good track record as far as Web-based CMS security goes, and there's a dedicated team of experts looking after Core and Contrib, but it's no secret that the most common vulnerabilities are those we accidentally introduce ourselves during our day-to-day tweaking (Drupal.org claims over 90%). The Drupal Security White Paper shows pretty clearly that the further we get away from the heavily peer-reviewed Core codebase, the more likely we are to unwittingly introduce something that's dangerous to our data.

In the case of what processes we can implement as individuals, self education and reflection is always important, so I figured that the present is as good a time as any to run through the OWASP Top 10 and present a few practical ideas and Drupal "Best Practices" to help mitigate the risks we inevitably expose ourselves to. I've added some quotes from the white paper to each section to put things into perspective.

#1 - Injection

Drupal contains a robust object-oriented database API that makes it difficult for developers to unknowingly create injection holes by automatically sanitizing query parameters and enforcing an interface. Drupal's file system interaction layer limits where files can be written and alters dangerous file extensions that the server could potentially execute.

In Drupal, injection attacks are generally going to be enabled by allowing unsafe data to sneak into SQL queries. In Drupal 7 we have two syntaxes for working with the database API, the classic Drupal 6 style db_query("SELECT * FROM foo f WHERE bar = 'baz'"); and the dynamic DBTNG style db_select('foo', 'f')->condition('bar', 'baz' , '=');.

For both syntaxes, there are two things I think are worth mentioning:

Make use of PHP's PDO and Prepared Statements

Drupal's database API wraps PHP's own PDO, which supports something called Prepared Statements that magically guarantee you won't suffer from an injection attack provided you actually use the API correctly.

So, if you're wondering how to use the API correctly, let's split all SQL queries we might want to use into two categories, those that could be considered hardcoded strings, and those that have one or more variable components. The examples above would be "hard coded", an example of something with variable components might look like this:

// Get the type of the node with the ID of the second URL component.
// WARNING: Don't actually do this! it is NOT secure.
$id = arg(1);
$query = db_query("SELECT type FROM node n WHERE n.nid = " . $id);

The issue here is that, unlike our hardcoded query, the value of $id can be set to anything at all by the end-user, most notably including strings that resemble fragments of SQL queries. We really don't want the end-user to discover one day that they can start executing their own queries against our database by carefully crafting URL components to exploit our PHP logic.

Here the fix is to either use PDO placeholders using Drupal's classic syntax, or leverage Drupal's internal query builder with the dynamic syntax. The following two examples (one for each syntax) are secure versions of the previous insecure example:

Drupal 6 syntax:

// Get the type of the node with the ID of the second URL component. // The important part here is that the second argument passed to db_query() // is an array of substitutions that will be sanitized internally. $id = arg(1); $query = db_query("SELECT type FROM node n WHERE n.nid = :nid", array(':nid' => $id));

Drupal 7 syntax:

// Get the type of the node with the ID of the second URL component. // The important part here is that we use the dynamic query builder to handle // the unsafe $id variable. $id = arg(1); $select = db_select('node', 'n') ->condition('n.nid', $id, '=') ->fields('n', array('type'));

The question now is, how do we know when a variable is "unsafe"?

The answer should really be, treat all variables as though they are unsafe by default and stop guessing. Be in the habit of using the more secure syntax by default, even when it is not strictly neccessary. This both reduces the risk of some edge-case creeping up on you that you hadn't considered, and makes your code more portable/standardised at the same time.

Make use of whitelists for tables/fields/operators

I think maybe this one is less obvious to many people than making use of PDO, but it is also important to consider.

As mentioned in a bunch of core issues, and elsewhere (read the comments) Drupal doesn't actually escape/sanitize everything that you pass the database API. The reason that those issues are still open and not flagged as "critical fix me NOW ZOMG" (In part), is because certain parts of our SQL queries are fundamentally unsafe to use user data for, even if they were being escaped by the system.

Imagine a query (presumably hooked up to a radio button or select element) like the following:

// Return the current user's username or email address to be displayed. // WARNING: Don't actually do this! it is NOT secure. global $user; $field_name = $form_state['values']['field']; $select = db_select('users', 'u') ->condition('u.uid', $user->uid, '=') ->fields('u', array($field_name));

In this case, the end-user can hack up the form you presented them however they like and submit something for the field form value like "password" to get a dump of what is stored in the password field for the current user account. It's not hard to imagine other, even more damaging scenarios.

Since Drupal knows that it is fundamentally insecure to be directly using user data for some things (e.g. table names, fields, operators in condition() and orderBy()) and assumes that you'll definitely be using whitelisted values only in these cases. There may well be a de-prioritised, outstanding Core bug that means your variables are not being sanitised/escaped at all, despite the fact that you're using the query builder. This means that, as well as the end-user getting at your user's passwords when you thought they could only see email addresses, they may also have a way to directly attempt an injection attack on your database.

The fix here is, make use of whitelists wherever you're dealing with variables for finite, pre-determined lists of valid options (like field names). For example, the above could be rewritten to be more secure like this:

// Return the current user's username or email address to be displayed. global $user; // Return the username by default. $field_name = 'username'; // Ony allow field names in our whitelist. $allowed_fields = array('username', 'mail'); if (in_array($allowed_fields, $form_state['values']['field'])) { $field_name = $form_state['values']['field']; } $select = db_select('users', 'u') ->condition('u.uid', $user->uid, '=') ->fields('u', array($field_name)); #2 - Broken authentication and session management

User accounts and authentication are managed by Drupal core. Authentication cookies and a user's name, ID, and password are managed on the server to prevent a user from easily escalating authorization. User passwords are salted and hashed using an algorithm based on the Portable PHP Password Hashing Framework and existing sessions are destroyed upon login and logout.

Drupal handles this well "out of the box" and most developers will be rarely doing anything that would break it. According to the white paper, there are very few Security Advisories being issued in this category, so I won't dwell on this.

#3 - Cross site scripting (XSS)

Drupal has a strong system for filtering user-generated content on display. Untrusted user's content is filtered to remove dangerous elements by default. For developers, Drupal has at least eight API functions for filtering output to prevent XSS attacks. When identified, common developer errors that lead to XSS vulnerabilities are mitigated by building safer defaults. For example, a page title function in Drupal 6 is the source of many XSS holes due to a lack of proper escaping. In Drupal 7 this function escapes output by default.

Hmmm, I think the words "by default" mean something different to the authors of the white paper than they do to me. If you do anything in the Drupal theme layer, and you don't explicitly, manually sanitise every single one of your variables as you render them, you have XSS holes in your theme.

In Drupal 8, there's a critical issue to try and get automatic escaping of markup into core by using the Twig rendering system which should dramatically increase security (in line with my intuitive definition of "by default") and improve performance as a nice bonus. That issue attempts to summarise the situation:

No-one can write XSS safe code. Nor core contributors, nor contrib developers, no-one.

and from a duplicate issue:

100% of all custom themes are insecure (the rest is rounding error). The reason is often that developers forget to escape their data in the templates.

By the white paper's own reported statistics, over 50% of reported security vulnerabilities in Drupal core and contributed community code are XSS issues.

In light of all this, between now and when Drupal 8 auto-escaping is released, even if you learn nothing else about Drupal security, you'll want to become familiar with a few of the API functions provided for string sanitisation.

For reference, the full list on api.drupal.org is:

Read up on all of the sanitisation functions, but the most commonly used (for general theming) are probably:

check_plain()

Use this when you have a string that is NOT supposed to be HTML, but you want to display it in an HTML context. It's really just a wrapper around htmlspecialchars(). Any characters in your non-HTML string that might be interpreted as HTML by the browser are converted into HTML entities so that they render as you would expect them to in a non-HTML context.

This means that your string that looks like X < Y & Y > Z becomes X &lt; Y &amp; Y &gt; Z.

A couple of things to keep in mind with this function:

  1. It's possible to accidentally double encode characters so that &amp; becomes &amp;amp;, which looks really bad when rendered. It is NOT a good idea to run check_plain() over everything without thinking, in case you run it on a string that has already had check_plain() run on it earlier.
  2. While check_plain() is an important function for security, "defusing" characters that could be interpreted as HTML, it's primary usage is for encoding/decoding characters, NOT guaranteeing that strings are "HTML safe" by stripping dangerous markup. For example, it's possible that a substring of a string that was previously run through check_plain() will have its encoding corrupted if an HTML entity is truncated before the closing ;.
check_markup()

Use this to apply input filters to a string that is intended to be used as HTML. In this case, we DO want HTML to be interpreted by the browser, but we also want to be careful not to open ourselves up to <script> elements or similar being executed maliciously. In the simplest usage, this function takes two arguments - the string and the machine name of the filter format to apply.

Filter formats themselves are an important part of core and too detailed a subject for me to go into here. Suffice to say that the "out of the box" formats set the tone for most custom filters created by developers:

  1. plain_text - Behaves as check_plain() does.
  2. filtered_html - Will strip any (customisable) HTML tags considered dangerous and leave the rest intact
  3. full_html - Will render any and all HTML tags in the string, even if they might be dangerous. (ab)Using this causes developers to grumble.

Avoid using the PHP input filter completely if you care at all about mitigating security risks.

t() and/or format_string()

Use this in situations where you want to perform simple string substitutions with variables (that might come from end-users data) and, in the case of t() also allow for the string to be translatable into other languages.

Since t() wraps format_string(), I encourage you to use the former as they behave the same way and you get the translatability "for free".

The advantage of using placeholders in strings, rather than concatenating variables, is twofold, format_string() will automatically apply check_plain() to substitutions that do NOT begin with ! and it makes the strings easier to contextualise for translaters.

// Here the translators can see a whole sentence and use the placeholders as clues. // We don't have to call check_plain() repeatedly because we're using @placeholder syntax. t('Yesterday I went to @place and brought home a @thing', array( '@place` => 'the park', '@thing' => 'frisbee', )); // Here translators only see two disjointed strings separately: // 'Yesterday I went to' and 'and brought home a'. t('Yesterday I went to ' . check_plain($place) . 'and brought home a ' . check_plain($thing)); #4 - Insecure direct object references

Drupal often provides direct object reference, such as unique numeric identifiers of user accounts or content available in the URL or form fields. While these identifiers disclose direct system information, Drupal's rich permissions and access control system prevent unauthorized requests. Methods for obfuscation are available through configuration and community-contributed code. Further, validation and protection against semantic forgery attacks is implemented in Drupal core via the Form API.

For Drupal, this largely comes down to making sure you have your server environment and Drupal site configured in a way that makes sense for your project, in the context of Drupal, I'm going to tie this into...

#5 - Security misconfiguration

Many critical risks, such as access to administrative site controls, text formats, and private information are restricted to a single admin account by default. Identified design inefficiencies that lead to misconfiguration are corrected often through usability testing and fixes are recommended for inclusion to core. Documentation of best practices for secure configuration and site building are provided for free on drupal.org and there are several contributed projects that conduct automated security review or implement further secure configurations.

In my experience, the two fastest ways to end up with hundreds of spambot accounts (or worse) on your account are:

  1. Servers configured in a way that is not Drupal friendly, lazily or by someone who isn't an experienced sysadmin.
  2. Developers building functionality as Drupal user 1 and never logging out or logging in as a user with a different role to test it.

For the first point. If you are not a sysadmin, you don't directly employ a sysadmin, or you don't have a friend who is a sysadmin who owes you a series of large favours, it is going to be much, much cheaper and less headache inducing to sign up with Acquia or Pantheon than to mess around with a shared hosting provider or to try and configure and maintain your own VM.

For the second point, the Drupal permissions grid is huge and tedious to manage as it involves a lot of user switching but there are a few things you can do for yourself to make maintaining complex permission sets easier.

Implement a simple, repeatable testing plan

In the Drupal community, SimpleTest and Behat are very popular testing tools. Both support simple assertions for the HTTP response code and the existence/absences of HTML elements on a rendered page. In fact, automated tests to check that a given user has permission to do something or visit certain pages are some of the easiest to write and can help you avoid those awkward conversations where we have to explain to someone that there was a regression in the site's fundamental security configuration.

Even if you don't have the time or resources to set up automated tests for a project, make step-by-step notes of critical functionality and user roles that can be tested as part of QA each release.

If you're using drush, you can generate a one time login for any user in the system with uli and their username:

$ drush @mysite.alias uli 'John Smith'

Have a deployment plan

People who don't know how to use the Drupal permissions grid just love to make changes to it, then immediately forget what changes they made, or tell anyone that they made the changes. That is, if you let them.

At the very minimum, you should be exporting your permissions into Features so that, should anything go wrong, you have some kind of "oh shit" button to get things back to working order, fast (without rolling back your database).

The Features approach is a little limiting for Permissions management though:

  • The permissions aren't actually locked. It's relatively easy for a permission to be changed on production and it won't be restored to the correct value until the Feature is next reverted.
  • It's not easy to toggle permissions on/off for different development environments. For most permissions you aren't going to want to do this anyway, but for those that you do, you really don't want the wrong permissions in the wrong environment.
  • There are a very large number of Permissions, and exporting them all to a Feature quickly bloats the Feature code and UI.
  • Adding a permission to a Feature artificially introduces a dependency of the Feature on that module.
  • Exporting permissions to Features is a tedious and error-prone manual process.
  • Permissions exported in Features are not very portable between projects.
  • The generated code in Features is difficult to read over quickly.
  • It's relatively difficult to manage permissions across multiple domains if you have a multisite setup.

There are various contrib modules that aim to make permissions management more secure and development friendly, to name a few:

Additionally, you might want to consider making permissions management part of your deploy/build scripts if you use such things to manage your environments.

#6 - Sensitive data exposure

Account passwords are salted and repeatedly hashed based on the Portable PHP Password Hashing Framework. Available Drupal community-contributed code offer solutions to encrypt sensitive data at rest or in transit.

This depends a lot on what your employer/client/government considers "sensitive" data. Where I live, in Australia, the government has published a convenient set of guidelides around sensitive and private data that can be used to gauge the level of risk if data were to be exposed. If you don't have any in your site, well that's great - although I still recommend implementing hook_menu() to unset the default node menu path if you haven't already, as it shows every node in the site by default, which can be awkward.

If you're working with Ubercart or Commerce, please, please triple check whether your payment gateway integration module sends user's credit card data through the Drupal Form API, to your server, before sending it to the payment gateway provider. This goes double (so sextuple check) for anything that claims to store credit card data for later use, even if it is "tokenized". If sensitive credit card (or similar) data touches your server even for a moment, you might be exposing yourself to fines if you haven't taken appropriate steps (PCI-DSS) to ensure encryption and security.

If you work with Drush, and multiple environments, you might want to consider implementing hook_drush_sql_sync_sanitize() for your project. This allows you to scrub out sensitive data from your production database as you pull it down, so that you don't accidently lose it to someone shady along with your laptop or not-so-trustworthy contractor. You don't need to use drush for this, there are lots of ways, including a simple shell script with SQL queries, to setup a decent database scrubbing script. Acquia have some documented examples of how to achieve this too, if you're interested.

#7 - Missing function level access control

Function level access in Drupal is protected by a powerful permissions-based system which checks for proper authorization before the action is taken. For the case of URL access, access checking is tightly integrated into the entire menu-rendering and routing system which means that visibility of navigation links and pages are protected by the same system that handles incoming requests.

Yes, menu-rendering uses access checking to ensure that navigation links are protected, but links generated by l() or #type => 'link' render arrays do not automatically run access checks. Function (and URL) level access control is very easy to implement in Drupal using hook_permission(), hook_menu() and user_access(). Creating new, custom permissions is very straightforward but it's also very easy to get wrong in subtle ways (especially if you're writing some new function that wraps another function with existing access checks) - as I mentioned above, make sure you have a solid testing plan in place for your new permissions scheme before you deploy it!

#8 - Cross-Site request forgery

Drupal validates user intention in actions using industry standard techniques. Typical actions with side- effects (such as actions that delete database objects) are generally conducted with the HTTP POST method. Drupal's Form API implements unique form tokens to protect against CSRF in POST requests. Less important actions can leverage the one-time token generation and validation functions of the Form API while still using an HTTP GET request.

Reviewing the security white paper, we can see that there's a relatively large incidence of contributed, non-core code that is not correctly implementing the Drupal Form API, leading to CSRF exploits.

Avoiding CSRF exploits in Drupal is relatively easy if you follow three simple rules:

  1. Whenever you expose an action to an end-user that modifies data in your site, implement it using a form (POST) rather than a link + menu callback (GET).
  2. Never try to build an HTML form manually, always use renderable form arrays and the Form API.
  3. Always use form validate/submit handlers and $form_state to access user submitted values rather than trying to extract information from $_POST directly.

If you need to quickly convert some GET based code you suspect might be at-risk to POST requests, the Drupal documentation suggests converting the page callback to a simple confirmation form using the confirm_form() core function as a base.

Another option, is to put a token in the URL that is unique for each page load and can't be easily forged, much like the Flag module does. Keep in mind though that this approach might not behave well in conjunction with cached markup containing links to URLs that rely on tokens like this.

#9 - Using components with known vulnerabilities

Included libraries and frameworks (of which there are few) in Drupal core are system-level, unsophisticated, and of low risk to full server or application compromise.

Unfortunately, this happens very, very frequently in Drupal as soon as you start counting contributed modules as "components". Ironically, the frequency of known security vulnerabilities showing up in installed modules is due in a large part to the security team doing a good job of reviewing and flagging community code. The difficult part here is being proactive about regularly deploying new module versions as security fixes are released.

It's a shame that the Droptor service was discontinued, as it provided a central dashboard for reviewing available security updates across multiple sites. Acquia and Pantheon both provide similar dashboards for sites hosted on their servers.

It's also a shame that the core Update module that "dials out" to Drupal.org to get the status of installed module versions is somewhat poorly optimised. It's very easy to configure a site (such as when using "poor man's cron") so that 20+ second page loads are experienced intermittently when using Update. If performance is important, I recommend enforcing the Update module to be enabled in a review environment, but not production or local development where slow page load times could become an issue.

There's little else to say here. Keeping your modules up-to-date is simply a matter of organisation/process and diligence and has little to do with development skills or further learning.

#10 - Unwanted redirects and forwards

Internal page redirects cannot be used to circumvent Drupal's integrated menu and access control system. Drupal protects against automatic redirection to off-site URLs which could be used in a phishing attack.

Drupal provides the drupal_goto() function for handling redirections correctly. This function will ignore absolute URLs in GET requests, but otherwise will always respect the destination parameter in the URL. This allows us to safely redirect/forward users by constructing our URLs correctly (with drupal_get_destination()), without opening ourselves up to phishing attacks.

The contrib External Links module also provides visual feedback for users, protecting them against unexpected offsite redirections, showing an icon on any link that will take the user to a new domain. The External Links Extra module takes this one step further and allows for a popup warning box, or even a dedicated intermediate page, to make it as clear as possible to users that they are about to be redirected offsite.

David Meister Director & Lead developer Using style-linking for sane @font-face declarations in a post-IE8 world Mon June 30, 2014 Say no to fake browser bold and fake browser italic, messy @font-face syntax and super-legacy browser bug support with the neat, logical style-linking @font-face syntax. Tags planet drupal
Categories: Elsewhere

Drupal core announcements: Drupal core updates for July 10, 2014

Fri, 11/07/2014 - 00:53
What's new with Drupal 8?

The past two weeks have seen steady progress on Drupal 8, with the release of drupal 8.0-alpha13, the Clearing of the RTBC Queue, the expected deployment of Semantic Versioning support on Drupal.org, the launch of the #D8CX initiative, and the announcement about the roadmap for Drupal Commerce for Drupal 8!

Updates to api.drupal.org

If you go to https://api.drupal.org/api/drupal/8 you'll notice a few updates:

  • A few months ago, we updated the landing page with a list of topics, which were mostly just stubs. Documentation has now been written for most of the topics that are linked from the landing page.
  • There's a list of Services on the right sidebar, which you can filter by tag and name keywords — and each service has its own page, with appropriate cross-linking (list of code that uses the service on the service page, and if a service name is used in code, it should link to the service page)
  • The Classes page now lists Traits as well as classes and interfaces
  • For hooks like hook_form_FORM_ID_alter(), you can now see a list of functions that implement it (previously this only worked for hooks like hook_form_alter() where the function name was modulename_hookname(), but now it works for ALL_CAPS replacements as well).
Where's Drupal 8 at in terms of release?

Last week, we fixed 1 critical issue and 5 major issues, and opened 2 criticals and 10 majors. That puts us overall at 97 release-blocking critical issues and 614 major issues.

Where can I help? Top criticals to hit this week

Each week, we check with core maintainers and contributors for the "extra critical" criticals that are blocking other work. These issues are often tough problems with a long history. If you're familiar with the problem-space of one of these issues, and have the time to dig in, help drive it forward by reviewing, improving, and testing its patch, and by making sure the issue's summary is up to date and any API changes are documented with a draft change record, we could use your help!

More ways to help

Issue #1679344: Race condition in node_save() when not using DB for cache_field recently caused a Drupal.org outage. The issue already has a proposed resolution recommended in comment #24 — help out by creating a patch for either D7 or D8.

Additionally, there are a bunch of easy documentation issues which need some help moving forward. For each of these, there is a "Child Issues" sidebar. Look there for issues that are "active", "needs work", or "needs review":

If you want to get started with the core development process, this is a great way to get your first commit in core!

You can also search the Drupal Core issue queue for issues tagged "Novice": the ones in the "documentation" component are especially good for new contributors.

As always, if you're new to contributing to core, check out Core contribution mentoring hours. Twice per week, you can log into IRC and helpful Drupal core mentors will get you set up with answers to any of your questions, plus provide some useful issues to work on.

You can also help by sponsoring Drupal core development.

Notable Commits

The best of git log --since "2014-06-25" --pretty=oneline (201 commits in total):

You can also always check the Change records for Drupal core for the full list of Drupal 8 API changes from Drupal 7.

Drupal 8 Around the Interwebs

Excited to learn more about the changes coming up in Drupal 8, but don't like reading patch files? Here are some of the best articles from the past two weeks:

Drupal 8 in "Real Life"

Want to meet up with other Drupal folks excited about moving Drupal 8 forward? Code sprints are an ideal way to meet new friends, contribute to Drupal core and/or contrib, learn, share tips/tricks and discover new talent.

Two big events, Twin Cities DrupalCamp (in Minnesota, USA) and Drupalaton (in Lake Balaton, Hungary), will be holding massive, 4-day Drupal 8 sprints on Aug 7-10. Help us make sure there is space for everyone by signing up ahead of time!

Here are some other upcoming events:

  • July 10: Forum One is hosting a Code Sprint at their offices in Washington DC.
  • July 12-13: Drupal 8 at the Jersey Shore in New Jersey, USA, has room for 40 Drupal 8 sprinters. @drupalcampnj
  • July 16: DesignHammer is hosting a Drupal Coder Lounge event in Durham, North Carolina, USA to help work on Drupal 8 core and update documentation and contribtued modules for Drupal 8.
  • July 17-20: DrupalCorn in Iowa, USA will have a Drupal 8 contributed module sprint. @drupalcorn
Whew! That's a wrap!

Do you follow Drupal Planet with devotion, or keep a close eye on the Drupal event calendar, or git pull origin 8.x every morning without fail before your coffee? We're looking for more contributors to help compile these posts. You could either take a few hours once every six weeks or so to put together a whole post, or help with one section more regularly. Contact xjm if you'd like to help communicate all the interesting happenings in Drupal 8!

Categories: Elsewhere

Drupal core announcements: Drupal core updates for July 10, 2014

Thu, 10/07/2014 - 22:13
What's new with Drupal 8?

The past two weeks have seen steady progress on Drupal 8, with the release of drupal 8.0-alpha13, the Clearing of the RTBC Queue, the expected deployment of Semanitc Versioning support on Drupal.org, the launch of the #D8CX initiative, and the announcement about the roadmap for Drupal Commerce for Drupal 8!

Updates to api.drupal.org

If you go to https://api.drupal.org/api/drupal/8 you'll notice a few updates:

  • A few months ago, we updated the landing page with a list of topics, which were mostly just stubs. Documentation has now been written for most of the topics that are linked from the landing page.
  • There's a list of Services on the right sidebar, which you can filter by tag and name keywords — and each service has its own page, with appropriate cross-linking (list of code that uses the service on the service page, and if a service name is used in code, it should link to the service page)
  • The Classes page now lists Traits as well as classes and interfaces
  • For hooks like hook_form_FORM_ID_alter(), you can now see a list of functions that implement it (previously this only worked for hooks like hook_form_alter() where the function name was modulename_hookname(), but now it works for ALL_CAPS replacements as well).
Where's Drupal 8 at in terms of release?

Last week, we fixed 1 critical issue and 5 major issues, and opened 2 criticals and 10 majors. That puts us overall at 97 release-blocking critical issues and 614 major issues.

Where can I help? Top criticals to hit this week

Each week, we check with core maintainers and contributors for the "extra critical" criticals that are blocking other work. These issues are often tough problems with a long history. If you're familiar with the problem-space of one of these issues, and have the time to dig in, help drive it forward by reviewing, improving, and testing its patch, and by making sure the issue's summary is up to date and any API changes are documented with a draft change record, we could use your help!

More ways to help

Issue #1679344: Race condition in node_save() when not using DB for cache_field recently caused a Drupal.org outage. The issue already has a proposed resolution recommended in comment #24 — help out by creating a patch for either D7 or D8.

Additionally, there are a bunch of easy documentation issues which need some help moving forward. For each of these, there is a "Child Issues" sidebar. Look there for issues that are "active", "needs work", or "needs review":

If you want to get started with the core development process, this is a great way to get your first commit in core!

You can also search the Drupal Core issue queue for issues tagged "Novice": the ones in the "documentation" component are especially good for new contributors.

As always, if you're new to contributing to core, check out Core contribution mentoring hours. Twice per week, you can log into IRC and helpful Drupal core mentors will get you set up with answers to any of your questions, plus provide some useful issues to work on.

You can also help by sponsoring Drupal core development.

Notable Commits

The best of git log --since "2014-06-25" --pretty=oneline (201 commits in total):

You can also always check the Change records for Drupal core for the full list of Drupal 8 API changes from Drupal 7.

Drupal 8 Around the Interwebs

Excited to learn more about the changes coming up in Drupal 8, but don't like reading patch files? Here are some of the best articles from the past two weeks:

Drupal 8 in "Real Life"

Want to meet up with other Drupal folks excited about moving Drupal 8 forward? Code sprints are an ideal way to meet new friends, contribute to Drupal core and/or contrib, learn, share tips/tricks and discover new talent.

Two big events, Twin Cities DrupalCamp (in Minnesota, USA) and Drupalaton (in Lake Balaton, Hungary), will be holding massive, 4-day Drupal 8 sprints on Aug 7-10. Help us make sure there is space for everyone by signing up ahead of time!

Here are some other upcoming events:

  • July 10: Forum One is hosting a Code Sprint at their offices in Washington DC.
  • July 12-13: Drupal 8 at the Jersey Shore in New Jersey, USA, has room for 40 Drupal 8 sprinters. @drupalcampnj
  • July 16: DesignHammer is hosting a Drupal Coder Lounge event in Durham, North Carolina, USA to help work on Drupal 8 core and update documentation and contribtued modules for Drupal 8.
  • July 17-20: DrupalCorn in Iowa, USA will have a Drupal 8 contributed module sprint. @drupalcorn
Whew! That's a wrap!

Do you follow Drupal Planet with devotion, or keep a close eye on the Drupal event calendar, or git pull origin 8.x every morning without fail before your coffee? We're looking for more contributors to help compile these posts. You could either take a few hours once every six weeks or so to put together a whole post, or help with one section more regularly. Contact xjm if you'd like to help communicate all the interesting happenings in Drupal 8!

Categories: Elsewhere

LightSky: 14 Modules for Improving the Administrative Usability of your Drupal Site

Thu, 10/07/2014 - 21:57

Often times, Drupal gets a bad rap for usability. That’s because out of the box Drupal isn’t very user friendly. As with everything Drupal, it requires a few contributed modules in order to really make it shine. Below are a list of fourteen modules that you can add to your Drupal site to increase its usability. Let’s begin!

Views Bulk Operations - VBO is a module that allows you to execute bulk actions on views rows. The actions it comes with are pretty standard, but you can extend it using the Rules module or even roll your own if that’s your thing. This module allows for your site admins to be able to do things like mass delete nodes, mass publish/unpublish nodes, or even mass change the nodes author.

Admin Views - Admin Views is a module that replaces the stock administration screens with views. Why is this neat? You can add additional exposed filters to your users administration screens, or change which columns appear in order to help your site admins easily find the information they are looking for.

Draggable Views - Draggable Views is a module that allows your rows in a view to be reordered using the same javascript implementation that you find scattered about the Drupal admin (blocks, menu, etc).

Module Filter - Module Filter is a module that seeks to garner control over the unwieldy module listing page. It does this by adding a tab on the left hand side for each package, as well as one for showing the modules alphabetically. It also adds a textbox that you can search to quickly filter the module listing.

Autocomplete Deluxe - The Autocomplete Deluxe module replaces the default autocomplete element with the jQuery UI version making it much more user friendly than the default implementation.

Pathologic - The Pathologic module is an input filter which fixes image and link paths that would otherwise cause them to break. This is useful in situations where your site admins have content on both staging and live sites. Gone are the days of the live site pointing to the test site by accident or vice versa.

Custom Contextual Links - Contextual links was one of the features that our D6 -> D7 clients really seemed to love. One great usability improvement that you can make is to add a contextual link to a view (for example) that would allow them to quickly add the piece of content that corresponds to that view. Normally you’d add these custom contextual links through a set of hooks, but this module provides a nice UI to make it simple. 

Conditional Fields - The Conditional Fields module allows you to create fields that are dependent upon one another in order to be shown. One example of this would be to show a textarea of an admin (or user) selected “Other”. I added this module because it can be go a long way towards cleaning up administration screens when adding content types with lots of information.

Linkit - The Linkit module replaces the default CKEditor link icon with an autocomplete field that allows admins to easily drill down to the content they are looking to link to. We have a great write up on this module that you can find here.

Edit - Drupal 8 will ship with inline editing, and if you are too excited to wait, check out the Edit module. Edit module allows you to do just that, edit content in place. Note that you’ll need to use the CKEditor WYSIWYG if you want this to work on WYSIWYG fields.

Select2 - Like the autocomplete deluxe module above, the Select2 module replaces the standard select box with one that supports searching, remote data sets and infinite scrolling of results.

References Dialog - The References Dialog replaces all the standard reference fields with a dialog that allows them to add, edit and search for references. This can go a long way towards simplifying the administration workflow.

Content Menu - The Content Menu module adds the ability for administrators to be able to create pieces of content straight from the menu administration pages. When creating a piece of content, you have the ability to add a menu item, so it only makes sense that you can add a piece a content when adding a menu item.

Navbar - The Navbar module adds a mobile friendly navigation bar to the administration section of your website replacing the default toolbar which is non-responsive.

There you go. Fourteen modules to improve the authoring experience of your Drupal site. What do you think of the list? Are there any modules you would like to see added? Feel free to discuss in the comments below.

For more tips like these, follow us on social media or subscribe for free to our RSS feed and newsletter. You can also contact us directly or request a consultation
Categories: Elsewhere

Drupal.org Featured Case Studies: University of Oxford

Thu, 10/07/2014 - 17:28
Completed Drupal site or project URL: http://www.ox.ac.uk

The previous version of the University of Oxford site, also designed by Torchbox, was the top rated University site in a Times Education Supplement survey and was much imitated, but after more than seven years of duty, it was a little dated and, critically, wasn’t responsive.

The University of Oxford and Torchbox were excited to have the opportunity to revisit the site, and to revitalise it for a more digitally advanced generation of visitors. At the same time, we took on the challenge of moving this high profile, high traffic site to the Drupal Content Management System.

Key modules/theme/distribution used: Custom BreadcrumbsDomain AccessDisplay SuiteFeaturesLinkitLeafletMediaMedia: YouTubeMedia: VimeoMenu blockMenu Trail By PathWorkbenchWorkbench ModerationWorkbench MediaViewsWysiwygmothership
Categories: Elsewhere

Mark Shropshire: Spectacle Digital Signage Publishing System Sprint

Thu, 10/07/2014 - 15:39

Spectacle is an open source digital signage publishing system for displaying content on any screen. The content is administered by Drupal and displayed using Meteor.

Classic Graphics, SUAR IT at UNC Charlotte, CharDUG, and Meteor Charlotte are sponsoring a Spectacle sprint on July 25th form 9am-4pm ET at Classic Graphics. While the project is well underway, there is still a lot to do. We will be updating the Trello board with ideas and tasks which need to be completed. We will also spend time demoing the current work completed and discussing Spectacle architecture concepts.

No matter what your skill level is with Drupal and Meteor, bring your laptop and we will get you up to speed to contribute in some fashion. We have tasks involving Drupal and Meteor site building, configuration, and development. We also have documentation and design needs. Some come on out and enjoy the fun of working together on a fantastic open source project.

Lunch will be provided by Classic Graphics.

Related links:

RSVP here or here. Either way, we want to know if you are coming so we know how much lunch to provide. :)

Contact Mark Shropshire with any questions

Blog Category: 
Categories: Elsewhere

precessionmedia: How To Create A Custom Filter Handler In Views

Thu, 10/07/2014 - 12:32

By dimitar on 10.07.2014

For those who work with Drupal the Views-module is probably known as well as Drupal itself. For a good reason: it's simply unbelievable how many amazing things you can do with it, without having to write a single line of code. Views has most of the things you'll need for your queries already baked in and there is a pile of modules extending it, but as always in life there are cases where you need something special. So as an example on how to extend Views this article will show how to create you own custom filter.

Our filter will allow users to filter their result depending on the number of words appearing in the node title. You need to create a basic custom module in your Drupal installation. The one I have in my custom environment is called "my_module". The very first thing that has to be done is to implement a hook in your .module file, telling Views which version of Views we are using, so that your module would know how to include files and handle further hooks later. We're using version 3, so our code looks like this:

/** * Implements hook_views_api(). */ function my_module_views_api() { return array( 'api' => 3, ); }

The next step is to literally tell Views that we want to add a new filter. This is done by adding this information in form of an array to the table structure already known by Views. In order to do that we have to implement another hook - "hook_views_data_alter". This hook (and eventually other hooks related to views) has to be implemented in a file called "my_module.views.inc" (of course replace "my_module" with the name of your module). Per default you add this file in the root of your module or in another location, if you specifiy such in "hook_views_api" above with the key of "path". We haven't done that so add the file to the root of your module. Then add following code to the file:

/** * Implements hook_views_data_alter(). */ function my_module_views_data_alter(&$data) { $data['node']['title_count']['title'] = 'Title word count'; $data['node']['title_count']['help'] = 'Count the number of words in titles.'; $data['node']['title_count']['filter']['handler'] = 'my_module_handler_filter_field_count'; }

The hook gets passed the data structure known to Views per reference, so we just need to add our part to it. It our case we add a field "title_count" into the "node" array, where "node" stands for the node table of the database. Take a look at the documentation of hook_views_data and/or print out the contents of the $data-variable within your hook_views_data_alter-implementation to better understand how this array is structured. We're using "hook_views_data_alter" because we want to add information to a table already known to Views. If we're adding database tables through our module, "hook_views_data" needs to be implemented to fully describe the new table.

In our case, the "node"-table already exists in the array, so we add our "title_count"-Views-field to the it, giving it "title" and "help" for identification in the Views UI. Most importantly we tell Views also that this field should be available as filter and the handler for that filter is called "my_module_handler_filter_field_count" (or whatever makes sense). If we would need to have this field also to appear in the sort section of Views, we would need to add $data['node']['title_count']['sort']['handler'] = 'my_module_handler_sort_field_count'; respectively, but that's not part of our example (yet). At that point you can already see this filter listed in Views:

It's not doing anything yet, because we need to add the handler we specified above. This is a two step process: first you need to add the information about the file which contains the handler to your modules' .info file. This way views will know about it and will autoload it whenever needed. Simply add following line to your .info file and clear your cache after that so the Drupal knows about the changes:

files[] = my_module_handler_filter_field_count.inc

We've put the file in the root of the module, but if you have more handlers it's probably a better idea to add it to a subdirectory to keep your files better organized.

So far so good. The last thing is to actually create this handler inside the file we specified above. We are not going to need to create everything from scratch though, because Views already has a handler for numerical filtering, which we will be using as a base for our needs. Because Views is OOP-written what we need to do is to extend the "views_handler_filter_numeric"-class and the methods that it provides to change them to be the way we need them. This is what we end up with (some explanations follow):

class my_module_handler_filter_field_count extends views_handler_filter_numeric { function operators() { $operators = parent::operators(); // We won't be using regex in our example unset($operators['regular_expression']);   return $operators; }   // Helper function to return a sql expression // for counting words in a field. function field_count() { // Set the real field to the title of the node $this->real_field = 'title';   $field = "$this->table_alias.$this->real_field"; return "LENGTH($field)-LENGTH(REPLACE($field,' ',''))+1"; }   // Override the op_between function // adding our field count function as parameter function op_between($field) { $field_count = $this->field_count();   $min = $this->value['min']; $max = $this->value['max'];   if ($this->operator == 'between') { $this->query->add_where_expression($this->options['group'], "$field_count BETWEEN $min AND $max"); } else { $this->query->add_where_expression($this->options['group'], "($field_count <= $min) OR ($field_count >= $max)"); } }   // Override the op_simple function // adding our field count function as parameter function op_simple($field) { $field_count = $this->field_count();   $value = $this->value['value'];   $this->query->add_where_expression($this->options['group'], "$field_count $this->operator $value"); } }

Let's see what's exactly going on here:

  • first we create our own version of the operators()-method, where we get the numerical comparison operators defined in the same method in the parent class (the "views_handler_filter_numeric"-class) and remove the regex comparision from the array (let's say we don't need it in our case). You can also add your own operators by adding an additional array inside (just print out the contents of $operators and see how the parent class adds them). By actually removing the regex comparison we can see that the rest of the operators are calling the methods "op_simple" and "op_between" to do their filtering.
  • the field_count-method is just a helper function for our handler which uses a mix of mysql's LENGTH and REPLACE functions and returns a statement which will be turned into the number of words in a sentence when mysql evaluates it. This method is only here, because we need the same statement in both "op_simple" and "op_between" methods, so it's better store it separately.
  • the last part of our class is to override of the op_simple and op_between methods of the parent class. This is necessary because in the parent class those methods use the "add_where" method of the views_plugin_query_default class. Because we convert the title of the node into a numerical value and add those additional mysql-functions (LENGTH and REPLACE) in the process, we need to do the filtering through another method of the views_plugin_query_default-class called - the "add_where_expression". This method allows us to create more complex expressions so the mysql-functions we added can be evaluated also.

That should be it. You can now add this filter to the a views listing nodes and give it some parameters:

and that filter should work right away:

This is just an example, but it show the necessary steps to implement a filter in Views. Your filter would probably make way more sense, but the point here is made clear.

If you have additional ideas or find a bug or anything related please leave a comment. I'd be happy to read it. Thanks!

Tags: drupalviewsDrupal PlanetShare this: 
Categories: Elsewhere

DrupalCon Amsterdam: Why DrupalCon is More Important Than Ever

Thu, 10/07/2014 - 11:00

DrupalCon has always served as an important forum to discuss the status of the project as well as a great place to learn Drupal skills from the experts. But technology moves fast. It’s no longer sufficient to focus solely on today’s challenges. That’s why DrupalCon has evolved into a one-of-a-kind event to not only help attendees solve the problems they face today, but also plan for the future.

  • Insight: At every DrupalCon, Drupal founder and project lead Dries Buytaert and other project leaders have a conversation with the community about the future of Drupal. Each DrupalCon serves as a stake in the ground for the project on important issues that include release cycles, milestones, processes, and Drupal software improvements. Having access to this roadmap information is crucial for making your own decisions.
  • Drupal 8: The next release of Drupal is packed with more than 200 great improvements and will have something for everyone to love. There is also something for everyone to learn. Attending DrupalCon will give you access to the foremost Drupal 8 experts in the world and help make sure you are ready with Drupal 8 knowledge and skills when your clients and colleagues need you.
  • Relationships: DrupalCon is where fruitful relationships are ignited, nurtured and advanced. The event offers countless opportunities to meet face-to-face with the peers, companies and talent that will help you be successful now and in the future.

Attendance at DrupalCon events continues to grow. The importance of attending is growing as well. We hope to see you there!

Get Your Tickets

Categories: Elsewhere

NEWMEDIA: DrupalCamp Colorado: My "Crossing the Rubicon" Moment

Thu, 10/07/2014 - 05:36
DrupalCamp Colorado: My "Crossing the Rubicon" MomentContributing to and interacting with the Drupal community isn't as scary or as daunting as you might think. My advice—take the plunge by attending a local meetup or camp and be open to the many opportunities that will start presenting themselves. It worked for me! Here's my story...

Looking back at my Drupal career, I regret that it took me so long to transition from a bystander to an active participant. I had been building my first large Drupal site for approximately 6 months before I finally faced a bug that annoyed me enough to justify creating an account so I could file my first issue. Still, I was so afraid to look stupid in front my would-be-peers that I used a fake username (frankrizzo) in order to prevent people from being able to make the connection between me and my comments, questions, and requests. This fear was completely irrational, and yet it made me so uncomfortable that it prevented me from communicating with and contributing to the community in any meaningful way.

The only justification I can give for my behavior is that I was a fish out of water. When I started this journey, I turned in my lab coat and ended my career as an engineer (where I knew virtually everything there was to know about my field of training) and jumped head first into the world of immediate gratification known as web development (where I had little to no formal training). I also got it in my head that I was unique in this regard and everyone else had a much more linear career path. However, after being in this community for 5+ years, I've heard story after story about how varied our backgrounds are: journalists, lawyers, designers, MBAs, bicycle repairmen, weldors, librarians, and the list goes on. And while this self-realization has finally eliminated all remaining aspects of impostor syndrome from my psyche, I still regret that fear kept me working in a vacuum during my first 2 years as a Drupal developer.

DrupalCamp Colorado 2011

The turning point for me was when I first started attending meetups. While I still kept quiet (so as to not expose my ignorance), it was at these events where I finally started to learn more about other community events and the benefits of participation. And while it was a little outside of my comfort zone to attend a conference with over 400 people (none of which I new personally beyond a casual conversation), I decided it was finally time to go big or go home.

I'll spare all the gory details, but wanted to highlight three things that have forever changed my involvement within the Drupal Community (as well as open source in general):

  1. The keynote talk by Webchick title Getting Involved in the Drupal Community.
  2. A session by Rick Nashleanas titled The Client Perspective on Website Development and Operation.
  3. A conversation with Webchick, chx, Dave Reid and several other core contributors in the coder lounge.

Webchick's keynote hit home for me because she really focused on the variety of ways one could contribute as well as the value of each contribution (big and small). Until that point, I had this misconception in my head that I needed to be some super human developer (you know, like Dave Reid) in order to be heard or to have any impact at all. However, I left the talk realizing the value of something as simple as reviewing or testing a patch. This is when my itch to contribute started...

The interaction with Rick Nashleanas was inspiring in a different way. I was so moved by the overall thrust of his message that I wanted to see if there was a way to take it further to the rest of the community. I went to talk to him right after the presentation and he immediately invited me to a followup BoF (which was a foreign word to me). Five minutes later, we were sitting around a table and starting to make a game plan. Several months later, it was this conversation that ultimately led me to organizing the Drupal Means Business track at the Day Stage in DrupalCon Denver.

The coder lounge experience was simply surreal. Here sat many of the biggest names in the community and I was actively involved in a heated discussion about how to tweak the drupal.org homepage to best serve all the various user demographics hitting the site. I don't know why I was so shocked that I wasn't dismissed for being a newb. It was yet another case of a fearful imagination gone wild. The reality was were just a bunch of normal yet extremely inteligent and passionate individuals sitting around a table hashing through ways to make Drupal better. I will never forget that experience.

Reflecting on Personal Contributions

I have no delusions of grandeur that what I've been able to contribute matches (or will ever match) some of the heavy hitters in the community. That said, I'm proud of what I've been able to accomplish since 2011. Here are some of the highlights:

More important than the metrics is the hope that I've been able to (in even the smallest ways) inspire others along their Drupal career path to go from bystander to contributor. And then there is the question about whether or not I would have achieved even a fraction of these items had I not attended the camp and had the experiences I've just described. There's no way of knowing for sure (it was, after all, a point of no return) and I'm sure I would have become active eventually, but I'm confident that it was a pivotal event in my career path.

Takeway Message

With over 1 million registered Drupal.org accounts, you would think that contributing (even on the order of a single patch review) would be more commonplace. However, I also wonder if people are holding back out of fear. To anyone in that category looking to contribute in a meaningful way, my advice is simple—get to a camp! You simply never know who will be your Rick Nashleanas that inspires you to take things to the next level.

PS. A short plug for those interested in attending DrupalCamp Colorado 2014! We're only a few weeks away and we don't want you to miss out.

Categories: Elsewhere

Get Pantheon Blog: Drupal Development - "The Gizra Way"

Wed, 09/07/2014 - 23:19

Amitai Bustein is one of the founders of Gizra, a legendary Drupal contributor as maintainer of the Organic Groups (og) system, and gives amazing presentations. This is his BoF from DrupalCon Austin in which he explains "the Gizra way". It's a must-see for anyone dreaming of upgrading their development practices.

What's wonderful about Amitai's presentation is not just that it's entertaining and engaging, but that he's presenting hard-won real world experience with the best practices — automated testing, building with installation profiles, and so on. He makes these accessible and inspiring, and explains how these practices pay real-world dividends:

  • Standards, "code smell" is and why they matter.
  • How Harvard reduced the release cycle for OpenScholar from months to weeks with testing.
  • The practical benefits of agile processes and prioritizing "honest code" over formalities.
  • Dealing with deadlines and time estimates.

I've been personally quite impressed with Gizra's work over the years, and for developers looking to level up, or shop owners looking for inspiration and guidance on how to grow, this session is a goldmine. We hope you enjoy it!

Categories: Elsewhere

Phase2: It’s Almost Time for Capital Camp and Drupal Gov Days!

Wed, 09/07/2014 - 19:49

We could not be more excited that two of our favorite DC events – Capital Camp and Drupal 4 Gov – are merging! The combined event, happening July 30th through August 1st at the National Institutes of Health, promises to be one of the most informative and inspiring conferences on Drupal and  open source in government yet. Phase2 is proud to be a platinum sponsor of what is sure to be an action-packed conference in the nation’s capital, our hometown.

We’ve lined up 10 of our all-stars to present sessions at this year’s event (we told you we were excited!). Whether you’re interested in design, collaboration, or custom government solutions, we’ve got you covered. Here’s a sneak peek at our speaker roster…

content management solutions for government

Kick off your Capital Camp experience with a case study on How San Mateo County Is Raising the Bar with OpenPublic. Experience Director Shawn Mole and Program Director Felicia Haynes will discuss the technical challenges that San Mateo faced as a local government, and how they utilized Phase2’s Drupal distribution to overcome those obstacles. For more details on OpenPublic, catch OpenPublic 1.0: The Next Generation of Open Source Government Sites, presented by Shawn Mole and Greg Wilson, Director of Public Sector Practice at Phase2. Then learn how to create a “Sleep at Night CMS” with Senior Developer Randall Knutson.

 design and user experience

Necessary Capital Camp preparation: put these three sessions from Phase2’s front-end masterminds on your agenda. Start with Senior Developer Mason Wendell, who knows that great design, like jazz, needs both harmony and discord. His session, Thinking Inside the Box X3, will focus on component-driven design. Senior Designer Joey Groh will expose a real projects’ collaborative design process in his session, Collaborative Design to the Rescue: Photoshop in a post-Photoshop World. Finally, in his talk Amazing Design Through Empathy, Senior Experience Analyst David Spira will illustrate how to use empathy to improve all aspects of product design, from requirements gathering to user research and everything in between.

 collaboration

Drupal has already proven to be a viable alternative to proprietary models for government CMS. Now Open Atrium is helping Drupal provide government agencies with an enterprise grade, open source platform to connect teams, departments and constituents. Learn from Greg Wilson and Mike Potter, Open Atrium’s Lead Architect, how OA2 addresses government collaboration needs in their talk, Open Source Collaboration for Government with Open Atrium. For a story of true open source collaboration and innovation, check out Director of Engineering Steven Merrill’s session on OpenShift and Drupal.

configuration, testing and site building

In recent years, Open Data has evolved from a buzzword to a reality to a requirement for governments, NPOs and NGOs globally. To explore what Open Data is, how to use it, and what it means to your organization’s website and its followers, stop by Senior Developer Robert Bates’ session, Open Data: Not Just a Buzzword. For more advanced developers, Steven Merrill will present on Open Source Logging and Metrics Tools, in which he will dive into the logging infrastructure of drupal.org and how you can apply the same tooling to your own sites. Finally, learn Best Practices for Development, Deployment, and Distributions from Mike Potter.

Be sure to visit our exhibitor booth to learn more about Phase2 and our people,  and of course  to grab some infamous Phase2 swag!  Are you attending Capital Camp and Drupal Days? What sessions are on your must-see list? Let us know below!

Categories: Elsewhere

Pages