by Hernani Borges de Freitas
Part of my job in Acquia involves looking to some of the most complex Drupal sites in the world and analyze problems on them that might be known or not. When client hire us to perform a site audit, they want to understand what is wrong with their website, because of complains regarding maintenance, performance, operation or security. Other times, an audit is a way of guaranteeing that everything is running safe and the team is not wasting resources and time. I like to look to an audit as a normal checkup you need to do to your site in different periods of its life to guarantee that everything is fine and ready to the future.
In the next two blog posts I will resume a list of topics that we usually find problematic when we audit a website. I hope that helps you not following the same patterns and gives you a different perspective about your site, looking to each part of the process of building a Drupal site. This blog post is a resume of a talk I gave this year in Drupal Camps in Europe: you could have seen it in Porto, Portugal and in Oxford, UK.
Content is the first thing you need to think when planning a Drupal site. Having a strong content architecture facilitates building displays on your site, helps training your content editors and makes normal site operation easier to handle. There is also an important detail regarding the way you structure your content: increasing the number of content types and fields you create in your site also increases the memory needed to load and the time to process them.
Some common mistakes we found in site audits include:
- Creating several content types that are similar (news and articles, for instance) that are used exactly to the same purpose.
- Creating content types that are not used, having zero nodes.
- Creating fields that are not reused across content types.
- Modeling all the content as nodes, when there is information that do not need to use all the features, properties and hook of nodes. Drupal new entity system or custom tables make sometimes more sense than using nodes, for special cases.
When you finish modeling your content, you will be thinking about creating displays. Common ways of creating displays in Drupal include using views to query the information and display it; creating blocks and organize them in rich displays using context or panels, or customizing templates manually or using modules like display suite.
Here are some tips useful when creating new displays in Drupal:
- Views is one of the most awesome modules in Drupal: Use and abuse it. Creating single views with several displays to handle the same function is a really good idea as you can save work by cloning them. Use contextual filters to allow page listing about similar content that you can filter by a taxonomy term, for instance.
- Contexts/panels/displaysuite have different usages and they can be used to handle different situations. There is a really good discussion about this topic in last drupalcon munich that you can check, when in doubt.
- PHP code in blocks/nodes is almost always a bad idea. Even if seems to be an easy and fast path to develop a small functionality it is always problematic to detect and fix problems with it. Most of the times I suggest to my clients to disable PHP filter to avoid the temptation.
- Look to your blocks configuration and understand which ones are being rendered in different pages. If you are hiding regions in your code, but your blocks are set to render in all pages, they will render anyway and will consume extra resources.
When in doubt if you are following best practices regarding the way you are creating and changing the display of your site, think about simple questions:
- Understand how your pages are build. The less custom code that you have to handle it, probably means the less work you will have to maintain and upgrade the site in the future.
- Could you reuse some of your views and panels to change its behaviors with (contextual) filters, instead of having a single instance to different situations?
- How easy is it to switch theme in your website (for your mobile site, special occasions or redesigns)?
When you want to add more functionality to your site, you will start choosing contributed modules, write your own code and integrate your site with other platforms. This is one of the areas where we find more mistakes.
- Drupal has an incredible quantity of contributed modules (at the time I am writing this blog posts, we have in Drupal.org 18368 modules. Before writing your own custom module, search in drupal.org for a contributed module that can perform the same feature you are looking for. If you find a module that does something similar but misses a specific feature, maybe it would make sense to implement it and contribute it back as a patch to the original module. Searching and using standard contributed modules almost always pay off versus writing custom code that you will need to maintain and upgrade in the future. Unfortunately, I can describe you several stories of clients that opted to develop custom modules without knowing the existence of similar contributed modules.
- Be sure to use the right amount of modules. Usually complex websites use from 100-150 modules. If you are in the higher end of this range, verify that you really all those modules installed. The more modules you install the more resources your site will consume.
- Drupal core and its API already do a lot of things that are expected in a modern web framework. Before starting to implement some special logic that you used to do before using Drupal, or you saw in other frameworks, verify if that's not already implemented by Drupal core, API or in contributed modules
- Do not hack core or contributed modules. Ok if you really need to do it, document it! The best way to document changes to code is via patches that should be present in the site docroot to indicate the changes introduced. Patches allow other developers to understand changes and simplify the process of updating modules and reapply the changes. If you are working or leading a development team and you are unsure if your code was changed, hacked! module can help you understanding it, by comparing code that lives in Drupal.org with your own.
- When developing custom code be sure to follow Drupal coding standards. Coding standards help other developers to read your code and are usually a good hint that developers were familiar with coding in Drupal. When reading code, seeing code that is not following coding standards is usually the first signal that a module is going to have more serious problems. Coder module can help you analyze custom code and verify it follows Drupal coding standards.
Software architecture is something that does not only occur in the beginning of your project, but trough its lifetime. Be sure to revaluate your architecture every semester: changes occurred in your site or in Drupal world could have simplified what you thought for it at the beginning, so there is always a chance to improve.
In the next post I will look to problems regarding security, performance, infrastructure and maintenance. We will also look to a couple of nice tools that can help tracing some of the most common problems.