I've been a professional Drupal developer for over 6 years now. In that time, I've seen a wide variety of projects come across my desk. These days, a healthy portion of my day to day activity is being the technical sales person / solutions architect on sales calls, RFP responses, timelines, and estimates.
The point of this blog post came from me being a bit introspective. During the first couple of years as being a Drupal developer, I was learning Drupal core and spent a lot of time looking through the most popular contrib modules. So what happens after (you think) get a good handle on those things (Form API, DB Abstraction layer, when to write a custom module and when not to, point and click site building, etc)? In all of my sales experience and talking to hundereds of potential clients over the past few years, a few skill-sets / niches in Drupal keep coming up.
While I do think that there is a lot to be said for the Drupal core and general knowledge of the popular contributed modules, I have found that most projects that are brought my way have at least one of the following components.
Drupal Commerce or Ubercart. This is probably the biggest area. I'd estimate that 1 in 5 clients want e-commerce for their website. Back in my Drupal 6 development days, I was pretty good at hacking Ubercart and wrangling the pane system and telling my graphic designers, "No, you really shouldn't design a custom cart page." I'm not knocking Ubercart at all, it was truly a love / hate thing, but for 95% of what I was trying to build, it worked out okay in the end.
These days, I really like the robustness of Drupal Commerce, but the separation of the products/SKUs from the product display baffles a lot of customers, until you show them the front end of it, then they have the "AHAH!" moment. I think I remember something recently about Commerce Kickstart trying to combine these things or something, but haven't yet played around with newer versions of the Kickstart project.
There are some things that are directly related to e-commerce that if you are ever in an interview with me, you will get asked. Recurring payments is one of my favorites. When dealing with a site hosted e-commerce application, you also have to take into account SSL certificates (to enable secure checkout) and to get an SSL certificate, you have to have a dedicated IP address. What payment gateways have you worked with and have you ever written a custom one? If the client is using one of the big names, odds are there's a module for that (thank you contrib community!), otherwise, it's time to bust out the PHP IDE and get to writing a custom integration module.
Some potential clients come to us with an existing site that has a bunch of content they need migrated over. The migrate module is my personal tool of choice for doing this. Yeah, the feeds module will do a lot for you, but when the client has an active site (users, comments, forum posts, e-commerce transactions, etc) they need brought over, you'll need to get a snapshot of the data, do the data mapping to the respective Drupal fields / tables and then just before launch, you'll need to run the migration again to get the latest and greatest content. The migrate module is great when the data is a in a database or XML file, but what happens when it's not? Say the client has a 10 year old site that has hundreds or even thousands of .html files in various directories?
We've written some code on top of the migrate module called Flatfish. What does it do? It allows for you to specify CSS-style DOM selectors to go get content on a site in a specific CSS selector, and basically do copy and paste into the Drupal site for you programatically. Just mapping source to destination. This does require for your static site to be well structured and for your CSS selectors to make sense.
A lot of work goes into translating a Drupal site. There is a fair amount of setup needed, and then who is responsible for the actual translation of the content? I would typically point a potential customer to translations.com or equivelant. Could you just throw in Google Translate into the site? Sure, but that doesn't always provide the best translations.
The search module that comes with Drupal core isn't very robust. It's also not very good on performance. Apache Solr is what we typically use when you need things like faceted (filtered) search results and it's based on Java and therefore a lot better at scalability than core Drupal search is.
Search API allows one to leverage different search platforms. There's Solr, but there also things like Google Search Appliances. Faceted searches are more natural with large, well structured data sets, which is something that Views doesn't handle well at all. The facetapi allows you to customize the facet widgets pretty easily. Customizing the search results and indexed values is pretty common, too. Search API doesn't work with multi-lingual content, but the dedicated apachesolr module does.
Performance & Scalability
"My Drupal site is running slow" is a common complaint I get. I could really talk about this niche for hours. How much a month are you paying for hosting? If it's less than ten dollars a month, that's probably where I would start. Drupal requires a healthy amount of memory and CPU cycles, which you typically don't get a lot of either on cheaper, shared hosting environments. Some of the things I typically check are:
- Run the top command from the command line. What is killing your server? Apache, MySQL, something else
- Are you running APC?
- Have you considered setting up and installing Memcache?
- Are you using the Drupal caching mechanisms appropriately in /admin/config/development/performance
- Have you considered Varnish as a reverse proxy cache for anonymous users?
- Then I'll start looking at things like XHProf, and the slow query logs
In conclusion, I did want to thank the Drupal community. I would not be where I am now without attending a lot of local meetups, Drupal Camps, and DrupalCons and listening to some very talented speakers. It also helps to work side by side with other developers and have the organic conversations about issues you're facing in person.
There are certainly other skills that I would definitely consider really important for a professional Drupal developer, but these main buckets is what I get asked about most often.