I recently had a client that began delegating access to all of its data assets across the enterprise network via OAuth, specifically the OAuth 2.0 protocol. While I was there architecting a Drupal solution as their new Web platform, they wanted me to to hook into this system to authenticate their Drupal users. Although there have been some modules available in the ecosystem to support OAuth2, there weren't any available to provide this functionality. So I created the OAuth2 Authentication module.
As I've been architecting Drupal solutions for almost ten years now, I've accumulated quite a bit of knowledge on devops best practices, which constitutes a sizeable amount of the consulting that I do. This includes documentation, configuration management, development processes and deployment processes. In this article, I'll be introducing Drupal Helpers, a collection of standard scripts and configurations that I use on all of my client projects (where applicable).
On October 15th, 2014, the highly critical SA-CORE-2014-005 - Drupal core - SQL injection vulnerability was announced. Shortly afterwards, research showed that sites not patched that same day could very well be compromised. Two weeks later, a public service announcement was released explaining the gravity of the situation. There was also a FAQ, a flowchart for dealing with it and a module that could potentially confirm a compromised site. Needless to say, it was a challenging time for the community.
Upgrading Drupal distributions, technically referred to as installation profiles, can be tricky. If you aren't using Drupal Core, but rather a distribution of it, it's not possible to follow standard processes for upgrading Drupal core and contributed modules. You must upgrade the distribution as a whole.
It is possible to expand compound search terms to multi-term synonyms. That is, if your Drupal site content contains text such as "dark room" or "key note", and you don't want your users to get No results pages on searches for "darkroom" or "keynote" (respectively), you'll need to do a bit of extra work to make this happen.
Drupal's strength as a content management framework is in its ability to effectively manage and display structured content through its Web user interface. However, the out-of-the-box system assumes all data is local (stored in the database). This can present challenges when attempting to integrate remote data stored in other systems. You cannot, by default, display non-local records as pages. While setting this up is in itself a challenge, it is an even bigger challenge to manipulate, aggregate and display this data through Views.
If you're interested in code quality and providing a means by which to bring Drupal beginners up-to-speed on the coding standards, I recommend reviewing code from all developers. I say "all" developers because everyone needs an editor.
When working with Drupal's language / locale components in code, we need to be aware of some issues to ensure that the multilingual subsystem works as we'd expect.
As great as Drupal 7 core can be, it doesn't scale well for Web sites with a lot of content and/or a lot of users. To make it perform better under these scenarios, it's necessary to make use of several strategies, tools and techniques.
Through my work as a Technical Architect, I recently did some DevOps consulting for client whose development process included steps to bundle all possible configuration changes though Features into a single feature. This bundling of all configurable data into a single Mega Feature was something they inherited from former consultants, who didn't bother to explain the ramifications of such an approach. It's a bad idea for several reasons.
