Drupal 7 will Change how we Build and Use Websites

published by thomas on Wed, 06/09/2010 - 20:22

In my Reviewing 1st week with Nutshell on Drupal 7 post yesterday I talked about my experience using Drupal 7 to build a real live website. As a quick follow up today I want to go a little bit more into detail about what you can expect from the upcoming release.

What's in Core

Drupal 7 is a huge upgrade and the number of new features in core is massive. Listing them all would make a very long list. The most important, in my opinion so far, is Field API (CCK), Image Styles (ImageCache), Tokens, the new Admin UI, Update Management and RDFa.

Together with the numerous smaller changes and new features they will transform Drupal 7 into a very complete platform to build websites on. It will provide a much more robust foundation with less need to add numerous contributed modules.

Just to put some numbers on how big of a change this is, I have simply compared the sizes of the unpacked archives of Drupal version 6.17 (current official release) and the alpha 5 version of Drupal 7.

Drupal v6.17: 3.38MB
Drupal v7a5: 8.51MB

That is a staggering 5.13MB of code difference or more than 2.5 times larger. Not surprising there is a lot of new things to learn :)

Why move Contributed Modules to Core?

Moving contributed modules to core offers a lot of advantages. One is that API's will not change, providing consistency until the next major release. Developers then know exactly what to develop for and how. They also know what is available in every Drupal X installation.

Then why not put every popular module in core if that is such an advantage?

Everything can't be in core. This is especially important to understand based on that very few new, if any, features are added to core between major releases. Minor updates are almost exclusively limited to security and bug fixes.

Therefore the project leaders must make decisions about what is logical to add to core and what is not. Even if the module is very popular, moving it to core is not always the best option. Only if the module provides features that won't change over time it is logical to add it to core. If the module constantly needs to evolve, features are added or changed, then its better to leave it in contrib.

Sometimes its right to move part of a module to core. That was done with CCK and ImageCache for example. Most of their features, and API's, now lives in core. The parts that made it provides the framework, API's and basic features that a majority of users will need. The rest will be in a contributed module that will evolve over time.

What's not in Core

Even though it is possible to build a fully functional and almost complete website with Drupal 7 Core, you will still need contributed, or custom, modules

Some of the areas where this is needed, that I have found working on Nutshell, is:

SEO - You still need Pathauto and other SEO modules to optimise for search engines.
Social Sharing & Syndication - Besides RSS, core comes will few features to allow your visitors to for example share links to your site, follow on Twitter, etc.
Media Management & Embedding - Yes, this is much better in core now, but the parts about using the files such as embedding images in the body text is not there.
WYSIWYG - Nope, core does not come with a default WYSIWYG editor.
Views - Nope Views didn't make it either.

The above list is all features that more or less every modern website needs today and you can argue that they should have made it to core.

Why didn't they make core then?

As I wrote above, functionality that evolves constantly is not optimal to have in core. Most of the above examples provide such functionality.

Another reason for this, my own theory, is that these features are heavily dependent on a lot of what is new in Drupal 7. Especially this is true for media management and Views. They are tightly integrated with the Field and Image Styles API's.

Since they both provide the UI to those who are building the websites, as well as how it is presented to visitors, then I believe it was a good choice not to include them.

By letting them continue to live as contributed modules, they will be able to mature and become much better than if they had been in core and feature locked.

Until Drupal 8 they will be used, changed, added to by hundreds of thousands of developers, designers and users. Evolving as new web technology becomes available. This is especially true if you think about HTML5.

I am also sure that a lot of new ways of using them will be invented. It will be very exiting, that Iäm sure of.

As a contributed module this it possible to change their features, as a core module it would be almost impossible. The main option would be to create a new modules to replace their functionality.

Smaller, more Focused Modules

Another advantage by limiting it to the framework, API's and basic functionality, is that contributed and custom modules in most cases will be smaller and more focused. How many of us haven't looked at modules that has some nice features we want, but comes with a lot of other features that we don't want, or require other modules to work properly. Often also adds unwanted complexity to our sites.

This will still happen, but it will not happen as often as now.

Maintaining modules will also be much easier since the API's wont change. Another thing to like.

A more Uniformed UI

Another advantage I see with Drupal 7 is all the work that has gone to the UI design and user experience. Especially when it comes to providing a much better API framework. Many of these changes are completely new, but many are also inspired and taken from popular modules.

I have already noticed in discussions for certain contributed modules that they are planning to make changes to their UI's to conform with Drupal 7.

This will help everyone working with Drupal websites as everything is going to be much more uniformed and logical.