Last year I had the privilege of meeting Charlie Schliesser, a fellow developer here in St. Louis. Little did I know, a few months later we'd actually be working together quite a bit as I took a new position with my church which utilized the services of the company he worked for. Since that time, we've had several co-working sessions where we swap tips, talk about new technologies, get help with problems and leave inspired to do cool work. Each time we depart, I feel like I have a few more tools in my toolbox and I'm eager to share them. With that in mind, I'd like to start a series of posts that share what we learn. Feel free to leave comments, ask questions, or give feedback!

Entity_metadata_wrapper and Null Values

Are you a fan of entity_metadata_wrapper from the entity module? If you aren't, it's a great alternative to node_load()/entity_load() that gives you chain-able, localized, and sanitized (if requested) access to fields and properties of any entity. If you are hip to EMW, you've likely run into an issue where you try to access the value() of a field that isn't set on the object and EMW throws a nasty exception killing the page.

This often happens when looping through nodes where a non-required field is blank (i.e. $wrapper->field_middle_name->value()) and is quite frustrating. Before today, I'd try to avoid this issue by using field_get_items() or dumping the entity (using $wrapper->value()) and checking the value there. Thankfully, today I found a stackoverflow post that provided a pretty elegant alternative.

The Solution

Who knew that the good folks who created EMW implemented the magic method __isset() on the EntityMetadataWrapper class? Now, we can do something like this to check for set values:

Pretty neat huh?

The first point release of the Guardr distribution for Drupal was released last week. Though the Guardr node wasn't created until May 2012, the project actually started about 5 years ago. The product follows much of the history of Drupal - as a collaboration between many developers across multiple different shops. The reality is that the Guardr make file is just a way to organize a crap-load of work that was done in module contrib land.

I was faced with hardening Drupal beyond the built-in controls as part of a project for a Fortune 100 company. At the time, my thoughts were to turn Drupal from a social publishing platform into a business application. One of my project requirements was to conform to business practices that would limit users' sessions - to make sure when someone shared a login at work that it could only be used by one person at a time. Shared logins break a security principle of accountability. As long as users are sharing the same account, nobody can tell for sure who updated node content or changed site configuration. That's when I started committing patches to the Session Limit project.

The Drupal Security Report, updated recently in December 2013, enumerates how Drupal is secure by default and how each of the security points match to the OWASP Top 10 vulnerabilities for web applications. The mitigations for OWASP Top 10 items haven't changed substantially over the past 5 years in Drupal core.

Though Drupal's default configuration sends seemingly harmless information, Guardr goes an extra step - it checks for security updates by default. It seems odd that I should even have to tout that as a feature. Drupal tries to be helpful by displaying errors to the screen after the installation is complete.

Guardr's install profile disables displaying error reporting by default, silently logging them instead. You should be reviewing your logs regularly anyway. Every time Drupal has to log a PHP warning, a deprecated function, or Drupal nuance, it drags down your database and extends your page load times. Even if you mess up in a big way, Guardr hides fatal PHP errors, too.

Part of Drupal's history is as a social platform. Even though the forum module has always been a joke to usefulness, the default new user rules permit new user registration without administrator approval - again, something that Guardr locks down.

While LoginTobogan was a great introduction for usability improvement, allowing users to login using their email address is a security weakness. I recently just added my real email address to the footer of my blog. If I then also allowed anyone on the Internet to login using my email address, the evil they would also have half of the credentials needed to break into my account. Guardr removes usernames from the default outgoing email texts, then combines the Realname module to help keep login usernames private. If the attacker doesn't know the username or their password, they've really got a lot of username/password combination permutations to try. Think of it like a poor man's two-factor authentication.

The Internet has several lists of modules that make Drupal sites more secure, but it's things like the pairing of modules like Realname with the removal of usernames in outgoing core emails that's what makes Guardr stand out. It's the build script. Another example - the Remove Generator module removes the META tag that displays "Drupal 7" in the HTML source of every page, but Guardr's build also removes the CHANGELOG.txt file from the root directory, another easy vector for determining both the software and the version of CMS. Why give the vulnerability scanners and penetration testers the easy way out? Let them try some Wordpress vulnerabilities first so your web application firewall and intrusion detection system can flag them well before they get to specific Drupal version exploits.

Starting with Guardr takes away a bunch of the headaches for securing your site from the start. Imagine having a password policy in place that even forces UID 1 to have a reasonably secure password or which even denies UID 1 the ability to activate the PHP input filter. Run your code through version control, test it, review it, wrap it in accountability, tag it, and don't skip the proper workflow.

Guardr's configuration keeps enough logs that you can actually go back a few weeks to review what your users have been doing, who's accountable, and pin-point events at specific times. Role watchdog module helps you track down scenarios where a user gave themselves extra access through a role change, then removed the role later - it's logged.

All this configuration and the modules to go with it are maintained by people who have studied advanced security issues, who work for companies who pursue security-conscious customers, and have proven over several years to contribute back to the Drupal security co-op.

It's my opinion that starting with Guardr and using the modules therein, sway the balance of Drupal towards being more secure without burdening administrators and users with excess annoyances and overhead. It gives you tools for maintaining uptime, auditing for accountability, injecting countermeasures for attacks, and enforcing policies to make active countermeasures less necessary.

We continue to get busier and busier at the Association, and we want to make sure that you know everything we've been up to. Although we normally hold board meetings on Wednesdays, this month we'll be hosting our meeting on Thursday to accommodate some SXSW travel.

Suppose you're using taxomomy terms in exposed filters, and you want the resulting page to display one of the the terms as a title. Taxonomy term pages will give this to you very easily, but sometimes the taxonomy term page is not the right solution. Here's how you can display the taxonomy term as the title of your views page.

The first in a three part series of posts on "eCommerce for Manufacturers" from our Alex Salvador with Drupal Commerce Delivery Partner The Jibe

Manufacturing and wholesale is a neglected sector when it comes to optimizing for ecommerce. Most businesses use outdated online approaches to lead generation and sales in what is now a sophisticated digital retail environment. Simply providing product overviews and product order sheets online is no longer enough to make the sale. For the big, high-volume projects supplied by manufacturers, the efficiency of digital tools is invaluable.

Product Customization and Scalability

Manufacturing products, when applied to retail scenarios, often come in an extensive array of variations (sizes, colours, power, speed, etc). Using the Drupal Commerce back-end, each product can be configured for these unique variations using a bulk product creation interface. Product variants are streamlined into a manageable, single product page. This eliminates the need to scroll through an endless catalogue which we often see on older, less optimal sites.

Inventory Management

Drupal Commerce simplifies inventory management and speeds up product creation by providing mechanisms to display a single back-end product in a variety of contexts. In other words, it is easy to reuse a single product and to display it on its own independent product page and in product bundles - no duplication of products required.

Products that are often purchased together can be sold in a bundle as a single item. This is especially relevant to the manufacturing industry because many items have associated accessories. Bundles promote intelligent cross-sells. For example, recommending baseboards and moulding to sell with wood flooring.

Discounting

Another must have for large retailers is a flexible discounting system. Drupal Commerce uses rules to drive this functionality: website administrators can create a rule that will apply an arbitrary discount on products that match the criteria defined by the rule. For example: discount products tagged with "high performance" by 10%; or discount all products with a SKU starting with XYZ by $5. These rules allow retailers to provide bulk discounts on a large set of items, or on a very granular basis.

In conclusion, next level product customization has made manufacturing ecommerce an intuitive next step in streamlining sales systems.

Upcoming in our Ecommerce for Manufacturers series: Sales and Marketing.

In the previous articles in this series, we've focused on aspects of architecture, security and performance and the choice of infrastructure.

In the previous article I showed you how you can add menu items with wildcards to your menus in custom modules. Since then, however, I've been shown a cool module that allows to do similar things through the UI: Menu token.

Menu token allows you to define menu items that include tokens (provided by the Token module). These tokens get replaced on page load depending on the context or whatever rule you set when you created the menu. So let's take a look at how it works.

To install it, go through the normal module installation procedure. With Drush, this is simple:

drush dl menu_token token && drush en menu_token token

You'll notice that we also install the Token module as it is needed.

Before anything, navigate to admin/config/menu_token and check/uncheck the relevant boxes. These are basically the available entity types exposed by Menu Token.

Next, go to your menu and add a new link. You'll notice a new checkbox saying Use tokens in title and in path. Check that box and you'll get all the options for the token in that menu link.

Example #1: Current User ID

Let's see how we can create a menu link that goes to the user page of the currently logged in user.

1. Under Method for users, select User from context.
2. Best to also check the box Remove token if replacement is not present to avoid problems if the token is not available on a given page
3. Browse the available tokens and look for this one: [current-user:uid]. This is the token for the currently logged in user account ID.
4. Add your menu title and for the path specify: user/[current-user:uid].
5. Save

Now if you go somewhere your menu is visible, you'll notice a new link that leads to your user account page. Neat. We have't done anything that isn't already available in Drupal core, but still neat. The reason I'm saying this is that you can create a menu link with the path user/ that will lead the same place. But for illustrating the power of Menu Token, it's a good example.

Example #2: Current Node Type

Let's say you have a View that displays nodes of two different content types: Article and Basic Page. This View has a contextual filter to show nodes of the type article when the first parameter after the path to the view is article. And same for the Basic Page (with page being the machine name). The view path is nodes.

Let's create a menu link for the main menu that will link to this view and pass to the URL the content type of the currently viewed node.

1. Under Method for nodes, select Node from context.
2. Best to also check the box Remove token if replacement is not present to avoid problems if the token is not available on a given page
3. Browse the available tokens and look for this one: [node:content-type:machine-name]. This is the token for the currently loaded node content type.
4. Add you menu title and the following path: nodes/[node:content-type:machine-name]
5. Save

Now if you navigate to an article page, you'll notice in your main menu a new link to the following path: nodes/article. If you go to a Basic page, it'll be nodes/page. And clicking on these will of course take you to your View page with the filtering applied.

Conclusion

These are a couple of simple examples of how you might use Menu Token. Of course you can use it in other situations depending on what you need and what tokens are available.

Hope this helps.

While I'm not going to Drupalcon, missing my second 'con in a row, I am hoping to attend some regional camps this year:

Panopoly 1.2 released

We are pleased to announce that the Panopoly 1.2 release is now available on Drupal.org.. Once again, thank you to all those that contributed.

Deeson Online 2014 DrupalCamp London round up

Running from Friday February 28 to Sunday March 2, DrupalCamp London was the second largest DrupalCamp ever seen in Europe: Attended by over 600 people, it included a CxO day, over 30 sessions and Bofs, and high-caliber keynotes from organisations ranging from Cancer Research and Government Digital Service to Drupal Association and Acquia.

Drupal's growing up

The event itself had more of a DrupalCon feel than a Camp - emphasising the view that Drupal community is 'growing up', something that Associate Director at Drupal Association, Megan Sanicki, also hit home in her keynote. We were lucky enough to catch up with Megan where she expanded on topics covered in her speech.

Expanding the Drupal talent pool

Talent was also very much part of the focus of DrupalCamp London. This was not only reflected in the attendance of a group of Drupal Apprentices (above) who met with potential employees at a special Bof, but also with the inclusion of Eric Gaffen, Global Manager, Talent Acquisition at Acquia. Eric travelled over from Boston to be at the event, and in this great short video told us why nurturing great Drupal talent is important for the whole of the Drupal ecosystem.

Networking, sessions... and swag!

Deeson Online not only sponsored it, MD Tim Deeson was also one of the organisers. And as this Vine proves, was also king of networking...

Deeson Online Developer Annika Clarke gave a session entitled Introducing Demo Framework, a distribution that aims to make the process of pitching Drupal to new clients a lot easier, while Solutions Architect John Ennew delivered his session on concurrent programming in Drupal. We'll be putting up their well-attended presentations very soon - so watch this space.

But as is the case with anything vaguely Drupaly... it's the swag that people really love, and our We Are Smarter Than Me tees went down a storm again!

2014 DrupalCamp London definitely upped the game, and next year's event will no doubt build on the great foundations set down last weekend. We're looking forward to it already!

DrupalCamp London: Interview with Megan Sanicki

While at DrupalCamp London, we caught up with Associate Director at Drupal Association, Megan Sanicki, for a quick video interview.

In it Megan highlighted key elements from her keynote speech including how:

• Drupal Association is stepping up their mission to further the project and help expand the community
• They plan to grow from 3% to 10 % of the web
• They're investing £850k to improve Drupal.org including marketing to help people understand why they should adopt Drupal 8.

A call to action

In the video, Megan also emphasises that Drupal Association want to know how they can better serve the UK Drupal community - so tell them @drupalassoc or contact them via their website.

Megan's DrupalCamp London keynote

You can also see the slide deck from her DrupalCamp London keynote below. In it Megan shares in more detail the Association's vision and the programs being implemented to help make that happen.