Drupal is an incredibly flexible and expressive CMS and development framework. As a developer, it allows you to express yourself quickly and easily. That being said, being able to do anything can be a little overwhelming.
Switching from .NET to Drupal 7 isn’t easy for most people. They take fundamentally different approaches to development that aren’t called out. There is also a surprising lack of articles and documentation on the subject. Two years ago I made the change to Drupal. I didn’t have anyone to help, so the transition was harsh. Developers not only struggle with the transition, but more importantly with the ability to adopt best practices. The end result is often unstable, and unmaintainable.
This is the first post in a series highlighting the differences between .NET and Drupal. The goal is to help you as a developer map concepts from .NET to Drupal and give you the foundation you need to be successful with Drupal. You’ll see that Drupal development is actually easy, robust, and a lot of fun.
Here are the top 5 ways that Drupal and .NET are different:
Framework Support
Drupal is a CMS but it’s also a development framework. Where .NET has an API for everything, Drupal has a lean core API, and a large ecosystem of open-source modules to provide extra functionality. This is where Drupal’s CMS background shines. Drupal has fully completed modules designed to meet business needs. There is a module for everything: modules for styling content on a page, displaying social content, and even translation. I cannot stress this point enough. There is a rich open source community in your corner backing you up. Modules keep you from reinventing the wheel and allow you to dramatically increase your development velocity.
While you have a clear API to follow with .NET or Java, Drupal requires a certain amount of tribal knowledge to build a real site. You need to be able to know which module meets your needs. It’s overwhelming at first. Here you are struggling to figure out Drupal core and at the same time, you have to figure out all these modules as well. It takes time, but eventually you start to get a feel for some of the basic modules to start with. (I recommend checking out Lightning for a curated list that we use here at Acquia. And posts on identifying, searching, and evaluating Drupal modules).
Different Approaches: OO vs. Procedural
In order to understand the chasm between .NET and Drupal it helps to understand the background and differences between C# and PHP.
C# is a descendant of C, C++, and Java. As such, C# has been around for a while and has a mature object model. PHP only added modern OO capabilities in PHP 5.0 (2005) and late static binding in PHP 5.3 (2009). PHP is a relative newcomer to the OO world.
The difference strongly influences code structure and coding practices in Drupal 7. A lot of PHP code in D7 is largely procedural. Some of the newer PHP code is OO but in D7 that’s the exception rather than the rule. This means that functions are not grouped together in small or medium understandable objects, or even namespaces. Most functions are defined in a global scope. Procedural code lacks the structure and aesthetic of OO code.
In an object-oriented world, a clear hierarchy of objects guides your development. When you are working in Java or ASP.NET, that object hierarchy can be reassuring. You can turn to it to tell you what to do. It is also listed in the API documentation, and you can drill down through it to understand what you need to do to effect change.
You can also always look at the object in a debugger to see all the methods and properties supported. The lack of object inheritance in procedural code makes it difficult to follow code and understand what is happening. In a procedural language you need to simply know the functions that are available to you. Since most functions are defined in global scope, they can be overwhelming!
Strong vs. Loose Typing
The other major difference is that C# is a strongly typed language and PHP is a loosely typed language. In strongly typed languages, such as C#, variables are declared with a type. In loosely typed languages, no type is required.
C#
string myVar = “This is a strongly typed declaration”;
PHP
$my_var = “This is a loosely typed declaration”;
One has a type and one doesn’t. So what’s the big deal? By looking at a variable declaration in C# you immediately know that it is storing a string. On the other hand, in PHP, you can only infer based on the right side of the declaration statement.
Here is a great example of the confusion this can lead to:
$my_var = node_load(123456);
What is the type of my_var? Without knowing what node_load returns you have no idea. This is represents a huge barrier to reading and understanding PHP code. I cannot stress this enough. Loose typing along with the fact that functions are defined in global scope means reading PHP code requires a much broader understanding than C#.
Why Is Everything an Array?
The combination of procedural code, lack of an object model, and loosely typing means that Drupal/PHP has to get creative when passing around bundles of information. It does this by creating infinitely nested dynamic arrays. Theses are incredibly powerful, flexible, and are core to Drupal’s ability to be customized to meet almost any need.
That being said, Drupal arrays can be hard to understand and follow. They are also largely undocumented and undocumentable. For a more in depth explanation see John Alban’s post on Drupal 7 and the Arrays of Doom.
So how do you work with these arrays? Most developers will either print them using the Devel module’s dpm or by using a PHP debug tool, such as PHPStorm. I’ll discuss both approaches more in depth in a later post. By poking around inside these structures you start to understand what’s going on and how to enact changes!
Code vs. Configuration
In Drupal, the distinction between code and config can be ambiguous. Since .NET is a framework not a CMS, there a clear line of demarcation between what is code and what is config stored in a database. In general items stored in the database represent content/user settings/config.
Drupal, on the other hand, is a CMS, one that is extremely customizable via the user interface. We call this site-building. In Drupal, you can build a new content type just as easily as you can create a new article. This flexibility and configurability are one of Drupal’s strengths. However, from a developer’s point of view, this makes things confusing. When do you need to write code? When do you need to do things via the GUI? The line between code and config is extremely blurry and often debated among Drupalistas. (We’ll cover this more in a later segment.)
Till Next time
No doubt, Drupal comes with its fair share of challenges, a few of which we just talked about. But those challenges are not insurmountable. At the end of the day, the things that can make Drupal tricky also contribute to its flexibility and power. These attributes have positioned Drupal as a CMS leader. I hope that mapping concepts from .NET to Drupal in this blog series will help make the transition smoother and easier for you.
In future blog posts, I’ll go into depth on some of the more granular elements of Drupal, such as working with hooks, modules, and Drupal core. Stay tuned.
